VPCは、AWSの中に自分専用のネットワーク空間を作る仕組みです。まず「CIDR（例：10.0.0.0/16）」でIP範囲を決め、その中を「サブネット」に区切ります。インターネットに公開する層（パブリック）と、DBなど外に出さない層（プライベート）に分けて構築します。

用語のキホン：CIDRとサブネット

CIDR（例：10.0.0.0/16）は、使えるIPアドレスの範囲を表す書き方です。末尾の数字が小さいほど範囲は広く、大きいほど狭くなります。サブネットは、そのIP範囲をさらに小さく区切った区画で、AZごとに作成します。インターネットゲートウェイへの経路を持つ区画をパブリックサブネット、持たない区画をプライベートサブネットと呼び、この2つを分けることがVPC設計の出発点になります。

経路とゲートウェイ

通信の経路は「ルートテーブル」で決めます。インターネットとの出入り口には「インターネットゲートウェイ」、プライベートからの外向き通信だけを許す「NATゲートウェイ」を使います。AWSサービスへ非インターネット経由で繋ぐ「VPCエンドポイント」（S3等向けのゲートウェイ型、その他のインターフェース型）も重要です。

接続と可視化

VPC同士は「ピアリング」や「Transit Gateway」で接続します。通信の記録は「VPCフローログ」で確認できます。ほぼ全てのAWS設計の土台になるため、パブリックとプライベートの分離は必ず理解しておきましょう。

セキュリティグループ（SG）は、EC2などインスタンス単位のファイアウォールです。ステートフルで、許可した通信の戻りは自動で通ります。書けるのは「許可」ルールだけで、デフォルトは全拒否から必要な通信を足していきます。SGは他のSGを参照でき（例：「このWeb-SGからのみ許可」）、柔軟に設計できます。

用語のキホン：ステートフルとステートレス

ステートフルとは、通信の「行き」を覚えていて、その「戻り」を自動的に許可する方式です（セキュリティグループ）。一方ステートレスは、行きと戻りをそれぞれ別の通信として扱うため、両方のルールを書かないと通信が成立しません（ネットワークACL）。NACLで「行き」だけ許可して戻り（エフェメラルポート）を書き忘れ、通信できない——というのが典型的なつまずきポイントです。

NACLとの違い・使い分け

ネットワークACL（NACL）は、サブネット単位のファイアウォールです。ステートレスで、行きと戻りの両方を明示する必要があります。「許可」と「拒否」の両方を番号順に評価するため、特定IPを丸ごとブロックする用途に向きます。SGを主に使い、NACLはサブネット全体の粗い制御として併用する「多層防御」が定石です。

通常、S3やDynamoDBはインターネット側のエンドポイントを持つため、プライベートサブネットからのアクセスにはNATゲートウェイが必要でした。VPCエンドポイントを作ると、その通信をAWS内部のネットワークだけで完結させられます。

用語のキホン：ゲートウェイ型とインターフェース型

ゲートウェイ型は、ルートテーブルに「S3宛はこちら」という経路を追加する方式です。対象はS3とDynamoDBのみで、追加料金はかかりません。インターフェース型（PrivateLink）は、サブネット内にENI（仮想的なネットワークカード）を作り、そのプライベートIP宛に通信する方式です。多くのAWSサービスや他社SaaSにも対応しますが、時間課金と転送量課金が発生します。

閉域化のメリット

インターネットゲートウェイもNATゲートウェイも経由しないため、通信がVPCの外に出ません。「社外に通信を出さないこと」が要件となる金融・医療などの環境で有効です。加えて、NATゲートウェイの処理量が減るぶん料金の削減にもつながります。

Transit Gatewayは、たくさんのVPCやオンプレ拠点をハブ＆スポーク型で相互接続する中継点です。VPCピアリングが1対1でしか繋げず、数が増えると接続数が爆発的に増えるのに対し、Transit Gatewayは中央に集約するため管理が容易です。

用語のキホン：アタッチメントとルートテーブル

TGWに何かを接続する単位をアタッチメントと呼びます（VPCアタッチメント、VPNアタッチメント、Direct Connectアタッチメントなど）。TGWはルートテーブルを複数持てるため、「どのアタッチメントから来た通信を、どのアタッチメントへ流すか」を細かく制御でき、「本番系と開発系は相互に通信させない」といったセグメント分離が実現できます。なお、AとB、BとCがつながっていてもAとCは通信できない性質を推移的ルーティング非対応と言い、これはVPCピアリングの制約ですが、TGWは中継役として通信を転送できるためこの制約を解消します。

リージョン間の接続

リージョンをまたぐ場合はTransit GatewayピアリングでTGWどうしを接続します。通信はインターネットを経由せず、暗号化された状態でAWSのグローバルネットワーク上を流れます。大規模ネットワークの要となる仕組みです。

アプリケーションを多数の小さなサービスに分割すると、サービス間の通信経路が急激に複雑になります。App Meshは、その通信部分だけを切り出して共通の仕組みで扱えるようにするサービスです。ECS、EKS、EC2、Fargate上のアプリケーションで利用できます。

用語のキホン：サービスメッシュとサイドカープロキシ

サービスメッシュとは、マイクロサービス同士の通信を専門に担当する層のことです。従来は「リトライ回数」「タイムアウト」「暗号化」といった通信の作法を各アプリのコードに書き込んでいましたが、サービスメッシュではこれをアプリの外側に追い出します。その実現手段がサイドカープロキシで、アプリのコンテナと同じ場所にもう1つプロキシ用のコンテナを並べて動かし、アプリの出入りする通信をすべてそのプロキシに通す方式です。App MeshではオープンソースのEnvoyというプロキシをサイドカーとして使います。アプリ側は「相手のサービス名を指定して送る」だけでよく、実際の経路制御はプロキシが引き受けます。

構成要素と、ロードバランサーとの使い分け

App Meshは、メッシュ全体を表すMesh、通信の受け口となるVirtual Service、経路の振り分けルールを持つVirtual RouterとRoute、実体を表すVirtual Nodeという単位で構成します。ELBが「外部から入ってくる通信」を主に扱うのに対し、App Meshは「サービス同士の内部通信」を細かく制御する点が違いです。重み付けルーティングができるため、新バージョンにわずかな割合の通信だけを流すカナリアリリースや、ブルーグリーンの切り替えに向いています。

コンテナやサーバーレスの環境では、リソースが頻繁に起動・停止し、そのたびにIPアドレスが変わります。接続先を設定ファイルに書き込む方法では追いつきません。Cloud Mapは、この「今どこにいるのか」を管理する住所録の役割を果たします。

用語のキホン：サービスディスカバリ

サービスディスカバリとは、通信したい相手のサービスが現在どのアドレスで動いているかを、動的に調べる仕組みのことです。中心にあるのがレジストリと呼ばれる登録簿で、起動したインスタンスが自分の情報をここに登録し、停止すれば削除されます。呼び出す側はレジストリに問い合わせて、生きている接続先を受け取ります。Cloud Mapでは、DNSの名前解決で引く方法と、APIを直接呼んで一覧を取得する方法の両方に対応しています。またRoute 53のヘルスチェックと連携でき、応答しなくなったインスタンスを結果から自動的に除外できます。

登録できる対象と、App Meshとの関係

Cloud Mapに登録できるのはコンテナだけではありません。DynamoDBのテーブル、S3バケット、SQSキューなど、任意のリソースに独自の属性を付けて登録できます。ECSにはCloud Mapを使ったサービスディスカバリ機能が組み込まれており、タスクの増減が自動的に反映されます。App Meshが「通信そのものをどう制御するか」を担当するのに対し、Cloud Mapは「相手がどこにいるかを教える」役割で、両者は組み合わせて使われます。

Direct Connectは、自社データセンターとAWSを専用線で直結するサービスです。インターネットを経由するVPNに比べ、帯域が安定し遅延も小さく、大量データのやり取りに向きます。

用語のキホン：BGPと仮想インターフェース

BGPとは、「どのネットワークへ行くにはどの経路を使うか」をルーター同士が自動で教え合うためのルーティングプロトコルです。Direct ConnectではこのBGPで経路を交換し、優先度を調整します。ある経路を優先させたいときはAS_PATHを短く、優先度を下げたいときはAS_PATHをわざと長くする（AS_PATHプリペンド）のが定番の手法です。また、1本の物理回線の上に作る論理的な接続を仮想インターフェース（VIF）と呼び、VPC向けのプライベートVIF、S3など向けのパブリックVIF、Transit Gateway向けのトランジットVIFを使い分けます。

Direct Connectゲートウェイと冗長化

Direct Connectゲートウェイを使うと、1本の専用線から複数リージョン・複数VPCへ接続できます。単一の専用線は障害時に全断するため、複数接続・複数ロケーションでの冗長化が定石です。バックアップとしてVPNを併用する場合、通常はDirect Connectの経路が優先され、障害時はBGPによって自動的にVPN経路へ切り替わります。

拠点側のルーター（カスタマーゲートウェイ）と、AWS側の仮想プライベートゲートウェイまたはTransit Gatewayとの間にIPsecトンネルを張ります。1つのVPN接続につきトンネルが自動的に2本作られ、片方が切れても通信が続きます。

用語のキホン：トンネル・IPsec・静的と動的ルーティング

トンネルとは、インターネットという公共の道の上に作る「暗号化された専用の通り道」のことです。IPsecはその暗号化の標準規格を指します。経路の教え方は2種類あり、管理者が手作業で経路を書く静的ルーティングと、BGPで自動的に経路を交換する動的ルーティングがあります。動的にしておくと、拠点側のネットワークが増えたときも自動で伝わり、障害時の経路切り替えも自動になります。

Direct Connectとの使い分け

帯域と品質の安定が必要なら専用線（DX）、すぐ使いたい・バックアップ用途ならVPN、が基本の使い分けです。両方を用意し、平常時はDX、DX障害時はVPNへ自動で切り替える冗長構成が定番として問われます。

接続の単位が「拠点まるごと」ではなく「利用者1人ずつ」である点が特徴です。利用者数に応じて自動的に規模が調整されるため、VPNサーバーを自前で構築・運用する必要がありません。

用語のキホン：クライアントVPNとサイト間VPNの違い

VPNには大きく2つの形があります。サイト間VPN（Site-to-Site VPN）は拠点のルーター同士をつなぐもので、拠点内のすべての端末が自動的にAWSと通信できるようになります。対してクライアントVPN（リモートアクセスVPN）は、個々の端末が自分でトンネルを張る方式で、端末ごとに認証が必要です。Client VPNはOpenVPNという広く使われるVPNの規格に対応したクライアントソフトから接続します。認証方式には、証明書を使う相互認証、Active Directoryのアカウントを使う方式、外部のIDプロバイダーを使うSAML連携（企業のシングルサインオン基盤と連携する標準規格）があり、接続後にどの宛先へアクセスできるかは認可ルールで制御します。

試験での選び方

問題文が「リモートワークの社員が個別に接続」「移動中のノートPCから」と述べていればClient VPN、「本社と支社をつなぐ」「拠点のネットワーク全体」であればSite-to-Site VPNです。なおサーバーの管理画面へ入るだけであれば、VPNを使わずSystems Manager Session Managerを使う方が安全かつ簡単な場合もあります。

Route 53は、ドメイン名（例：example.com）を実際のサーバー（IPアドレス）に結びつけるDNSサービスです。ドメインの登録・管理もでき、公開向けの「パブリックホストゾーン」とVPC内向けの「プライベートホストゾーン」があります。AWSリソースを直接指す「エイリアスレコード」が便利です。

用語のキホン：DNSとレコード

DNSは、人が読みやすいドメイン名（example.com）を、コンピューターが使うIPアドレスに変換する「住所の電話帳」のような仕組みです。変換のルールはレコードという単位で登録し、IPを指すAレコード、別名のCNAME、AWSリソースを直接指すエイリアスなどがあります。変更の反映にかかる時間はTTL（キャッシュの有効期間）で調整します。

ルーティングポリシー

賢い振り分けが可能です。レイテンシー（最も速いリージョンへ）、加重（比率で分散）、位置情報（地域別）、フェイルオーバー（障害時に予備へ）、複数値回答などを使い分け、ヘルスチェックと連動させれば健全なサーバーへ自動誘導できます。オンプレとの相互名前解決には「Route 53 Resolver」を使います。

Route 53 Resolverのインバウンド・アウトバウンドエンドポイントを使うと、オンプレのDNSからAWS内のプライベート名を解決したり、その逆（AWSからオンプレの名前解決）を行えます。特定ドメインだけを転送する「条件付き転送」で使い分けます。

用語のキホン：名前解決の「向き」と条件付き転送

DNSの名前解決とは、ホスト名からIPアドレスを調べることです。エンドポイントは通信の向きで2種類あり、インバウンドエンドポイントはオンプレ側からAWSへ問い合わせを受け取る入口、アウトバウンドエンドポイントはAWS側からオンプレへ問い合わせを送り出す出口です。そして条件付き転送とは、「corp.example.comで終わる名前だけはオンプレのDNSに聞きに行く」というように、ドメインごとに問い合わせ先を振り分ける設定を指します。

VPC内のDNSのキホン

VPC内では、VPCのCIDRの先頭から2番目のIPアドレス（例：10.0.0.0/16なら10.0.0.2）にあるAmazon提供のDNSが名前解決を担っており、その実体がRoute 53 Resolverです。利用にはVPC設定の「DNS解決」「DNSホスト名」の有効化が前提となります。ハイブリッド環境では、オンプレとクラウドが互いのホスト名を解決できることが不可欠です。

ALBはURLやヘッダーの中身を見て振り分けるL7のロードバランサー、NLBはIPとポートだけを見て極めて高速にさばくL4、GWLBはサードパーティのファイアウォールやIDSなどの検査機器へ通信を通すための特殊なロードバランサーです。

用語のキホン：ターゲットタイプとクロスゾーン負荷分散

ターゲットグループとは振り分け先のまとまりで、その指定方法（ターゲットタイプ）にはインスタンス指定、IPアドレス指定、Lambda指定があります。またクロスゾーン負荷分散とは、AZをまたいで均等に振り分ける設定です。これが無効だと、まずAZへ均等に配られてからAZ内で分配されるため、AZごとの台数が違うと1台あたりの負荷に偏りが出ます。ALBは既定で有効、NLBは既定で無効という違いがよく問われます。

選び方の指針

Webアプリでパスによる振り分けや認証連携が要るならALB、固定IPやUDPが必要・極端な性能が要るならNLB、通信を検査機器に通したいならGWLBを選びます。NLBは送信元IPをそのまま保持できる点も特徴です。

利用者の通信を、できるだけ早くインターネットからAWSのグローバルネットワークへ引き込むことで、遅延とばらつきを減らします。CloudFrontと混同されやすいため、違いを整理して覚えるのが得点のコツです。

用語のキホン：エニーキャストとCloudFrontとの違い

エニーキャストとは、同じIPアドレスを世界中の複数拠点に持たせておき、利用者から最も近い拠点へ自動的に届ける仕組みです。Global Acceleratorはこれで受け口を作ります。決定的な違いとして、CloudFrontはコンテンツをキャッシュして配るCDNであるのに対し、Global Acceleratorはキャッシュせず、通信そのものを速く安定して運ぶサービスです。したがって画像や動画の配信ならCloudFront、オンラインゲームや音声通話などTCP・UDPのリアルタイム通信ならGlobal Acceleratorが向きます。

フェイルオーバーと重み付け

接続先リージョンのヘルスチェックが失敗すると、数十秒以内に自動で健全な別リージョンへ切り替わります。リージョンごとに割合を指定するトラフィックダイヤルもあり、段階的な移行にも使えます。

CloudFrontは、コンテンツを世界中の「エッジロケーション」にキャッシュし、利用者に最も近い拠点から配信するCDNです。遠くの元サーバー（オリジン）まで毎回取りに行かずに済むため、表示が速くなり、オリジンの負荷も下がります。オリジンにはS3・ELB・外部サーバーを指定できます。

用語のキホン：CDN・エッジ・オリジン

CDN（コンテンツ配信ネットワーク）とは、世界中に置いた拠点にコンテンツの写しを置き、利用者に近い場所から配る仕組みです。その配信拠点をエッジロケーション、元のデータがある場所（S3など）をオリジンと呼びます。エッジに写しを一時保存しておくことをキャッシュと言い、これにより表示が速くなり、オリジンへのアクセスも減ります。

キャッシュとカスタマイズ

パスごとの挙動は「ビヘイビア」で設定し、キャッシュ期間は「TTL」で調整、更新反映は「無効化（invalidation）」で行います。S3を安全に見せる「OAC」、限定配信の「署名付きURL/Cookie」、エッジで処理を差し込む「CloudFront Functions／Lambda@Edge」も使えます。

セキュリティ連携

WAFやAWS Shieldと組み合わせて、DDoSやWeb攻撃からの防御を強化できます。動的コンテンツの高速化にも利用されます。

API Gatewayは、クライアントとバックエンドの間に立つ受付窓口です。個々のアプリで作り込みがちな認証や流量制御をこの層に寄せることで、バックエンドは本来の処理に集中できます。SAA-C03では、サーバーレス構成やマイクロサービスの前段として頻出します。

用語のキホン：APIとスロットリング

APIとは、プログラム同士がやり取りするための決められた呼び出し口のことで、ウェブの世界ではHTTPのリクエストとレスポンスとして表現されるのが一般的です。多数のクライアントが同時に呼び出すと、背後のシステムが処理しきれず全体が停止するおそれがあります。これを防ぐのがスロットリングで、一定時間あたりの呼び出し回数に上限を設け、超えた分は制限を示すエラーを返す仕組みです。API Gatewayでは、全体、利用者ごと、メソッドごとといった単位で上限を設定でき、平常時の毎秒レートに加えて瞬間的な集中を吸収するバーストの枠も指定できます。利用者ごとに枠を割り当てる場合は、APIキーと使用量プランを組み合わせます。

3つのAPIタイプとキャッシュ・統合

API Gatewayには、機能が豊富なREST API、機能を絞って安価かつ低遅延にしたHTTP API、サーバーからも送信できる双方向通信のWebSocket APIがあります。REST APIでは、同じ問い合わせへの応答を一定時間ためておくキャッシュを有効にでき、バックエンドの負荷と応答時間を減らせます。バックエンドとの接続方法は統合と呼ばれ、Lambda統合のほかHTTPエンドポイントやAWSサービスを直接呼ぶ形も選べます。アクセス制御には、IAM、Cognito、Lambdaで独自判定を行うLambdaオーソライザーが使えます。

VPC内に専用のサブネットを設けて配置し、そこを通る通信を検査します。ルールはオープンソースのSuricata形式で記述でき、細かい制御が可能です。

用語のキホン：SG・NACL・Network Firewallの守備範囲

3つは守る単位と見られる深さが違います。セキュリティグループはインスタンス単位で、IPとポートを許可するだけ。ネットワークACLはサブネット単位で、IPとポートを許可・拒否するだけ。これに対しNetwork FirewallはVPC単位で、通信の中身まで見て「このドメインへのアクセスだけ許す」「既知の攻撃パターンを遮断する」といった制御ができます。中身を見て判断することをディープパケットインスペクションと呼びます。

代表的な使い方

「業務に必要なドメイン以外への外向き通信は全て遮断する」というアウトバウンドのドメイン許可リストが典型です。マルウェアが外部の指令サーバーへ通信するのを防ぐ効果があります。

AWS WAFは、HTTPやHTTPSのリクエストの中身を見て、通すか遮断するかを判断するサービスです。ネットワーク層のファイアウォールでは見抜けない、アプリケーションの作りを悪用する攻撃に対応します。ルールを自分で書くほか、AWSやセキュリティベンダーが用意した管理ルールグループをそのまま適用することもできます。

用語のキホン：L7攻撃とレート制限

通信は役割ごとに階層に分けて考えられ、いちばん上のアプリケーション層はL7（レイヤー7）と呼ばれます。ここを狙う攻撃がL7攻撃で、見た目は正常なWebアクセスなのに、中身に不正な命令が仕込まれていたり、大量に繰り返されてサーバーを消耗させたりします。代表例がSQLインジェクション（入力欄にデータベースへの命令文を紛れ込ませ、情報を抜き取る攻撃）やクロスサイトスクリプティング（他人のブラウザで動く不正なスクリプトを埋め込む攻撃）です。これに対してレート制限（レートベースルール）は、同じ送信元からの一定時間内のリクエスト数を数え、しきい値を超えた送信元を一時的に遮断する仕組みです。中身が正常に見える攻撃でも、量の異常さで捉えられる点が特徴です。

ルールの構成と試験ポイント

ルールはWeb ACL（ルールをまとめた入れ物）に登録し、それを保護対象のリソースに関連付けて有効化します。判定条件にはIPアドレス、国（地理的一致）、URLのパス、ヘッダー、ボディの内容などを使え、動作は許可・ブロック・カウント（記録のみ）から選べます。試験では「特定の国からのアクセスを遮断したい」「1つのIPからの過剰なリクエストを止めたい」「SQLインジェクション対策をしたい」といった要件が出たらAWS WAFが答えになります。Shieldがネットワーク規模の飽和攻撃を担うのに対し、AWS WAFはリクエスト単位の中身の判定を担う、という役割の違いを押さえてください。

AWS Shieldは、AWS上のリソースをDDoS攻撃から保護する専用サービスです。Standardは申し込み不要で常時働いており、一般的なネットワーク層の攻撃を自動的に緩和します。Advancedは追加契約が必要で、より大規模な攻撃への対応、詳細な可視化、専門チームによる支援が受けられます。

用語のキホン：DDoS攻撃

DDoS攻撃（分散型サービス妨害攻撃）とは、多数の端末から一斉に大量の通信を送りつけ、対象のサーバーや回線を処理しきれない状態にしてサービスを止める攻撃です。大きく分けると、回線の帯域を埋め尽くすボリューム型、通信の接続手順の不備を突くプロトコル型、正常に見えるリクエストを大量に送るアプリケーション層型があります。攻撃元が世界中に分散しているため、単純に1つのIPアドレスを遮断しても止まりません。防御の基本は、攻撃の通信を利用者のサーバーに届く手前で吸収・振り分けること、そして正常な通信と攻撃通信を見分けて捨てることです。AWSの場合、CloudFrontやRoute 53のような世界中に分散した拠点を持つサービスを前段に置くこと自体が、攻撃を分散して受け止める効果を持ちます。

StandardとAdvancedの使い分け

Standardは全AWS利用者に自動適用され、代表的なネットワーク層・トランスポート層の攻撃を防ぎます。Advancedでは、対象リソースを指定した高度な検知、攻撃時の詳細なメトリクスや通知、AWSのDDoS対応チームへのエスカレーション、そして攻撃に起因して急増した利用料金の補填申請といった仕組みが利用できます。Advancedを契約するとAWS WAFの一部機能を追加費用なしで使える点も、試験では「大規模攻撃を受けても止まらない構成」を問う設問の判断材料になります。

アカウントが数十に増えると、各アカウントで個別にWAFのルールを設定するのは現実的ではなく、設定漏れも生じます。Firewall Managerは中央のセキュリティ管理者が一度ポリシーを定義すれば、対象すべてに反映される仕組みを提供します。

用語のキホン：ファイアウォールとポリシーの一元管理

ファイアウォールとは、通信を検査して許可するか遮断するかを判断する仕組みの総称です。AWSでは、Webアプリへの攻撃を防ぐAWS WAF、大規模なDDoS攻撃から守るAWS Shield Advanced、VPCの通信を検査するAWS Network Firewall、そしてセキュリティグループがこれにあたります。Firewall Managerはこれらの設定をセキュリティポリシーとしてまとめ、適用範囲をアカウント単位やタグ単位で指定します。前提としてAWS Organizations（複数アカウントを組織として束ねる仕組み）が有効になっている必要があり、これは試験でよく問われる条件です。

試験での位置づけ

「複数アカウントにまたがって」「新規リソースにも自動的に」「セキュリティ設定の準拠状況を継続的に確認したい」という要件が並べばFirewall Managerです。単一アカウント・単一アプリの保護だけならAWS WAFを直接設定すれば足ります。設定の準拠監査という点でAWS Configと似ていますが、Firewall Managerはファイアウォール系に特化し、適用まで自動で行う点が異なります。

IAMは、AWSの操作権限を管理する仕組みです。「ユーザー」「グループ」「ロール」に「ポリシー（許可の内容をJSONで記述）」を与えて制御します。安全のため、権限は必要最小限にする「最小権限の原則」が基本です。

用語のキホン：認証と認可

アクセス管理は「認証」と「認可」の2段階で考えます。認証（Authentication）は「あなたが誰か」を確かめること（ログイン）、認可（Authorization）は「その人が何をしてよいか」を決めることです。IAMは主にこの認可（ポリシーによる操作の許可・拒否）を担い、多要素認証（MFA）などで認証も強化できます。

ロールと一時認証

特に重要なのが「IAMロール」です。EC2・Lambdaなどにロールを付与すると、STSが発行する一時的な認証情報が自動で供給され、アクセスキーをコードに埋め込まずに安全にアクセスできます。外部IdP（Google等）と連携する「フェデレーション」やクロスアカウントアクセスもロールで実現します。

ポリシー評価と保護

ポリシーには識別ベース・リソースベース・権限境界・SCPなどがあり、評価では明示的な拒否が最優先されます。重要操作にはMFA（多要素認証）を必須にでき、ルートユーザーは極力使わないのが鉄則です。

AWS RAMは、リソースをコピーしたり移動したりせずに、所有アカウントに置いたまま他アカウントへ利用権を渡す仕組みです。共有先はAWS Organizations内の組織全体、特定の組織単位、または個別のアカウントIDを指定できます。共有できるリソースの種類はサービス側で決められています。

用語のキホン：リソース共有とマルチアカウント設計

組織が大きくなると、部門やシステムごとにAWSアカウントを分けるマルチアカウント設計が一般的になります。請求の分離、権限の分離、障害の影響範囲の限定といった利点がある一方で、ネットワークのように本来1つにまとめたい要素まで重複してしまう問題が生じます。リソース共有は、この重複を避けるための考え方で、共通基盤を1つのアカウントに集約し、他アカウントはそれを借りて使います。共有されたリソースは所有アカウントの持ち物のままなので、課金や設定変更の責任は所有側に残り、利用側は決められた範囲で使うだけです。この責任の分かれ方が、統制のとれた運用につながります。

代表的な共有対象と使い分け

よく問われるのは共有VPCで、ネットワーク管理アカウントがVPCとサブネットを作り、それを各アプリケーションアカウントへ共有します。各アカウントは共有されたサブネットに自分のEC2やLambdaを配置でき、ネットワーク設計は一箇所で統制できます。ほかにTransit Gateway、Route 53 Resolverのルール、License Managerの設定などが共有対象です。VPCピアリングやTransit Gatewayが「ネットワーク同士をつなぐ」手段であるのに対し、AWS RAMは「同じリソースを一緒に使う」手段である、という違いを押さえてください。

VPC・サブネット・ENI（ネットワークカード）の単位で有効にでき、記録はCloudWatch Logs、S3、Kinesis Data Firehoseへ出力できます。

用語のキホン：何が記録され、何が記録されないか

記録されるのは、送信元・宛先のIPとポート、プロトコル、パケット数・バイト数、そしてACCEPT（許可）かREJECT（拒否）かといったメタデータだけです。通信の中身（ペイロード）は記録されません。中身まで見たい場合は後述のトラフィックミラーリングを使います。切り分けでは、REJECTが記録されていればSGやNACLが原因、そもそもログが1行も出ていなければ通信がそのENIまで到達していない（ルーティングの問題）、と当たりを付けられるのが実務上の要点です。

分析のしかた

S3へ出力してAthenaでSQL分析する、あるいはCloudWatch Logs Insightsでクエリする方法が一般的です。長期保管はS3、即時調査はCloudWatch Logsと使い分けます。

VPC Reachability Analyzerは、始点と終点を指定すると、ルートテーブル・セキュリティグループ・NACLなどの設定を辿って到達可能かを判定し、不可能な場合はどの設定でブロックされているかまで示します。トラフィックミラーリングは、ENIを流れるパケットそのものを複製して解析用のサーバーへ送ります。

用語のキホン：到達性分析とパケットキャプチャの違い

到達性分析は実際に通信を流さず、設定だけを読んで「論理的につながるか」を判定します。パケットを1つも送らないため、本番環境でも安全に実行できるのが利点です。一方パケットキャプチャ（ミラーリング）は、実際に流れている通信を複製して中身まで見る方法で、「つながってはいるが応答内容がおかしい」といったアプリ層の問題調査に向きます。「つながらない」ならReachability Analyzer、「つながるが変」ならミラーリング、と覚えると選択問題で迷いません。

使いどころ

ミラーリングは通信量が増えるため、対象や割合を絞って使います。取得したパケットは、解析用EC2上のツールや、NLB配下の解析基盤へ送って分析します。

CloudWatchは、AWSリソースやアプリの状態を監視するサービスです。CPU使用率などの「メトリクス」、アプリの「ログ（CloudWatch Logs）」、変化を表す「イベント（EventBridge）」を扱います。

用語のキホン：メトリクス・ログ・イベント

メトリクスは「CPU 70%」のような数値の時系列データ、ログはアプリやOSが出す文字の記録、イベントは「インスタンスが起動した」のような状態変化の通知です。CloudWatchはこの3つを扱い、メトリクスがしきい値を超えたら「アラーム」、イベントが起きたら「EventBridge」で、それぞれ次のアクションにつなげます。

アラームと自動化

「アラーム」でしきい値超過を検知し、SNS通知やAuto Scaling起動、Lambda実行などの自動アクションにつなげられます。OSの中の情報（メモリ使用率など）を取るには「CloudWatchエージェント」を入れます。ログを検索・分析する「Logs Insights」、状況を一覧化する「ダッシュボード」も便利です。

似たサービスとの違い

CloudWatchは「監視・メトリクス・ログ」、CloudTrailは「誰が何をしたかの監査証跡」、Configは「構成の評価」と目的が異なります。混同しやすいので区別しましょう。

クラウドの操作はほぼすべてAPI呼び出しとして行われます。CloudTrailはそのAPI呼び出しを記録し、後から検証できるようにします。既定でも直近の操作履歴は参照できますが、長期保存には証跡の作成が必要です。

用語のキホン：管理イベント・データイベント・証跡

管理イベントとは、リソースそのものを操作する記録のことで、EC2インスタンスの起動やIAMユーザーの作成などが該当します。データイベントは、リソース内のデータに対する操作の記録で、S3オブジェクトの読み書きやLambda関数の実行などが含まれます。データイベントは件数が非常に多くなるため、既定では記録されず、必要な対象を指定して有効化します。証跡（Trail）は、これらのイベントをS3バケットなどへ継続的に保存する設定のことです。証跡にはログファイル検証という機能があり、保存されたログが改ざんされていないかを確認できます。

CloudWatch・Configとの役割の違い

ここは試験で最も混同しやすい部分です。CloudTrailは「誰が何をしたか（操作の記録）」、CloudWatchは「今どう動いているか（メトリクスとログによる監視）」、Configは「今どういう設定になっているか、いつ変わったか（構成の状態と履歴）」を担当します。「不正なセキュリティグループ変更を行った犯人を特定したい」ならCloudTrail、「セキュリティグループが基準に違反していないか常に確認したい」ならConfigです。

「暗号化されていないEBSボリュームが存在しないか」「パブリック公開されたS3バケットがないか」といった確認を、人手で継続的に行うのは現実的ではありません。Configはこの点検を自動化します。

用語のキホン：構成項目・コンプライアンス・自動修復

構成項目（Configuration Item）とは、あるリソースのある時点の設定内容をスナップショットとして記録したものです。これが蓄積されることで、「1週間前はどういう設定だったか」を遡って確認できます。Configルールは、リソースが満たすべき条件を定義したもので、AWSがあらかじめ用意したマネージドルールと、Lambdaで独自に書くカスタムルールがあります。ルールに適合していれば準拠（Compliant）、違反していれば非準拠（Noncompliant）と判定されます。自動修復は、非準拠を検知した際にSystems Manager Automationのランブックを実行し、設定を自動的に正しい状態へ戻す仕組みです。

試験ポイント：継続的な評価という考え方

Configの本質は「一度きりの点検」ではなく「設定変更のたびに評価が走る継続的な監視」にあります。コンフォーマンスパックを使えば、複数のルールと修復設定をまとめて組織全体へ展開できます。監査証跡としての操作履歴が欲しいならCloudTrail、設定の状態と準拠状況が欲しいならConfig、と覚えてください。

EC2は、AWSのデータセンター上に「仮想的なコンピューター（インスタンス）」を立てて使うサービスです。「AMI」というOSやソフトのテンプレートから起動し、Webサーバー・アプリ・バッチ処理などを動かします。物理サーバーの購入や設置が不要で、数分で用意でき、不要になれば削除できます。

用語のキホン：リージョンとアベイラビリティゾーン

リージョンは「東京」「大阪」のような地理的に離れた大きな拠点、アベイラビリティゾーン（AZ）はリージョン内にある独立したデータセンター群です。1つのAZが障害で止まっても他のAZは生き残るため、サーバーを複数AZに分散して置くことが可用性設計の基本になります。なお、起動した1台1台のサーバーのことをインスタンスと呼びます。

主な構成要素

用途に応じてインスタンスタイプ（ファミリー）を選びます。バランス型の「t/m系（汎用）」、CPU重視の「c系（コンピュート最適化）」、メモリ重視の「r系（メモリ最適化）」などがあります。ディスクはEBSを接続し、ネットワークはENI（ネットワークインターフェース）とセキュリティグループで制御します。同じ構成を再利用したいときは、設定をまとめた「起動テンプレート」を使います。

料金と可用性

料金は用途で選びます。常時稼働なら割引のある「Savings Plans・リザーブド」、途中で止まってもよい処理なら最大約9割引の「スポット」です。EC2単体は1台のサーバーに過ぎないため、実運用では複数AZに分散し、Auto ScalingとELBを組み合わせて可用性とスケールを確保します。

Auto Scaling（EC2 Auto Scaling）は「Auto Scalingグループ（ASG）」という単位でEC2の台数を管理し、「最小・希望・最大」を決めておくと負荷に応じて自動で増減します。どんなインスタンスを増やすかは「起動テンプレート」で定義します。

用語のキホン：スケールアウトとスケールイン

スケールアウトは「台数を増やす」こと、スケールインは「台数を減らす」ことを指し、どちらも横に並べる台数を増減する水平スケーリングです。一方、1台あたりのCPUやメモリを大きくする（インスタンスタイプを上げる）のはスケールアップ、小さくするのはスケールダウンで、こちらは1台の性能を変える垂直スケーリングと呼びます。Auto Scalingが自動で行うのは主に水平方向で、負荷が上がれば自動でスケールアウト、下がれば自動でスケールインします。

スケーリングポリシー

増減の判断方法にはいくつかあります。目標値（例：CPU 50%）を保つように調整するターゲット追跡、しきい値ごとに段階的に増やすステップスケーリング、時間を決めて増減するスケジュールがあります。無駄な増減を防ぐ「クールダウン」、起動直後の準備時間を扱う「ウォームプール」なども関係します。

自己修復と連携

ヘルスチェック（EC2のステータス、またはELBのヘルスチェック）で異常と判断されたインスタンスを自動で終了し、新しく立て直す自己修復が大きな役割です。複数AZにまたがって台数を均等化し、ELBと組み合わせるのが定番構成です。

アプリケーションはEC2だけで動いているわけではなく、背後のデータベースやキャッシュも同時に負荷を受けます。EC2だけを増やしてもデータベースが追いつかなければ意味がありません。AWS Auto Scalingはアプリケーション全体を見た拡張を可能にします。

用語のキホン：EC2 Auto Scalingとの違い

ここは混同しやすい重要な区別です。Amazon EC2 Auto Scalingは、EC2インスタンスの台数だけを増減させる機能で、Auto Scalingグループ（同じ設定のインスタンス群の管理単位）を作り、最小・希望・最大の台数を指定して運用します。これに対してAWS Auto Scalingは、複数のサービスにまたがるリソースを1つのスケーリングプランとしてまとめて管理する上位の仕組みです。対象にはEC2 Auto Scalingグループ、DynamoDBのテーブルとインデックス、Auroraのリードレプリカ、ECSサービス、Spot Fleetなどが含まれます。試験で「単一のアプリケーションを構成する複数リソースを統合的にスケールしたい」とあれば、こちらを選びます。

スケーリング方式

ターゲット追跡は、CPU使用率70パーセントといった目標値を維持するように自動調整する方式で、最も設定が簡単です。ステップスケーリングは、しきい値の超過幅に応じて増減量を変える方式、スケジュールスケーリングは、負荷の増える時間帯があらかじめ分かっている場合に時刻で増減させる方式です。AWS Auto Scalingでは、可用性優先・コスト優先などの方針を選ぶだけで推奨設定を生成することもできます。

Lambdaは、サーバーの構築やOS管理をせずに「関数（コード）」を実行できるサービスです。何かのイベントをきっかけに自動で動き、実行時間（ミリ秒単位）と割り当てメモリに応じて課金されます。待機している間は料金がかかりません。

用語のキホン：サーバーレスとイベント駆動

サーバーレスとは「サーバーが無い」という意味ではなく、サーバーの用意・管理を利用者が意識しなくてよい方式のことです。イベント駆動とは、常に動かし続けるのではなく「何かが起きたとき（イベント）」にだけ処理を動かす考え方です。Lambdaはこの2つの代表で、イベントが来たときだけ動き、動いた分だけ課金されます。

実行の仕組み

呼び出し方は、応答を待つ同期（API Gatewayなど）、投げっぱなしの非同期（S3イベントなど・自動リトライあり）、順番に処理するストリーム（DynamoDB StreamsやKinesis）があります。割り当てメモリを増やすとCPUも比例して増えます。最大実行時間は15分で、それを超える処理には向きません。しばらく呼ばれないと初回起動が少し遅くなる「コールドスタート」も特徴です。

関連する仕組み

共通ライブラリは「レイヤー」で共有でき、VPC内のリソース（RDS等）へアクセスするにはVPC接続の設定が必要です。過負荷を防ぐ「同時実行数」の管理や、失敗時の退避先（デッドレターキュー）も重要です。

FargateはECSとEKSの両方で使える「起動タイプ」です。コンテナに必要なCPUとメモリを指定するだけで実行され、その裏側のサーバーは意識しません。

用語のキホン：サーバーレスコンテナという考え方

従来のEC2起動タイプでは、コンテナを載せるためのEC2群（クラスター）を自分で用意し、台数が足りているか、OSに脆弱性がないかを管理する必要がありました。Fargateはこの層をAWSに委ねる方式で、サーバーレスコンテナと呼ばれます。利用者の責任範囲がコンテナイメージとその設定だけに縮まるため、運用負荷が大きく下がります。これは責任共有モデルにおける境界線が、より AWS 側に寄ることを意味します。

トレードオフ

単価はEC2起動タイプより割高で、GPUの利用や細かなカーネル設定はできません。「変動が大きく管理を減らしたい」ならFargate、「常時高負荷でコストを詰めたい・特殊要件がある」ならEC2起動タイプ、が基本の判断軸です。

ECSは、コンテナをまとめて運用するためのAWS独自のサービスです。IAMやELB、CloudWatchとそのまま統合できるため、AWS中心の構成では最も導入しやすい選択肢になります。

用語のキホン：コンテナとオーケストレーション

コンテナとは、アプリと必要なライブラリを1つにまとめ、どの環境でも同じように動かせるようにした軽量な実行単位です。仮想マシンと違いOSごと持たないため、起動が速く軽量です。多数のコンテナについて「何個動かすか、異常なら再起動するか、どう振り分けるか」まで自動で管理する仕組みをオーケストレーションと呼び、ECSがこれを担います。

タスクとサービス

実際に動くコンテナのひとまとまりをタスク、その設計図をタスク定義と呼びます。そして「常時この数のタスクを維持し、落ちたら補充する」という継続稼働の仕組みがサービスです。動かす土台は、自分で管理するEC2起動タイプと、AWSに任せるFargateから選べます。

EKSは、コンテナオーケストレーションの業界標準であるKubernetesを、AWS上でマネージドに使えるようにしたサービスです。

用語のキホン：Kubernetesとコントロールプレーン

Kubernetesは、コンテナの配置・自動復旧・負荷分散を宣言的に管理するオープンソースの基盤です。「あるべき状態」をマニフェストに書くと、実際の状態がそこへ収束します。Kubernetesは指令を出すコントロールプレーンと、実際にコンテナが動くデータプレーン（ワーカーノード）に分かれ、このうち構築・運用が最も難しいコントロールプレーンをAWSが管理してくれるのがEKSです。コンテナの最小実行単位はポッドと呼ばれます。

ECSとの選び分け

AWSに寄せてシンプルに運用したいならECS、既存のKubernetes資産や他クラウドとの共通化を活かしたいならEKSが基本です。EKSは機能が豊富な反面、学習コストと管理コストは高くなります。

ECSやEKSがコンテナを起動する際、その元になるイメージを取得する先がECRです。プライベートな倉庫として、社内のイメージを安全に保管できます。

用語のキホン：イメージ・レジストリ・タグ

コンテナイメージは、アプリと実行環境をまとめて固めた「テンプレート」で、これを起動したものがコンテナです。そのイメージを保管・配布する場所がレジストリで、ECRがこれにあたります。イメージにはタグ（v1.2、latestなど）を付けて版を区別します。ただしタグは付け替えられるため、同一性を厳密に保証したい場合は内容から算出されるダイジェストで指定します。

セキュリティとコスト管理

登録時に自動で脆弱性スキャンを行えます（Amazon Inspectorと連携）。またライフサイクルポリシーで「古いイメージは自動削除」と設定でき、保管料金の膨張を防げます。

EventBridgeは以前CloudWatch Eventsと呼ばれていたサービスが発展したもので、現在はAWS内のイベント連携における標準的な選択肢です。SAA-C03では「AWSリソースの状態変化に応じて自動処理を起動する」設計で登場します。イベントはJSON形式で表現され、内容を見て柔軟に条件を書ける点が強みです。

用語のキホン：イベント駆動アーキテクチャ

イベントとは「何かが起きた」という事実を表すデータで、たとえば「EC2インスタンスが停止した」「ファイルが保存された」といった記録です。イベントが発生したことをきっかけに処理を動かす設計をイベント駆動アーキテクチャと呼びます。定期的に状態を確認しにいくポーリング方式と比べて無駄が少なく、反応も早くなります。イベントの送り手と受け手は互いを知らないため、SNSと同様に疎結合が保たれます。

イベントバス・ルール・スケジュール

イベントバスはイベントが集まる経路で、AWSサービスの出来事が自動的に流れ込むデフォルトバス、自分のアプリ用に作るカスタムバス、SaaS連携用のパートナーイベントバスがあります。ルールはバスを流れるイベントを条件で選び分ける設定で、条件式をイベントパターンと呼びます。合致したイベントの送り先をターゲットといい、Lambda、SQS、SNS、Step Functionsなど多数を指定できます。さらにcron形式などで時刻を指定するスケジュールルールも作れるため、定期バッチの起動にも使えます。

SNSはメッセージを保管して待たせるSQSとは役割が異なり、届いた瞬間に登録先へ押し出すのが特徴です。SAA-C03では、SQSとの組み合わせで出題されることが非常に多いサービスです。標準トピックのほかに、順序と重複排除を保証するFIFOトピックも用意されています。

用語のキホン：パブリッシュ・サブスクライブ（Pub/Sub）

パブリッシュ・サブスクライブとは、送信者が特定の相手を指定せず、トピックという名前の置き場所にメッセージを投げる通信方式です。メッセージを投げる行為をパブリッシュ（発行）、そのトピックを受け取りたいと登録することをサブスクライブ（購読）といいます。送信者は誰が受け取るかを知る必要がなく、受信側の追加や削除をしても送信側のコードは変わりません。SQSが一対一の受け渡しであるのに対し、こちらは一対多の配信になる点が大きな違いです。配信に失敗したメッセージはリトライされ、それでも届かない場合はデッドレターキューへ退避できます。

ファンアウトとメッセージフィルタリング

1つのSNSトピックに複数のSQSキューを購読させ、1回の発行で各キューへ同じメッセージを配る構成をファンアウトと呼びます。各キューの先で別々の処理を並行して走らせられるうえ、SQSが受け皿になるため、処理側が一時停止してもメッセージを失いません。また、メッセージに付けた属性をもとに購読者ごとに受け取る条件を絞るメッセージフィルタリングも設定でき、不要な処理の起動を減らせます。

SQSはAWSで最も古くから提供されているサービスの一つで、分散システムの基本部品として位置づけられています。SAA-C03では「疎結合にする」「急なアクセス増を吸収する」という設計課題の答えとして頻繁に登場します。サーバーの管理は不要で、必要な分だけ自動的に拡張されます。

用語のキホン：キューイングと非同期処理

キューとは、処理してほしい仕事を一時的にためておく待ち行列のことです。仕事を出す側をプロデューサー（送信者）、取り出して処理する側をコンシューマー（受信者）と呼びます。送信者は受信者の返事を待たずに次の作業へ進めるため、この方式を非同期処理といいます。両者が直接つながっていない状態を疎結合と呼び、片方が障害で停止しても、もう片方は動き続けられるという利点があります。さらに、急激なアクセス増加が起きてもキューがメッセージをためて受信者を守るため、この効果を負荷平準化（バッファリング）と呼びます。

可視性タイムアウトとデッドレターキュー

受信者がメッセージを取り出すと、そのメッセージは一定時間ほかの受信者から見えなくなります。これを可視性タイムアウトといい、同じ仕事を複数のサーバーが二重に処理しないための仕組みです。受信者が処理を終えて削除操作を行えばメッセージは消えますが、時間内に終わらなければ再びキューに現れ、別の受信者が処理します。何度失敗しても消えないメッセージは他の処理を妨げるため、規定回数を超えたものを退避させる専用キューを用意します。これをデッドレターキュー（DLQ）と呼び、後から原因を調査できます。

標準キューとFIFOキューの使い分け

標準キューは非常に高いスループットを出せますが、順序は保証されず、まれに同じメッセージが二重に届くことがあります。そのため受信側は、同じ処理を複数回受け取っても結果が変わらない冪等（べきとう）な作りにしておく必要があります。一方FIFOキューは送った順番どおりに一度だけ届くことを保証しますが、処理できる件数の上限は標準キューより低くなります。試験では「順序が重要か」「重複を許容できるか」で選び分けます。

S3は、写真・動画・ログ・バックアップなどの「オブジェクト（ファイル）」を、容量を気にせず保管できるサービスです。データは「バケット」に入れ、「キー（ファイル名のようなもの）」で管理します。保存したデータは自動的に複数AZへ複製され、99.999999999%（イレブンナイン）という非常に高い耐久性を実現します。書き込み後すぐ読める「強い整合性」を持ちます。

用語のキホン：3種類のストレージ

AWSのストレージは大きく3種類あり、役割が異なります。オブジェクトストレージ（S3）はファイルを丸ごと出し入れする方式でWeb配信やバックアップ向き、ブロックストレージ（EBS）はOSやDBが使うディスク、ファイルストレージ（EFS）は複数サーバーで共有するフォルダです。S3はこのうちオブジェクト型で、ファイルの部分書き換えより「まるごと保存・取得」を得意とします。

コスト最適化と管理機能

アクセス頻度に応じ「標準／標準-IA（低頻度）／One Zone-IA／Glacier系（アーカイブ）」から選びます。自動で変化させたい場合は「ライフサイクルルール」で古いデータをGlacierへ移したり削除したりします。誤削除に備える「バージョニング」、別リージョンへ複製する「レプリケーション（CRR）」もあります。

セキュリティ

暗号化は「SSE-S3」「SSE-KMS」などから選べます。アクセス制御はバケットポリシー・IAM・ACLで行い、誤公開を防ぐ「ブロックパブリックアクセス」を有効にするのが基本です。VPC内から非インターネット経由でアクセスするにはゲートウェイ型VPCエンドポイントを使います。

本番環境と検証環境で設定が微妙に違ってしまう、という問題は多くの現場で起こります。CloudFormationはインフラの定義をコードとして扱うことで、この差異をなくします。テンプレートはJSONまたはYAML形式で記述します。

用語のキホン：スタック・変更セット・ドリフト・べき等性

スタックとは、1つのテンプレートから作られたリソースのまとまりのことです。スタックを削除すれば、その中のリソースがまとめて消えるため、後片付けが簡単になります。変更セットは、テンプレートを更新したときに「何が追加・変更・削除されるか」を実行前に確認できる差分プレビューの仕組みです。ドリフトは、テンプレートの定義とAWS上の実際の状態がずれてしまった状態を指し、誰かがコンソールから手作業で設定を変えた場合などに発生します。べき等性とは、同じ操作を何度実行しても結果が同じになる性質のことで、CloudFormationはこの性質を持つため、繰り返し適用しても環境が壊れません。

仕組みと試験ポイント

更新中にエラーが起きると、既定ではロールバック（変更前の状態へ自動的に戻す動作）が働き、中途半端な構成になることを防ぎます。複数のアカウントやリージョンへ同じテンプレートを一括展開したい場合はStackSetsという機能を使います。試験では「環境を再現可能にしたい」「インフラをコードで管理したい」という要件が出たら、まずCloudFormationを検討します。

企業では、部門ごと・環境ごとにAWSアカウントを分けるのが一般的です。アカウントを分けると影響範囲を隔離できますが、数が増えると管理が煩雑になります。Organizationsはその管理を一元化します。

用語のキホン：OU・SCP・ガードレール

OU（Organizational Unit、組織単位）とは、アカウントをグループ化するための入れ物で、フォルダのように階層構造を作れます。SCP（Service Control Policy、サービスコントロールポリシー）は、OUやアカウントに対して「これ以上のことはできない」という上限を定めるポリシーです。ここで重要なのは、SCPは権限を与えるものではなく、あくまで許可の上限を絞るものだという点です。実際に操作できるかどうかは、SCPの上限とIAMポリシーの許可の両方を満たすかで決まります。ガードレールとは、利用者の自由をある程度残しつつ、危険な操作だけを組織的に禁止する考え方を指す言葉です。

一括請求と試験ポイント

一括請求（Consolidated Billing）により、組織内の全アカウントの利用料をまとめて支払えます。使用量が合算されるため、ボリューム割引やリザーブドインスタンスの割引を組織全体で共有しやすくなります。試験では「全アカウントで特定リージョン以外の利用を禁止したい」といった要件はSCP、「アカウントごとの権限設定」はIAMと切り分けて考えます。

OrganizationsやConfig、CloudTrail、IAM Identity Centerを自分で組み合わせてマルチアカウント基盤を作ることもできますが、設計と構築には相応の手間がかかります。Control Towerはその一式をAWSの推奨構成で自動的に用意します。

用語のキホン：ランディングゾーン・コントロール・アカウントファクトリー

ランディングゾーンとは、統制の効いたマルチアカウント環境の初期構成一式のことです。Control Towerはこれを自動生成し、ログ保管用アカウントと監査用アカウントを分離して作成します。コントロール（旧称ガードレール）は適用するルールのことで、必ず適用される必須、推奨される強く推奨、任意の選択的に分類されます。動作の観点では、違反操作をそもそも実行させない予防的コントロール（SCPで実現）と、違反を後から検知して報告する発見的コントロール（Configルールで実現）に分かれます。アカウントファクトリーは、統制済みの新規アカウントをテンプレートから払い出す機能です。

試験ポイント：Organizationsとの関係

Control TowerはOrganizationsの代替ではなく、その上に構築されるオーケストレーション層です。細かく自分で設計したい場合はOrganizationsを直接使い、素早く推奨構成を立ち上げたい場合はControl Towerを選びます。

AWSは長年の運用で得られたベストプラクティスを蓄積しており、Trusted Advisorはそれを自分の環境に照らして自動チェックしてくれます。コンソールを開くだけで結果が確認でき、追加の設定はほとんど不要です。

用語のキホン：5つのチェックカテゴリ

Trusted Advisorの点検は、コスト最適化、パフォーマンス、セキュリティ、フォールトトレランス（障害耐性）、サービスクォータ（利用上限）という5つのカテゴリに分かれています。フォールトトレランスとは、一部が壊れてもシステム全体が動き続ける性質のことで、たとえばEC2が単一のアベイラビリティゾーンに偏っていないかが点検されます。サービスクォータとは、アカウントごとに定められた各リソースの作成上限のことで、上限に近づくと警告が出ます。なお、全カテゴリの全チェックを利用できるのはビジネス以上のサポートプランで、基本のプランでは一部のチェックに限定されます。

試験ポイント：他サービスとの使い分け

Trusted Advisorは「幅広く浅く、既定のベストプラクティスに照らして助言する」ツールです。より深く設計思想まで踏み込んで評価したい場合はWell-Architected Tool、EC2などのサイズが適切かを実測値から判断したい場合はCompute Optimizerが適します。

AWSは良いアーキテクチャの考え方をWell-Architected フレームワークとして文書化しています。このツールは、その文書をチェックリスト形式でシステムに適用し、レビュー結果をレポートとして残せるようにしたものです。

用語のキホン：6つの柱とワークロード

フレームワークは6つの柱で構成されます。運用上の優秀性（運用を継続的に改善できるか）、セキュリティ（データと資産を守れるか）、信頼性（障害から回復できるか）、パフォーマンス効率（リソースを適切に選び使えているか）、コスト最適化（不要な支出を避けられているか）、持続可能性（環境負荷を減らせているか）です。診断の単位はワークロードと呼ばれ、これは1つのビジネス価値を提供するアプリケーションとリソースのまとまりを指します。診断結果は高リスク項目と中リスク項目として提示され、改善計画を立てる材料になります。

試験ポイント：レビューのタイミング

Well-Architectedのレビューは、設計段階だけでなく本番稼働後も定期的に行うことが推奨されます。マイルストーンという機能で、ある時点のレビュー結果を保存でき、時間の経過とともにどれだけ改善したかを比較できます。自動で環境をスキャンするTrusted Advisorとは異なり、こちらは人が設問に答える定性的なレビューである点が違いです。

システムに異常が出たとき、原因が自社の変更なのかAWS基盤側の問題なのかを早く判断できると、対応時間を大きく短縮できます。Health Dashboardはその判断材料を提供します。

用語のキホン：サービス正常性とアカウント固有のイベント

Health Dashboardには2つの視点があります。サービス正常性（Service health）は、全利用者に共通の、リージョンごとのサービス稼働状況を示す公開情報です。もう一方のアカウント固有のイベント（Your account health）は、自分のアカウントのリソースにだけ関係する通知で、たとえば「あなたが使っている特定のEC2インスタンスが基盤メンテナンスのため再起動されます」といった内容が届きます。後者はAWS Health APIで取得でき、EventBridgeと組み合わせて自動処理につなげられます。なおAPIによる取得はビジネス以上のサポートプランが前提です。

試験ポイント

試験では「AWS側の計画メンテナンス通知を自動で受け取り、対応を自動化したい」という要件で登場します。この場合、Health イベントをEventBridgeで受け取り、SNS通知やLambdaによる自動対応につなげる構成が定番です。

AWS CLIは自分のパソコンやサーバーにインストールして使います。マネジメントコンソールで行えることのほとんどは、CLIからも実行できます。裏側では同じAWS APIを呼び出しているため、CLIでの操作もCloudTrailに記録されます。

用語のキホン：プロファイル・認証情報・リージョン設定

CLIを使うには、まずAWSに自分が誰であるかを伝える認証情報が必要です。これはアクセスキーIDとシークレットアクセスキーの組、あるいはIAMロールによる一時的な認証情報として与えられます。プロファイルとは、この認証情報と既定リージョン、出力形式をまとめて名前を付けた設定の単位で、複数アカウントを扱う際は名前を切り替えて使い分けます。EC2やLambdaの上でCLIを動かす場合は、キーをファイルに置かずIAMロールを割り当てるのが推奨される方法です。キーの漏えいリスクがなく、認証情報が自動的に更新されるためです。

試験ポイント

コマンドは「aws サービス名 操作名」という形式で統一されています。結果はJSONなどの構造化データで返るため、他のツールと組み合わせた自動処理に向きます。試験では「アクセスキーをコードに埋め込むのは避け、IAMロールを使う」という原則が繰り返し問われます。

マネジメントコンソールは、AWSを学び始めるときの入口になる存在です。一方で、本番環境の運用では手作業による設定ミスや再現性の欠如が問題になるため、コードによる管理と併用するのが実務での基本になります。

用語のキホン：ルートユーザーとIAMユーザー・ロールの切り替え

コンソールへのサインイン方法は複数あります。ルートユーザーとは、アカウント作成時のメールアドレスでログインする最上位の利用者で、すべての操作が可能なため、日常的な作業には使わず厳重に保護すべき存在です。日常の操作にはIAMユーザーや、IAM Identity Centerを通じた一元的なサインインを使います。スイッチロールは、別アカウントのIAMロール（一時的な権限のまとまり）へ画面上で切り替える機能で、マルチアカウント環境では日常的に使われます。いずれの場合も多要素認証（パスワードに加えて別の要素で本人確認する仕組み）の有効化が強く推奨されます。

試験ポイント：グローバルとリージョンの区別

コンソールでは右上でリージョンを切り替えますが、IAMやRoute 53、CloudFrontなどはグローバルサービスのためリージョン選択の影響を受けません。リソースが見つからないときは、リージョンの選択間違いをまず疑うとよいでしょう。また、コンソールで行った操作もCLIと同様にCloudTrailへ記録されます。

請求書の合計金額だけでは、費用が増えた原因はわかりません。Cost Explorerは同じ費用データを多角的に切り替えて眺められるため、増加の要因を素早く特定できます。マネジメントコンソールから利用でき、分析用のAPIも提供されています。

用語のキホン：コスト配分とタグ

AWSの費用を部門やプロジェクトごとに把握するには、リソースに目印を付けておく必要があります。この目印がキーと値の組で付けるタグで、費用の集計軸として使うと宣言したものをコスト配分タグと呼びます。有効化した時点以降のデータに反映されるため、運用開始時に付与ルールを決めておくことが大切です。また複数アカウントをまとめて管理するAWS Organizationsを使っている場合、請求を1つにまとめる一括請求（コンソリデーティッドビリング）により、管理アカウントから全体の費用を横断的に分析できます。この仕組みには、複数アカウントの利用量を合算してボリューム割引が効きやすくなる利点もあります。

できることと近いサービスとの違い

Cost Explorerでは過去の費用推移の表示に加え、実績をもとにした将来の費用予測、Savings PlansやRIの購入推奨、購入済み割引がどれだけ使われたかを示す使用率レポートとカバレッジレポートが確認できます。あくまで分析と可視化のためのツールであり、予算超過を知らせる役割はAWS Budgets、明細レベルの生データはCost and Usage Reportが担います。