AWS認定の無料練習問題
毎日5問、解説で学ぶ。

正解はAとBです。 【A について】ALB は IPv4/IPv6 の Dualstack プロトコルに対応し、Layer 7 機能によってリクエストパスやホスト名に基づくルーティングが可能です。複数 AZ 配置により高可用性を実現します。要件 1・2・4 を満たす基礎的な構成要素として必須です。 【B について】AWS WAF は web ACL という保護ポリシーを定義し、ALB などの保護対象リソースに関連付けることで、SQLインジェクション、XSS、ボット攻撃など複数の脅威パターンを検知・ブロックします。要件 3 のセキュリティ対策を実装するために必須です。 【C について】NLB は Layer 4 で動作し、TCP/UDP ポートレベルの負荷分散に特化していますが、HTTP リクエストのパスやホスト名に基づくルーティングは Layer 7 機能のため対応していません。マイクロサービスのパスベースルーティング（要件 2）が実現できないため、この要件セットでは不適切です。 【D について】Classic Load Balancer は IPv4 のみのサポートであり、IPv6 に対応していません。公式ドキュメントで明記されている通り、要件 1 の IPv4/IPv6 両対応を実現できません。 【E について】Global Accelerator は複数地域からのアクセス経路を最適化するサービスですが、この問題では要件として明記されていません。基本的なマルチAZ構成と要件内容の対応には必須ではなく、追加的な最適化ソリューションに該当します。

A：要件1（IPv4/IPv6対応）と要件2（パス/ホスト名ベースルーティング）を満たすために必須の選択です。ALBはIPv4とIPv6の両方を同時にサポートするDualstackに対応しており、Layer 7機能によってリクエストパスに基づくマイクロサービスへのルーティングが可能です。複数AZ配置により要件4の高可用性も実現します。

B：要件3の不正アクセス対策を実装するために必須の選択です。AWS WAF は web ACL を通じて、指定した保護対象リソース（この場合はALB）に対して、攻撃パターンに基づいた検知・ブロックルールを設定できます。SQLインジェクション、XSS、ボット攻撃など複数の脅威に対するルール群を web ACL に追加することで、要件を満たします。

C：NLBはIPv6に対応しており高スループット環境に優れていますが、Layer 4（トランスポート層）で動作するため、HTTPのリクエストパスやホスト名に基づいたルーティングができません。要件2のマイクロサービスルーティング（パス/ホスト名ベース）は Layer 7機能であり、NLBではサポートされていないため、この要件を満たしません。

D：Classic Load Balancer はIPv4のみのサポートであり、IPv6のDualstack機能に対応していません。公式ドキュメントで確認可能な通り、Classic LB の対応プロトコルは IPv4 のみとなっているため、要件1（IPv4/IPv6対応）を満たすことができません。

E：Global Accelerator は地理的に分散したクライアントからのアクセス経路を最適化するサービスですが、この問題の要件には明記されていません。ALB本体でアジア太平洋地域のクライアント要件に対応可能であり、Global Accelerator は要件外の追加機能に該当します。基本的な要件（IPv4/IPv6対応、パスベースルーティング、セキュリティ、複数AZ）を満たすには含める必要がありません。

学習のポイント：Load Balancer の選択は、要件で求められるルーティングレイヤーと対応プロトコル（IPv4/IPv6）を組み合わせて判断する必要があります。パスベースルーティングは Layer 7 機能であり、NLB などの Layer 4 ロードバランサーでは実装できません。

公式ドキュメント

• how-elastic-load-balancing-works.html
• how-aws-waf-works.html

この問題の鍵は、クロスゾーンロードバランシングの動作原理にあります。参考ドキュメント1では、「クロスゾーンロードバランシング有効時、各ロードバランサーノードが全AZの登録済みターゲットに均等にトラフィックを分配する」と明記されています。 無効時の振る舞い：各ノードが同一AZ内のターゲットのみに分配するため、AZ-A の3ターゲット対 AZ-B の9ターゲットという不均等が「そのまま反映」され、AZ-A 内の各ターゲットが25%、AZ-B 内の各ターゲットが約6.25%のトラフィック受取となります。 有効時の振る舞い：全12ターゲットが均等に約8.3%ずつ受け取ります。ここが重要で、「ポッド数が異なるAZ構成でも、クロスゾーンロードバランシング有効にすると均等性が実現される」という原理です。 AZ可用性の観点では、無効状態でAZ-A が完全にダウンすると、AZ-A 向けにルーティングされていたトラフィック枠がロストされます（設計上、ALBノードはAZ間で50%ずつ分配されるため）。有効状態なら、残りのAZ-B内ターゲットがすべてのトラフィックを吸収できます。

A：クロスゾーンロードバランシング有効時、参考ドキュメントの記述に従えば「各ロードバランサーノードが、有効なすべての可用性ゾーン内の登録済みターゲット全体にトラフィックを分配」されます。結果として、AZ-A の3ポッドと AZ-B の9ポッドが均等に約8.3%のトラフィックを受け取ります。AZ-A が完全にダウンしても、AZ-B の9ポッドがすべてのトラフィック需要を吸収でき、負荷分散が成立します。

B：Route 53 はこの問題の in-scope サービスに含まれ、複数のAZ間でのトラフィック分配に使用できますが、単一のLoad Balancer Controllerによる Ingress リソースの管理では、同一のALBを複数リージョン/AZに複製する必要があります。問題はKubernetesの単一クラスタ内での Ingress 統合を求めており、この選択肢は過度な複雑性をもたらします。

C：セッション親和性は「同じクライアントを同じターゲットにルーティング」する機能であり、AZ間の負荷均等配分には対応しません。むしろ、AZ-B のターゲット数が多いため、AZ-A がダウン時にそのセッションが喪失されるという可用性の問題をもたらします。

D：クロスゾーンロードバランシング無効時は、各ノードが同一AZ内のターゲットのみにトラフィック分配します。AZ-A（3ターゲット）がダウンすると、AZ-A に割り当てられていたトラフィック枠（約50%）がロストされ、AZ-B だけでは全体需要を処理できません。また、AZ-A と AZ-B 間で負荷が不均等（AZ-A 内の各ターゲットが25%、AZ-B 内の各ターゲットが約5.6%）になります。

学習のポイント：クロスゾーンロードバランシング有効時、各ロードバランサーノードは全AZ内のすべてのターゲットにトラフィック分配するため、AZ間のターゲット数差異が均等負荷を阻害しない。AZ可用性喪失時、残存AZが全容量を処理できる設計になる。

公式ドキュメント

• how-elastic-load-balancing-works.html
• aws-load-balancer-controller.html

この問題は、セキュリティ要件の下で CloudWatch Logs にログを安全に送信するアーキテクチャを選択する能力を問うています。 選択肢A が正解の理由：CloudWatch Logs を VPC 内からプライベートにアクセスするには、interface VPC endpoint が必須です。サービス名 com.amazonaws.region.logs を指定することで、VPC 内のリソースが public internet を経由せずに CloudWatch Logs と通信できるようになります。 選択肢B が正解の理由：VPC endpoint を作成した後、endpoint policy を適切に設定しなければ、実際には CloudWatch Logs API を呼び出すことができません。Policy により、VPC 内のエンティティに対して log stream の作成や log event の送信といった必要な操作を許可することが必須です。Endpoint policy は JSON 形式で記述され、その中に適切な permissions が記載される必要があります。 選択肢C が不正解の理由：Internet Gateway を使用することは、問題文で明示的に禁止された『public な経路を使用しない』という要件に直接に反します。また、VPC endpoint を使用することでプライベート接続が可能であるため、public internet への接続は不要です。 選択肢D が不正解の理由：Transit Gateway は複数の VPC や on-premises ネットワークを接続するサービスであり、VPC から CloudWatch Logs への接続を提供するものではありません。この問題の要件を解決するツールとして不適切です。また、複数 VPC を経由するルーティングは不要な複雑さを導入します。 選択肢E が不正解の理由：VPC Flow Logs は CloudWatch Logs に直接送信できるため、S3 経由での転送は不要なステップです。このアプローチは運用の複雑さを増加させ、ログの遅延を導入し、さらに追加の IAM 権限管理が必要になります。最小限で必要なアーキテクチャを選択すべきです。

A：プライベート接続でCloudWatch Logsにアクセスするには、interface VPC endpoint が必須です。このendpointを通じてVPC内からCloudWatch Logsサービスに直接接続できます。public internet を経由する必要がなくなり、セキュリティ要件を満たします。

B：Interface VPC endpoint を作成しただけでは不十分です。Endpoint policy を JSON形式で設定することにより、VPC内のリソースが CloudWatch Logs に対して log stream の作成やログ送信などの操作を実行できるようになります。ポリシーの設定はendpointの機能を有効にするために必須です。

C：この方法は問題文で明確に禁止されたアプローチです。Internet Gateway を通じて public internet に接続することは、セキュリティ要件の『プライベートVPC内に通信を収める』という条件に反します。また、flow logs をCloud Watch に送信するにはVPC endpointを使用すべきです。

D：Transit Gateway は複数VPC間のルーティングのためのサービスであり、VPC内から CloudWatch Logs への接続を提供するものではありません。また、複数VPC経由のルーティングは不要な複雑さを増し、セキュリティ要件の解決策として不適切です。VPC endpoint を使用したプライベート接続の方が直接的で効率的です。

E：この方法は不要な複雑さを追加しています。VPC Flow Logs は CloudWatch Logs に直接送信できるため、S3 を経由する必要はありません。また、S3 から CloudWatch Logs への転送プロセスを管理することは、運用負担を増加させ、セキュリティ要件を満たすための最小限のステップ原則に反しています。

学習のポイント：VPC 内から AWS マネージドサービスにプライベートアクセスする場合、interface VPC endpoint とそのポリシー設定が必須であり、これにより public internet を経由しないセキュアな通信が実現される。

公式ドキュメント

• cloudwatch-logs-and-interface-VPC.html

プライベートホストゾーン環境でのヘルスチェック実装には重要な物理的制約があります。Route 53 health checkersはVPC外に配置されているため、VPC内のプライベートIPアドレスのみを持つインスタンスに直接アクセスできません。 選択肢Aは、VPC側のセキュリティグループ設定を提案していますが、この制約はネットワークアーキテクチャの問題であり、セキュリティグループの設定変更では解決しません。 選択肢Bが正解です。VPC外のヘルスチェッカーが直接到達できないという制約を回避するには、CloudWatchメトリクスとアラームを活用します。インスタンス内で収集されるEC2メトリクス（StatusCheckFailedなど）をCloudWatchで監視し、その監視データに基づくアラームを作成してから、Route 53でそのアラームのデータストリームに基づくヘルスチェックを構成します。これにより、インスタンスのヘルスをプライベートIPのみの状態で監視できます。 選択肢Cは、プライベートIPアドレスの数を増やすことを提案していますが、Route 53 health checkersがVPC外にあるという根本的な制約は変わらないため、複数のIPが存在しても直接アクセスはできません。 選択肢Dは、Route 53 health checkersをVPC内に導入することを提案していますが、Route 53 health checkersはAWSマネージドサービスであり、お客様がVPC内に配置することはできません。

A：このアプローチは機能しません。Route 53 health checkersはVPC外に配置されており、VPC内のセキュリティグループルールの修正だけではVPC外からのアクセスが実現できないという根本的な制約があります。セキュリティグループの設定変更ではVPC外のリソースがプライベートIPに到達できません。

B：これが正しいアプローチです。Route 53がVPC外にあるために直接プライベートIPにアクセスできないという制約がある場合、CloudWatchメトリクスを活用した代替手段が有効です。EC2のStatusCheckFailedメトリクスをCloudWatchで監視し、そのメトリクスに対するアラームを作成してから、そのアラームデータに基づくヘルスチェックをRoute 53で構成することで、セキュリティ要件を満たしながらフェイルオーバーを実現できます。

C：プライベートIPアドレスを追加しても根本的な問題は解決しません。Route 53 health checkersはVPC外に配置されているため、複数のプライベートIPアドレスが存在していても、それらに直接アクセスすることはできません。追加のIPアドレスはこの物理的な配置の制約を変えません。

D：Route 53 health checkersをVPC内に導入することはできません。Route 53 health checkersはAWSが管理する外部サービスであり、お客様がVPC内に配置することは実装不可能なアプローチです。AWS PrivateLinkはサービスへのアクセス方法を変えるものではなく、health checkerのアーキテクチャそのものは変わりません。

学習のポイント：Route 53 health checkersはVPC外にあるため、プライベートIPのみのインスタンスに直接アクセスできない制約がある場合、CloudWatchメトリクス + アラーム + ヘルスチェックの組み合わせが必要な実装方法です。

公式ドキュメント

• dns-failover-private-hosted-zones.html

この問題は、Transit Gatewayでのリアルタイムトラフィック異常検出の要件を、CloudWatchアラームという具体的なメカニズムで実現する方法を問うています。 A（VPC Flow Logs）はトラフィック詳細の記録には有用ですが、自動通知機能がないため、急激な変化への即座の対応という要件に対応できません。 B（CloudWatchアラーム）は、Transit Gatewayがパブリッシュするメトリクスを監視し、しきい値超過時に自動的に通知を発行できます。トラフィック急増やDDoS攻撃によるバイト数・パケット数の急激な増加を検出し、即座にネットワーク管理者に通知できるため、要件を完全に満たします。 C（CloudTrail）はAPI呼び出しと設定変更を記録する監査ツールであり、ネットワークトラフィック自体の監視には利用されません。 D（Trusted Advisor）はセキュリティベストプラクティスの定期監査に用いられるもので、リアルタイムの異常検出には適していません。

A：VPC Flow Logsはトラフィック詳細を記録しますが、記録されたログを分析する必要があり、リアルタイムの自動通知機能を備えていません。急激な変化への即座の対応という要件には不十分です。

B：Transit GatewayはCloudWatchにメトリクス（BytesIn、PacketsInなど）をパブリッシュします。これらのメトリクスに基づくCloudWatchアラームを設定すれば、異常なトラフィック変化を検出し、即座に通知を送信できます。これがリアルタイム検出と自動対応の要件を満たします。

C：CloudTrailはユーザーのアクション（設定変更やコンソール操作）を記録するサービスであり、ネットワークトラフィック自体の監視には設計されていません。トラフィック異常の検出に適していません。

D：Trusted Advisorはセキュリティ設定の最適化や設定推奨を提供するサービスであり、リアルタイムのトラフィック異常検出には設計されていません。急激なトラフィック変化への即座の対応には不適切です。

学習のポイント：リアルタイムトラフィック異常検出と自動通知の要件を満たすには、Transit GatewayのCloudWatchメトリクスを監視するアラームが最適です。ログ記録（VPC Flow Logs）や監査（CloudTrail）ではなく、メトリクス監視とアラーム機能が鍵になります。

公式ドキュメント

• transit-gateway-cloudwatch-metrics.html