【期間限定：無料公開】イラストで速攻理解IT入門 AWS

この記事について

初心者の方にも無理なく理解していただけるよう、学習の基礎となる内容をわかりやすく図で解説しています。
これからの学びを支える一助になれば幸いです。

著者：ライフハックゴリラ（x.com ⇒ @LifeHackGorilla）
経歴：システムエンジニア歴5年以上

企業でAI担当をしています。
Kindleで複数の書籍を出版しています。Xをフォローしていただくと見逃さずにすむかもしれません。

X ⇒ https://x.com/LifeHackGorilla

はじめに

システムエンジニアとしてAWSを基礎から実務レベルまで理解するための学習資料です。AWSはサービス数が多いため、最初からすべてのサービスを暗記しようとすると挫折しやすくなります。大切なのは、サービス名を覚えることではなく、何を解決するためのサービスなのかを理解することです。

AWSを学ぶときは、クラウドの考え方、アカウントとセキュリティ、ネットワーク、コンピューティング、ストレージ、データベース、公開構成、監視、コスト、IaC、設計評価の順に進めると理解しやすくなります。

AWSは、サーバーを借りる場所ではありません。アプリケーションを安全に、止まりにくく、拡張しやすく、運用しやすく作るための部品が集まったクラウド基盤です。

第1章 AWSとクラウドの全体像

1.1 AWSとは何か

AWSはAmazon Web Servicesの略です。サーバー、ストレージ、データベース、ネットワーク、セキュリティ、AI、分析、開発者ツールなどをインターネット経由で利用できるクラウドサービス群です。

従来は、システムを作るために物理サーバーを購入し、データセンターへ設置し、ネットワーク機器、電源、冷却、保守まで考える必要がありました。AWSでは、これらの多くをAWSが用意してくれるため、利用者は必要なリソースを必要な分だけ作成できます。

**AWSの本質は、ITインフラをコードや設定で素早く作成・変更・削除できることです。**これにより、システム開発のスピードが上がり、初期投資を抑えやすくなります。

1.2 クラウドコンピューティングとは何か

クラウドコンピューティングとは、サーバーやストレージなどのITリソースを、インターネット経由で必要なときに利用する仕組みです。自社で機器を買って持つのではなく、クラウド事業者が用意した巨大な基盤を利用します。

クラウドは、必要なときにすぐ使え、使った分に応じて料金が発生し、台数や容量を増減しやすいことが特徴です。たとえるなら、オンプレミスは自分で発電機を買って電気を作る方式、クラウドは電力会社から必要な分だけ電気を使う方式に近いです。

観点	オンプレミス	AWSクラウド
初期投資	機器購入が必要	小さく始めやすい
拡張	調達に時間がかかる	数分で増減しやすい
管理範囲	物理機器も管理	物理基盤はAWSが管理
コスト	固定費が中心	従量課金が中心
変更速度	手続きが重い	APIやIaCで変更しやすい

1.3 IaaS、PaaS、SaaS

IaaSはInfrastructure as a Serviceの略で、仮想サーバーやネットワークなどの基盤を提供する形態です。Amazon EC2は代表的なIaaSです。OSやミドルウェアの管理は利用者が行います。

PaaSはPlatform as a Serviceの略で、アプリケーションを動かすための実行環境を提供する形態です。AWS LambdaやAWS Elastic Beanstalkなどが近い考え方です。サーバー管理の負担を減らせます。

SaaSはSoftware as a Serviceの略で、完成したアプリケーションをサービスとして利用する形態です。利用者はインフラやアプリケーション実装を意識せず、機能を使います。

種類	利用者が主に管理するもの	AWSで近い例	特徴
IaaS	OS、ミドルウェア、アプリ	EC2	自由度が高い
PaaS	アプリ、設定	Lambda、Elastic Beanstalk	管理負担が少ない
SaaS	利用設定、データ	Amazon Qなど	すぐ使いやすい

1.4 従量課金と初期投資

AWSの多くのサービスは従量課金です。従量課金とは、利用した時間、容量、リクエスト数、データ転送量などに応じて料金が発生する仕組みです。

従量課金のメリットは、小さく始められることです。一方で、不要なリソースを放置すると料金が増えます。検証用に作成したEC2、NAT Gateway、RDS、EBSスナップショット、CloudWatch Logsなどは定期的に確認します。

AWSでは、作る力と同じくらい、消す力が重要です。

1.5 マネージドサービス

マネージドサービスとは、サーバーやソフトウェアの運用管理の一部をAWSが代わりに行うサービスです。Amazon RDSは、データベースエンジンのセットアップ、バックアップ、パッチ適用などを支援するマネージドデータベースです。

EC2上に自分でMySQLをインストールすることもできますが、その場合はOS、データベース、バックアップ、監視、障害対応を自分で設計します。RDSを使うと、これらの多くをAWSの機能として利用できます。

実務では、特別な理由がなければマネージドサービスを優先するのが基本です。

1.6 AWSの主要カテゴリ

AWSサービスは、コンピューティング、ストレージ、データベース、ネットワーク、セキュリティ、運用管理、開発者ツール、分析、AI/MLに分けると理解しやすくなります。

コンピューティング：EC2、Lambda、ECS、EKSなど、処理を実行するサービスです。
ストレージ：S3、EBS、EFSなど、データを保存するサービスです。
データベース：RDS、Aurora、DynamoDBなど、構造化されたデータを扱います。
ネットワーク：VPC、Route 53、CloudFront、ELBなど、通信を制御します。
セキュリティ：IAM、KMS、WAF、GuardDutyなど、権限や防御を担います。
運用管理：CloudWatch、CloudTrail、Config、Systems Managerなど、監視と管理を担います。

第2章 AWSの基本用語とサービス地図

2.1 サービスとリソース

AWSのサービスとは、EC2、S3、RDS、Lambdaのような機能のまとまりです。リソースとは、そのサービスを使って作成した具体的な実体です。

たとえば、EC2はサービス名で、起動した仮想サーバー1台はEC2インスタンスというリソースです。S3はサービス名で、作成したバケットや保存したオブジェクトがリソースです。

**AWSでは、サービス名とリソース名を区別して理解することが重要です。**料金、権限、監視、削除の対象になるのは、多くの場合リソースです。

2.2 リージョン、アベイラビリティゾーン、エッジロケーション

リージョンとは、AWSのデータセンター群が存在する地理的な地域です。東京リージョン、大阪リージョン、バージニア北部リージョンなどがあります。

アベイラビリティゾーンは、リージョン内にある独立したデータセンター群です。AZと略されます。1つのAZで障害が起きても、別のAZでシステムを動かせるように設計できます。

エッジロケーションとは、ユーザーに近い場所でコンテンツ配信や名前解決などを行う拠点です。CloudFrontやRoute 53などで使われます。

リージョンは場所、AZは障害に備える単位、エッジロケーションはユーザーに近づける単位と覚えると整理しやすいです。

2.3 グローバルサービスとリージョンサービス

AWSサービスには、グローバルサービスとリージョンサービスがあります。グローバルサービスは、特定リージョンだけに閉じないサービスです。IAMやRoute 53は代表例です。

リージョンサービスは、リソースを作成するリージョンを選ぶサービスです。EC2、RDS、VPC、Lambdaなどは基本的にリージョンを意識します。リソースが見つからないときは、まずリージョンを確認します。

2.4 ARN、アカウントID、リソースID

ARNはAmazon Resource Nameの略で、AWSリソースを一意に表す名前です。IAMポリシーやログで頻繁に登場します。

arn:aws:s3:::example-bucket
arn:aws:lambda:ap-northeast-1:123456789012:function:my-function

ARNは、AWS内での住所のようなものです。どのサービスの、どのリージョンの、どのアカウントの、どのリソースかを表します。

2.5 タグによる管理

タグは、AWSリソースに付けるキーと値のラベルです。たとえば、Environment=Production、Owner=AppTeam、Project=SalesSystemのように設定します。

タグは、検索、権限管理、コスト配分、運用自動化に使えます。実務では、タグがないと誰のリソースなのか、削除してよいのか、どのシステムの費用なのかが分からなくなります。

2.6 AWSを操作する方法

AWSの操作方法は、AWSマネジメントコンソール、AWS CLI、AWS SDK、IaCの4つです。初心者はコンソールで理解し、次にCLIで確認し、実務ではIaCで再現可能にする流れが効率的です。

aws sts get-caller-identity
aws ec2 describe-regions --all-regions

sts get-caller-identityは、現在どのAWS認証情報で操作しているかを確認する基本コマンドです。

2.7 可用性、耐久性、レイテンシー、スループット

可用性とは、システムが使える状態を維持できる度合いです。耐久性とは、保存したデータが失われにくい度合いです。レイテンシーとは、リクエストしてから応答が返るまでの遅延です。スループットとは、一定時間に処理できる量です。

Webサイトにたとえると、画面が開くまでの待ち時間がレイテンシーで、同時にどれだけ多くの利用者を処理できるかがスループットです。

2.8 認証、認可、監査、暗号化

認証とは、誰であるかを確認することです。認可とは、認証された利用者に何を許可するかを決めることです。監査とは、誰が、いつ、何をしたかを記録し、後から確認できるようにすることです。暗号化とは、データを第三者が読めない形式に変換することです。

セキュリティは、認証、認可、監査、暗号化の4つで考えると整理しやすいです。

第3章 AWSアカウント作成と安全な初期設定

3.1 ルートユーザーとIAMユーザー

ルートユーザーは、AWSアカウント作成時に作られる最上位のユーザーです。請求情報、アカウント解約、重要なセキュリティ設定など、非常に強い権限を持ちます。

IAMユーザーは、AWS Identity and Access Managementで作成する利用者です。通常の作業では、ルートユーザーを使わず、IAMユーザーやIAM Identity Centerを使います。

ルートユーザーは日常作業に使いません。金庫の鍵のように保管し、必要なときだけ使います。

3.2 MFAの必須化

MFAはMulti-Factor Authenticationの略で、多要素認証のことです。パスワードに加えて、認証アプリやセキュリティキーなど別の要素で本人確認します。

AWSアカウントでは、ルートユーザーに必ずMFAを設定します。管理者権限を持つユーザーにもMFAを設定します。パスワードだけの認証は、漏えいした瞬間に突破される可能性があるためです。

3.3 IAM Identity Center

IAM Identity Centerは、複数のAWSアカウントやアプリケーションへのアクセスを一元管理するサービスです。以前はAWS Single Sign-Onと呼ばれていました。

実務では、個別にIAMユーザーを大量作成するよりも、IAM Identity Centerで利用者と権限セットを管理する方が安全です。退職者や異動者のアクセス削除もしやすくなります。

3.4 予算アラートと請求アラート

AWSでは、リソースを作ると料金が発生します。学習環境でもNAT Gateway、RDS、EC2、EBS、CloudWatch Logsなどで料金が発生することがあります。

AWS Budgetsを使うと、月額予算を超えそうなときに通知できます。初心者は、最初に必ず予算アラートを設定します。

AWS学習の最初のハンズオンは、EC2作成ではなく予算アラート作成です。

3.5 無料利用枠の注意点

AWSには無料利用枠があります。ただし、すべてが無料になるわけではありません。無料枠の対象サービス、対象サイズ、対象期間、上限を超えた利用は課金されます。

また、無料利用枠の範囲でも、関連サービスで料金が発生する場合があります。EC2を停止しても、EBSボリュームが残っていると課金対象になる場合があります。

3.6 CloudTrailの初期有効化

CloudTrailは、AWSアカウント内で実行されたAPI操作を記録するサービスです。誰が、いつ、どのサービスに、どのような操作をしたかを追跡できます。

不正操作や誤操作の調査では、CloudTrailが非常に重要です。学習環境でも、本番環境でも、監査ログを残す習慣を持ちます。

3.7 AWS CLIとCloudShell

AWS CLIは、コマンドラインからAWSを操作するツールです。CloudShellは、ブラウザから利用できるAWS管理用のシェル環境です。

aws configure
aws sts get-caller-identity

アクセスキーをローカルPCに保存する場合は、取り扱いに注意します。実務では、IAM Identity Centerや一時認証情報、OIDCを使い、長期アクセスキーを減らす設計が望ましいです。

3.8 不要リソースの削除

AWSでは、リソース削除の確認が重要です。EC2を終了してもEBSスナップショットが残る、ALBを消してもターゲットグループが残る、CloudWatch Logsが残るなど、関連リソースが残ることがあります。

学習後は、EC2、EBS、Elastic IP、NAT Gateway、RDS、S3、Load Balancer、CloudWatch Logsを確認します。

第4章グローバルインフラとリージョン設計

4.1 リージョン選択の基準

リージョンは、システムを配置する地理的な単位です。リージョン選択では、利用者との距離、法規制、利用したいサービスの提供状況、コスト、障害対策を考えます。

日本の利用者向けサービスでは東京リージョンを選ぶことが多いです。西日本に災害対策拠点を置きたい場合、大阪リージョンも候補になります。

リージョンは近ければよいだけではありません。可用性、法務、コスト、サービス提供状況を含めて選びます。

4.2 アベイラビリティゾーンとマルチAZ

アベイラビリティゾーンは、リージョン内の独立した設備群です。AZ間は低遅延のネットワークで接続されています。

マルチAZとは、複数のAZにリソースを分散する構成です。1つのAZで障害が発生しても、別のAZでサービスを継続しやすくなります。

たとえば、Webサーバーを2つのAZに配置し、ALBで振り分ける構成にすると、片方のAZで障害が起きても、もう片方で応答できます。

4.3 Local Zones、Wavelength、Outposts

Local Zonesは、特定都市の近くで低遅延アプリケーションを動かすための拠点です。Wavelengthは、5Gネットワークに近い場所でアプリケーションを動かし、超低遅延を狙う仕組みです。

Outpostsは、AWSのインフラやサービスをオンプレミス環境に拡張するサービスです。法規制や低遅延要件でオンプレミスに機器を置きたい場合に使います。

4.4 RTOとRPO

RTOはRecovery Time Objectiveの略で、障害発生後にどれくらいの時間で復旧する必要があるかを表します。

RPOはRecovery Point Objectiveの略で、どれくらい前のデータまで失ってよいかを表します。

**RTOは時間の停止許容、RPOはデータ損失の許容です。**この2つはDR設計の出発点です。

4.5 DRの基本

DRはDisaster Recoveryの略で、災害復旧のことです。大規模障害、リージョン障害、人的ミス、ランサムウェアなどに備える設計です。

DR方式	復旧速度	コスト	概要
バックアップ＆リストア	遅い	低い	バックアップから復元する
パイロットライト	中程度	中程度	最小構成を常時用意する
ウォームスタンバイ	速い	高い	縮小版の本番環境を待機させる
アクティブ/アクティブ	非常に速い	非常に高い	複数環境で同時稼働する

復元できることを定期的に確認する復元テストが必要です。

第5章責任共有モデルとセキュリティ基礎

5.1 責任共有モデル

責任共有モデルとは、AWSと利用者がそれぞれどの範囲を守るかを分ける考え方です。AWSはクラウド基盤そのものを守り、利用者はクラウド上に作る設定やデータを守ります。

AWSは、データセンター、物理サーバー、ネットワーク設備、仮想化基盤などを管理します。一方、利用者はIAM権限、S3公開設定、OSパッチ、アプリケーション、データ暗号化、ログ確認などを担当します。

AWSを使うだけで安全になるのではなく、安全に設定して初めて安全になります。

5.2 サービスによって責任範囲は変わる

EC2では、利用者がOSの更新、ミドルウェア設定、セキュリティパッチ、ウイルス対策などを管理します。

RDSでは、データベースエンジンの管理やバックアップ機能の多くをAWSが支援します。ただし、パラメータ設定、アクセス制御、データ内容、接続元制限は利用者の責任です。

Lambdaでは、サーバー管理の負担はさらに小さくなります。ただし、実行ロール、コードの脆弱性、環境変数、入力検証は利用者が管理します。

5.3 最小権限

最小権限とは、利用者やサービスに必要最低限の権限だけを付与する考え方です。ログを読むだけの担当者に、EC2削除権限やIAM変更権限を与えるべきではありません。

最小権限は、事故の影響範囲を小さくします。権限が強すぎると、誤操作や不正利用による被害が大きくなります。

5.4 多層防御

多層防御とは、1つの防御策に依存せず、複数の防御を重ねる考え方です。WAF、ALB、セキュリティグループ、IAM、KMS、CloudTrail、CloudWatchを組み合わせます。

どれか1つが破られても、次の防御で止める設計が大切です。

5.5 暗号化と監査ログ

暗号化には、保存時の暗号化と通信時の暗号化があります。保存時の暗号化は、S3やEBS、RDSに保存されたデータを暗号化することです。通信時の暗号化は、HTTPSやTLSで通信内容を保護することです。

監査ログは、操作履歴を後から確認するための記録です。AWSではCloudTrailが中心になります。ログがないと、原因調査も再発防止も困難になります。

第6章 IAMを絶対に理解する

6.1 IAMとは何か

IAMはIdentity and Access Managementの略で、AWSにおける認証と認可を管理するサービスです。誰がAWSへアクセスできるか、その人やサービスが何をできるかを決めます。

IAMはAWS学習の最重要項目です。IAMを理解しないままAWSを使うと、権限エラーで作業が止まるだけでなく、過剰権限による事故につながります。

6.2 認証と認可

認証は、アクセスしている相手が誰かを確認することです。認可は、認証された相手に何を許可するかを決めることです。

たとえるなら、認証は会社の入口で社員証を確認すること、認可はその社員がどの部屋に入れるかを決めることです。

6.3 IAMユーザー、グループ、ロール

IAMユーザーは、人やアプリケーションに対応する個別のIDです。IAMグループは、複数のIAMユーザーに同じ権限を付けるためのまとまりです。IAMロールは、一時的に引き受ける権限です。

人にはユーザーまたはIdentity Center、AWSサービスにはロール、という考え方が基本です。

6.4 IAMポリシー

IAMポリシーは、どの操作をどのリソースに対して許可または拒否するかをJSONで書いたものです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

Effectは許可か拒否を表します。Actionは操作内容です。Resourceは対象リソースです。Conditionを使うと、条件付きで許可できます。

6.5 デフォルトDeny、明示的Allow、明示的Deny

AWSの権限評価では、基本的に何も許可されていなければ拒否されます。これをデフォルトDenyまたは暗黙的Denyと呼びます。

操作を許可するには、ポリシーで明示的にAllowする必要があります。ただし、どこかに明示的Denyがある場合、AllowよりもDenyが優先されます。

何も書いていない：拒否
Allowがある：許可候補
Denyがある：必ず拒否

IAMの権限評価では、明示的Denyが最強です。

6.6 アイデンティティベースポリシーとリソースベースポリシー

アイデンティティベースポリシーは、IAMユーザー、グループ、ロールに付けるポリシーです。リソースベースポリシーは、S3バケットやSQSキュー、KMSキーなど、リソース側に付けるポリシーです。

プリンシパルとは、AWSへリクエストを行う主体です。IAMユーザー、IAMロール、AWSサービス、別アカウントなどが該当します。

6.7 信頼ポリシー

信頼ポリシーは、IAMロールを誰が引き受けられるかを定義するポリシーです。ロールには、権限ポリシーと信頼ポリシーがあります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

sts:AssumeRoleは、ロールを引き受けるための操作です。

6.8 パーミッションバウンダリーとSCP

パーミッションバウンダリーは、IAMユーザーやロールに設定する権限の上限です。SCPはService Control Policyの略で、AWS Organizationsで使うアカウント全体の権限上限です。

たとえるなら、IAMポリシーは社員への作業許可、パーミッションバウンダリーはその社員の職務上限、SCPは会社全体の禁止ルールです。

6.9 EC2ロールとLambda実行ロール

EC2からS3へアクセスするとき、アクセスキーをEC2内に保存するのは危険です。代わりにEC2にIAMロールを付与します。Lambda実行ロールは、Lambda関数がAWSサービスへアクセスするためのロールです。

AWSサービスからAWSサービスへアクセスするときは、長期アクセスキーではなくIAMロールを使います。

6.10 クロスアカウントロールとAccess Analyzer

クロスアカウントロールは、別のAWSアカウントからロールを引き受ける仕組みです。監査アカウントから本番アカウントを参照する、CI/CDアカウントから開発アカウントへデプロイするなどの用途で使います。

IAM Access Analyzerは、外部からアクセス可能なリソースや過剰な権限を検出するためのサービスです。IAMは一度設定して終わりではなく、定期的に権限を見直します。

第7章 VPCとネットワーク基礎

7.1 VPCとは何か

VPCはVirtual Private Cloudの略で、AWS上に作る論理的に隔離された仮想ネットワークです。EC2、RDS、ECSなど多くのリソースはVPC内に配置します。

VPCはAWSネットワークの土台です。VPCを理解すると、EC2、RDS、ALB、ECSの構成が一気に理解しやすくなります。

7.2 CIDR、IPv4、IPv6

CIDRはClassless Inter-Domain Routingの略で、IPアドレス範囲を表す記法です。たとえば10.0.0.0/16は、10.0.0.0から始まる大きなIP範囲を表します。

IPv4は、192.168.1.10のような形式のIPアドレスです。IPv6は、より広いアドレス空間を持つ新しい形式です。

7.3 パブリックIPとプライベートIP

パブリックIPは、インターネットから到達可能なIPアドレスです。プライベートIPは、VPC内など閉じたネットワークで使うIPアドレスです。

DBサーバーにパブリックIPを付けるのは危険です。通常、RDSなどのデータベースはプライベートサブネットに配置し、アプリケーションからのみ接続させます。

7.4 サブネット

サブネットは、VPCのIPアドレス範囲を分割したものです。サブネットは1つのAZに属します。

パブリックサブネットは、インターネットへ直接出入りできる経路を持つサブネットです。プライベートサブネットは、インターネットから直接到達できないサブネットです。

7.5 ルートテーブルとInternet Gateway

ルートテーブルは、通信をどこへ送るかを決める表です。Internet Gatewayは、VPCとインターネットを接続するためのゲートウェイです。

パブリックサブネットにするには、ルートテーブルに0.0.0.0/0 -> Internet Gatewayのような経路を設定します。0.0.0.0/0は、すべてのIPv4宛先を意味します。

7.6 NAT Gateway

NAT Gatewayは、プライベートサブネット内のリソースがインターネットへ出ていくためのサービスです。インターネットからプライベートサブネットへ直接入ってくる通信は許可しません。

NAT Gatewayは便利ですが、時間課金とデータ処理課金があります。検証環境で放置するとコストが増えやすいサービスです。

7.7 セキュリティグループとネットワークACL

セキュリティグループは、EC2やRDSなどのリソースに付ける仮想ファイアウォールです。許可ルールだけを書きます。状態を持つため、戻り通信は自動的に許可されます。

ネットワークACLは、サブネット単位で設定するファイアウォールです。許可と拒否の両方を書けます。状態を持たないため、戻り通信も明示的に考える必要があります。

項目	セキュリティグループ	ネットワークACL
適用単位	リソース単位	サブネット単位
ルール	Allow中心	AllowとDeny
状態	ステートフル	ステートレス
主な用途	通信制御の中心	補助的な境界防御

7.8 VPCエンドポイントとPrivateLink

VPCエンドポイントは、インターネットを経由せずにVPCからAWSサービスへ接続する仕組みです。S3やDynamoDBにはゲートウェイエンドポイント、他の多くのサービスにはインターフェイスエンドポイントを使います。

PrivateLinkは、インターフェイスエンドポイントを使って、プライベートにサービスへ接続する仕組みです。

7.9 DNS、VPC Flow Logs、Reachability Analyzer

DNSはDomain Name Systemの略で、ドメイン名をIPアドレスに変換する仕組みです。Route 53 Resolverは、VPC内外の名前解決を扱うサービスです。

VPC Flow Logsは、VPC内のネットワークインターフェイスを通る通信のメタ情報を記録する機能です。Reachability Analyzerは、送信元から送信先までネットワーク的に到達可能かを分析するサービスです。

第8章ネットワーク実務設計

8.1 3層ネットワーク

3層ネットワークは、Web層、アプリケーション層、データベース層に分ける設計です。Web層は外部からの入口、アプリケーション層は業務処理、データベース層はデータ保存を担当します。

AWSでは、ALBをパブリックサブネットに配置し、ECSやEC2をプライベートサブネットに配置し、RDSをさらに制限されたプライベートサブネットに配置する構成がよく使われます。

外部公開するものを最小限にし、内部リソースはプライベートに置くことが基本です。

8.2 マルチAZサブネット設計

本番環境では、少なくとも2つのAZにサブネットを作成します。パブリックサブネット、アプリケーション用プライベートサブネット、DB用プライベートサブネットを各AZに用意すると、障害に強い構成になります。

Public Subnet A、Public Subnet C
App Private Subnet A、App Private Subnet C
DB Private Subnet A、DB Private Subnet C

8.3 ALB配置

ALBはApplication Load Balancerの略で、HTTP/HTTPS通信を複数のターゲットへ振り分けるロードバランサーです。ALBは通常、複数のパブリックサブネットに配置します。

ALBのセキュリティグループでは、インターネットからのHTTPSを許可し、アプリケーション側のセキュリティグループでは、ALBからの通信だけを許可します。

8.4 NAT Gateway配置

NAT GatewayはAZごとに配置するのが可用性の観点では望ましいです。ただし、コストが増えます。

本番環境では各AZにNAT Gatewayを配置し、各プライベートサブネットから同じAZのNAT Gatewayへ出るようにします。開発環境ではコストを抑えるために1台だけにする場合もあります。

可用性とコストは常にトレードオフです。環境ごとに判断します。

8.5 VPCエンドポイントによるS3接続

プライベートサブネットからS3へアクセスする場合、NAT Gateway経由にするとコストが増えることがあります。S3ゲートウェイエンドポイントを使うと、VPC内からS3へプライベートに接続できます。

8.6 踏み台サーバーとSession Manager

踏み台サーバーは、プライベートサブネット内のサーバーへ接続するための中継サーバーです。ただし、踏み台サーバー自体の管理やSSH鍵の管理が必要になります。

Session ManagerはSystems Managerの機能で、SSHポートを開けずにEC2へ接続できます。IAMで接続権限を制御でき、操作ログも残しやすくなります。

8.7 オンプレミス接続

オンプレミスとAWSを接続する方法には、Site-to-Site VPN、Client VPN、Direct Connectがあります。Transit Gatewayは、複数VPCやVPN、Direct Connectを集約するハブです。

8.8 ネットワーク障害の切り分け

通信できない場合は、送信元と送信先のIP、ポート、プロトコルを確認し、セキュリティグループ、NACL、ルートテーブル、DNS、アプリケーションの待ち受けを順番に確認します。

ネットワーク障害は、感覚ではなく経路を1つずつ確認します。

第9章 EC2と仮想サーバー

9.1 EC2とは何か

EC2はElastic Compute Cloudの略で、AWS上で仮想サーバーを起動するサービスです。OS、CPU、メモリ、ストレージ、ネットワークを選んでサーバーを作成できます。

EC2は自由度が高く、既存アプリケーションの移行や細かい設定が必要な用途に向いています。一方で、OSパッチやミドルウェア管理などの運用負担があります。

9.2 AMIとインスタンスタイプ

AMIはAmazon Machine Imageの略で、EC2を起動するためのテンプレートです。OSや初期ソフトウェアが含まれます。

インスタンスタイプは、CPU、メモリ、ネットワーク性能などの組み合わせです。CPU重視ならC系、メモリ重視ならR系、汎用ならM系やT系など、用途に応じて選びます。

9.3 キーペア、SSH、RDP、Session Manager

キーペアは、EC2へSSH接続するための公開鍵と秘密鍵の組み合わせです。LinuxではSSH、WindowsではRDPを使うことが多いです。

鍵ファイルの漏えいは重大事故につながります。可能であればSession Managerを使い、SSHポートを開けない運用にします。

9.4 EBSとインスタンスストア

EBSはElastic Block Storeの略で、EC2に接続するブロックストレージです。EC2を停止してもデータを保持できます。

インスタンスストアは、インスタンスに物理的に接続された一時ストレージです。高速ですが、停止や終了でデータが失われる場合があります。

9.5 ユーザーデータ

ユーザーデータは、EC2起動時に実行するスクリプトです。初回起動時にWebサーバーをインストールするなどの初期設定に使います。

#!/bin/bash
dnf update -y
dnf install -y nginx
systemctl enable nginx
systemctl start nginx
echo "Hello AWS" > /usr/share/nginx/html/index.html

ユーザーデータを使うと、手作業を減らし、同じ設定のサーバーを再現しやすくなります。

9.6 Auto Scaling Group

Auto Scaling Groupは、EC2インスタンス数を自動で増減する仕組みです。負荷が高いときに増やし、低いときに減らせます。また、異常なインスタンスを置き換えることもできます。

9.7 Systems Managerとパッチ管理

Systems Managerは、EC2やオンプレミスサーバーを管理するサービス群です。Session Manager、Run Command、Patch Managerなどがあります。

Patch Managerを使うと、OSパッチ適用を自動化できます。EC2を使う場合、OS管理は利用者の責任なので、パッチ運用を設計に含めます。

9.8 Spot、Savings Plans、Reserved Instances

Spot Instancesは、AWSの余剰キャパシティを安く使う仕組みです。ただし、中断される可能性があります。Savings PlansとReserved Instancesは、長期利用を前提に料金を下げる仕組みです。

9.9 EC2のアンチパターン

EC2に何でも入れる構成は、最初は簡単ですが、運用が重くなりやすいです。ログ、バックアップ、スケーリング、パッチ、障害復旧をすべて考える必要があります。

新規開発では、RDS、S3、Lambda、ECSなどのマネージドサービスを組み合わせ、EC2の管理範囲を減らすことを検討します。

第10章ストレージ：S3、EBS、EFS、FSx、Backup

10.1 ストレージの種類

AWSのストレージは、オブジェクトストレージ、ブロックストレージ、ファイルストレージに分けると理解しやすいです。

種類	代表サービス	主な用途
オブジェクトストレージ	S3	ファイル、ログ、画像、バックアップ、データレイク
ブロックストレージ	EBS	EC2のディスク
ファイルストレージ	EFS、FSx	複数サーバーで共有するファイルシステム

10.2 Amazon S3

S3はSimple Storage Serviceの略で、オブジェクトストレージサービスです。大量のファイル、バックアップ、ログ、画像、動画、データレイクなどに使います。

aws s3 mb s3://example-learning-bucket
aws s3 cp ./sample.txt s3://example-learning-bucket/sample.txt
aws s3 ls s3://example-learning-bucket/

10.3 S3ストレージクラス

S3ストレージクラスは、アクセス頻度や復元時間に応じてコストを最適化するための保存クラスです。頻繁にアクセスするデータにはS3 Standard、アクセス頻度が低いデータにはStandard-IA、長期保管にはGlacier系のクラスを検討します。

ライフサイクルルールを使うと、一定期間後にストレージクラスを変更したり、古いオブジェクトを削除したりできます。

10.4 バージョニング、レプリケーション、暗号化

バージョニングは、同じキーのオブジェクトを複数世代で保存する機能です。誤削除や誤更新から復旧しやすくなります。

レプリケーションは、別バケットや別リージョンへオブジェクトを複製する機能です。DRやコンプライアンス目的で使います。

S3では保存時暗号化を有効化できます。SSE-S3、SSE-KMSなどの方式があります。

10.5 パブリックアクセスブロックとバケットポリシー

S3の公開設定ミスは重大な情報漏えいにつながります。パブリックアクセスブロックは、意図しない公開を防ぐ重要な機能です。

バケットポリシーは、バケットに対するアクセス制御をJSONで定義するリソースベースポリシーです。

S3は便利ですが、公開設定を誤ると危険です。原則は非公開です。

10.6 署名付きURLと静的Webサイトホスティング

署名付きURLは、一定時間だけS3オブジェクトへアクセスできるURLです。非公開ファイルを一時的に配布するときに使います。

静的Webサイトホスティングは、S3バケットを使ってHTML、CSS、JavaScriptなどの静的サイトを公開する機能です。HTTPSや独自ドメインを使う場合はCloudFrontやACMと組み合わせるのが一般的です。

10.7 EBS、EFS、FSx、AWS Backup

EBSはEC2に接続するブロックストレージです。EBSスナップショットは、EBSボリュームのバックアップです。

EFSはLinux向けの共有ファイルストレージです。FSxは、用途別の高機能ファイルストレージです。

AWS Backupは、複数のAWSサービスのバックアップを一元管理するサービスです。復元できることまで確認して初めてバックアップです。

第11章データベース：RDS、Aurora、DynamoDB

11.1 RDBとNoSQL

RDBはRelational Databaseの略で、テーブル、行、列、SQLを使ってデータを扱うデータベースです。NoSQLは、RDBとは異なる柔軟なデータモデルを持つデータベースの総称です。

観点	RDB	NoSQL
代表サービス	RDS、Aurora	DynamoDB
得意な処理	複雑な検索、結合、トランザクション	高スケールな読み書き、単純なアクセス
設計の起点	正規化、SQL	アクセスパターン、キー設計
注意点	スケール設計	キー設計の失敗

11.2 Amazon RDS

RDSはRelational Database Serviceの略で、マネージドなリレーショナルデータベースです。MySQL、PostgreSQL、MariaDB、Oracle、SQL Serverなどを利用できます。

RDSでは、DBインスタンス、DBサブネットグループ、パラメータグループ、オプショングループ、セキュリティグループを理解します。通常、RDSは複数AZのプライベートサブネットに配置します。

11.3 バックアップ、スナップショット、マルチAZ

RDSの自動バックアップは、指定した保持期間内でポイントインタイムリカバリを可能にします。ポイントインタイムリカバリとは、特定時刻の状態へ戻すことです。

マルチAZは、スタンバイDBを別AZに用意し、障害時にフェイルオーバーする構成です。フェイルオーバーとは、障害時に待機系へ切り替えることです。

11.4 リードレプリカ

リードレプリカは、読み取り負荷を分散するための複製DBです。検索やレポート処理など、読み取りが多いシステムで使います。

マルチAZは可用性向上、リードレプリカは主に読み取り性能向上のための機能です。

11.5 Amazon Aurora

Auroraは、AWSがクラウド向けに設計したリレーショナルデータベースです。MySQL互換とPostgreSQL互換があります。

Auroraは、ストレージが分散され、高い可用性と性能を目指した設計です。Aurora Serverlessを使うと、需要に応じて容量を自動調整しやすくなります。

11.6 DynamoDB

DynamoDBは、フルマネージドなNoSQLデータベースです。高いスケーラビリティと低レイテンシーを必要とする用途に向いています。

DynamoDBでは、テーブル、項目、属性、パーティションキー、ソートキーを理解します。パーティションキーはデータの分散と検索の基本になるキーです。ソートキーは、同じパーティションキー内でデータを並べたり範囲検索したりするためのキーです。

11.7 GSIとLSI

GSIはGlobal Secondary Indexの略で、別のキーで検索できるようにするインデックスです。LSIはLocal Secondary Indexの略で、同じパーティションキーを使いながら別のソートキーで検索するインデックスです。

DynamoDBでは、後から自由にSQL検索するのではなく、最初にアクセスパターンを決めてキー設計します。

11.8 オンデマンドとプロビジョンド

オンデマンドモードは、リクエスト量に応じて自動的に処理能力が調整される課金方式です。予測しにくい負荷に向いています。

プロビジョンドモードは、読み書きキャパシティをあらかじめ設定する方式です。負荷が予測できる場合にコストを抑えやすいです。

11.9 周辺データベースサービス

ElastiCacheは、RedisやMemcached互換のキャッシュサービスです。DocumentDBはMongoDB互換のドキュメントデータベースです。Neptuneはグラフデータベースです。Redshiftはデータウェアハウスです。Timestreamは時系列データベースです。OpenSearch Serviceは検索とログ分析に使います。

第12章 ELB、Route 53、CloudFront、ACMで公開する

12.1 DNSとRoute 53

DNSは、ドメイン名をIPアドレスなどに変換する仕組みです。Route 53は、AWSのDNSサービスです。

ホストゾーンは、ドメインのDNSレコードを管理する入れ物です。Aレコードは名前をIPv4アドレスへ対応させ、CNAMEは別名を設定します。Aliasレコードは、ALBやCloudFrontなどAWSリソースへ名前を向けるときに便利です。

12.2 ルーティングポリシー

Route 53のルーティングポリシーを使うと、単純な名前解決だけでなく、加重ルーティング、レイテンシーベースルーティング、フェイルオーバールーティングなどができます。

12.3 ACMとTLS証明書

ACMはAWS Certificate Managerの略で、TLS証明書を管理するサービスです。TLS証明書は、HTTPS通信でサーバーの正当性を証明し、通信を暗号化するために使います。

12.4 ELB、ALB、NLB

ELBはElastic Load Balancingの総称です。通信を複数のターゲットへ分散します。

種類	主な用途	特徴
ALB	HTTP/HTTPS	パスやホスト名で振り分けできる
NLB	TCP/UDP	高性能で固定IPが必要な用途にも使える
CLB	旧世代	新規では基本的にALB/NLBを検討する

ターゲットグループは、ALBやNLBが通信を振り分ける先のまとまりです。ヘルスチェックにより、異常なターゲットへ通信を流さないようにできます。

12.5 CloudFrontとCDN

CloudFrontは、AWSのCDNサービスです。CDNはContent Delivery Networkの略で、ユーザーに近いエッジロケーションからコンテンツを配信し、表示速度や可用性を高める仕組みです。

CloudFrontの配信元をオリジンと呼びます。S3、ALB、EC2、カスタムサーバーなどをオリジンにできます。キャッシュを使うと、同じコンテンツへのアクセスを高速化し、オリジンへの負荷を減らせます。

12.6 OACと署名付きURL

OACはOrigin Access Controlの略で、CloudFrontからS3オリジンへ安全にアクセスするための仕組みです。S3を直接公開せず、CloudFront経由だけで配信できます。

署名付きURLは、一定条件や一定時間だけアクセスできるURLです。有料コンテンツや限定配布に使えます。

12.7 WAFとShield

WAFはWeb Application Firewallの略で、SQLインジェクションやクロスサイトスクリプティングなどのWeb攻撃を検出・遮断するサービスです。

ShieldはDDoS攻撃から保護するサービスです。DDoSはDistributed Denial of Serviceの略で、大量の通信でサービスを妨害する攻撃です。

第13章可用性、スケーリング、耐障害性

13.1 可用性と単一障害点

可用性は、システムが利用可能な状態を維持する度合いです。単一障害点は、そこが壊れるとシステム全体が止まる箇所です。

EC2が1台だけ、DBが1台だけ、特定AZだけに配置、手動復旧が必要、といった構成は単一障害点になりやすいです。

止めたくないシステムでは、単一障害点を見つけて減らすことが基本です。

13.2 スケールアップとスケールアウト

スケールアップは、サーバーをより高性能なものに変更する方法です。スケールアウトは、サーバー台数を増やす方法です。

クラウドでは、スケールアウトしやすい設計が重要です。そのためには、アプリケーションをステートレスに近づけます。

13.3 ステートレス設計とセッション管理

ステートレスとは、サーバーが利用者ごとの状態を持たない設計です。どのサーバーにリクエストが届いても同じように処理できます。

セッション情報を各EC2のメモリに持つと、別のEC2へ振り分けられたときにログイン状態が失われることがあります。セッションはElastiCacheやDynamoDBなど外部ストアに持たせるとスケールしやすくなります。

13.4 キューによる疎結合

キューは、処理待ちのメッセージを一時的にためる仕組みです。SQSを使うと、急激なアクセス増加や処理遅延を吸収できます。

注文受付処理でメール送信や在庫更新を同期的にすべて行うと、どこかが遅いだけで注文受付が遅くなります。SQSにメッセージを入れ、後続処理を非同期化すると、受付処理を安定させやすくなります。

13.5 バックアップ戦略とDR戦略

バックアップは、データを復旧するための基本です。RDSスナップショット、S3バージョニング、EBSスナップショット、AWS Backupなどを使います。

DR戦略では、復旧時間とコストのバランスを考えます。重要なシステムほど、複数AZや複数リージョンを使った構成を検討します。

13.6 障害テスト

設計上は冗長化していても、実際に切り替わるとは限りません。Auto Scaling、RDSフェイルオーバー、復元手順、アラーム通知などはテストします。

障害は起きない前提ではなく、障害が起きても被害を小さくする前提で設計します。

第14章サーバーレス：Lambda、API Gateway、EventBridge

14.1 サーバーレスとは何か

サーバーレスとは、サーバーが存在しないという意味ではなく、サーバーの管理を利用者が直接行わない設計です。AWSが実行基盤を管理し、利用者はコードや設定に集中します。

Lambda、API Gateway、DynamoDB、S3、SQS、EventBridgeなどを組み合わせると、サーバー管理を大幅に減らしたアプリケーションを作れます。

14.2 Lambda

Lambdaは、イベントに応じてコードを実行するサーバーレスコンピューティングサービスです。HTTPリクエスト、S3イベント、DynamoDB Streams、SQSメッセージなどをきっかけに実行できます。

def lambda_handler(event, context):
    name = event.get("name", "AWS")
    return {
        "statusCode": 200,
        "body": f"Hello {name}"
    }

14.3 実行ロール、環境変数、タイムアウト

Lambda実行ロールは、LambdaがAWSサービスへアクセスするためのIAMロールです。DynamoDBへ書き込むならDynamoDBへの権限、CloudWatch Logsへログを書き込むならログ権限が必要です。

環境変数は、コード外から設定値を渡す仕組みです。タイムアウトは、Lambdaが最大何秒実行できるかの設定です。

14.4 同時実行数とコールドスタート

同時実行数は、Lambdaが同時に処理できる実行数です。アクセスが急増すると、同時実行数も増えます。

コールドスタートは、新しい実行環境を初期化するために発生する遅延です。重い初期化処理がある関数では影響する場合があります。

14.5 API Gateway

API Gatewayは、HTTP APIを作成・公開するサービスです。Lambdaと組み合わせると、サーバーレスAPIを構築できます。

HTTP APIはシンプルで低コストな用途に向き、REST APIはより豊富な機能が必要な用途に向きます。

14.6 EventBridge

EventBridgeは、イベント駆動アーキテクチャを作るためのイベントバスサービスです。イベントバスとは、イベントを受け取り、ルールに応じて宛先へ配信する仕組みです。

14.7 SQS、SNS、Step Functions

SQSはメッセージキューです。SNSはPub/Sub型の通知サービスです。Step Functionsは、複数の処理を状態遷移として定義するサービスです。

14.8 冪等性、リトライ、DLQ

冪等性とは、同じ処理を複数回実行しても結果が変わらない性質です。DLQはDead Letter Queueの略で、処理に失敗したメッセージを退避するキューです。

イベント駆動では、失敗と再実行を前提に設計します。

第15章コンテナ：ECS、Fargate、EKS、ECR

15.1 コンテナとは何か

コンテナは、アプリケーションと実行に必要なライブラリや設定をひとまとめにして動かす仕組みです。環境差分を減らし、開発環境と本番環境で同じように動かしやすくなります。

Dockerイメージは、コンテナを起動するためのテンプレートです。

15.2 Dockerfile

Dockerfileは、Dockerイメージを作るための手順書です。

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "app.py"]

15.3 ECR

ECRはElastic Container Registryの略で、Dockerイメージを保存するレジストリです。ECSやEKSからECRに保存したイメージを取得してコンテナを起動します。

ECRにはイメージスキャン機能があり、コンテナイメージに含まれる脆弱性を検出できます。

15.4 ECS

ECSはElastic Container Serviceの略で、AWSのコンテナオーケストレーションサービスです。コンテナの起動、停止、配置、スケーリングを管理します。

ECSの主要用語は、クラスター、タスク定義、タスク、サービスです。タスク定義はコンテナの設計書、タスクは実行中のコンテナ、サービスはタスクを指定数維持する仕組みです。

15.5 Fargate

Fargateは、サーバー管理なしでECSやEKSのコンテナを実行する起動方式です。EC2インスタンスを自分で管理せず、タスク単位でCPUやメモリを指定します。

15.6 タスクロールとタスク実行ロール

タスクロールは、コンテナ内のアプリケーションがAWSサービスへアクセスするためのIAMロールです。タスク実行ロールは、ECSがECRからイメージを取得したり、CloudWatch Logsへログを送ったりするためのロールです。

アプリ用がタスクロール、ECS基盤用がタスク実行ロールです。

15.7 EKSとApp Runner

EKSはElastic Kubernetes Serviceの略で、AWS上でKubernetesを運用するマネージドサービスです。Kubernetesは、コンテナを大規模に管理するオープンソースの仕組みです。

App Runnerは、コンテナやソースコードからWebアプリを簡単に公開できるサービスです。

15.8 デプロイ戦略

コンテナでは、ローリングデプロイ、Blue/Greenデプロイ、Canaryデプロイなどを使います。

方式	概要	特徴
Rolling	少しずつ置き換える	標準的で扱いやすい
Blue/Green	新旧環境を切り替える	戻しやすい
Canary	一部通信から段階拡大	リスクを抑えやすい

第16章アプリケーション統合とイベント設計

16.1 疎結合

疎結合とは、システムの部品同士の依存を弱くする設計です。あるサービスが一時的に遅くなっても、全体に影響しにくくなります。

密結合な設計では、注文受付、在庫更新、メール送信、請求処理がすべて同期的につながり、どこかが失敗すると全体が失敗します。疎結合では、キューやイベントで処理を分離します。

16.2 SQS

SQSはSimple Queue Serviceの略です。メッセージをキューにため、処理側が順番に取り出します。

標準キューは高スループットで、メッセージ順序や重複排除は厳密ではありません。FIFOキューは順序保証と重複排除を重視します。

16.3 DLQ

DLQは、何度処理しても失敗するメッセージを退避するキューです。失敗メッセージを本流から分離し、後から原因を調査できます。

16.4 SNS

SNSはSimple Notification Serviceの略で、Pub/Sub型のメッセージ配信サービスです。Pub/Subとは、発行者がメッセージを出し、購読者が受け取る仕組みです。

SNSからSQS、Lambda、メール、HTTPエンドポイントなどへ配信できます。

16.5 EventBridge

EventBridgeは、イベントをルールで振り分けるサービスです。AWSサービスのイベント、独自アプリのイベント、SaaSのイベントを扱えます。

16.6 Step Functions

Step Functionsは、ワークフローを状態として定義するサービスです。状態遷移、分岐、並列処理、待機、リトライ、エラー処理を明示できます。

16.7 オーケストレーションとコレオグラフィ

オーケストレーションは、中央の司令塔が処理順序を管理する方式です。Step Functionsが代表例です。

コレオグラフィは、各サービスがイベントに反応して自律的に動く方式です。EventBridgeやSNSを使う構成が近いです。

第17章開発者ツールとCI/CD

17.1 CI/CD

CIはContinuous Integrationの略で、継続的インテグレーションです。コード変更を頻繁に統合し、自動テストやビルドを行います。

CDはContinuous DeliveryまたはContinuous Deploymentの略です。ビルド済みアプリケーションを安全にデプロイする仕組みです。

CI/CDの目的は、手作業を減らし、変更を小さく速く安全に届けることです。

17.2 Gitとブランチ戦略

Gitはソースコードの変更履歴を管理するツールです。ブランチは、作業の流れを分けるための枝です。

小さなチームでは、mainブランチとfeatureブランチを使い、Pull Requestでレビューしてからマージする方式が分かりやすいです。

17.3 CodePipeline、CodeBuild、CodeDeploy

CodePipelineは、ソース取得、ビルド、テスト、デプロイなどの流れをつなぐサービスです。CodeBuildは、ビルドやテストを実行するサービスです。CodeDeployは、EC2、ECS、Lambdaなどへのデプロイを支援します。

version: 0.2
phases:
  install:
    runtime-versions:
      python: 3.12
  build:
    commands:
      - pip install -r requirements.txt
      - pytest
artifacts:
  files:
    - '**/*'

17.4 デプロイ方式

Rollingデプロイは、少しずつ新バージョンへ置き換える方式です。Blue/Greenデプロイは、新旧環境を用意し、通信を切り替える方式です。Canaryデプロイは、一部の利用者だけ新バージョンへ流し、問題がなければ徐々に拡大します。

17.5 GitHub ActionsとOIDC

GitHub ActionsからAWSへデプロイする場合、長期アクセスキーをGitHub Secretsに保存する方式は漏えいリスクがあります。

OIDCを使うと、GitHub Actionsが一時的にAWSロールを引き受けられます。CI/CDでは、長期アクセスキーを減らし、一時認証情報を使うことが重要です。

17.6 Secrets ManagerとParameter Store

Secrets Managerは、DBパスワードやAPIキーなどの機密情報を管理するサービスです。Parameter Storeは、設定値や一部の機密値を管理できるSystems Managerの機能です。

機密情報をソースコードやコンテナイメージに埋め込んではいけません。

第18章監視、ログ、監査：CloudWatch、CloudTrail、Config

18.1 メトリクス、ログ、トレース

メトリクスは、CPU使用率、リクエスト数、エラー数のような数値データです。ログは、アプリケーションやシステムが出力する記録です。トレースは、1つのリクエストが複数サービスをまたいでどう処理されたかを追跡する情報です。

監視では、メトリクスで異常を検知し、ログで原因を調べ、トレースで処理の流れを追います。

18.2 CloudWatch MetricsとAlarms

CloudWatch Metricsは、AWSリソースやアプリケーションの数値データを収集します。CloudWatch Alarmsは、メトリクスがしきい値を超えたときに通知や自動処理を行います。

18.3 CloudWatch LogsとLogs Insights

CloudWatch Logsは、ログを収集・保存するサービスです。Logs Insightsは、CloudWatch Logsに対してクエリを実行する機能です。

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20

18.4 CloudTrail

CloudTrailは、AWS API操作を記録する監査サービスです。コンソール操作、CLI操作、SDK操作の多くはAPIとして記録されます。

誤ってS3バケットが公開された、IAMポリシーが変更された、RDSが削除された、という場合に、誰がいつ操作したかを確認できます。

18.5 AWS Config

AWS Configは、AWSリソースの設定履歴を記録し、ルールに基づいて準拠状況を評価するサービスです。

たとえば、S3バケットが公開されていないか、EBSが暗号化されているか、セキュリティグループでSSHが全開放されていないかを継続的に確認できます。

18.6 X-RayとSystems Manager

X-Rayは、分散アプリケーションのトレースを収集するサービスです。Systems Managerは、運用管理のためのサービス群です。Session Manager、Run Command、Patch Managerなどがあります。

18.7 監視設計

監視設計では、何を検知したいのかを先に決めます。重要なのは、可用性、レイテンシー、エラー率、飽和度です。

第19章セキュリティサービス実践

19.1 KMS

KMSはKey Management Serviceの略で、暗号鍵を管理するサービスです。S3、EBS、RDS、Lambda環境変数など、多くのサービスでKMSキーを利用できます。

KMSでは、キーポリシーとIAMポリシーの両方を理解する必要があります。

19.2 Secrets Manager

Secrets Managerは、DBパスワードやAPIキーなどの機密情報を安全に保存するサービスです。アプリケーションはSecrets Managerから実行時に値を取得します。

import boto3

client = boto3.client("secretsmanager")
response = client.get_secret_value(SecretId="prod/db/password")
secret = response["SecretString"]

19.3 WAF、Shield、Network Firewall

WAFはWebアプリケーションへの攻撃を防ぐサービスです。ShieldはDDoS保護サービスです。Network Firewallは、VPCレベルでより高度なネットワーク制御を行うマネージドファイアウォールです。

19.4 GuardDuty

GuardDutyは、脅威検出サービスです。CloudTrail、VPC Flow Logs、DNSログなどを分析し、不審な操作や通信を検出します。

19.5 Security Hub

Security Hubは、複数のセキュリティサービスの検出結果を集約し、セキュリティ基準に照らして評価するサービスです。

19.6 Inspector、Macie、Detective

Inspectorは、EC2、ECR、Lambdaなどの脆弱性を検出するサービスです。Macieは、S3内の機密データを検出するサービスです。Detectiveは、セキュリティインシデントの調査を支援するサービスです。

19.7 インシデント対応

インシデント対応では、検知、封じ込め、調査、復旧、再発防止を行います。CloudTrail、GuardDuty、Security Hub、VPC Flow Logs、CloudWatch Logsを使って証跡を確認します。

平常時からログを残し、調査できる状態を作ります。

第20章コスト管理とクラウド財務管理

20.1 従量課金を理解する

AWSでは、リソースの稼働時間、保存容量、リクエスト数、データ転送量などに応じて料金が発生します。

コスト管理の基本は、何に料金が発生しているかを把握することです。請求画面だけでなく、Cost Explorer、Budgets、タグを使って確認します。

20.2 Cost Explorer

Cost Explorerは、AWS利用料金を可視化するサービスです。サービス別、アカウント別、タグ別、期間別にコストを確認できます。

コストが急増した場合、まずCost Explorerでどのサービスが増えたかを確認します。

20.3 AWS BudgetsとCost Anomaly Detection

AWS Budgetsは、予算を設定し、超過しそうなときに通知するサービスです。Cost Anomaly Detectionは、通常と異なるコスト増加を検出するサービスです。

20.4 タグによるコスト配分

タグを使うと、プロジェクト別、環境別、チーム別にコストを集計できます。

Project=PaymentSystem
Environment=Production
Owner=BackendTeam

20.5 コストが増えやすいポイント

初心者が見落としやすいコストには、NAT Gateway、未使用EBS、古いスナップショット、RDSの起動しっぱなし、ALBの放置、CloudWatch Logsの長期保管、データ転送料があります。

AWSコストは、作ったものではなく、残っているものから発生し続けます。

20.6 Savings Plans、Reserved Instances、Spot

Savings Plansは、一定のコンピューティング利用を約束して割引を受ける仕組みです。Reserved Instancesは、特定条件のリソースを長期利用する前提で割引を受ける仕組みです。Spotは、余剰キャパシティを安く使う仕組みです。

20.7 FinOps

FinOpsは、クラウドの技術利用とコスト管理を結びつける考え方です。単に安くするのではなく、必要な性能や可用性を満たしながら無駄を減らすことが重要です。

第21章 IaC：CloudFormation、CDK、SAM、Terraform

21.1 IaCとは何か

IaCはInfrastructure as Codeの略で、インフラ構成をコードとして管理する考え方です。手作業で画面から作るのではなく、テンプレートやプログラムでAWSリソースを定義します。

本番環境では、手作業で作ったリソースより、コードで再現できるリソースの方が管理しやすいです。

21.2 CloudFormation

CloudFormationは、AWS公式のIaCサービスです。テンプレートにリソースを定義し、スタックとして作成します。

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  SampleBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub 'sample-bucket-${AWS::AccountId}-${AWS::Region}'

Resourcesは作成するリソースを定義するセクションです。Parametersは外部から渡す値、Outputsは作成後に出力する値です。

21.3 RefとFn::GetAtt

Refは、リソースやパラメータを参照する関数です。Fn::GetAttは、リソースの属性を取得する関数です。

21.4 Change SetsとDrift Detection

Change Setsは、スタック更新前に何が変更されるかを確認する機能です。Drift Detectionは、CloudFormationで管理している状態と実際のリソース状態がずれていないかを確認する機能です。

21.5 CDK

CDKはCloud Development Kitの略で、TypeScript、Python、Javaなどのプログラミング言語でAWSリソースを定義するツールです。

Constructは、CDKで使う部品です。Stackは、デプロイ単位です。Appは、複数のStackを含むCDKアプリ全体です。

21.6 SAM

SAMはServerless Application Modelの略で、サーバーレスアプリケーション向けのIaCフレームワークです。Lambda、API Gateway、DynamoDBなどを簡潔に定義できます。

21.7 Terraform

Terraformは、HashiCorpが提供するIaCツールです。AWSだけでなく複数クラウドやSaaSを管理できます。

ツール	主な用途	特徴
CloudFormation	AWS公式IaC	AWSとの統合が強い
CDK	プログラムでAWS定義	抽象化しやすい
SAM	サーバーレス	Lambda中心に扱いやすい
Terraform	複数基盤管理	State管理が重要

第22章 Organizations、Control Tower、マルチアカウント

22.1 マルチアカウントの必要性

AWSでは、1つのアカウントにすべてを詰め込むより、用途ごとにアカウントを分ける設計が推奨されます。

開発、本番、監査、ログ、ネットワーク、セキュリティなどを分けると、権限、請求、障害影響、監査を分離しやすくなります。

アカウントは単なる契約単位ではなく、強力な分離境界です。

22.2 AWS Organizations

AWS Organizationsは、複数のAWSアカウントを一元管理するサービスです。管理アカウントとメンバーアカウントで構成されます。

OUはOrganizational Unitの略で、アカウントをまとめる単位です。一括請求により、複数アカウントの請求をまとめられます。

22.3 SCP

SCPはService Control Policyの略で、アカウントやOUに適用する権限の上限です。

SCPは権限を付与するものではありません。SCPは最大権限を制限するものです。

22.4 Control Tower

Control Towerは、AWSのマルチアカウント環境を標準的な構成で作成・管理するサービスです。

ランディングゾーンは、安全なマルチアカウント環境の土台です。Account Factoryは、新しいアカウントを標準化して作成する機能です。

22.5 ログアーカイブ、監査、ネットワークアカウント

ログアーカイブアカウントは、CloudTrailやConfigなどのログを集約するアカウントです。監査アカウントは、セキュリティチームや監査担当が各アカウントを確認するためのアカウントです。

ネットワークアカウントは、Transit Gateway、共有VPC、Direct Connectなど、共通ネットワークを管理するために使うことがあります。

第23章ガバナンスと社内運用ルール

23.1 ガバナンスとは何か

ガバナンスとは、組織としてAWSを安全かつ効率的に使うためのルール、仕組み、監視のことです。

自由に使える環境は便利ですが、ルールがないと、権限過剰、公開ミス、コスト増加、命名不統一、ログ不足が起きます。

23.2 命名規則とタグ標準

命名規則は、リソース名を一貫した形式にするルールです。

{system}-{env}-{component}-{region}
payment-prod-api-apne1

タグ標準では、Project、Environment、Owner、CostCenter、ManagedByなどを定義します。

23.3 暗号化、ログ、バックアップ標準

暗号化標準では、S3、EBS、RDS、DynamoDBなどで保存時暗号化を有効にする方針を定めます。

ログ保存期間は、セキュリティ要件や法令に応じて決めます。バックアップ標準では、対象、頻度、保持期間、復元テストの頻度を決めます。

23.4 変更管理

変更管理は、本番環境への変更を安全に行うための手続きです。変更内容、影響範囲、リリース手順、切り戻し手順、承認者を明確にします。

23.5 職務分掌と権限レビュー

職務分掌は、1人に強すぎる権限を集中させない考え方です。権限レビューでは、定期的にIAMユーザー、ロール、アクセスキー、管理者権限を棚卸しします。

23.6 自動修復

Config RulesやEventBridge、Lambdaを使うと、望ましくない設定を検出して自動修復できます。たとえば、S3バケットが公開されたら自動でパブリックアクセスブロックを有効化する、といった運用ができます。

第24章分析基盤：S3、Glue、Athena、Redshift、QuickSight

24.1 データレイクとDWH

データレイクは、構造化データ、半構造化データ、非構造化データをそのまま蓄積する場所です。AWSではS3をデータレイクの中心にすることが多いです。

DWHはData Warehouseの略で、分析に適した形に整理されたデータ基盤です。Redshiftが代表です。

24.2 ETLとELT

ETLはExtract、Transform、Loadの略で、データを抽出し、変換し、格納する処理です。ELTは、先にデータを格納し、その後で変換する方式です。

24.3 ファイル形式とパーティション

分析基盤では、CSVだけでなくParquetのような列指向フォーマットを使うと、クエリ性能とコストを改善しやすくなります。

パーティションは、日付やカテゴリなどでデータを分割する仕組みです。Athenaで日付パーティションを使うと、必要な範囲だけ読み取り、コストを抑えられます。

24.4 Glue

Glueは、データ統合とETLのためのサービスです。Glue Data Catalogは、テーブル定義やスキーマ情報を管理するメタデータカタログです。

Glue Crawlerは、S3上のデータをスキャンしてスキーマを推測し、Data Catalogに登録します。Glue Jobは、データ変換処理を実行します。

24.5 Athena

Athenaは、S3上のデータに対してSQLを実行できるサービスです。サーバーを管理せず、クエリ単位で利用できます。

SELECT status, count(*)
FROM access_logs
WHERE dt = '2026-05-13'
GROUP BY status;

Athenaは読み取ったデータ量に応じて料金が発生するため、Parquet化やパーティション設計が重要です。

24.6 RedshiftとQuickSight

Redshiftは、分析用のデータウェアハウスです。QuickSightは、BIダッシュボードを作成するサービスです。AthenaやRedshiftなどのデータを可視化できます。

24.7 Kinesis、Firehose、MSK

Kinesis Data Streamsは、リアルタイムストリーミングデータを処理するサービスです。Data Firehoseは、ストリーミングデータをS3、Redshift、OpenSearchなどへ配信するサービスです。

MSKはManaged Streaming for Apache Kafkaの略で、Kafkaをマネージドで利用するサービスです。

第25章 AI/MLと生成AI：Bedrock、SageMaker AI、Amazon Q

25.1 AI、ML、生成AI

AIはArtificial Intelligenceの略で、人工知能を意味します。MLはMachine Learningの略で、データからパターンを学習する機械学習です。

生成AIは、文章、画像、コード、音声などを生成するAIです。基盤モデルはFoundation Modelとも呼ばれ、大量データで事前学習された大規模モデルです。

25.2 推論、ファインチューニング、RAG

推論とは、学習済みモデルに入力を与えて出力を得ることです。ファインチューニングは、既存モデルを追加データで調整することです。

RAGはRetrieval-Augmented Generationの略で、検索で取得した外部情報を使って生成AIに回答させる方式です。社内文書やFAQを参照するAIでよく使います。

25.3 Amazon Bedrock

Amazon Bedrockは、複数の基盤モデルをAPI経由で利用し、生成AIアプリケーションを構築するためのマネージドサービスです。

モデル選択、ナレッジベース、エージェント、ガードレールなどの機能があります。

25.4 SageMaker AI

SageMaker AIは、機械学習モデルの構築、学習、デプロイ、運用を支援するサービスです。

トレーニングジョブはモデル学習を実行する処理です。エンドポイントは、学習済みモデルを推論APIとして公開する仕組みです。MLOpsは、機械学習の開発、デプロイ、監視、再学習を継続的に行う運用方法です。

25.5 Amazon Q

Amazon Qは、業務支援や開発支援に使える生成AIアシスタント群です。利用時は、アクセス権限、データ接続、機密情報、回答の正確性を必ず確認します。

25.6 AIセキュリティとAIコスト

生成AIでは、プロンプトインジェクション、機密情報漏えい、不正確な回答、過剰なAPI利用コストに注意します。

AI機能は便利ですが、必ず人間の確認、アクセス制御、ログ、コスト上限、入力検証を設計します。

第26章専門カテゴリの全体像

26.1 IoT

IoTはInternet of Thingsの略で、センサーや機器をインターネットに接続してデータを収集・制御する分野です。

IoT Coreは、デバイスとAWSを安全に接続するサービスです。IoT Greengrassは、エッジデバイス上でローカル処理を行うために使います。IoT Device Defenderは、デバイスのセキュリティ監視に使います。

26.2 メディアサービス

MediaConvertは、動画ファイルの変換に使います。MediaLiveは、ライブ動画処理に使います。IVSはInteractive Video Serviceの略で、低遅延のライブ配信を構築できます。

26.3 エンドユーザーコンピューティング

WorkSpacesは、クラウド上の仮想デスクトップサービスです。AppStream 2.0は、アプリケーションをストリーミング配信するサービスです。WorkSpaces Secure Browserは、安全なブラウザアクセス環境を提供するサービスです。

26.4 モバイル・Webアプリ支援

Amplifyは、Webアプリやモバイルアプリのフロントエンド開発、ホスティング、認証、API連携を支援するサービスです。Cognitoは、アプリケーションのユーザー認証やユーザー管理を行うサービスです。AppSyncは、GraphQL APIを提供するサービスです。

26.5 その他の専門サービス

Amazon Connectは、クラウドコンタクトセンターサービスです。GameLift Serversは、ゲームサーバー運用を支援します。Amazon Braketは量子コンピューティング関連サービスです。AWS Ground Stationは衛星通信データの受信に使います。

第27章移行とハイブリッドクラウド

27.1 移行の7R

移行の7Rは、既存システムをクラウドへ移す方法を分類する考え方です。代表的には、Rehost、Replatform、Refactor、Repurchase、Retire、Retain、Relocateがあります。

Rehostは、既存サーバーを大きく変えずEC2などへ移す方法です。Replatformは、少し構成を変更してマネージドサービスを利用する方法です。Refactorは、アプリケーションを作り直してクラウドに最適化する方法です。

27.2 移行計画

移行では、対象システム、依存関係、データ量、停止可能時間、切り戻し手順を確認します。依存関係を調査しないまま移行すると、移行後に外部システム接続やバッチ処理が動かないことがあります。

27.3 Application Migration Service

Application Migration Serviceは、既存サーバーをAWSへ移行するためのサービスです。サーバー単位の移行に向いています。

27.4 Database Migration Service

DMSはDatabase Migration Serviceの略で、データベース移行を支援するサービスです。CDCを使うと、移行元DBの変更を継続的に移行先へ反映できます。

CDCはChange Data Captureの略で、変更データを捕捉する仕組みです。Schema Conversion Toolは、異なるDBエンジン間のスキーマ変換を支援します。

27.5 DataSync、Transfer Family、Snow Family

DataSyncは、オンプレミスや他ストレージからAWSへデータを転送するサービスです。Transfer Familyは、SFTP、FTPS、FTPでS3やEFSへファイル転送するサービスです。

Snow Familyは、大容量データを物理デバイスでAWSへ移すためのサービス群です。

27.6 ハイブリッド接続

ハイブリッドクラウドでは、オンプレミスとAWSを組み合わせます。VPN、Direct Connect、Transit Gateway、Route 53 Resolver、Storage Gatewayなどを使います。

第28章 Well-Architected Frameworkで設計評価

28.1 Well-Architected Frameworkとは

Well-Architected Frameworkは、AWS上のシステムを良い設計に近づけるためのベストプラクティス集です。6つの柱に基づいて設計を評価します。

6つの柱は、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性です。

Well-Architectedは、完成後の採点ではなく、継続的に改善するための考え方です。

28.2 運用上の優秀性

運用上の優秀性は、システムを効果的に運用し、継続的に改善する能力です。運用手順をコード化する、変更を小さくする、障害から学ぶ、メトリクスを使って改善する、といった実践が含まれます。

28.3 セキュリティ

セキュリティの柱では、ID管理、検知、防御、データ保護、インシデント対応を評価します。IAM最小権限、MFA、暗号化、CloudTrail、GuardDuty、WAF、Secrets Managerなどが関係します。

28.4 信頼性

信頼性は、障害から復旧し、需要の変化に対応し、期待通りに機能する能力です。マルチAZ、Auto Scaling、バックアップ、DR、SQSによる疎結合、障害テストが重要です。

28.5 パフォーマンス効率

パフォーマンス効率は、リソースを効率的に使って要件を満たす能力です。適切なインスタンスタイプ、キャッシュ、CDN、データベース設計、サーバーレス、マネージドサービス選択が関係します。

28.6 コスト最適化

コスト最適化は、必要な価値を最小限の無駄で提供する能力です。Cost Explorer、Budgets、タグ、Savings Plans、不要リソース削除、S3ライフサイクル、ログ保持期間見直しが重要です。

28.7 持続可能性

持続可能性は、環境負荷を減らしながらシステムを運用する考え方です。不要なリソースを削除し、効率的なアーキテクチャを選び、過剰な計算や保管を避けます。

第29章実践アーキテクチャ集

29.1 静的Webサイト

静的Webサイトでは、S3にHTML、CSS、JavaScriptを保存し、CloudFrontで配信し、Route 53で独自ドメインを設定し、ACMでHTTPS化します。

S3は直接公開せず、CloudFront OACを使ってCloudFront経由だけでアクセスさせる構成が安全です。

29.2 3層Webアプリ

3層Webアプリでは、CloudFront、ALB、ECSまたはEC2、RDSを組み合わせます。

ALBはパブリックサブネットに配置し、アプリケーションはプライベートサブネットに配置し、RDSはDB用プライベートサブネットに配置します。

29.3 サーバーレスAPI

サーバーレスAPIでは、API Gateway、Lambda、DynamoDBを組み合わせます。小規模APIや急なアクセス変動があるサービスでは、サーバー管理を減らせるメリットがあります。

29.4 非同期バッチ

非同期バッチでは、S3、SQS、Lambda、Step Functionsを組み合わせます。S3にファイルがアップロードされたら処理を開始し、SQSで処理待ちを管理し、Lambdaで変換し、Step Functionsで全体の流れを管理します。

29.5 コンテナWebサービス

コンテナWebサービスでは、ECR、ECS Fargate、ALBを使います。CI/CDでDockerイメージをビルドし、ECRへプッシュし、ECSサービスを更新します。

29.6 データ分析基盤

データ分析基盤では、S3にデータを集め、Glueでカタログ化し、AthenaでSQL検索し、QuickSightで可視化します。大規模分析や高性能なDWHが必要な場合はRedshiftを使います。

29.7 生成AI社内FAQ

生成AI社内FAQでは、社内文書をS3に保存し、Bedrock Knowledge Basesなどで検索可能にし、LambdaやAPI Gateway、Cognitoと組み合わせて社内利用者向けに公開します。

利用者が閲覧できない文書をAIが回答に使わないよう、データアクセス制御を設計します。

第30章トラブルシューティングと障害対応

30.1 基本手順

障害対応では、まず事象、影響範囲、発生時刻、直前の変更、再現条件を確認します。次に、仮説を立て、ログやメトリクスで確認します。

感覚で設定を変更すると、原因が分からなくなり、被害が広がることがあります。

30.2 EC2に接続できない

EC2へ接続できない場合は、インスタンス状態、パブリックIP、セキュリティグループ、NACL、ルートテーブル、OS側のSSHサービス、Session Manager設定を確認します。

30.3 ALB 5xx

ALBで502や503が出る場合、ターゲットが正常か、ヘルスチェックに成功しているか、アプリケーションが対象ポートで待ち受けているかを確認します。

30.4 RDSに接続できない

RDS接続不可では、DBエンドポイント、ポート、セキュリティグループ、サブネット、ルート、認証情報、DB状態を確認します。

30.5 Lambdaタイムアウト

Lambdaタイムアウトでは、外部API、DB接続、VPC設定、NAT Gateway、DNS、メモリ不足を確認します。

30.6 S3 AccessDenied

S3のAccessDeniedでは、IAMポリシー、バケットポリシー、ACL、KMSキー権限、Block Public Access、VPCエンドポイントポリシーを確認します。

30.7 IAM権限エラー

IAM権限エラーでは、エラーメッセージのActionとResourceを確認します。必要な権限がAllowされているか、明示的Denyがないか、SCPやパーミッションバウンダリーで制限されていないかを確認します。

30.8 コスト急増

コスト急増では、Cost Explorerでサービス別に確認します。NAT Gateway、データ転送、RDS、EC2、CloudWatch Logs、スナップショットがよくある原因です。

30.9 ポストモーテム

ポストモーテムは、障害後の振り返りです。原因、影響、検知方法、対応、再発防止策を整理します。目的は犯人探しではなく、仕組みを改善することです。

第31章ハンズオン総合演習

31.1 演習の進め方

ハンズオンでは、最初に予算アラートを作成し、作業後に必ずリソースを削除します。演習用環境は本番環境と分けます。

31.2 基礎セットアップ

aws sts get-caller-identity
aws configure list
aws ec2 describe-vpcs

現在の認証情報、CLI設定、既存VPCを確認します。

31.3 VPCとEC2 Webサーバー

VPC、パブリックサブネット、Internet Gateway、ルートテーブル、セキュリティグループを作成し、EC2を起動します。ユーザーデータでnginxをインストールし、ブラウザから表示確認します。

31.4 ALBとAuto Scaling

EC2を複数AZに配置し、ALBで振り分けます。Auto Scaling Groupで希望台数を維持します。1台を終了してもAuto Scalingで再作成されることを確認します。

31.5 RDS接続

RDSをプライベートサブネットに作成し、アプリケーション用セキュリティグループからの接続だけを許可します。

31.6 サーバーレスAPI

API Gateway、Lambda、DynamoDBを使って簡単なAPIを作ります。LambdaにはDynamoDBへの最小権限ロールを設定します。CloudWatch Logsで実行ログを確認します。

31.7 SQS非同期処理

APIで受け付けた処理をSQSへ送信し、別のLambdaで処理します。失敗時にはDLQへ送ります。

31.8 IaC化

手作業で作った構成をCloudFormationまたはCDKで再作成します。最初はS3バケットやLambdaなど小さなリソースから始め、最終的にVPC、ALB、ECS、RDSなどをコード化します。

31.9 監視と障害再現

CloudWatch Alarmを設定し、意図的にヘルスチェック失敗やLambdaエラーを発生させます。障害時にどのログを見るか、どのメトリクスを見るかを演習します。

31.10 リソース削除

演習後は、作成したリソースを削除します。CloudFormationやCDKで作ったものはスタック削除を使います。

第32章 AWSエンジニアの学習ロードマップ

32.1 入門段階

入門段階では、AWSの全体像、IAM、VPC、EC2、S3、RDS、CloudWatchを優先します。最初からすべてのサービスを深掘りする必要はありません。

32.2 基礎固め

基礎固めでは、IAMポリシー、VPC設計、ALB、Route 53、CloudFront、Lambda、DynamoDB、CloudTrail、Configを学びます。

32.3 実務構築

実務構築では、ECS、Fargate、CI/CD、IaC、Secrets Manager、KMS、Systems Manager、AWS Backupを学びます。

32.4 運用改善

運用改善では、CloudWatch、X-Ray、Security Hub、GuardDuty、Cost Explorer、Compute Optimizer、Well-Architected Toolを使います。

32.5 職種別の次の学習

インフラエンジニアは、VPC、Direct Connect、Transit Gateway、Organizations、Control Tower、IaCを深めます。

アプリケーションエンジニアは、Lambda、ECS、API Gateway、DynamoDB、SQS、EventBridge、CI/CDを深めます。

セキュリティエンジニアは、IAM、KMS、GuardDuty、Security Hub、Inspector、Macie、CloudTrail、Configを深めます。

SREは、CloudWatch、X-Ray、Auto Scaling、障害対応、信頼性設計、Well-Architectedを深めます。

データエンジニアは、S3、Glue、Athena、Redshift、Kinesis、Lake Formationを深めます。

AI/MLエンジニアは、Bedrock、SageMaker AI、データ基盤、MLOps、AIセキュリティを深めます。

32.6 AWS認定資格

最初の資格としては、AWS Certified Cloud PractitionerまたはAWS Certified Solutions Architect - Associateが候補になります。

資格は目的ではなく、知識の抜け漏れを確認する手段です。ハンズオンと設計説明を組み合わせて学ぶと実務力につながります。

付録A AWS重要用語集

アカウント：AWS利用の契約・管理単位です。
ARN：AWSリソースを一意に表す名前です。
リージョン：AWSリソースを配置する地理的地域です。
AZ：リージョン内の独立した設備群です。
VPC：AWS上の仮想ネットワークです。
CIDR：IPアドレス範囲を表す記法です。
サブネット：VPCを分割したIP範囲です。
セキュリティグループ：リソース単位の仮想ファイアウォールです。
IAM：認証と認可を管理するサービスです。
ロール：一時的に引き受ける権限です。
ポリシー：許可や拒否を定義するJSONです。
KMS：暗号鍵を管理するサービスです。
S3：オブジェクトストレージです。
EBS：EC2向けブロックストレージです。
RDS：マネージドRDBサービスです。
DynamoDB：マネージドNoSQLデータベースです。
Lambda：イベントでコードを実行するサーバーレスサービスです。
CloudWatch：メトリクスとログの監視サービスです。
CloudTrail：AWS API操作の監査ログサービスです。
IaC：インフラをコードで管理する考え方です。
DR：災害復旧です。
RTO：復旧までに許容される時間です。
RPO：許容されるデータ損失時点です。

付録B よく使うAWS CLIコマンド集

# 現在の認証主体を確認
aws sts get-caller-identity

# CLI設定を確認
aws configure list

# S3バケット一覧
aws s3 ls

# EC2一覧
aws ec2 describe-instances

# VPC一覧
aws ec2 describe-vpcs

# RDS一覧
aws rds describe-db-instances

# Lambda一覧
aws lambda list-functions

# CloudWatch Logsロググループ一覧
aws logs describe-log-groups

# CloudTrailイベント検索
aws cloudtrail lookup-events

# CloudFormationスタック一覧
aws cloudformation list-stacks

付録C IAMポリシー例

S3読み取り専用

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::example-bucket",
        "arn:aws:s3:::example-bucket/*"
      ]
    }
  ]
}

明示的Denyの例

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "s3:DeleteObject",
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

明示的DenyはAllowより優先されます。削除を絶対に防ぎたい場合などに使います。

付録D セキュリティチェックリスト

ルートユーザーにMFAを設定していますか。
ルートユーザーを日常作業に使っていませんか。
管理者権限を持つ利用者を把握していますか。
未使用アクセスキーを削除していますか。
S3バケットの公開設定を確認していますか。
CloudTrailを有効化していますか。
GuardDutyを有効化していますか。
Security Hubで検出結果を集約していますか。
重要データをKMSで暗号化していますか。
Secrets ManagerやParameter Storeで機密情報を管理していますか。
セキュリティグループでSSHやRDPを全開放していませんか。
バックアップと復元テストを行っていますか。
CloudWatchアラームを設定していますか。
予算アラートを設定していますか。

付録E コスト最適化チェックリスト

AWS Budgetsを設定していますか。
Cost Explorerでサービス別コストを確認していますか。
タグでコスト配分できていますか。
未使用EC2を停止または削除していますか。
未使用EBSを削除していますか。
古いスナップショットを確認していますか。
NAT Gatewayの利用状況を確認していますか。
S3ライフサイクルを設定していますか。
RDSサイズを見直していますか。
Savings Plansを検討していますか。
Spot利用可能な処理を検討していますか。
CloudWatch Logsの保持期間を設定していますか。
開発環境を夜間停止できますか。
データ転送料を確認していますか。

付録F トラブルシューティング早見表

事象	最初に確認すること	関連サービス
EC2に接続できない	SG、NACL、ルート、鍵、Session Manager	EC2、VPC、SSM
ALBで502が出る	ターゲット状態、ポート、アプリログ	ALB、EC2、ECS
RDSに接続できない	SG、サブネット、認証情報、DB状態	RDS、VPC
Lambdaがタイムアウトする	外部接続、VPC、NAT、DNS、メモリ	Lambda、VPC
S3でAccessDenied	IAM、バケットポリシー、KMS、Block Public Access	S3、IAM、KMS
CloudFrontで古い内容	キャッシュ、Invalidation、Cache-Control	CloudFront、S3
コストが急増した	サービス別、リージョン別、タグ別に確認	Cost Explorer

最終まとめ

AWSを理解するうえで最も重要なのは、個別サービスを断片的に覚えることではありません。IAMで権限を制御し、VPCで通信を設計し、マネージドサービスで運用負担を下げ、CloudWatchとCloudTrailで状態を観測し、IaCで再現可能にし、Well-Architectedで継続的に改善することです。

AWSは、学習範囲が広いサービスです。しかし、基礎の考え方は一貫しています。何を守るのか、どこに置くのか、どう通信するのか、どう止まりにくくするのか、どう監視するのか、どうコストを抑えるのか。この問いに答えられるようになると、サービス名の暗記ではなく、実務で使えるAWS設計力が身につきます。