【完全自分用】　解説べた張り

資格合格の一番の近道は解説のなぜを覚えることにあります。

ポイントは理解する必要はなく覚えるという点です。

なのでChatGPTに聞いた解説をひたすら貼っていこうと思います。

A. Elastic Load Balancerを使用して複数のEC2インスタンスにトラフィックを分散させ、Auto Scalingグループを利用することで、EC2インスタンスが障害から自動的に回復するようにします。最小容量が2インスタンスで設定することで、常に少なくとも1台のインスタンスが稼働し続けるようにします。
D. Amazon RDSのMulti-AZデプロイメントを設定することで、RDS DBインスタンスが別のアベイラビリティゾーンに複製され、1つのアベイラビリティゾーンに障害が発生しても、データベースの可用性を確保できます。これにより、ダウンタイムを最小限に抑えることができます。
F. ElastiCache for Redisにレプリケーショングループを作成し、Multi-AZを有効にすることで、Redisの可用性を向上させます。これにより、1つのノードがダウンしても、他のノードがサービスを継続できるため、アプリケーションの可用性が高まります。

A. Amazon S3にカスタムエラーページをアップロードして静的ウェブサイトとしてホスティングすることで、ALBでエラーが発生した場合にそのカスタムエラーページを表示できます。この方法は、運用負荷が少なく、簡単に実装できるため最適です。
E. CloudFrontを使ってカスタムエラーページを設定することで、ALBのエラー発生時にCloudFrontが指定されたカスタムエラーページを表示できます。これにより、訪問者に対してよりカスタマイズされたエラーページを提供できます。

他の選択肢（B、C、D）は、ALBのヘルスチェックやDNS設定を変更する方法であり、運用負荷が高く、目的に対して過剰な対応となる可能性があります。

A. インフラストラクチャアカウントにトランジットゲートウェイを作成することで、複数のアカウントにわたるネットワーク接続を効率的に管理できます。トランジットゲートウェイは、VPC間の通信を集約し、個別のアカウント間でリソースを共有するための基盤を提供します。
D. AWS Resource Access Managerでリソース共有を作成し、特定のAWS OrganizationsのOUに関連するサブネットを選択してリソースを共有することで、個別のアカウントがインフラストラクチャアカウントのネットワークリソース（サブネット）を利用できるようになります。これにより、インフラストラクチャアカウントがネットワークの管理を担当し、個別のアカウントはサブネット内でAWSリソースを作成できます。
A. AWS PrivateLinkを使用すると、VPC内からプライベート接続でサードパーティのSaaSアプリケーションと通信できます。PrivateLinkを使用することで、インターネットを経由せずにプライベートな通信が可能になり、企業のセキュリティポリシーに準拠した接続を提供できます。セキュリティグループを設定することで、アクセスを最小限に制限することができ、最小権限の原則にも適合します。

AWS Systems Manager (SSM) Patch Manager は、オンプレミスサーバーとEC2インスタンスのパッチ管理を一元化するために設計されており、統一されたパッチ適用プロセスを提供できる。
SSM の Patch Compliance Reporting 機能を使用すると、すべてのサーバーのパッチステータスを一元的に管理し、レポートを作成できる。
AWS Systems Manager Agent (SSM Agent) をオンプレミスのサーバーにインストールすることで、AWSとの統合が可能になり、一元的な管理が実現できる。
他の選択肢が不適切な理由：
- B (OpsWorks + QuickSight)：OpsWorks は主に構成管理用のツールであり、パッチ管理に特化していない。
- C (EventBridge + Amazon Inspector)：Amazon Inspector は主に脆弱性スキャン用であり、パッチ管理のコンプライアンスレポートを生成する適切なツールではない。
- D (OpsWorks + X-Ray)：X-Ray はアプリケーションのトレース分析用であり、パッチ適用状況の可視化には適していない。

B. AWS Systems Manager ドキュメントを作成し、ライフサイクルフックを使用して SSM の SendCommand を実行し、ログファイルをコピー後に CONTINUE を送信してインスタンスを終了させる。

理由：

Auto Scaling グループのライフサイクルフックを使用することで、インスタンスが終了する前に処理を実行できる
- autoscaling:EC2_INSTANCE_TERMINATING フックを使用すると、インスタンス終了時に AWS Lambda をトリガーして適切な処理を実行できる。
AWS Systems Manager (SSM) を使用すると、EC2 インスタンスに追加のスクリプトを事前配置する必要がなくなる
- SendCommand を使用すると、リアルタイムでスクリプトを実行できるため、事前にスクリプトを埋め込む必要がない。
- これにより、管理の柔軟性が向上し、インスタンスごとに異なる設定を動的に適用可能。
ABANDON ではなく CONTINUE を使用することで、適切にインスタンスを終了させることができる
- ABANDON を使用すると、Auto Scaling グループがインスタンスの終了を認識しないため、適切なスケーリングが機能しなくなる可能性がある。
- 一方、CONTINUE を使用すれば、処理後に Auto Scaling によって適切にインスタンスが終了される。

他の選択肢が不適切な理由：

A (ABANDON を使用)：Auto Scaling グループの正常な動作を妨げる可能性がある。また、直接スクリプトを EC2 に配置する管理負担がある。
C (User Data + Lambda)：User Data スクリプトはインスタンス起動時にしか実行されず、終了時には機能しない。また、EventBridge の EC2 終了イベントはすでにインスタンスが終了した後に発生するため、ログをコピーできない。
D (SNS を使用)：SNS で通知を受け取った後に手動でコマンドを実行するのは冗長。また、ABANDON を使用すると、Auto Scaling の終了管理に影響を与える。

✅ C. Account A のホストゾーンを Account B の VPC に関連付けるための認可を作成する。
✅ E. Account B の VPC を Account A のホストゾーンに関連付け、Account A の認可を削除する。

誤りの選択肢:

❌ A. データベースを EC2 に移行し、プライベート IP のレコードを作成する。
→ RDS をすでに使用しており、DNS 解決の問題なのでデータベースのデプロイ方法を変更する必要はない。

❌ B. /etc/resolv.conf に RDS エンドポイントの IP アドレスを追加する。
→ RDS の IP アドレスは変わる可能性があり、手動設定では管理が困難になる。

❌ D. Account B に example.com のプライベートホストゾーンを作成し、Route 53 のレプリケーションを設定する。
→ Route 53 にはプライベートホストゾーンのレプリケーション機能が存在しない。

✅ C. Amazon CloudFront ディストリビューションを設定し、S3 バケットを指すように構成し、動画を EFS から S3 に移行する。
→ CloudFront はグローバルなキャッシュ機能を持ち、S3 は動画配信に適した耐久性とスケーラビリティを提供する。

誤りの選択肢:

❌ A. Amazon EFS を最大 I/O モードに再構成する。
→ 最大 I/O モードはスループットを向上させるが、EFS は動画配信に適しておらず、コストも増大する。

❌ B. インスタンスストアボリュームを使用し、起動時にサイトコンテンツをコピーし、シャットダウン時に S3 に保存する。
→ インスタンスストアは一時的なストレージであり、耐久性がなく、スケーラビリティも不足している。

❌ D. CloudFront ディストリビューションをすべてのサイトコンテンツ用にセットアップし、ALB を指すように設定する。
→ ALB は動的コンテンツ向けであり、動画のキャッシュには不向き。動画を S3 に保存し、CloudFront を経由する方が適切。

✅ A. Direct Connect ゲートウェイをプロビジョニングし、複数のリージョンと接続できるようにする。
→ Direct Connect ゲートウェイ (DXGW) を使用することで、複数のリージョンと VPC に接続可能になる。また、2 つの Direct Connect 接続を通じて冗長性を確保できる。

誤りの選択肢:

❌ B. 既存のプライベート仮想インターフェースを維持し、2 つ目の Direct Connect 接続を VPC に直接接続する。
→ この方法では、1 つのリージョンの単一 VPC にしか接続できず、他のリージョンへの拡張性がない。

❌ C. 2 つ目の Direct Connect 接続にパブリック仮想インターフェースを作成する。
→ パブリック VIF は AWS のパブリックサービスに接続するためのものであり、VPC への直接接続には適していない。

❌ D. Transit Gateway を使用して接続する。
→ Transit Gateway はリージョン内の VPC 間接続には適しているが、複数のリージョンとの接続には Direct Connect ゲートウェイの方が適している。

回答:

✅ C. Web アプリケーションと動画を Amazon S3 にホストし、S3 イベント通知と AWS Lambda を使用して Amazon Rekognition で動画を分類する。
→ この方法は AWS のフルマネージドサービスを最大限活用し、EC2 や EBS の管理負担を削減できるため、運用の効率化とコスト削減に最適。

誤りの選択肢:

❌ A. ECS とスポットインスタンスを使用する。
→ ECS によるコンテナ管理は良い選択肢だが、EC2 インスタンスが必要であり、運用負担が残る。スポットインスタンスはコスト削減にはなるが、SQS キュー処理の安定性が保証されない。

❌ B. EFS を使用する。
→ EFS は EC2 にマウントする必要があり、EC2 の管理負担が発生する。また、S3 の方がコスト効率が良く、S3 イベント通知の方がシンプルな構成となる。

❌ D. Elastic Beanstalk を使用する。
→ Elastic Beanstalk は EC2 の運用管理を一部簡略化できるが、完全にマネージドではなく、EC2 の管理負担が残る。AWS Lambda を活用する C の方がより適した選択肢。

✅ B. AWS SAM と AWS CodeDeploy を使い、段階的デプロイと CloudWatch アラームによるロールバックを実装する。
→ この方法は AWS のマネージドサービスを活用し、デプロイの迅速化とエラー時の自動ロールバックを実現できる。

誤りの選択肢:

❌ A. CloudFormation の変更セットを利用する。
→ CloudFormation は Lambda のデプロイ自体には適しているが、トラフィックの段階的シフトや自動ロールバック機能がないため、エラー検出とリカバリーの迅速化には不向き。

❌ C. AWS CLI スクリプトを統合する。
→ 手動スクリプトは運用負担が増え、デプロイとロールバックの自動化が十分でないため、運用ミスのリスクがある。

❌ D. API Gateway のエンドポイントを切り替える。
→ CloudFront のオリジンを手動で変更するのは遅く、エラー発生時の迅速な対応には向かない。API Gateway を都度作成・変更するのも非効率。

回答:

✅ D. Amazon S3 Glacier Deep Archive をデフォルトストレージに設定し、S3 インターフェイスエンドポイントを介してアクセスする。
→ コストを最小限に抑えつつ、低頻度のデータアクセスに適した設計。

誤りの選択肢:

❌ A. S3 One Zone-IA を使用する。
→ S3 One Zone-IA は Glacier Deep Archive よりコストが高いため、コスト最適化の要件を満たさない。

❌ B. EC2 + EFS One Zone-IA を使用する。
→ EFS One Zone-IA は低コストだが、EC2 インスタンスの維持コストが発生し、運用オーバーヘッドも増える。S3 Glacier Deep Archive よりもコスト効率が悪い。

❌ C. EC2 + EBS (Cold HDD) を使用する。
→ EBS（Cold HDD）は安価だが、EC2 インスタンスのコストがかかり、スケーラビリティや管理の手間を考えると適していない。

回答:

✅ A. AWS IAM Identity Center (AWS Single Sign-On) を SAML 2.0 で Active Directory に接続し、SCIM による自動プロビジョニングと ABAC を使用する。
→ IAM Identity Center を Active Directory と統合することで、ユーザー ID の一元管理とグループ/ロールに基づいた条件付きアクセスを実現できる。

誤りの選択肢:

❌ B. IAM Identity Center を ID ソースとして使用する。
→ この設定では Active Directory を ID ソースとして使用しないため、要件の「ユーザー ID を 1 か所で管理する」に適合しない。

❌ C. IAM の SAML 2.0 ID プロバイダーを使用する。
→ IAM でフェデレーションアクセスを実装できるが、IAM Identity Center を使用した統合の方が AWS Organizations に適した方法であり、管理の負担も軽減される。

❌ D. OpenID Connect (OIDC) ID プロバイダーを使用する。
→ Active Directory は OIDC ではなく SAML 2.0 をネイティブにサポートしているため、OIDC を使うのは適切でない。

回答:

✅ A. S3 Intelligent-Tiering と FSx for Lustre（lazy loading）を使用する。
→ Amazon S3 にデータを保存し、必要なときに FSx for Lustre を作成し、遅延読み込みでアクセスすることでコストを大幅に削減できる。
→ FSx for Lustre は、HPC（ハイパフォーマンスコンピューティング）向けに最適化されており、共有ストレージとして高いパフォーマンスを発揮できる。
→ ジョブの実行時のみ FSx for Lustre を作成・使用し、完了後に削除するため、ストレージコストが最小化される。

誤りの選択肢:

❌ B. EBS Multi-Attach を使用する。
→ EBS Multi-Attach は複数のインスタンスにアタッチ可能だが、200 TB のデータを保持するには非常に高額なコストがかかる。
→ EBS はファイルベースではなくブロックストレージであり、今回のユースケースには適さない。

❌ C. S3 Standard + FSx for Lustre（batch loading）を使用する。
→ Batch loading は、データを S3 から完全にロードするため、時間とコストがかかる。
→ Lazy loading の方が、必要なデータのみロードするため効率的。

❌ D. AWS Storage Gateway（ファイルゲートウェイ）を使用する。
→ Storage Gateway は、オンプレミスとクラウドのハイブリッド環境向けであり、AWS ネイティブ環境では FSx for Lustre よりパフォーマンスが低い。
→ 特に 200 TB ものデータを毎回キャッシュするのは非効率で、パフォーマンスが出ない可能性が高い。

回答:

✅ C. Network Load Balancer (NLB) に Elastic IP を割り当てる。
→ NLB は TCP/UDP の静的ポートを公開するのに最適で、複数の AZ に跨る高可用性を提供できる。
→ 各アベイラビリティゾーンごとに Elastic IP を割り当てることで、固定アドレスの要件を満たす。
→ A レコード (alias) で my.service.com に NLB の DNS 名を登録すれば、負荷分散しながら固定 IP アドレスを提供可能。
→ Elastic IP を他社に提供すれば、許可リストに追加できる。

誤りの選択肢:

❌ A. EC2 インスタンスの Elastic IP を直接 DNS に登録する。
→ 個々の EC2 インスタンスの Elastic IP を DNS に登録すると、インスタンス障害時に手動対応が必要になる。
→ NLB を活用しないと、高可用性や自動フェイルオーバーが実現できない。

❌ B. ECS クラスターのパブリック IP を直接 DNS に登録する。
→ ECS クラスターの IP は動的に変わる可能性があり、固定アドレスとして提供できない。
→ ECS は通常、ロードバランサーを前提として運用される。

❌ D. Application Load Balancer (ALB) を使用する。
→ ALB は HTTP/HTTPS 用であり、TCP ベースの静的ポートには適さない。
→ TCP ベースのワークロードには NLB の方が適している。

正解: ✅ A. AWS Secrets Manager + RotationSchedule を使用

✅ AWS Secrets Manager は、RDS の認証情報管理と自動ローテーションに最適。
✅ RotationSchedule を設定すれば、Secrets Manager が自動で 90 日ごとにローテーション可能。
✅ AWS Lambda を使うことで、RDS のパスワード変更を自動化できる。
✅ CloudFormation で Secrets Manager + Lambda + RotationSchedule を定義できるので、運用負担が少ない。

誤りの選択肢:

❌ B. AWS Systems Manager Parameter Store を使用する。

Parameter Store にはネイティブなローテーション機能がない。
RotationSchedule というリソースも存在しない。
Secrets Manager の方が RDS 認証情報の管理に適している。

❌ C. EventBridge を使って Lambda をトリガーする。

Secrets Manager には RotationSchedule という組み込み機能があり、EventBridge を使う必要がない。
EventBridge を使うと Lambda の管理が複雑になるため、運用コストが増える。

❌ D. AWS AppSync DataSource を使用する。

AppSync DataSource はデータ API であり、パスワードのローテーションには関係ない。
AWS Systems Manager Parameter Store にはネイティブなローテーション機能がない。

回答：

✅ C. AWS Lambda 関数を作成し、JSON ドキュメントとイベントメッセージを使用してリダイレクト URL を検索・応答する。
✅ D. Amazon API Gateway API を使用し、カスタムドメインで AWS Lambda 関数を公開する。
✅ F. AWS Certificate Manager (ACM) を使用して SSL 証明書を作成し、ドメインを Subject Alternative Names (SAN) に含める。

解説：

Lambda (C) はサーバーレスで運用負担が低く、リクエストを処理して適切なリダイレクトを実装可能。
API Gateway (D) を使えば、Lambda を公開し、HTTP/HTTPS リクエストを適切に処理できる。
ACM (F) を使うことで、HTTPS 通信を確保し、すべてのドメインを 1 つの証明書でカバーできる。
Route 53 の Alias レコードを API Gateway に向ければ、各ドメインごとにリダイレクト可能。
完全サーバーレスアーキテクチャ で 最小限の管理コスト で済む。

誤りの選択肢：

❌ A. EC2 インスタンス上に動的 Web ページを作成する。
→ EC2 を使うと 運用負担 が増える（スケール管理・OSメンテナンス・冗長性確保が必要）。
→ サーバーレス（Lambda + API Gateway）の方が低コスト・低運用負担。

❌ B. Application Load Balancer (ALB) を作成する。
→ ALB はターゲットとして EC2 や ECS を想定 しており、Lambda には直接対応しない。
→ API Gateway を使う方が適切。

❌ E. Amazon CloudFront + Lambda@Edge を使用する。
→ CloudFront は静的コンテンツのキャッシュ向け で、動的リダイレクトには 不要なオーバーヘッド。
→ API Gateway + Lambda で十分対応可能。

この構成により、サーバーレスでスケーラブルなリダイレクトサービスを実現 できる。

回答：

✅ A. AWS Resource Access Manager (RAM) を使用して Transit Gateway をメンバーアカウントと共有する。
✅ C. AWS CloudFormation StackSet を使用して VPC と Transit Gateway アタッチメントを自動作成し、管理アカウントの Transit Gateway に関連付ける。

解説：

AWS Transit Gateway は AWS Organizations に統合されていない ため、SCP (B) や Service Catalog (E) では共有できない。
AWS RAM (A) は、AWS Organizations 内のアカウント間で Transit Gateway を共有できる 唯一の方法。
CloudFormation StackSet (C) を使えば、新しいメンバーアカウントに VPC と Transit Gateway アタッチメントを自動的に作成できる。
Transit Gateway のアタッチメントは AWS RAM を介して共有し、管理アカウントの Transit Gateway に関連付けることで、VPC 間接続を確立できる。

誤りの選択肢：

❌ B. AWS Organizations の SCP を使用して Transit Gateway を共有する。
→ SCP は AWS のリソース共有に使用できない。
→ SCP はアクセス制御 (ポリシー適用) のみを行うため、Transit Gateway の共有には適さない。

❌ D. Peering Transit Gateway アタッチメントを作成し、サービスリンクロールを使用する。
→ Transit Gateway に Peering 接続は不要。
→ AWS RAM を使えば直接共有できるため、Peering の設定は不要で、管理の手間が増える。

❌ E. AWS Service Catalog を使用して Transit Gateway を共有する。
→ AWS Service Catalog は、組織内で標準的なインフラストラクチャをデプロイするためのツールであり、AWS RAM のようなリソース共有機能は持たない。
→ Transit Gateway の共有には適さない。

この方法により、新規アカウント作成時に VPC と Transit Gateway アタッチメントの作成を自動化しつつ、AWS RAM を使ってメンバーアカウントと安全に共有する ことができる。

回答：

✅ C. SCP を使用して Private Marketplace の管理権限を制御し、procurement-manager-role 以外のアクセスを禁止する。

解説：

AWS Organizations の SCP を使用すれば、組織全体の Private Marketplace の管理権限を一元的に制御できる。
「共有サービスアカウント」だけに “procurement-manager-role” を作成することで、管理範囲を限定しつつ、アクセスを一元化できる。
「SCP で role 作成を制限する」ことで、他のアカウントで同じ名前の role を作成して権限を奪うことを防ぐ。

誤りの選択肢：

❌ A. PowerUserAccess を付与し、インラインポリシーで Private Marketplace を制限する。
→ PowerUserAccess は管理者に近い権限を持ち、Private Marketplace の管理を完全に制限できない可能性がある。
→ インラインポリシーでは、組織全体に適用する SCP のような強力な制御ができない。

❌ B. AdministratorAccess を付与し、パーミッションバウンダリで制限する。
→ AdministratorAccess は強すぎるため、他の管理権限まで与えてしまう可能性がある。
→ パーミッションバウンダリは IAM ユーザーやロールの制限には使えるが、組織全体に適用できる SCP の方が適切。

❌ D. 開発者が使用するアカウントに procurement-manager-role を作成し、SCP を適用する。
→ 開発者アカウントに管理用の role を作成するのは適切ではない。
→ Private Marketplace の管理は開発者アカウントではなく、「共有サービスアカウント」に集中させるべき。
→ SCP を「共有サービスアカウント」に適用しても、開発者アカウントでの制限を完全には保証できない。

この構成により、開発者は承認済みソフトウェアのみ取得でき、Private Marketplace の管理は購買チーム専用に制限される。

回答：

✅ D. ALB を導入し、EC2 インスタンスをプライベートサブネットに移動する。

解説：

ALB は動的なトラフィック分散が可能 であり、急な負荷増加にもスケーラブルに対応できる。
ALB のターゲットグループを使用すれば、EC2 の追加・削除が自動化されるため、Route 53 の手動更新が不要。
EC2 をプライベートサブネットに移動することで、セキュリティも向上 する。
ALB は Auto Scaling と連携できるため、負荷に応じたスケーリングも容易。
マルチバリュー回答ルーティングを使用するよりも、ALB の方が可用性が高く、管理もシンプルになる。

誤りの選択肢：

❌ A. API を Lambda に移行し、API Gateway を導入する。
→ モノリシックな API を Lambda に分割するのは大規模なリファクタリングが必要 であり、最小限の運用負荷という要件に合わない。
→ 急なトラフィック増加に対しては有効だが、現状の EC2 ベースのシステムとは大きく異なる構成になるため、移行のコストが高い。

❌ B. API をコンテナ化し、EKS に移行する。
→ EKS の導入・管理は運用負荷が高く、現状の EC2 ベースのシステムと大きく異なるアーキテクチャ になる。
→ モノリシックなアプリを EKS に移行するには時間とコストがかかるため、「最小限の運用負荷」という要件に合わない。

❌ C. Auto Scaling グループを作成し、Route 53 のレコードを Lambda で動的に更新する。
→ Auto Scaling は有効だが、EC2 インスタンスの IP アドレスが頻繁に変わるため、Route 53 のレコードを更新する Lambda の管理が煩雑になる。
→ Route 53 を手動で更新するよりも、ALB を使った方が負荷分散が自動化され、管理の手間が少ない。

このため、最小限の運用負荷で負荷変動に対応できる「ALB の導入」が最適なソリューション となる。

回答：

✅ B. AWS Organizations の管理アカウントから CUR を作成し、QuickSight で可視化する。

解説：

AWS Cost and Usage Report (CUR) は、AWS Organizations の管理アカウントで集約できる。
管理アカウントから一元的に CUR を作成することで、OU やアカウントごとのコストを簡単に分析可能。
Amazon QuickSight を使用すれば、コストデータを可視化し、各 OU に提供できる。
最も運用負荷が少なく、全アカウントのコストを正確に分析できる方法である。

誤りの選択肢：

❌ A. 各 OU に AWS Resource Access Manager (RAM) を使用して CUR を作成する。
→ AWS Resource Access Manager (RAM) はリソース共有のためのサービスであり、CUR の作成には適さない。
→ CUR は AWS Organizations の管理アカウントで一括管理するのが一般的で、各 OU に分散して作成するのは非効率。

❌ C. 各メンバーアカウントで CUR を作成する。
→ 各アカウントごとに CUR を作成すると、管理が煩雑になり、コストの一元管理ができない。
→ AWS Organizations の管理アカウントで集約する方が合理的であり、コストの全体像を把握しやすい。

❌ D. AWS Systems Manager を使用して CUR を作成する。
→ AWS Systems Manager はコスト管理に特化したツールではなく、CUR の作成には適していない。
→ AWS Cost and Usage Report (CUR) は、AWS Cost Management の機能として提供されるべきもので、Systems Manager OpsCenter での可視化は一般的ではない。

このため、管理アカウントから CUR を作成し、QuickSight で可視化する方法が最も適切 である。

回答：

✅ B. AWS DataSync を使用して、オンプレミスの Windows ファイルサーバーと Amazon FSx の間でデータを毎日レプリケートする。

解説：

Amazon FSx は Windows ファイルサーバーのフルマネージドサービスであり、Windows 環境に最適なファイルシステムを提供する。
AWS DataSync は、オンプレミスと AWS 間で高速なデータ転送を実現するためのサービスであり、スケジュールされたレプリケーションが可能。
既存の Windows ワークロードと互換性を保つためには、Windows ネイティブの SMB プロトコルをサポートする Amazon FSx が最適。
オンプレミスと AWS の間に Direct Connect があるため、高速で安定したデータ同期が可能。

誤りの選択肢：

❌ A. AWS Storage Gateway のファイルゲートウェイを使用する。
→ Storage Gateway はハイブリッドストレージソリューションであり、クラウドへのキャッシュまたはバックアップ用途がメイン。
→ データをクラウド上のネイティブな Windows ファイルシステム (Amazon FSx) に移行するには適していない。

❌ C. AWS Data Pipeline を使用する。
→ AWS Data Pipeline はデータ処理ワークフロー管理のためのサービスであり、ファイルの継続的なレプリケーションには適していない。
→ データ移行には AWS DataSync の方が適している。

❌ D. AWS DataSync を使用して Amazon EFS にデータをレプリケートする。
→ Amazon EFS は Linux ベースの NFS プロトコルを使用するため、Windows 環境との互換性が低い。
→ Windows ファイルサーバーからの移行には、Windows ネイティブな SMB をサポートする Amazon FSx が適している。

このため、AWS DataSync を使用して Amazon FSx にレプリケートする B が最適な選択肢 となる。

回答：

✅ C. us-east-1 の S3 バケットにレプリケーションを設定し、第 2 のリージョンの S3 バケットにオブジェクトを自動複製する。CloudFront ディストリビューションをセットアップし、オリジングループに 2 つの S3 バケットを設定する。

解説：

S3 のクロスリージョンレプリケーション（CRR） を設定すれば、オブジェクトの追加・更新時に自動的に第 2 のリージョンの S3 バケットへレプリケーションされるため、運用負荷が低い。
Amazon CloudFront のオリジングループ を使用すると、プライマリの S3 バケットが利用できない場合、自動的にセカンダリの S3 バケットにフェイルオーバーできる。
CloudFront を経由することで、S3 からの静的コンテンツの配信が高速化され、パフォーマンスが向上する。
アプリケーションコードの変更は不要であり、S3 の運用負荷も最小限に抑えられる。

誤りの選択肢：

❌ A. 各オブジェクトを 2 つの S3 バケットに書き込む方式
→ アプリケーション側でデータの複製を実装する必要があり、開発と運用の負担が大きい。
→ S3 のクロスリージョンレプリケーション（CRR）を利用した方が効率的。

❌ B. AWS Lambda を使用して S3 バケット間でオブジェクトをコピーする方式
→ Lambda を使用したレプリケーションは手動管理が必要になり、運用負荷が高い。
→ S3 のネイティブなクロスリージョンレプリケーション（CRR）の方が簡単かつ自動化されている。

❌ D. フェイルオーバー時にアプリケーションコードを変更する方式
→ アプリケーションコードの変更が必要になり、管理が複雑になる。
→ CloudFront のオリジングループを利用すれば、コード変更なしで自動フェイルオーバー可能。

回答：

✅ B. AWS CloudFormation を使用し、3 つの AZ にまたがる ALB と EC2 Auto Scaling グループをデプロイ。Multi-AZ 構成の Amazon Aurora MySQL DB クラスターを使用する。

解説：

1. スケーラブルで高可用性のある Web 層

EC2 Auto Scaling グループ を使用し、トラフィックの変動に応じてサーバーを動的にスケール可能。
Application Load Balancer（ALB） を使用し、アプリケーションレイヤー（レイヤー 7）のトラフィックを適切に分配。

2. 高可用性のデータベース層

Amazon Aurora MySQL（Multi-AZ） は MySQL 互換であり、高可用性と自動フェイルオーバー機能を備えている。
Aurora は RDS MySQL よりパフォーマンスが高く、1 日 200,000 ユーザーのワークロードに適している。

3. Infrastructure as Code（IaC）による自動管理

AWS CloudFormation を使用すると、インフラのデプロイと管理が自動化できるため、運用負荷が低減される。

誤りの選択肢：

❌ A. Elastic Beanstalk + NLB + RDS MySQL
→ Elastic Beanstalk は便利だが、大規模アプリケーションでは細かい制御がしづらい。
→ ネットワークロードバランサー（NLB）は TCP レベル（レイヤー 4）の負荷分散のみで、HTTP レベルのルーティングができないため、ALB の方が適切。
→ Aurora の方が RDS MySQL よりスケーラブルで高可用性。

❌ C. Elastic Beanstalk + ALB（2 リージョン）+ Aurora（クロスリージョンリードレプリカ）
→ 2 リージョン間のデータ同期が複雑になり、過剰設計。
→ Aurora は高可用性があるため、クロスリージョンレプリカが不要。
→ ジオプロキシミティルーティングは、マルチリージョンの要件がある場合のみ有効。

❌ D. ECS（Spot インスタンス）+ ALB + RDS MySQL
→ Spot インスタンスはコスト削減には良いが、安定した可用性が必要なワークロードには不向き。
→ Aurora の方が RDS MySQL よりスケーラブルで適切。
→ ECS を使用する場合は、Fargate などのマネージドコンテナの方が管理しやすい。

選択肢の分析

A.

✅ Organizations メンバーアカウントで StackSet を作成し、サービス管理の権限（service-managed permissions）を使用。デプロイ対象を Organizations 全体に設定し、CloudFormation StackSets のドリフト検出を有効化。
→ 誤り！StackSet は管理アカウントで作成する必要がある。

B.

❌ Organizations メンバーアカウントでスタックを作成し、自己管理の権限（self-service permissions）を使用。デプロイ対象を Organizations 全体に設定し、CloudFormation StackSets の自動デプロイを有効化。
→ 誤り！自己管理の権限（self-service permissions）では、管理アカウントからの一括デプロイができない。

C.（正解 ✅）

✅ Organizations 管理アカウントで StackSet を作成し、サービス管理の権限（service-managed permissions）を使用。デプロイ対象を Organizations 全体に設定し、CloudFormation StackSets の自動デプロイを有効化。
→ 正しい！管理アカウントから StackSet を作成し、AWS Organizations 全体にデプロイできる。

D.

❌ Organizations 管理アカウントでスタックを作成し、サービス管理の権限を使用。デプロイ対象を Organizations 全体に設定し、CloudFormation StackSets のドリフト検出を有効化。
→ 誤り！StackSet ではなく、単なるスタック（stack）を管理アカウントに作成しても、メンバーアカウントへデプロイできない。

正解:

✅ C. Create a stack set in the Organizations management account. Use service-managed permissions. Set deployment options to deploy to the organization. Enable CloudFormation StackSets automatic deployment.

解説：

1. なぜ AWS Organizations の管理アカウントで StackSet を作成するのか？

管理アカウントで StackSet を作成することで、Organizations 全体に自動適用できる。
メンバーアカウントで個別に StackSet を作成する必要がなく、一元管理が可能。

2. なぜ「サービス管理の権限（service-managed permissions）」を使用するのか？

AWS Organizations の「信頼されたアクセス（Trusted Access）」が有効になっているため、StackSet の管理を AWS に委ねることができる。
これにより、すべてのメンバーアカウントに対して自動的にスタックがデプロイされる。

3. なぜ「自動デプロイ（automatic deployment）」を有効にするのか？

新しく AWS アカウントが Organizations に追加されたときに、手動で再デプロイする手間を省ける。
新しいアカウントにも自動で SNS トピックを作成できる。

解説

この問題のポイントは DynamoDB のコスト最適化 です。現在、ピーク時の負荷に合わせて RCU（Read Capacity Unit）と WCU（Write Capacity Unit）を設定 しており、普段の負荷よりも高い容量を維持しているため、コストが無駄になっています。

また、アクセスパターンは「書き込みが多く、読み込みは比較的少ない」という点も考慮する必要があります。

各選択肢の評価

A. AWS Application Auto Scaling を使用してピーク時にキャパシティを増加。平均負荷に合わせた予約キャパシティ（Reserved Capacity）を購入する。

❌ 不適切

DynamoDB のプロビジョニングされたキャパシティは、Application Auto Scaling でスケール可能 ですが、スケールには数分の遅延が発生する ため、急激なトラフィックの変動には対応しにくい。
予約キャパシティ（Reserved Capacity）は長期間一定の負荷がある場合に有効 であり、1 週間のうち 4 時間だけピークになるワークロードには適していない。
結果として、ピーク時の負荷に合わせるための予約キャパシティが無駄になり、コスト削減にならない。

B. テーブルのキャパシティモードをオンデマンド（On-Demand）に設定する。

✅ 適切（正解）

オンデマンドモードは変動する負荷に最適。必要なときに自動的にスケールし、アイドル時はコストがかからないため、ピーク時と通常時の負荷に大きな差がある場合に最適。
1 週間に 4 時間だけピークが発生するため、常にプロビジョニングキャパシティを維持するより オンデマンドの方がコストを削減できる可能性が高い。
ただし、オンデマンドモードは一定の RCU/WCU を維持するプロビジョンドモードよりリクエスト単価が高い ため、もし負荷が一定ならプロビジョンドモードの方がコスト効率が良い。しかし、このケースでは変動が大きいため、オンデマンドが適切。

C. DynamoDB Accelerator (DAX) を導入し、プロビジョニングされた読み込みキャパシティを削減する。

❌ 不適切

DAX は読み取りキャッシュ であり、「書き込みが多く、読み込みが少ない」という本問題のワークロードにはあまり適さない。
また、DAX の導入には追加のコストが発生する ため、コスト削減の目的には逆効果。
さらに、DAX はプロビジョニングされたキャパシティを維持する前提のため、オンデマンドモードにする方が柔軟なコスト削減になる。

D. DynamoDB Accelerator (DAX) を導入し、オンデマンドモードにする。

❌ 不適切

DAX は書き込み負荷の多いワークロードには向かない。
さらに、DAX を使用すると追加コストが発生する ため、コスト削減にならない。
もし読み取り負荷が非常に高ければ DAX の利用を検討できるが、本問題では書き込み負荷が多いワークロードのため不要。

結論（正解）

✅ B. テーブルのキャパシティモードをオンデマンドに設定する

アクセスパターンが変動するワークロードにはオンデマンドモードが最適。
ピーク時だけスケールし、通常時のコストを削減できる。
運用の手間がかからず、自動でスケーリングするため、管理負担が少ない。

補足

オンデマンドモードとプロビジョンドモードの使い分け

モード	適したワークロード	コストの特徴
オンデマンド	負荷が変動するワークロード	高い RCU/WCU 単価だが、アイドル時はコストなし
プロビジョンド	負荷が一定のワークロード	低い RCU/WCU 単価だが、未使用時もコスト発生

今回のケースでは、負荷が週 1 回大きく変動する ため、オンデマンドが最適 という結論になります。

解説

この問題では、オンプレミスのデータ処理アプリケーションを AWS に移行 するためのコスト効率の高い方法を選択する必要があります。
重要な要件は次のとおりです：

ファイルのアップロードと処理のワークフロー
- ユーザーがファイルをアップロード → メッセージキューに送信 → 処理サーバーがファイルを処理 → 結果を保存
ワークロードの変動
- 業務時間中に負荷が高まり、業務時間外には負荷が低下する。
- この変動に応じたスケーリングが必要。
コストの最適化
- 常にインスタンスを起動しておくとコストがかかるため、負荷に応じたスケーリングが求められる。

各選択肢の評価

A. Amazon SQS を使用し、メッセージがあるときに AWS Lambda を起動して処理を行う

❌ 不適切

Lambda には最大 15 分の実行時間制限がある ため、1 時間の処理時間が必要なワークロードには向かない。
長時間処理のワークロードには、EC2 やコンテナ（ECS / Fargate）が適切。
SQS の利用は適切だが、Lambda では処理しきれないため、この選択肢は不適。

B. Amazon MQ を使用し、メッセージを受信したときに EC2 インスタンスを起動して処理を行う

❌ 不適切

Amazon MQ は ActiveMQ / RabbitMQ ベースのフルマネージドメッセージブローカー であり、一般的にレガシーアプリケーションとの互換性を考慮する際に使用する。
しかし、本ケースでは既存のメッセージングシステムの変更に関する要件がないため、Amazon SQS（サーバーレスで低コスト）がより適している。
EC2 インスタンスを処理のたびに起動・停止するとオーバーヘッドが大きくなり、遅延が発生するため、スケーリングベースのアプローチの方が望ましい。

C. Amazon MQ を使用し、AWS Lambda で処理を行う

❌ 不適切

A と同様に Lambda の最大実行時間 15 分の制限により、1 時間の処理が必要なワークロードには適さない。
Amazon MQ の利用もコストがかかるため、シンプルな SQS を使うべき。

D. Amazon SQS を使用し、EC2 Auto Scaling グループでスケールアウトして処理を行う

✅ 適切（正解）

Amazon SQS はフルマネージドで、メッセージの増減に応じてスケールしやすい。
EC2 Auto Scaling によるスケーリングは、負荷変動に応じたコスト最適化が可能。
- 業務時間中は EC2 インスタンスを増やして処理。
- 業務時間外はインスタンスを縮小してコスト削減。
S3 を使用して処理結果を保存するのは、コストとスケーラビリティの観点から適切。

結論（正解）

✅ D. Amazon SQS を使用し、EC2 Auto Scaling グループでスケールアウトして処理を行う

負荷変動に応じたスケーリングが可能。
コスト効率が高く、必要な処理能力を確保しながら無駄なリソースを削減できる。
AWS の推奨アーキテクチャに沿った設計。

補足

Amazon SQS と Amazon MQ の使い分け

サービス	特徴	適したユースケース
Amazon SQS	フルマネージドの分散メッセージキュー。低コスト。	シンプルなメッセージキュー（今回のケース）
Amazon MQ	ActiveMQ / RabbitMQ ベースのマネージドブローカー。	既存の MQ システムを AWS に移行する場合

本ケースでは、新規システム構築のため、SQS を使うのが適切 です。

解説

要件の整理

OpenSearch Service のコストを削減したい
データは 1 か月間クエリ可能である必要がある
コンプライアンスのため、S3 にデータを保持し続ける必要がある

選択肢の評価

A. すべてのデータノードを UltraWarm に変更し、S3 Glacier Deep Archive にデータを保存
❌ 不適切

UltraWarm はコスト削減に役立つが、データノードを完全になくすのはリスク。
S3 Glacier Deep Archive にデータを移行するのは正しいが、OpenSearch のパフォーマンスが低下する可能性がある。

B. データノードを 2 つに削減し、UltraWarm にデータを移行。1 か月後に S3 Glacier Deep Archive にアーカイブ
✅ 適切（正解）

データノードを 2 つに減らす ことで OpenSearch のコストを削減。
UltraWarm にインデックスを移行 することで、1 か月間低コストでデータを保持しながら、検索可能な状態を維持。
S3 のライフサイクルポリシーを設定し、1 か月後にデータを S3 Glacier Deep Archive に移行 → コンプライアンス要件を満たしつつ、長期保存コストを最適化。

C. データノードを 2 つに削減し、UltraWarm + Cold Storage を導入。1 か月後に S3 のデータを削除
❌ 不適切

Cold Storage を利用すると さらなるコスト削減 ができるが、S3 のデータを削除してしまうのはコンプライアンス違反。
S3 にデータを保持する必要があるため、不適切。

D. データノードを 2 つに削減し、インスタンスバックドノードを使用
❌ 不適切

インスタンスバックド（Instance-backed）ノードはコスト削減に適さない（主に高スループット用途向け）。
UltraWarm や Cold Storage を活用しないため、ストレージコストの最適化が不十分。

結論（正解）

✅ B. データノードを 2 つに削減し、UltraWarm にデータを移行。1 か月後に S3 Glacier Deep Archive にアーカイブ

OpenSearch のコストを最小限に抑えつつ、1 か月間データを検索可能な状態で維持。
S3 Glacier Deep Archive にデータを移行し、長期保存コストを削減。
パフォーマンスとコスト削減のバランスが最適。

補足：UltraWarm と Cold Storage の違い

ストレージタイプ	用途	クエリ性能	コスト
Hot Storage（データノード）	頻繁にアクセスするデータ	高速	高い
UltraWarm	過去のデータを安価に保存	中速	中程度
Cold Storage	ほぼアクセスしないデータ	遅い（取り出しに時間がかかる）	低い

本ケースでは 1 か月間データを保持する必要があるため、UltraWarm が適切 です。

解説

要件整理

「0.0.0.0/0」を許可するインバウンドルールの作成を防ぐ必要がある。
対象は NonProd OU に属するアカウントのみ。
運用負荷を最小限にする。

選択肢の評価

A. EventBridge + Lambda でルールを削除
❌ 不適切

EventBridge は 「事後対応」 の仕組みであり、ルールが作成された後に削除する 形になるため、根本的な解決にはならない。
Lambda 関数の管理が必要 で、運用負荷が増加 する。
禁止するのではなく、削除する仕組み なので、一時的に危険な設定が作成されるリスク もある。

B. AWS Config のマネージドルールを適用
❌ 不適切

AWS Config は監視ツールであり、セキュリティグループの作成自体を防ぐことはできない。
「vpc-sg-open-only-to-authorized-ports」は、特定のポートだけを許可するルールであり、0.0.0.0/0 を禁止するものではない。
事後検知型のアプローチ になり、問題発生を未然に防ぐことはできない。

C. SCP で「0.0.0.0/0 以外のアクセスは許可」
❌ 不適切

SCP は「許可ベース」のポリシーではなく、どのアクションを「拒否」するかを決めるもの。
「許可リスト方式」は、AWS の SCP の性質に合っていないため、適用できない。
実装が難しく、設定ミスが発生しやすい。

D. SCP で「0.0.0.0/0 の場合に作成を拒否」
✅ 適切（正解）

SCP を Organizations の NonProd OU に適用すれば、対象のアカウントに自動適用される。
「0.0.0.0/0」のセキュリティグループルールの作成を完全に禁止 できる。
管理負荷がほぼゼロ で、設定後は 追加の運用作業が不要。
事前対応型のアプローチで、危険なルールを未然に防げる。

結論（正解）

✅ D. SCP を使用して、「0.0.0.0/0」の場合に ec2:AuthorizeSecurityGroupIngress を拒否する

「事後対応」ではなく、「事前対応」 で危険なルールの作成を防げる。
AWS Organizations の SCP を活用し、一括適用できるため運用負荷が低い。
最小限の設定で、NonProd OU 全体に適用可能。

解説

要件整理

サーバーレスアーキテクチャへ移行する。
運用負荷を最小限に抑える。
現在の ALB + EC2 でのウェブフック処理を移行する。
Git サーバーがウェブフックを呼び出せるようにする。

選択肢の評価

A. AWS Lambda の関数 URL を利用する
✅ 適切（正解）

最もシンプルで運用負荷が低い方法。
Lambda 関数 URL を使用すれば API Gateway を使わずに直接 HTTP リクエストを処理できる ため、構成が簡素化される。
Git サーバーの設定を、ALB ではなく Lambda 関数 URL に変更するだけで済む。
EC2 の管理が不要 になり、完全にサーバーレス化できる。

B. API Gateway + Lambda を利用する
⭕ 適切だが、A より運用負荷がやや高い

API Gateway を使用することで、エンドポイントの管理がしやすくなる。
Git サーバーから API Gateway のエンドポイントを呼び出す形になるため、リクエスト管理がしやすい。
ただし、API Gateway の設定・管理が必要になるため、運用負荷が A に比べてやや増える。
Lambda 関数 URL だけで完結できるなら、A の方がシンプル。

C. App Runner + ALB を利用する
❌ 不適切

App Runner はコンテナベースの PaaS であり、Lambda よりも運用コストがかかる。
ALB を引き続き利用することになるため、サーバーレス化のメリットが限定的。
サーバー管理の負担が残る ため、最小限の運用負荷とは言えない。

D. ECS Fargate + API Gateway を利用する
❌ 不適切

ECS Fargate は サーバーレスなコンテナ実行環境 だが、Lambda の方が軽量かつシンプル。
API Gateway の設定が必要で、運用負荷が高まる。
コンテナ化する手間がかかる ため、既存のシステムをそのまま移行するには適さない。
サーバーレス化のメリットを十分に活かせない。

結論（正解）

✅ A. 各ウェブフックを AWS Lambda の関数 URL で公開し、Git サーバーから直接呼び出す

理由：

API Gateway を使わずに、Lambda だけで HTTP リクエストを処理可能。
最小限の構成変更で移行が可能（Git サーバーのエンドポイント設定を変更するだけ）。
完全にサーバーレスで、EC2 や ALB の運用が不要になる。
運用負荷が最も少なく、コストも低く抑えられる。

解説

要件整理

サーバーメトリクスを収集する必要がある。
- CPU、RAM、OS、プロセス情報を取得する。
データをクエリおよび分析できるようにする必要がある。
- クエリを実行できる環境が必要。
1,000 台のサーバーが対象のため、自動化が必要。
- 手動でデータを更新するのは非現実的。
AWS Migration Hub を活用するのが望ましい。

選択肢の評価

A. Agentless Discovery Connector + AWS Glue + S3 Select
❌ 不適切

Agentless Discovery Connector は VMware 環境専用であり、OS レベルの詳細な情報（RAM 使用率やプロセス情報など）は取得できない。
ETL 処理（AWS Glue）を使うのはオーバーヘッドが大きい。
S3 Select は簡易的なデータ検索向けであり、分析には向かない。

B. VM パフォーマンス情報のエクスポート + QuickSight での分析
❌ 不適切

VM パフォーマンス情報のみでは OS 情報やプロセス情報を取得できない。
Migration Hub へのデータインポートが手動での更新を前提としており、1,000 台に対して現実的ではない。
QuickSight は可視化ツールであり、データの収集や格納には向かない。

C. スクリプトを使ったデータ収集 + AWS CLI で Migration Hub へデータ送信
❌ 不適切

スクリプトの作成・管理の負担が大きく、スケールしにくい。
データをクエリする仕組みがないため、追加の開発が必要。
AWS が推奨する移行支援ツールを活用していない。

D. Application Discovery Agent + Amazon Athena
✅ 正解

Application Discovery Agent は OS レベルの詳細情報（CPU、RAM、OS、プロセス情報）を取得できる。
Migration Hub の Data Exploration を利用すれば、データを分析しやすくなる。
収集したデータは Amazon S3 に保存され、Athena を使用して SQL ベースでのクエリが可能。
1,000 台のサーバーに対してスケール可能な AWS 標準のアプローチ。

結論（正解）

✅ D. AWS Application Discovery Agent をデプロイし、Athena でデータを分析する。

理由：

サーバーメトリクスを自動で収集できる。
Amazon Athena を使って、収集したデータを簡単にクエリ可能。
AWS Migration Hub の標準機能を活用でき、運用負荷が低い。
スケールしやすく、1,000 台のサーバーを効率的に管理できる。

解説

要件整理

Lambda は VPC 内で実行されている
- デフォルトでは VPC 内の Lambda はインターネットに直接アクセスできない。
- NAT ゲートウェイやインターネットゲートウェイを通じて通信する必要がある。
外部プロバイダーは、特定のパブリック IPv4 アドレスからのリクエストのみ許可
- 単一の固定パブリック IP が必要（動的な IP ではダメ）。
- Elastic IP を使用するのが適切。
最適な方法で Lambda からインターネットへアクセスする必要がある
- VPC 内の Lambda は直接インターネットにアクセスできない。
- NAT ゲートウェイを使用するのが一般的な解決策。

選択肢の評価

A. NAT ゲートウェイを使用する（✅正解）

NAT ゲートウェイは、プライベートサブネット内のリソースがインターネットへアクセスするために使用される。
Elastic IP を NAT ゲートウェイに割り当てれば、単一の固定パブリック IP を確保できる。
Lambda から外部サービスへアクセス可能になり、要件を満たす。
✅ この方法が最適解。

B. Egress-only IGW を使用する（❌不適切）

Egress-only IGW は IPv6 専用のため、IPv4 の要件を満たせない。
また、Lambda が属する VPC の ENI に egress-only IGW を割り当てることはできない。
❌ IPv4 の要件を満たせないため、不適切。

C. インターネットゲートウェイを使用する（❌不適切）

インターネットゲートウェイ（IGW）は、パブリックサブネット内のリソースが直接インターネットにアクセスするためのもの。
しかし、VPC 内の Lambda は IGW を直接利用できない。
NAT ゲートウェイが必要。
❌ Lambda から直接 IGW を利用できないため、不適切。

D. インターネットゲートウェイをデフォルトルートに設定する（❌不適切）

インターネットゲートウェイを設定しても、プライベートサブネット内の Lambda は直接インターネットにアクセスできない。
NAT ゲートウェイを使用する必要がある。
❌ プライベートサブネットの Lambda は IGW ではなく NAT GW を経由する必要があるため、不適切。

結論（正解）

✅ A. NAT ゲートウェイを使用し、Elastic IP を割り当てる。

理由：

Lambda（VPC 内）がインターネットにアクセスできるようになる。
Elastic IP を NAT ゲートウェイに割り当てれば、外部プロバイダーに提供する固定パブリック IP を確保できる。
AWS の推奨アーキテクチャに沿ったベストプラクティス。

解説

問題の根本原因

Lambda は「ステートレス」 であり、リクエストごとに新しい接続を開く（そのため大量の接続が発生）。
Aurora に対して接続数が多すぎるとパフォーマンスが低下 する。
適切なコネクション管理（接続プール）を導入する必要がある。

各選択肢の評価

✅ B. RDS Proxy を使用し、コネクションプールを設定する（正解）

RDS Proxy は Lambda のデータベース接続管理を最適化するための推奨ソリューション。
リクエストごとに新しい DB 接続を作成せず、コネクションプールを利用する。
これにより、Aurora の接続負荷が軽減され、スケーラビリティが向上する。
✅ この問題に対する最適解の一つ。

✅ D. データベース接続処理をイベントハンドラーの外に移動する（正解）

Lambda の「コールドスタート」時にのみ DB 接続を確立し、後続のリクエストで再利用できる。
リクエストごとに新しい接続を開くのではなく、同じ接続を使い回すことで接続数を削減できる。
✅ この実装を行うと、Lambda の効率が向上し、Aurora の負荷も軽減される。

（例: 不適切な実装）

python

コピーする編集する

def lambda_handler(event, context): connection = connect_to_database() # ❌毎回新規接続 result = execute_query(connection) return result

（改善後の実装）

python

コピーする編集する

# ✅ コールドスタート時にのみ接続を確立 connection = connect_to_database() def lambda_handler(event, context): result = execute_query(connection) return result

❌ A. Aurora のクラスターエンドポイントを使用する（不適切）

クラスターエンドポイントは「書き込み用」 のエンドポイント。
リードレプリカを活用して負荷を分散したい場合は、リーダーエンドポイントを使うべき。
❌ このケースでは RDS Proxy の方が適している。

❌ C. Lambda の「プロビジョンドコンカレンシー」機能を使用する（不適切）

プロビジョンドコンカレンシーは「コールドスタートの回避」には有効だが、DB 接続の最適化には関係がない。
データベースの接続数を削減するわけではないため、問題の本質的な解決にならない。
❌ 今回の問題には適さない。

❌ E. API Gateway を「エッジ最適化」に変更する（不適切）

エッジ最適化エンドポイントは、グローバルに分散したユーザー向けのパフォーマンス向上手法。
しかし、問題の原因は「データベース接続」なので、API Gateway の種類を変えても影響はない。
❌ 今回の問題とは無関係。

結論（正解）

✅ B. RDS Proxy を使用し、接続プールを設定する。
✅ D. データベース接続処理をイベントハンドラーの外に移動する。

理由：

RDS Proxy により、Lambda の大量の DB 接続を適切に管理できる。
イベントハンドラーの外で DB 接続を確立すると、接続の再利用が可能になり、リクエストごとの接続数を削減できる。
この2つの対策を組み合わせることで、Lambda と Aurora のパフォーマンスが大幅に向上する。

解説

エンドツーエンドの暗号化とは？

「エンドツーエンドの暗号化」 とは、クライアント →（ロードバランサー）→ EC2 インスタンスまでの通信がすべて HTTPS で暗号化されることを指す。
つまり、ALB や NLB だけでなく、EC2 インスタンスでも SSL/TLS を適用する必要がある。

各選択肢の評価

✅ C. ALB + ACM（ALB）+ サードパーティ証明書（EC2） （正解）

ALB に ACM の SSL 証明書を適用することで、クライアントと ALB 間の通信を HTTPS で暗号化できる。
EC2 インスタンスにもサードパーティの SSL 証明書をインストールすることで、ALB → EC2 の通信も HTTPS で暗号化できる。
この構成により、「エンドツーエンドの暗号化」を実現できる。
✅ 本問の要件を完全に満たしているため、正解。

❌ A. ACM 証明書を ALB に関連付け、同じ証明書を EC2 にエクスポートする（不適切）

ACM の証明書はエクスポートできないため、EC2 インスタンスにはインストールできない。
よって、「エンドツーエンドの暗号化」を満たせない。
❌ ACM 証明書を EC2 にインストールできないため、不適切。

❌ B. CloudFront + ACM 証明書（不適切）

CloudFront は通常 ALB や S3 バケットをオリジンとして使用し、EC2 インスタンスに直接ルーティングすることは少ない。
CloudFront の背後に ALB や EC2 を直接配置する場合、CloudFront → ALB/EC2 の通信が HTTPS である保証はない。
この選択肢ではエンドツーエンドの暗号化の要件を完全には満たさない。
❌ CloudFront を使用しても、EC2 までの通信が HTTPS である保証はないため、不適切。

❌ D. NLB + サードパーティ証明書（不適切）

NLB は L4（ネットワーク層）で動作するため、通常 SSL/TLS の終端処理を行わない。
そのため、ALB のように HTTPS を処理できず、SSL オフロードもできない。
「エンドツーエンドの暗号化」を実現するためには、NLB ではなく ALB を使用すべき。
❌ NLB は L4 ロードバランサーであり、SSL/TLS の処理ができないため不適切。

結論（正解）

✅ C. ALB + ACM（ALB）+ サードパーティ証明書（EC2）

理由：

ALB に ACM の SSL 証明書を適用し、クライアントとの通信を HTTPS で暗号化できる。
EC2 インスタンスにもサードパーティの SSL 証明書を適用し、ALB → EC2 の通信も HTTPS で暗号化できる。
これにより、「エンドツーエンドの暗号化」を実現できる。

解答と解説

正解：B.

✅ 理由：

新しいオブジェクトの暗号化を管理キー（KMS）で統一するため、デフォルトの暗号化を SSE-KMS に変更する。
- SSE-S3 では S3 がキーを管理するため、企業がキーを管理できるようにするには SSE-KMS に移行する必要がある。
すべてのオブジェクトを適切なキーで再暗号化するために、既存オブジェクトを再アップロードする。
- S3 はデフォルトで既存オブジェクトの暗号化方式を変更しないため、CLI でオブジェクトを再アップロードする必要がある。
S3 バケットポリシーを設定し、暗号化されていない PutObject リクエストを拒否することで、将来のオブジェクトが適切に暗号化されるようにする。

他の選択肢が誤りの理由

❌ A.（SSE-S3 から CMK への変更 + 再アップロード）

CMK（カスタマーマネージドキー）に変更すると書かれているが、正しいのは SSE-KMS（KMS のカスタマーマネージドキー）。
「CMK」の表現があいまいで、KMS のキーかどうか不明確。
KMS を明示的に利用する B の方が要件を正確に満たしている。

❌ C.（SSE-KMS への変更 + 自動暗号化ポリシー）

S3 バケットポリシーで GetObject 時に暗号化を適用することはできない。
PutObject 時に暗号化を適用するには、バケットポリシーではなく S3 のデフォルト暗号化設定を変更する必要がある。
既存のオブジェクトの暗号化を変更する方法が書かれていない。

❌ D.（AES-256 のカスタマーマネージドキー + 再アップロード）

「AES-256 のカスタマーマネージドキー」という表現が不明確で、KMS を指しているか不明。
S3 の SSE-KMS を使うのが適切であるため、B の方が明確に要件を満たす。
KMS で管理するキーでの暗号化が要件なので、AES-256 という記述では不十分。

問題（和訳）

ある企業が AWS クラウド上で Web アプリケーション を運用している。

アプリケーションは Amazon EC2 インスタンス上で動的コンテンツを生成 する。
EC2 インスタンスは Auto Scaling グループ によりスケーリングされ、Application Load Balancer（ALB） のターゲットグループとして構成されている。
Amazon CloudFront を使用して、アプリケーションをグローバルに配信 している。
CloudFront のオリジン（データ取得元）は ALB である。
Amazon Route 53 で DNS を管理 し、www.example.com の A レコードを CloudFront に設定 している。

✅ 要件:
このアプリケーションを 高可用性（Highly Available） かつ フォールトトレラント（Fault Tolerant） にする必要がある。

選択肢（和訳）と評価

A.

別の AWS リージョンにアプリケーション全体を複製（フルデプロイメント）する。
Route 53 の A レコードをフェイルオーバーレコードに変更する。
両方の CloudFront ディストリビューションを登録し、Route 53 ヘルスチェックを作成する。

✅ 評価:

Route 53 のフェイルオーバールーティングは適切な HA/FT（高可用性 & フォールトトレラント）対策。
CloudFront のディストリビューションを 2 つに分けるのは冗長。
Route 53 のヘルスチェックにより、障害時に別リージョンへフェイルオーバー可能。
➡️ ほぼ適切だが、CloudFront を 2 つ作るのは不要。

B.

別の AWS リージョンに ALB、Auto Scaling グループ、EC2 を作成する。
CloudFront のオリジンを 2 つにする（新しい ALB を追加）。
CloudFront のオリジングループを設定し、プライマリ & セカンダリを構成する。

✅ 評価:

CloudFront のオリジングループを使うことで、プライマリ障害時にセカンダリへ自動フェイルオーバー可能。
Route 53 での DNS フェイルオーバーより速い切り替えが可能。
CloudFront でエッジキャッシュを利用できるため、低遅延なアクセスが実現可能。
➡️ 最も適切な HA/FT 構成。 ✅ （正解）

C.

別の AWS リージョンに Auto Scaling グループと EC2 インスタンスを作成する。
ALB のターゲットグループに新しい Auto Scaling グループを追加する。
ALB でフェイルオーバールーティングを設定する。

❌ 評価:

ALB はリージョンをまたいで負荷分散できないため、この方法は機能しない。
ALB のフェイルオーバールーティングでは、リージョン間の冗長性を実現できない。
➡️ ALB の制約により不適切。 ❌

D.

別の AWS リージョンにアプリケーション全体を複製（フルデプロイメント）する。
CloudFront のディストリビューションを 2 つ作成し、新しいアプリケーションをオリジンに設定する。
AWS Global Accelerator を使い、2 つの CloudFront ディストリビューションをエンドポイントとして登録する。

✅ 評価:

Global Accelerator はグローバルなトラフィック管理が可能。
リージョンごとに CloudFront を分ける必要はないため、CloudFront 1 つで対応可能。
Global Accelerator は高可用性を向上させるが、CloudFront 自体がグローバル対応しているため不要なケースが多い。
➡️ CloudFront のオリジングループを使う B の方がシンプルで適切。 ❌

結論と正解

✅ 正解：B.
CloudFront のオリジングループを利用し、プライマリ（通常時のオリジン） と セカンダリ（障害時のオリジン） を設定するのが 最も適切な高可用性（HA） & フォールトトレラント（FT）構成 である。

補足：オリジングループを使う理由

CloudFront は オリジングループ（Origin Groups） を使用することで、プライマリオリジンがダウンした際にセカンダリへ自動的にフェイルオーバー する。

メリット:
- エンドユーザーに影響なく、CloudFront 内で障害対応ができる。
- グローバルに低遅延でコンテンツを提供可能。
- Route 53 を使うフェイルオーバーより速い切り替えが可能。

➡️ したがって、CloudFront のオリジングループを活用する B が最適解。 ✅

選択肢（和訳）と評価

A. JSON ファイルを S3 に保存し、SNS と Lambda でセキュリティグループを更新

Amazon S3 に JSON ファイル を作成し、内部 IP アドレス範囲を保存。
各アカウントに Amazon SNS トピックを作成し、JSON 更新時に通知。
AWS Lambda を SNS にサブスクライブし、セキュリティグループを更新。

❌ 評価:

S3 に保存するだけでは一元管理が難しい。
SNS + Lambda を各アカウントにデプロイするのは運用負荷が高い。
セキュリティグループの更新を Lambda に任せるのは管理が煩雑。
➡️ 運用オーバーヘッドが大きいため、不適切。 ❌

B. AWS Config のマネージドルールを作成し、セキュリティグループを監視・修正

AWS Config にカスタムルールを作成し、IP アドレス範囲を含める。
セキュリティグループを監視し、内部 IP アドレスが適用されているか確認。
コンプライアンス違反のセキュリティグループを自動修正（remediation）。

❌ 評価:

AWS Config は監視には適しているが、IP アドレスの一元管理には向いていない。
各アカウントで AWS Config の修正アクションを設定する必要があるため、運用負荷が高い。
IP アドレス範囲を変更するたびに、AWS Config ルールを更新する必要がある。
➡️ AWS Config はポリシー監視向けであり、IP アドレス管理には不適切。 ❌

C. Transit アカウントで VPC プレフィックスリストを作成し、共有

Transit アカウントで VPC プレフィックスリスト（Prefix List）を作成。
AWS Resource Access Manager（RAM）を使用して、他のアカウントとプレフィックスリストを共有。
他のアカウントのセキュリティグループで、このプレフィックスリストを参照。

✅ 評価:

VPC プレフィックスリストは、IP アドレスの管理を一元化できる適切なソリューション。
すべてのアカウントで同じリストを参照できるため、一括管理が可能。
AWS Resource Access Manager を使うことで、手動で IP を更新する手間が省ける。
➡️ 最も運用負荷が低く、要件に適したソリューション。 ✅ （正解）

D. Transit アカウントでセキュリティグループを作成し、他のアカウントが参照

Transit アカウントでセキュリティグループを作成。
他のアカウントのセキュリティグループが、このセキュリティグループを参照するよう設定（nested security group reference）。

❌ 評価:

異なる AWS アカウント間でセキュリティグループを直接参照することはできない。
セキュリティグループは VPC 内のリソース間の通信制御が主目的であり、IP 範囲管理には向いていない。
トランジットアカウントの SG を更新しても、他のアカウントのセキュリティグループには即座に反映されない。
➡️ セキュリティグループをまたぐ管理はできないため、不適切。 ❌

結論と正解

✅ 正解：C.
「VPC プレフィックスリストを Transit アカウントで作成し、AWS Resource Access Manager を使って共有」 するのが、最も運用負荷が低く、要件に適した方法。

補足：VPC プレフィックスリストを使う理由

VPC プレフィックスリスト（Prefix List）は、複数の IP アドレス範囲を一元管理できる AWS のネイティブ機能 であり、セキュリティグループやルートテーブルで利用可能。

✅ メリット:

一元管理: IP アドレス範囲を 1 つのリストで管理 できる。
自動更新: 他のアカウントに共有 することで、一括更新が可能。
簡単な運用: 各アカウントで セキュリティグループに適用するだけで、管理の手間が省ける。

➡️ したがって、C の「VPC プレフィックスリスト + AWS Resource Access Manager」が最適解。 ✅

問題（和訳）

ある企業が Amazon S3 で静的ウェブサイトをホスティング し、CloudFront 経由で配信している。

バックエンドには API Gateway と AWS Lambda を使用。
API の各メソッドが Lambda 関数を実行。

✅ 要件:

2 週間ごとに CSV レポートを作成。
レポートの内容:
1. 各 Lambda 関数の 推奨メモリ設定。
2. 推奨コスト。
3. 現在の設定とのコスト差額。
レポートを S3 バケットに保存。

✅ 条件:

最小の開発工数で実装。

選択肢（和訳）と評価

A. CloudWatch Logs から Lambda のメトリクスを収集し、手動で計算

Lambda を作成し、CloudWatch Logs から Lambda のメトリクスを取得。
収集したデータを CSV 形式に整形。
S3 に保存。
EventBridge ルールで 2 週間ごとに実行。

❌ 評価:

CloudWatch Logs からメモリ推奨値を直接取得できない。
計算ロジックを自作する必要があり、開発工数が大きい。
➡️ 手間がかかるため不適切。 ❌

B. AWS Compute Optimizer の ExportLambdaFunctionRecommendations を使用

AWS Compute Optimizer を有効化。
Lambda を作成し、Compute Optimizer の ExportLambdaFunctionRecommendations API を実行。
Compute Optimizer の推奨メモリとコストを CSV 形式で S3 に出力。
EventBridge ルールで 2 週間ごとに Lambda を実行。

✅ 評価:

Compute Optimizer は Lambda のメモリ推奨値とコスト推奨値を自動計算。
ExportLambdaFunctionRecommendations を使えば、開発工数を最小化できる。
➡️ 最も手間がかからず、要件を満たすため適切。 ✅ （正解）

C. Compute Optimizer のコンソールから手動でエクスポート

AWS Compute Optimizer を有効化し、Enhanced Infrastructure Metrics を設定。
Compute Optimizer のコンソールで手動エクスポートをスケジュール。
CSV を S3 に保存。

❌ 評価:

Compute Optimizer の コンソールでは手動エクスポートのみ可能 であり、自動化できない。
自動化が必須要件のため不適切。
➡️ 手動作業が必要なので不適切。 ❌

D. AWS Trusted Advisor のコスト最適化レポートを使用

AWS Business Support プランを購入。
AWS Trusted Advisor のコスト最適化レポートを利用。
CSV を S3 に保存。

❌ 評価:

Trusted Advisor は Compute Optimizer ほど詳細な Lambda の設定推奨を提供しない。
Business Support プランが追加コストとなる。
Compute Optimizer の方が直接的に Lambda の最適化データを提供できる。
➡️ コストがかかり、要件に適さないため不適切。 ❌

結論と正解

✅ 正解：B.
「AWS Compute Optimizer を有効化し、ExportLambdaFunctionRecommendations API を使って CSV を S3 にエクスポート」 するのが最も開発負荷が少なく、要件を満たす。

補足：Compute Optimizer の利点

AWS Compute Optimizer は Lambda の推奨メモリ設定とコスト最適化情報を提供 するツール。

Amazon CloudWatch メトリクスを分析し、適切なメモリサイズを推奨。
現在の設定とのコスト差額を計算可能。
API を使って自動で CSV をエクスポート可能。

✅ Compute Optimizer の導入だけで解決できるので、最も開発工数が少なく済む。 ✅

問題（和訳）

ある企業が 単一の VPC で 20 以上のアプリケーションを運用 している。

EC2、ECS、RDS でアプリケーションをホスト。
3 つの開発チームが存在し、それぞれのチームが特定のアプリケーションのコストとパフォーマンスを管理。
リソースには「アプリケーション名」と「チーム名」を示すタグが付与。
IAM アクセスを使用して AWS にログイン。

✅ 要件:

月ごとの AWS 請求書を分析し、各アプリケーションやチームのコストを算出。
過去 12 か月のコスト比較と、今後 12 か月のコスト予測が可能なレポートを作成。

✅ 適切な AWS Billing and Cost Management ソリューションを選択。

選択肢（和訳）と評価

A. ユーザー定義のコスト配分タグを有効化 ✅ （正解）

コスト配分タグ（Cost Allocation Tags）を有効化すると、タグを使ってコストを細分化できる。
「アプリケーション」や「チーム」をタグとして使用することで、チームごとのコストを可視化可能。
➡️ 必須の設定。正解。 ✅

B. AWS が生成したコスト配分タグを有効化 ❌ （不適切）

AWS 自動生成タグ は aws: で始まるが、デフォルトでは特定のチームやアプリケーションを識別するタグはない。
ユーザー定義のタグ（Aの選択肢）を使用する方が適切。
➡️ AWS の自動タグでは要件を満たせないため不適切。 ❌

C. コストカテゴリを作成 ✅ （正解）

コストカテゴリ（Cost Categories）を使うと、タグを基に「アプリケーション別」「チーム別」のコスト分類が可能。
たとえば、「アプリA の全コスト」「チームX の全コスト」などを簡単に集計できる。
➡️ チームごとのコストを把握するために必須。正解。 ✅

D. IAM アクセスを Billing and Cost Management に有効化 ❌ （不適切）

IAM アクセスを有効化すると、IAM ユーザーが AWS Billing の情報を確認できるが、コスト分析機能とは関係ない。
単にコストレポートを作成するためなら不要。
➡️ 必要な設定ではないため不適切。 ❌

E. コスト予算（Cost Budget）を作成 ❌ （不適切）

Cost Budget は「特定の金額を超えたらアラートを送る」機能。
コスト分析や予測のためのレポート作成には不要。
➡️ コスト予測の要件には適さないため不適切。 ❌

F. Cost Explorer を有効化 ✅ （正解）

Cost Explorer は「過去 12 か月のコスト分析」と「今後 12 か月のコスト予測」が可能。
レポートを作成し、アプリケーションやチームごとのコストを可視化できる。
➡️ 長期のコスト分析・予測に必須。正解。 ✅

結論と正解

✅ 正解：A, C, F

A. ユーザー定義のコスト配分タグを有効化（チーム別・アプリ別のコストを分類）
C. コストカテゴリを作成（タグを基にチーム別・アプリ別のコストを集計）
F. Cost Explorer を有効化（過去 12 か月のコスト分析・今後 12 か月のコスト予測）

補足

💡 企業が AWS コスト管理を強化する方法

タグ付けを徹底する（「環境」「アプリ」「チーム」など）
コストカテゴリでグループ化（部署やプロジェクトごとのコスト管理）
Cost Explorer を活用（過去のコスト分析と将来のコスト予測）
AWS Budgets を設定（特定のしきい値を超えたらアラートを出す）

✅ これらを組み合わせることで、企業は効率的に AWS コストを管理できる！ ✅

問題（和訳）

AWS の顧客が、オンプレミスで稼働している Web アプリケーションを AWS に移行 したい。

アプリケーションは、ファイアウォールの背後にあるサードパーティ API にデータを取得。
サードパーティは、1 つの公開 CIDR ブロックのみを許可リストに追加可能。

✅ AWS 環境

EC2 インスタンス（Web アプリ） → プライベートサブネットに配置
ALB（Application Load Balancer） → パブリックサブネットに配置
NAT ゲートウェイがプライベートサブネットからのインターネットアクセスを提供

✅ 要件
AWS に移行後も、Web アプリケーションがサードパーティ API にアクセスできるようにすること。

選択肢の評価

A. VPC に顧客所有のパブリック IP アドレスのブロックを関連付け、パブリックサブネットのパブリック IP アドレスを有効化 ❌ （不適切）

NAT ゲートウェイはプライベートサブネットからの通信に必要。
ALB はアウトバウンド通信をしないため、ALB のパブリック IP ではサードパーティ API にアクセスできない。
➡️ 適切な NAT ゲートウェイ設定が必要なので、不適切。 ❌

B. 顧客所有のパブリック IP アドレスブロックを AWS アカウントに登録し、そのアドレスブロックから Elastic IP を作成し、NAT ゲートウェイに割り当てる ✅ （正解）

NAT ゲートウェイを通じて、プライベートサブネットの EC2 インスタンスがインターネットにアクセス可能。
NAT ゲートウェイの Elastic IP を、サードパーティ API の許可リストに登録できる。
➡️ NAT GW に特定の EIP を割り当てることで、サードパーティ API からのアクセスを維持できる。正解。 ✅

C. 顧客所有のパブリック IP から Elastic IP を作成し、ALB に割り当てる ❌ （不適切）

ALB はアウトバウンド通信には使われない。
ALB に Elastic IP を割り当てても、EC2 からの通信には影響なし。
➡️ アウトバウンド通信の問題を解決できないので、不適切。 ❌

D. 顧客所有のパブリック IP を AWS に登録し、AWS Global Accelerator を使用して Elastic IP を割り当て、ALB をエンドポイントに設定 ❌ （不適切）

Global Accelerator はグローバルなアプリケーションの可用性向上が目的。
アウトバウンド通信（EC2 → サードパーティ API）には影響を与えない。
➡️ 必要な機能ではないため、不適切。 ❌

結論と正解

✅ 正解: B
「顧客所有のパブリック IP を AWS に登録し、その IP から Elastic IP を作成し、NAT ゲートウェイに割り当てる」

プライベートサブネットの EC2 インスタンスは、NAT ゲートウェイを経由して API にアクセスできる。
NAT ゲートウェイの Elastic IP は固定なので、サードパーティの許可リストに登録可能。

➡️ これにより、Web アプリは AWS 移行後も問題なく API にアクセス可能。 ✅

問題（和訳）

会社が Amazon Linux 2 で動作する EC2 インスタンスにホストされたモノリシックアプリケーション を運用している。

EBS ボリュームは暗号化されている。
法律部門からの指示で、データを Amazon S3 にバックアップする必要がある。
アプリケーションは継続して稼働する必要がある。
管理用の SSH キーペアは利用できない。

要件

✅ データを S3 にバックアップする
✅ アプリケーションのダウンタイムを避ける
✅ SSH キーなしで作業を実施する方法を選択

選択肢の評価

A. AWS Systems Manager Session Manager を使用してインスタンスにアクセスし、データを S3 にコピーする ✅ （正解）

Systems Manager Session Manager は SSH キーなしでインスタンスにアクセス可能。
IAM ロールをアタッチすれば、S3 への書き込みが可能。
アプリケーションはそのまま稼働できる（ダウンタイムなし）。
➡️ 要件をすべて満たすため、最適な選択肢。 ✅

B. イメージを作成して新しい EC2 インスタンスを起動し、データを S3 にコピーする ❌ （不適切）

新しいインスタンスを作成すると、データのコピー後に余分なリソースが発生する。
イメージ作成時にインスタンスをリブートすると、ダウンタイムが発生する可能性がある。
より簡単な方法（Systems Manager）があるため、最適ではない。
➡️ 手順が複雑で、ダウンタイムのリスクがあるため不適切。 ❌

C. Amazon Data Lifecycle Manager (DLM) を使って EBS スナップショットを作成し、データを S3 にコピーする ❌ （不適切）

EBS スナップショットを直接 S3 に保存することはできない。
スナップショットを作成しても、アプリケーションデータのバックアップにはならない。
データを取得するには別のインスタンスでマウントする必要があり、手間がかかる。
➡️ 要件を満たさないため、不適切。 ❌

D. イメージを作成して新しい EC2 インスタンスを起動し、データを S3 にコピーする ❌ （不適切）

B と同じ理由で、手順が複雑。
新しい EC2 インスタンスを作る必要はなく、Systems Manager で直接対応可能。
➡️ よりシンプルな方法があるため、不適切。 ❌

結論と正解

✅ 正解: A
「AWS Systems Manager Session Manager を使い、IAM ロールをアタッチして S3 にデータをコピー」

SSH キーなしでインスタンスにアクセス可能。
アプリケーションを停止せずに作業できる（ダウンタイムなし）。
追加のリソースが不要で、コストと手間を最小限に抑えられる。
➡️ 最も効率的な解決策。 ✅

問題（和訳）

ソリューションアーキテクトは、AWS CLI を使用して ある AWS アカウントの Amazon S3 バケット から 別の AWS アカウントの新しい S3 バケット にデータをコピーする必要がある。

要件

✅ AWS CLI を使用してコピーする必要がある
✅ 異なる AWS アカウント間での S3 データ転送を実施
✅ 必要な IAM ポリシーやバケットポリシー を設定

各選択肢の評価

A. バケットポリシーを作成し、送信元バケットが送信先バケットにデータをコピーできるようにする ✅ （正解）

送信元バケットが送信先バケットに書き込み可能である必要がある。
オブジェクトの ACL を設定できる必要がある。
➡️ 送信先バケットに適用するバケットポリシーとして必要。 ✅

B. バケットポリシーを作成し、送信先アカウントのユーザーが送信元バケットのデータを取得できるようにする ✅ （正解）

送信先アカウントのユーザーが送信元バケットのデータを読み取れるようにする必要がある。
➡️ 送信元バケットに適用するバケットポリシーとして必要。 ✅

C. 送信元アカウントの IAM ユーザーに、送信元と送信先バケットへのアクセス権限を付与する IAM ポリシーを作成 ❌ （不適切）

データをコピーするのは送信先アカウントのユーザーが推奨される。
送信先バケットにアクセスするための IAM 設定を送信元で行うのは一般的でない。
➡️ 送信先アカウント側の IAM ユーザーに設定するのが適切（Dが正しい）。 ❌

D. 送信先アカウントの IAM ユーザーに、送信元バケットの読み取りと送信先バケットの書き込み権限を付与する IAM ポリシーを作成 ✅ （正解）

データをコピーするのは送信先アカウントの IAM ユーザーが適切。
送信元バケットのデータを読み取る権限が必要。
送信先バケットに書き込む権限が必要。
➡️ 適切な IAM ポリシー設定のため必要。 ✅

E. 送信元アカウントのユーザーとして `aws s3 sync` コマンドを実行する ❌ （不適切）

データをコピーするのは送信先アカウントの IAM ユーザーが推奨される。
➡️ 送信先アカウント側で aws s3 sync を実行するのが適切（Fが正しい）。 ❌

F. 送信先アカウントのユーザーとして `aws s3 sync` コマンドを実行する ✅ （正解）

送信先アカウントで実行すれば、適切な IAM 設定とバケットポリシーによりデータを取得＆書き込みできる。
➡️ 正しいアプローチのため必要。 ✅

結論と正解の組み合わせ

✅ 正解: A, B, D, F

(A) 送信先バケットのバケットポリシーを設定
(B) 送信元バケットのバケットポリシーを設定
(D) 送信先アカウントの IAM ユーザーに適切な権限を付与
(F) 送信先アカウントの IAM ユーザーとして aws s3 sync コマンドを実行
➡️ 最小の手間で、異なる AWS アカウント間でデータを安全にコピーできる方法。 ✅

問題（和訳）

企業は AWS Lambda ベースのアプリケーション を AWS CloudFormation スタック でデプロイしている。
しかし、本番リリースで発生した問題 により、数分間の障害が発生した。
ソリューションアーキテクトは、カナリアリリース（Canary Release）をサポートするようにデプロイプロセスを調整する必要がある。

カナリアリリースとは？

カナリアリリースは、新しいバージョンを 一部のトラフィック にのみ適用し、問題がないことを確認した後に全体に展開するデプロイ方式。
AWS Lambda の場合、エイリアスとトラフィックシフト を利用して実現できる。

各選択肢の評価

A. エイリアスを作成し、AWS CLI の `update-alias` コマンドの `routing-config` パラメータを使用する ✅ （正解）

AWS Lambda では、エイリアス（Alias）を作成し、バージョン間でトラフィックを分割 できる。
update-alias の routing-config パラメータを使えば、新バージョンに徐々にトラフィックを流すカナリアリリースが可能。
公式ドキュメントでも Lambda のトラフィックシフトはこの方法が推奨されている。
➡️ カナリアリリースに適した正しい方法。 ✅

B. 新しい CloudFormation スタックをデプロイし、Route 53 の加重ルーティング（Weighted Routing）を使用する ❌ （不適切）

Route 53 の Weighted Routing は Lambda には適用できない。
- Route 53 は DNS レベル のルーティングのため、Lambda 関数の バージョン管理とは異なる。
さらに、新しい CloudFormation スタックをデプロイするとインフラ全体を再構築することになり、オーバーヘッドが大きい。
➡️ Lambda のカナリアリリースには適さない。 ❌

C. `update-function-configuration` コマンドの `routing-config` パラメータを使用する ❌ （不適切）

update-function-configuration はLambda 関数の設定（メモリ、タイムアウトなど）を変更するコマンド。
routing-config はエイリアスで使用するものであり、このコマンドでは使用できない。
➡️ 技術的に誤った方法。 ❌

D. AWS CodeDeploy の `CodeDeployDefault.OneAtATime` を使用する ❌ （不適切）

CodeDeployDefault.OneAtATime は EC2 / ECS 用のデプロイ設定 であり、Lambda には適用できない。
Lambda の場合、CodeDeploy の Canary10Percent5Minutes などのカナリア設定を使用するのが正解。
問題文では CodeDeploy の設定変更には触れていないため、選択肢としては不適切。
➡️ Lambda のカナリアリリースには適していない。 ❌

結論と正解の選択肢

✅ 正解: A
（エイリアスを作成し、AWS CLI の update-alias の routing-config を使用する）

➡️ Lambda のカナリアリリースには、エイリアスと routing-config を活用するのがベストプラクティス！ 🎯

各選択肢の評価

A. EC2 を Auto Scaling グループに追加し、ALB の背後に配置する ❌ （不適切）

SFTP（SSHベース）では、ALB（L7 HTTP/HTTPS 用）は適さない。
- ALB は HTTP(S) プロトコル専用 であり、SFTP は TCP/22（SSH） を使用するため動作しない。
Auto Scaling にしても、SFTP はステートフルな接続が必要なので、複数のEC2に負荷分散するのは困難。
➡️ ALB は SFTP に適していないため不適切。 ❌

B. AWS Transfer for SFTP に移行し、DNS を更新する ✅ （正解）

AWS Transfer for SFTP はフルマネージドの SFTP サービスであり、可用性とスケーラビリティが向上する。
EC2 インスタンスを管理する必要がなくなり、AWS による自動スケーリング で高可用性を確保できる。
SFTP のエンドポイントを AWS が提供するため、DNS の sftp.example.com を新しいエンドポイントに更新するだけで移行可能。
➡️ 最適な選択肢！ ✅

C. AWS Storage Gateway のファイルゲートウェイに移行する ❌ （不適切）

Storage Gateway は SFTP を提供しない（NFS/SMB ベースのオンプレミス連携向け）。
現在の SFTP クライアントは NFS/SMB に対応していない可能性が高い。
➡️ Storage Gateway は SFTP の代替にならないため不適切。 ❌

D. EC2 を NLB の背後に配置し、DNS を更新する ❌ （不適切）

NLB は TCP ベースなので、SFTP の負荷分散は可能だが、Auto Scaling による動的なスケーリングは難しい。
EC2 の管理負担が変わらず、根本的な可用性の改善にはならない。
➡️ AWS Transfer for SFTP を使うほうが適切。 ❌

結論と正解の選択肢

✅ 正解: B
（AWS Transfer for SFTP に移行し、DNS を更新する）

➡️ AWS Transfer for SFTP はフルマネージドで、可用性・スケーラビリティの向上に最適！ 🚀

各選択肢の評価

A. アプリを Docker イメージ化し、ECR に公開 ✅ （適切）

Lambda の制限を回避するために、ECS で実行可能な Docker イメージを作成するのは適切なアプローチ。
Amazon ECR は AWS のコンテナレジストリで、ECS や Fargate でのデプロイが容易。
➡️ ECS に移行するための準備として正しい選択。 ✅

B. ECS タスク（Fargate）を作成し、Lambda からトリガー ✅ （適切）

Fargate はインフラ管理不要で、長時間実行が可能 → Lambda の制約を克服できる！
Lambda から Fargate のタスクを起動できるため、イベント駆動のアーキテクチャを維持できる。
➡️ 完全にマネージドで、長時間処理にも適しているため適切！ ✅

C. Step Functions で並列処理を導入 & Lambda のプロビジョンドコンカレンシー増加 ❌ （不適切）

Step Functions はワークフロー管理に適しているが、Lambda の最大実行時間（15分）制約は変わらない。
プロビジョンドコンカレンシーを増やしても、各関数の実行時間が長すぎる場合は解決にならない。
➡️ 処理時間の問題を根本的に解決できないため不適切。 ❌

D. ECS タスク（EC2）を作成し、Lambda からトリガー ❌ （不適切）

ECS（EC2）は管理すべきインフラが発生するため、運用負担が増える。
問題文の「インフラ管理を避けたい」に反する。
➡️ Fargate の方が適しているため不適切。 ❌

E. EFS に保存し、RDS を使用するように変更 ❌ （不適切）

EFS は共有ストレージとして便利だが、Lambda の実行時間制約を解決しない。
RDS に移行しても、Lambda のタイムアウトの問題は変わらない。
➡️ 長時間処理の問題を解決しないため不適切。 ❌

結論と正解の選択肢

✅ 正解: A & B

A: Docker イメージを作成し、ECR に公開する。
B: Fargate を使い、Lambda から ECS タスクを起動する。

➡️ インフラ管理なしで、長時間処理のワークロードに対応できる最適な解決策！ 🚀

各選択肢の評価

A. AWS Control Tower の「Mandatory Guardrails」を適用する ❌ （不適切）

Mandatory Guardrails（必須ガードレール） は、AWS によって強制的に適用されるポリシー だが、RDS の暗号化チェックに関するものは存在しない。
したがって、この選択肢では要件を満たせない。

➡️ 不適切。 ❌

B. 「Strongly Recommended Guardrails」を適用する ❌ （不適切）

Strongly Recommended Guardrails（推奨ガードレール） には、RDS の暗号化チェックを行うものはない。
AWS Control Tower のガードレールは SCP や AWS Config ルールを組み合わせたものだが、直接的な RDS の暗号化チェックは提供していない。

➡️ 不適切。 ❌

C. AWS Config を使用してカスタムルールを作成し、OU に適用する ✅ （適切）

AWS Config には「rds-storage-encrypted」ルールがあり、RDS の暗号化状態を監視できる。
AWS Config ルールを OU 配下のすべてのアカウントに適用することで、要件を満たせる。
AWS Organizations と AWS Config の統合を利用すると、組織全体のルール管理が可能。

➡️ 適切なソリューション。 ✅

D. AWS Control Tower の SCP（サービスコントロールポリシー）を作成し、OU に適用する ❌ （不適切）

SCP は「ポリシー適用」には適しているが、「既存のリソースの検出」には使えない。
SCP は新しいリソースの作成や変更を制限するが、すでに作成されている「暗号化されていない RDS インスタンス」を検出する機能はない。

➡️ 検出が目的のため不適切。 ❌

結論と正解の選択肢

✅ 正解: C. AWS Config を使用してカスタムルールを作成し、OU に適用する

AWS Config を使用すれば、組織全体で RDS の暗号化チェックを自動的に実施できる。
これが要件を満たす最も適切な解決策。 🚀

問題のポイント

✅ SSH アクセスのセキュリティを向上させる必要がある
✅ エンジニアが実行するコマンドの監査（Auditing）が必要
✅ 既存の構成には VPN があり、EC2 インスタンスはプライベートサブネット内にある

各選択肢の評価

A. EC2 Instance Connect を使用する ❌ （不適切）

EC2 Instance Connect は Amazon Linux 2 で利用できるが、プライベートサブネット内の EC2 では利用が難しい。
EC2 Instance Connect はパブリック IP を持つインスタンスでの SSH アクセスを容易にするが、プライベートサブネットの EC2 には適していない。
また、エンジニアが実行するコマンドの監査機能は提供されない。

➡️ 不適切。 ❌

B. IP 制限付きの SSH ＋ CloudWatch Logs で監査 ❌ （不適切）

エンジニアのデバイスの IP アドレスのみを許可することでセキュリティは向上するが、完全な SSH アクセスを許可しているため根本的な問題は解決しない。
CloudWatch Logs を使用して監査ログを記録するのは良いが、SSH セッション自体をより安全に管理する仕組みがない。

➡️ 不適切。 ❌

C. IP 制限付きの SSH ＋ AWS Config & AWS Firewall Manager を利用する ❌ （不適切）

SSH アクセスを IP 制限することでセキュリティは向上するが、SSH 自体を無効化していないためリスクが残る。
AWS Config でセキュリティグループの変更を監視し、Firewall Manager で修正するのは良いが、監査機能としては不十分。
エンジニアのコマンドを記録する仕組みがない。

➡️ 不適切。 ❌

D. AWS Systems Manager Session Manager を使用する ✅ （適切）

IAM ロールに AmazonSSMManagedInstanceCore ポリシーを適用することで、SSH を不要にしつつ EC2 インスタンスへ安全にアクセスできる。
Session Manager は AWS CloudTrail による監査ログ記録を提供し、エンジニアが実行したコマンドの監査が可能。
SSH を完全に排除することで、セキュリティリスクを大幅に削減できる。
VPN は維持したまま、オンプレミスから Session Manager 経由でアクセス可能。

➡️ 最も適切なソリューション。 ✅

結論と正解の選択肢

✅ 正解: D. AWS Systems Manager Session Manager を使用する

SSH を完全に無効化し、Session Manager による安全なアクセスと監査ログを実現。
セキュリティ強化と運用の容易さを両立できる。 🚀

問題のポイント

✅ 開発者が AWS で実験できるようにするが、コストを制限する必要がある
✅ 各開発者アカウントに固定の月間予算を設定する必要がある
✅ 高額なサービスの使用を防ぐ、または制限する必要がある

各選択肢の評価

A. SCP を作成して固定の月間使用制限を設定し、開発者アカウントに適用する ❌ （不適切）

Service Control Policies (SCPs) は AWS の API 呼び出しを制限するが、コスト制限の機能は提供しない。
SCP で「$100 以上のコストを発生させる API をブロックする」といった制限は設定できない。
SCP ではなく AWS Budgets を使用するのが正解。

➡️ 不適切。 ❌

B. AWS Budgets を使用して各開発者アカウントに固定の月間予算を設定する ✅ （適切）

AWS Budgets を使用すると、各開発者アカウントに対して月ごとの固定予算を設定できる。
予算を超えた場合にアラートを発生させることが可能。

➡️ 適切。 ✅

C. SCP を作成して高額なサービスやコンポーネントへのアクセスを拒否し、開発者アカウントに適用する ✅ （適切）

SCP は AWS Organizations 内のアカウント全体に適用できるため、高額なサービス（例: Amazon Redshift, Amazon SageMaker, 高スペック EC2 インスタンスなど）をブロックするのに適している。
開発者がコストの高いリソースを作成しないように制限できる。

➡️ 適切。 ✅

D. IAM ポリシーを作成して高額なサービスやコンポーネントへのアクセスを拒否し、開発者アカウントに適用する ❌ （不適切）

IAM ポリシーは特定の IAM ユーザーやグループに適用するものなので、アカウント全体に適用するには SCP の方が適している。
SCP は AWS Organizations の管理者が組織単位 (OU) やアカウントに一括適用できるため、SCP の方が管理しやすい。

➡️ 不適切。 ❌

E. AWS Budgets のアラートアクションを設定し、予算に達したらすべてのサービスを強制終了する ❌ （不適切）

AWS Budgets のアラートアクションでは、直接すべてのサービスを自動終了することはできない。
AWS Budgets から直接リソースを削除するアクションは提供されていない。
代わりに、SNS 通知＋Lambda でリソースを停止する手法を使用すべき。

➡️ 不適切。 ❌

F. AWS Budgets のアラートアクションを設定し、SNS 通知を送信して Lambda を実行し、すべてのサービスを強制終了する ✅ （適切）

AWS Budgets では、設定した予算を超えた場合に Amazon SNS で通知を送信できる。
SNS 通知をトリガーに AWS Lambda を実行し、EC2 インスタンスの停止、RDS のスナップショット作成後の削除などを自動化できる。
この方法ならば、一定のコストを超えた際にサービスを確実に停止し、開発者のコストを制限できる。

➡️ 適切。 ✅

結論と正解の選択肢

✅ 正解: B, C, F

B. AWS Budgets で開発者アカウントに固定の月間予算を設定
C. SCP を使って高額なサービスの使用を制限
F. AWS Budgets のアラートを SNS 経由で Lambda に渡し、リソースを停止

この 3 つの組み合わせにより、コストの上限設定・高額リソースの制限・コスト超過時の自動対応が実現できる。 🚀

問題のポイント

✅ AWS Organizations 内の Source アカウントから Target アカウントへ Lambda 関数と Aurora データベースを移行する
✅ ダウンタイムを最小限にする必要がある
✅ Aurora は自動バックアップを設定済み
✅ Lambda 関数はデプロイメントパッケージを使用してデプロイされている

各選択肢の評価

A. Lambda のデプロイメントパッケージをダウンロードし、Target アカウントで新しい Lambda を作成。Aurora の自動スナップショットを共有する。 ✅ （適切）

Lambda のデプロイメントパッケージをダウンロードして再デプロイするのは一般的な方法。
Aurora の自動スナップショットは AWS Organizations 内で他のアカウントと共有可能。
Target アカウントでスナップショットを元に新しい Aurora クラスターを作成できる。
ダウンタイムを最小限に抑えながらデータの移行が可能。

➡️ 適切。 ✅

B. Lambda のデプロイメントパッケージをダウンロードし、Target アカウントで新しい Lambda を作成。AWS RAM で Aurora クラスターを共有し、クローンを作成する。 ❌ （不適切）

Aurora のクラスター自体は AWS RAM で共有できない。
Aurora クラスターのスナップショットを共有することは可能。
クラスターの直接共有はできないため、適切ではない。

➡️ 不適切。 ❌

C. AWS RAM を使用して、Lambda 関数と Aurora クラスターを共有し、Target アカウントでクローンを作成する。 ❌ （不適切）

Lambda 関数は AWS RAM で共有できない。
Aurora クラスター自体も AWS RAM では共有できない（スナップショットは共有可能）。
Lambda はデプロイメントパッケージを再デプロイする必要がある。

➡️ 不適切。 ❌

D. AWS RAM を使用して Lambda 関数を共有し、Aurora の自動スナップショットを共有する。 ❌ （不適切）

Lambda 関数は AWS RAM で共有できない。
Aurora のスナップショットは AWS RAM ではなく、手動で共有する必要がある。
Lambda 関数の移行にはデプロイメントパッケージを再デプロイする方法が適切。

➡️ 不適切。 ❌

結論と正解の選択肢

✅ 正解: A

Lambda のデプロイメントパッケージをダウンロードして Target アカウントで新しい Lambda を作成する。
Aurora の自動スナップショットを Target アカウントと共有し、新しいクラスターを作成する。

この方法が 最もシンプルかつダウンタイムを最小限に抑えた移行方法 となる。 🚀

問題のポイント

✅ Python スクリプトが 10 分ごとに実行され、S3 からファイルを取得・処理する。
✅ 平均 5 分で 1 ファイルを処理するため、EC2 インスタンスが約 40% の時間アイドル状態。
✅ 高可用性、スケーラビリティ、管理負担の低減が必要。
✅ コストを最適化したい。

各選択肢の評価

A. AWS Lambda を使用し、S3 イベント通知で Lambda 関数をトリガーする。 ✅ （最適解）

Lambda はイベント駆動型であり、アイドル時間がなくコスト効率が良い。
S3 イベント通知を活用し、新しいファイルがアップロードされたら即時処理を開始できる。
サーバーレスなので、管理負担が最も少ない。
Lambda の最大実行時間（15 分）内に処理が完了するため適用可能。
スケーラブルであり、複数のファイルを並行処理可能。

➡️ コスト最適化、高可用性、スケーラビリティ、管理負担の削減の観点から最適。 ✅

B. SQS キューを作成し、EC2 Auto Scaling でスケールアウトする。 ❌ （不適切）

SQS を活用してワークロードの分散はできるが、EC2 インスタンスを維持するためのコストが発生する。
EC2 のアイドル時間が発生する可能性があり、コスト最適化に劣る。
Auto Scaling は可能だが、Lambda のような柔軟なスケーリングには及ばない。
管理負担（EC2 の運用・スケーリング）が発生する。

➡️ EC2 を使用するため、コスト効率や管理負担の面で適切ではない。 ❌

C. コンテナ化して EC2 上で実行し、S3 をポーリングする。 ❌ （不適切）

コンテナを EC2 で動かすと、EC2 の管理が必要になる。
アイドル時間が発生する可能性があり、コスト効率が悪い。
S3 のポーリングは非効率で、イベント駆動の Lambda よりも適切ではない。

➡️ Lambda のほうが管理負担が少なく、コスト効率も良い。 ❌

D. ECS on Fargate を使用し、Lambda で Fargate タスクをトリガーする。 ❌ （不適切）

Fargate はサーバーレスコンテナであり、EC2 よりも管理負担は少ないが、Lambda よりもコストが高い場合がある。
Lambda で Fargate タスクをトリガーするより、直接 Lambda で処理したほうがシンプルで管理が楽。
イベント駆動は可能だが、Lambda のほうがより手軽でコスト効率が良い。

➡️ Lambda を直接使うほうがシンプルでコスト効率が良い。 ❌

結論と正解の選択肢

✅ 正解: A

AWS Lambda を使用し、S3 イベント通知でファイル処理をトリガーする。
イベント駆動型であり、アイドル時間がなく、コスト効率が最も良い。
サーバーレスのため、管理負担が最小限。
Lambda の最大実行時間（15 分）内に処理が完了するため適用可能。

この方法が 最もコスト効率が良く、スケーラブルで、管理負担が少ない最適なソリューション となる。 🚀

問題のポイント

✅ 高可用性（HA）: us-east-1 でアプリケーションをホストし、複数の Availability Zones (AZs) に分散させる。
✅ スケーラビリティ: トラフィックに応じて EC2 Auto Scaling を使用する。
✅ ディザスタリカバリ（DR）: us-west-1 にパッシブフェイルオーバー環境を用意する。
✅ フェイルオーバー: Route 53 を使用してヘルスチェックを行い、us-west-1 に切り替える。

各選択肢の評価

A. VPC ピアリングを設定し、ALB を両方の VPC にまたがる形で配置する。 ❌ （不適切）

ALB はリージョンをまたぐことはできない → マルチリージョン ALB はサポートされていない。
VPC ピアリングを使っても、ALB は他のリージョンの VPC にまたがることができない。
DR 環境（us-west-1）の Auto Scaling の構成が考慮されていない。

➡️ ALB のリージョン制限により、このアプローチは実現不可能。 ❌

B. 各リージョン（us-east-1, us-west-1）に同じ構成を作成し、Route 53 でレコードを作成する。 ❌ （不適切）

"Enable health checks to ensure high availability between Regions" とあるが、フェイルオーバールーティングの設定が明確でない。
Route 53 でヘルスチェックを行う記述はあるが、フェイルオーバールーティングポリシーがないため、アクティブ-パッシブ DR を完全に実装できていない。

➡️ フェイルオーバールーティングが不足しているため、要件を満たしていない。 ❌

C. 各リージョン（us-east-1, us-west-1）に同じ構成を作成し、Route 53 のフェイルオーバールーティングを設定する。 ✅ （最適解）

各リージョンに VPC を作成し、ALB を複数の AZ に分散。
各リージョンの Auto Scaling Group を ALB の背後に配置し、動的スケーリングが可能。
Route 53 にヘルスチェックを設定し、フェイルオーバールーティングを適用。
us-east-1 の ALB にプライマリレコードを作成し、障害発生時に us-west-1 の ALB にフェイルオーバー。

➡️ アクティブ-パッシブ DR、スケーラビリティ、高可用性のすべてを満たしているため、最適な解答。 ✅

D. VPC ピアリングを設定し、ALB を両リージョンにまたがる形で配置する。 ❌ （不適切）

ALB はリージョンをまたげないため、実現不可能。
A と同じ問題がある（ALB は VPC ピアリングを通じて別リージョンのリソースにトラフィックをルーティングできない）。
フェイルオーバーの設定がなく、DR 戦略として機能しない。

➡️ ALB の制約のため、技術的に不可能。 ❌

結論と正解の選択肢

✅ 正解: C

各リージョンに VPC を作成し、それぞれに ALB + Auto Scaling をデプロイ。
Route 53 でフェイルオーバールーティングポリシーを設定し、ヘルスチェックを適用。
プライマリ（us-east-1）がダウンした場合、自動的に us-west-1 にフェイルオーバー。
可用性、スケーラビリティ、ディザスタリカバリの要件をすべて満たす。

この構成が 最も実用的で、AWS のベストプラクティスに合致したアプローチ となる。 🚀

問題のポイント

✅ IAM ユーザー管理の簡素化:

現在、IAM ユーザーを手動管理しているが、Active Directory (AD) の資格情報を使ってログインしたい。
✅ AWS IAM Identity Center (AWS Single Sign-On) を利用:
IAM Identity Center を使用し、既存の AD 資格情報で AWS 管理コンソールにアクセスできるようにする。
✅ コスト効率の高いソリューション:
AWS Managed Microsoft AD は高コストであるため、より低コストな AD Connector の使用が理想的。

各選択肢の評価

A. AWS Managed Microsoft AD を使い、IAM Identity Center の ID ソースとして設定する。 ❌ （コストが高い）

AWS Managed Microsoft AD は高コスト（1 か月あたり数百ドル以上）。
IT サポートチームが Active Directory をそのまま使いたいだけなら、AWS Managed Microsoft AD を使う必要はない。
よりコスト効率の良い AD Connector で代用可能。

➡ AWS Managed Microsoft AD は不要なため、不適切。 ❌

B. AD Connector を使い、IAM Identity Center の ID ソースとして設定する。 ✅ （最適解）

AD Connector を利用することで、AWS Managed Microsoft AD のコストを回避できる。
オンプレミスの Active Directory にそのまま接続可能。
IAM Identity Center に AD Connector を ID ソースとして設定できる。
低コストで既存の AD 資格情報を活用できる。

➡ 最もコスト効率が高く、シンプルな解決策。 ✅

C. AWS Managed Microsoft AD を使い、IAM Identity Center の ID ソースとして設定する。 ❌ （A と同じ理由でコストが高い）

A の選択肢と同じく、AWS Managed Microsoft AD を使用しており、コストがかかる。
要件を満たすだけなら、AWS Managed Microsoft AD を使う必要はない。

➡ コストが高いため、不適切。 ❌

D. AD Connector を使い、IAM Identity Center の ID ソースとして設定する（B と類似）。 ✅ （適切）

AD Connector を使用するため、低コストで Active Directory を AWS に統合できる。
IAM Identity Center を利用して、SSO 認証を実現できる。
B とほぼ同じ内容で、正しいアプローチ。

➡ B と同じく、適切な解決策。 ✅

結論と正解の選択肢

✅ 最適な選択肢: B または D（どちらも正解）

AD Connector を使用することで、AWS Managed Microsoft AD のコストを回避。
IAM Identity Center に統合し、Active Directory の資格情報を使って AWS にログイン可能。
コスト効率が高く、シンプルな構成で運用できる。

最もコスト効率の良い解決策は B または D！ 🚀

問題のポイント

✅ オーストラリアのユーザー向けに S3 へのアップロードを高速化する必要がある。
✅ アップロードするファイルサイズは 1GB ～ 10GB と大きい。
✅ アップロードの途中で失敗するケースがある。
✅ 遅延を最小限に抑えつつ、失敗率を低減する必要がある。

各選択肢の評価

✅ A. S3 Transfer Acceleration を有効にし、アプリを Transfer Acceleration エンドポイントを使用するように構成する。

S3 Transfer Acceleration は Amazon CloudFront のエッジロケーションを利用して、物理的に遠いユーザーでも S3 へのアップロードを高速化できる。
オーストラリアのユーザーは、近くのエッジロケーションを経由して、低遅延で S3 にファイルをアップロード可能。
解決策として理想的。

➡ 正解 ✅

❌ B. 各リージョンに S3 バケットを作成し、S3 クロスリージョンレプリケーション（CRR）を使用してコピーする。

S3 CRR は「データの冗長性とバックアップ」のための機能であり、「アップロードの高速化」には適さない。
ユーザーが直接アップロードするため、各リージョンの S3 にルーティングする方法が必要になる。
ユーザーのアップロード速度には影響しないため不適切。

➡ 不正解 ❌

❌ C. Amazon Route 53 のレイテンシーベースルーティングを使用し、最も近い S3 バケットリージョンにルーティングする。

S3 バケットは「リージョンごと」に作成されるが、S3 自体にはレイテンシーベースルーティング機能がない。
ユーザーが特定のリージョンの S3 にアップロードするには、アプリ側でリージョンを指定する必要がある。
S3 Transfer Acceleration のほうが適切な解決策。

➡ 不正解 ❌

✅ D. アプリを変更して動画ファイルをチャンク（分割）し、マルチパートアップロードを使用して S3 に転送する。

S3 マルチパートアップロード は、大きなファイルを小さなチャンクに分割してアップロードすることで、失敗時の再試行を容易にする。
途中でネットワークが切れても、再送が可能になるため、アップロード成功率が向上。
特に 5GB 以上のファイルではマルチパートアップロードが推奨される。

➡ 正解 ✅

❌ E. ファイル名にランダムなプレフィックスを追加してからアップロードする。

S3 では大量のアップロードが同じプレフィックスを持つと、内部でホットスポット（ボトルネック）が発生する可能性がある。
しかし、アップロード速度の向上には関係ない。
これは**「大量の小さなファイル」を扱う場合のパフォーマンス最適化手法**であり、本ケースには適さない。

➡ 不正解 ❌

結論と正解の選択肢

✅ 最適なソリューション:
1️⃣ A. S3 Transfer Acceleration（低遅延でのアップロード）
2️⃣ D. マルチパートアップロード（アップロード失敗を減らす）

正解: ✅ A と D 🚀

問題のポイント

✅ Amazon RDS for MySQL Multi-AZ のフェイルオーバー後にアプリケーションがデータベース接続を再確立できない問題が発生している。
✅ アプリケーションを再起動すると接続できるため、接続の処理方法に問題がある可能性が高い。
✅ フェイルオーバー後のデータベースエンドポイントの変更に影響されないソリューションが必要。

各選択肢の評価

✅ B. RDS プロキシを作成し、RDS エンドポイントをターゲットとして設定。アプリケーションの接続設定を RDS プロキシエンドポイントに更新する。

RDS Proxy は、データベースへの接続プールを管理し、フェイルオーバー時にアプリケーションがシームレスに接続できるようにする。
フェイルオーバーが発生しても、アプリケーションは RDS Proxy のエンドポイントに接続し続けることができるため、アプリ再起動が不要。
接続の再確立が自動で行われるため、要件を満たす最適なソリューション。

➡ 正解 ✅

❌ A. Amazon Aurora MySQL Serverless v1 に移行し、アプリの接続先を Aurora のリーダーエンドポイントに変更する。

Aurora Serverless v1 は オンデマンドでインスタンスをスケールする ソリューションであり、「フェイルオーバー時の接続維持」とは関係がない。
Aurora のリーダーエンドポイントは 読み取り専用 であり、書き込み操作がある場合は適用できない。
問題の根本解決にはならないため、不適切。

➡ 不正解 ❌

❌ C. Aurora MySQL クラスターを作成し、RDS を移行。RDS Proxy を設定し、アプリの接続先を変更する。

Aurora クラスターは高可用性を提供するが、RDS の Multi-AZ でも同様のフェイルオーバー機能を提供しているため、移行は不要。
フェイルオーバー後の接続維持の問題は Aurora に移行しても解決しないため、RDS Proxy の導入だけで十分。
余分な移行作業が発生するため、コストと運用負担が増加。

➡ 不正解 ❌

❌ D. Amazon S3 にデータをエクスポートし、Athena でクエリを実行。ODBC ドライバーを使用してアプリの接続先を Athena に変更する。

Athena は S3 上のデータに対して SQL クエリを実行するサービス であり、リアルタイムなトランザクション処理（OLTP）には適していない。
既存のアプリケーションの動作を大幅に変更する必要があり、根本的な解決策にならない。
フェイルオーバー後の接続再確立とは関係がないため不適切。

➡ 不正解 ❌

結論と正解の選択肢

✅ 最適なソリューション:
B. RDS Proxy を導入し、フェイルオーバー時の接続維持を実現する。

正解: ✅ B 🚀

問題（和訳）

ある企業が AWS クラウド上にソリューションを構築しています。数千台のデバイスがこのソリューションに接続し、データを送信します。

✅ 各デバイスは MQTT プロトコルを使用してデータを送受信する必要があります。
✅ 各デバイスは 一意の X.509 証明書 を使用して認証する必要があります。
✅ 最小限の運用オーバーヘッド で要件を満たすソリューションを選択する必要があります。

選択肢（和訳）

A. AWS IoT Core をセットアップする。各デバイスに対応する Amazon MQ キュー を作成し、証明書をプロビジョニングする。各デバイスを Amazon MQ に接続する。

B. Network Load Balancer（NLB） を作成し、AWS Lambda 認可機能を設定する。Amazon EC2 インスタンス上に MQTT ブローカー を実行し、Auto Scaling グループで管理する。NLB のターゲットに Auto Scaling グループを設定し、各デバイスを NLB に接続する。

C. AWS IoT Core をセットアップする。各デバイスに対応する AWS IoT Thing を作成し、証明書をプロビジョニングする。各デバイスを AWS IoT Core に接続する。

D. Amazon API Gateway の HTTP API と Network Load Balancer（NLB） をセットアップする。API Gateway と NLB の統合を設定し、相互 TLS（mTLS）証明書認可 を HTTP API に構成する。Amazon EC2 インスタンス上に MQTT ブローカー を実行し、NLB のターゲットとして設定する。各デバイスを NLB に接続する。

回答と解説

✅ 正解: C. AWS IoT Core をセットアップし、各デバイスに AWS IoT Thing と証明書をプロビジョニングする。各デバイスを AWS IoT Core に接続する。

解説

AWS では、IoT デバイスが MQTT プロトコルを使用して効率的にデータを送受信できるように AWS IoT Core が提供されています。

🔹 AWS IoT Core の利点:
✅ X.509 証明書によるデバイス認証 がネイティブでサポートされている。
✅ MQTT プロトコルをサポート し、デバイスとクラウド間でリアルタイム通信が可能。
✅ フルマネージドサービス のため、EC2 インスタンスやロードバランサーの運用が不要で、最小限のオーバーヘッドで済む。
✅ スケーラブル であり、数千台のデバイスを効率的に管理できる。

この選択肢は、最小限の運用負担 で最適なソリューションを提供するため、正解です。

誤りのある選択肢とその理由

❌ A. Amazon MQ を使用する方法

理由:
🔸 Amazon MQ は主にエンタープライズ向けのメッセージブローカー であり、IoT デバイスの大規模管理には適していない。
🔸 MQTT をサポートしているが、X.509 証明書ベースの認証機能がネイティブにない。
🔸 スケーラビリティが AWS IoT Core に比べて低い。
➡ 運用負荷が増え、要件に最適ではないため不適切。

❌ B. Network Load Balancer（NLB）+ EC2 MQTT ブローカー

理由:
🔸 NLB は TCP トラフィックの負荷分散はできるが、MQTT 用の認証機能を提供しない。
🔸 MQTT ブローカーを EC2 インスタンス上で運用する必要があり、管理コストが増大する。
🔸 スケーリングや高可用性の管理が AWS IoT Core に比べて難しい。
➡ フルマネージドな AWS IoT Core に比べて運用負荷が高く、最適な解決策ではない。

❌ D. API Gateway + NLB + EC2 MQTT ブローカー

理由:
🔸 API Gateway の HTTP API は、主に REST API 向けのサービスであり、MQTT プロトコルとの相性が悪い。
🔸 mTLS（相互 TLS）はセキュリティを強化できるが、AWS IoT Core では X.509 証明書ベースの認証がすでに提供されているため、不要な追加コストが発生する。
🔸 EC2 で MQTT ブローカーを運用する必要があり、スケーラビリティや可用性の管理が AWS IoT Core に比べて難しい。
➡ 運用コストが増大し、AWS IoT Core よりも適していない。

結論

最小限の運用負担で要件を満たすベストな選択肢は C: AWS IoT Core を使用する方法。

✅ 正解: C 🎯

答と解説

✅ 正解: C. AWS CloudFormation の操作のみ許可し、承認済みリソースのプロビジョニングはサービスロールを使用する。

解説

この問題のポイントは 「エンジニアが承認済みリソースのみを作成できるように制限する」 ことです。

C のアプローチ:
✅ エンジニアの IAM ロール は、AWS CloudFormation の操作のみ許可する（スタックの作成・更新・削除など）。
✅ リソースのプロビジョニング権限 は、AWS CloudFormation スタック実行時に使用する IAM サービスロール に委任する。
✅ IAM サービスロールには、承認済みリソースのみを作成できる権限を付与 する。
✅ エンジニアは AWS CloudFormation を通じてのみリソースを作成できるが、承認済みリソース以外は作成できない。

この方法なら、エンジニアが IAM ポリシーを変更したり、別のリソースを作成したりするリスクを防げる ため、最も適切です。

誤りのある選択肢とその理由

❌ A. S3 に CloudFormation テンプレートを保存し、IAM ポリシーで制限

理由:
🔸 S3 に CloudFormation テンプレートを保存しても、エンジニアがそのテンプレートを使用するかどうか 強制できない。
🔸 エンジニアが独自の CloudFormation テンプレートを作成し、好きなリソースを作成する可能性がある。
➡ 制限が不十分なため不適切。

❌ B. エンジニアの IAM ポリシーで承認済みリソースのみ許可する

理由:
🔸 IAM ポリシーで「承認済みリソースのみ許可」を実装することは可能だが、エンジニアが IAM ポリシーを変更するリスクがある。
🔸 CloudFormation にリソース制限を組み込む方法がないため、抜け道ができる可能性がある。
➡ IAM サービスロールを使う方がより厳密な制御が可能なので不適切。

❌ D. CloudFormation スタックを使い、エンジニアの IAM ロールをスタック単位で制限

理由:
🔸 「エンジニアが承認済みリソースのみを作成できる」ことを保証できない。
🔸 エンジニアが CloudFormation テンプレートの内容を自由に変更できる可能性がある。
🔸 すでに作成されたスタックへのアクセス制限はできるが、新規リソースの制御には不十分。
➡ C の方がより厳密に制御できるため不適切。

結論

✅ C のアプローチ（CloudFormation の操作のみ許可し、承認済みリソースのプロビジョニングは IAM サービスロールを使用） が最適なソリューション。
✅ 正解: C 🎯

回答と解説

✅ 正解: B. Amazon DynamoDB を使用し、TTL 機能で 120日後に自動削除

解説

DynamoDB を選択すべき理由

✅ 高いスケーラビリティと低レイテンシー

DynamoDB は大規模な書き込みにも対応でき、データの取得も高速。
アプリケーションが毎分数百万レコードを処理できるようにスケール可能。

✅ TTL（Time to Live）機能で自動削除

TTL を設定すれば 120日後にレコードが自動削除され、手動の削除処理が不要。
コスト最適化にも有効（不要なデータが残らない）。

✅ データサイズに適している

1レコード 4 KB 未満 → DynamoDB のアイテムサイズ制限（最大 400 KB）に十分収まる。
年間 10-15 TB のストレージ → DynamoDB なら ストレージ管理を意識せずに利用可能。

誤りのある選択肢とその理由

❌ A. 各レコードを個別の .csv ファイルとして S3 に保存

理由:
🔸 S3 はスケーラブルだが、低レイテンシーのデータ取得には向いていない。
🔸 1レコード 4 KB の小さなファイルを大量に保存すると、S3 のパフォーマンスが低下する。
🔸 S3 には ネイティブなインデックス検索機能がない（オブジェクト名検索に頼ることになる）。
➡ データ取得のレイテンシーが大きく、要件に合わない。

❌ C. Amazon RDS MySQL を使用し、cron ジョブで古いデータを削除

理由:
🔸 毎分数百万レコードの書き込みを処理するには RDS MySQL はスケールしにくい。
🔸 テーブルサイズが増大するとクエリのパフォーマンスが低下する。
🔸 ナイトリーの cron ジョブでデータ削除すると、大量のレコード削除に時間がかかる。
➡ 高負荷のワークロードに適さず、管理も複雑になる。

❌ D. レコードをバッチ処理し、S3 に保存してメタデータ検索を使用

理由:
🔸 S3 のメタデータ検索機能（S3 Select や Amazon Athena）は強力だが、レイテンシーが大きい。
🔸 バッチ処理すると、リアルタイムでデータ取得するのが難しくなる。
🔸 S3 はオブジェクト単位での削除が必要（DynamoDB のように自動削除ができない）。
➡ リアルタイムの低レイテンシー取得には向いていない。

結論

要件	A: S3 (.csv)	B: DynamoDB (TTL)	C: RDS MySQL	D: S3 (バッチ処理)
スケーラビリティ	❌ 遅い	✅ 優秀	❌ 限界あり	❌ 限界あり
低レイテンシー取得	❌ 高レイテンシー	✅ 低レイテンシー	❌ クエリが重い	❌ 高レイテンシー
ストレージ管理	✅ S3 のライフサイクル	✅ TTL で自動管理	❌ 手動管理必要	✅ S3 のライフサイクル
削除の簡便さ	✅ ライフサイクル設定	✅ TTL で自動削除	❌ cron ジョブが必要	✅ ライフサイクル設定
コスト効率	❌ 小さいファイルの管理コスト増	✅ 必要なデータのみ保存	❌ RDS のスケールコスト高	✅ コスト最適化可能だが非効率

✅ B. DynamoDB + TTL が最適なソリューション 🎯

解説

❌ B. Transit Gateway + 新しい VPN は不要

すでにオンプレミスと VPC A は Site-to-Site VPN で接続済み。
VPC A ⇄ VPC B はピアリング済み なので、追加の VPN 接続は不要。

❌ C. BGP 伝播だけでは対応できない

AWS の VPC ピアリングでは、オンプレミスとのルートを自動伝播しない。
BGP 伝播を有効にするだけでは、オンプレミスが VPC B のルートを認識しないため 通信できない。

❌ D. VPN の仮想プライベートゲートウェイ（VGW）は VPC 1 つにしか関連付けられない

AWS の VGW は 1 つの VPC にしか関連付けられない（マルチ VPC にアタッチ不可）。
VPC B に直接 VGW をアタッチする方法は存在しない。

✅ A. AWS Transit Gateway を使用するとシンプルに解決できる

Transit Gateway を作成し、オンプレミス VPN・VPC A・VPC B をアタッチすれば、すべてのネットワークが接続可能になる。
シンプルなルートテーブル設定で、すべての通信を一元管理できる（管理負担が少ない）。
AWS 推奨のネットワーク設計パターン に適合している。

まとめ

選択肢	解説
A (正解)	Transit Gateway を作成し、VPN・VPC A・VPC B を接続する。最もシンプルで管理しやすい解決策。✅
B	VPC A 経由の VPN 接続が既にあるため、新しい VPN は不要。🚫
C	VPC ピアリングではオンプレミスのルートを自動伝播しないため、BGP 伝播だけでは不十分。🚫
D	1 つの VGW は 1 つの VPC にしか関連付けられないため、この方法は非現実的。🚫

AWS ネットワーク設計のベストプラクティスとして、複数の VPC とオンプレミス接続を統合する場合は Transit Gateway を活用するのが最適です！ 🚀

選択肢（和訳）

A. アプリケーションをTLS Wrapperを使用してAmazon SESに接続するように設定する。ses:SendEmail および ses:SendRawEmail の権限を持つIAMロールを作成し、そのロールをAmazon EC2インスタンスにアタッチする。

B. アプリケーションをSTARTTLS を使用してAmazon SESに接続するように設定する。SESのSMTP認証情報を取得し、認証情報を使用してAmazon SESに認証を行う。

C. アプリケーションをSES API を使用してメール送信するように設定する。ses:SendEmail および ses:SendRawEmail の権限を持つIAMロールを作成し、SESのサービスロールとして利用する。

D. アプリケーションをAWS SDK を使用してメール送信するように設定する。SES用のIAMユーザーを作成し、APIアクセスキーを生成する。そのアクセスキーを使用してSESに認証を行う。

回答: ✅ B. アプリケーションをSTARTTLSを使用してAmazon SESに接続し、SESのSMTP認証情報を使用して認証する。

解説:

Amazon SESのSMTP機能の要件

Amazon SESはSMTPインターフェース を提供しているが、ポート25の直接利用は推奨されていない
TLS Wrapper（SMTPS、ポート465）には対応しておらず、STARTTLS（ポート587）を使用する必要がある
SMTPを利用する場合、IAMのSMTPクレデンシャルを取得して認証する 必要がある

選択肢の評価

選択肢	内容	正誤	理由
A	TLS Wrapperを使用し、IAMロールで認証する	❌	SESはTLS Wrapper（ポート465）をサポートしていない
B	STARTTLSを使用し、SESのSMTP認証情報で認証する	✅	SESのSMTP接続方法として正しい
C	SES APIを使用し、IAMロールで認証する	❌	アプリケーションはSMTPしかサポートしていないため、APIは利用できない
D	AWS SDKを使用し、IAMユーザーのAPIキーで認証する	❌	アプリケーションがSMTPしか対応していないため、SDKは使用不可

ポイントまとめ

✅ Amazon SESのSMTPエンドポイントに接続するには、STARTTLSを使用する必要がある
✅ SMTP認証には、IAMユーザーのSES用クレデンシャルを取得し使用する
✅ アプリケーションがSMTPのみサポートしているため、SES APIやAWS SDKは使用できない

最終結論

この問題では、「Amazon SESのSMTPエンドポイントに適切に接続する方法」 を問われています。
したがって、「B. STARTTLSを使用し、SMTP認証情報を取得して認証する」 が正解です。 ✅

選択肢（和訳）

A. AWS Cost and Usage Report（CUR） を組織全体に対して作成する。レポート内でタグとコストカテゴリ を定義する。
Amazon Athena にテーブルを作成し、そのデータを基に Amazon QuickSight のデータセットを作成する。
財務チームとデータセットを共有する。

B. AWS Cost and Usage Report（CUR） を組織全体に対して作成する。レポート内でタグとコストカテゴリ を定義する。
AWS Cost Explorer でカスタムテンプレートを作成し、財務チームがレポートを作成できるようにする。

C. Amazon QuickSight データセットを作成し、AWS Price List Query API から取得したコスト情報を受信する。
データセットを財務チームと共有する。

D. AWS Price List Query API を使用して、アカウントごとの支出情報を収集する。
AWS Cost Explorer でカスタムテンプレートを作成し、財務チームがレポートを作成できるようにする。

回答: ✅ A. AWS Cost and Usage Report（CUR）を使用し、Athena + QuickSight で分析

解説:

1. AWS Cost and Usage Report（CUR）が最適な理由

CUR は AWS Organizations 全体の詳細なコストデータを提供
タグとコストカテゴリを使用して、各企業（アカウント）ごとに意味のあるコストグループを作成可能
Amazon Athena と統合することで、SQLクエリを用いた柔軟なコスト分析が可能
Amazon QuickSight を使うと、財務チームが簡単にダッシュボードやレポートを作成できる

2. 各選択肢の評価

選択肢	方法	正誤	理由
A	CUR + Athena + QuickSight	✅ 正解	詳細なコストデータを扱え、柔軟な分析・可視化が可能
B	CUR + Cost Explorer	❌	Cost Explorer ではカスタムクエリや詳細なデータ分析が難しい
C	Price List Query API + QuickSight	❌	Price List Query API は価格情報を提供するが、利用コストのレポートには適さない
D	Price List Query API + Cost Explorer	❌	Price List Query API は価格情報のみで、利用コストの詳細分析はできない

ポイントまとめ

✅ AWS Cost and Usage Report（CUR）を使うと、組織全体の詳細なコスト情報を取得可能
✅ Amazon Athena を使うと、CUR のデータを柔軟にクエリ可能
✅ Amazon QuickSight を使うと、財務チームが視覚的なレポートを作成できる

最終結論

組織全体のコストレポートを効率的に管理・分析するには、「A. AWS Cost and Usage Report（CUR） + Amazon Athena + QuickSight」 が最適です。 ✅

問題（和訳）

ある企業が AWS上でIoTプラットフォーム を運用しています。

IoT センサーがさまざまな場所 からデータを送信し、それが Amazon EC2 上の Node.js API サーバー（Application Load Balancer 配下） に送られます。
データは Amazon RDS MySQL（4TB General Purpose SSD） に保存されます。

課題:

センサーの増加により API サーバーが過負荷
RDSの書き込みレイテンシが高い
今後もセンサー数が増えるため、スケーラブルでコスト効率の良い解決策が必要

この問題を根本的に解決し、スケーラブルでコスト効率の良いプラットフォームを実現するには？（2つ選択）

選択肢（和訳）

A. MySQL の General Purpose SSD ストレージを 6TB に拡張し、IOPSを向上させる。

B. Amazon RDS MySQL を Amazon Aurora に移行 し、リードレプリカを追加 する。

C. Amazon Kinesis Data Streams + AWS Lambda を活用 して、データの取り込みと処理を最適化 する。

D. AWS X-Ray を使用してアプリケーションの問題を分析・デバッグし、API サーバーの数を増やす。

E. Amazon RDS MySQL を Amazon DynamoDB に移行 し、スケーラビリティを向上させる。

回答: ✅ B（Aurora + リードレプリカ） & ✅ C（Kinesis Data Streams + Lambda）

解説:

1. IoTワークロードの特徴

センサーの増加により、書き込み負荷が増大
RDSの書き込み遅延がボトルネック
APIサーバーがオーバーロード（スケーリングが必要）
将来的なスケール拡張を考慮する必要がある

2. 各選択肢の評価

選択肢	方法	正誤	理由
A	RDS MySQL の SSD ストレージを 6TB に拡張	❌	一時的な IOPS 向上は見込めるが、根本的なスケーリング解決にはならない。データ増加には対応しきれない。
B	Aurora + リードレプリカ	✅	Aurora は RDS MySQL よりスケーラブルで、書き込み性能も向上。リードレプリカで読み込み負荷分散も可能。
C	Kinesis Data Streams + Lambda	✅	センサーのデータ取り込みをバッファリングでき、RDS への負荷を軽減可能。ストリーミング処理のため、リアルタイム性も向上。
D	AWS X-Ray + API サーバー増設	❌	API サーバーの負荷対策にはなるが、データベースの書き込み遅延は解決しない。
E	DynamoDB に移行	❌	NoSQL はスケーラブルだが、既存の MySQL ベースのアプリケーションの移行コストが高い。リレーショナルデータが必要なら適さない。

3. 最適な解決策

✅ B: Amazon Aurora へ移行 + リードレプリカ

RDS MySQL より高性能な Aurora を使用し、スケーラビリティとパフォーマンスを向上
リードレプリカを活用して読み込み負荷を分散
自動スケーリング機能で将来的なデータ増加にも対応可能

✅ C: Amazon Kinesis Data Streams + AWS Lambda

センサーデータを直接 RDS に書き込むのではなく、Kinesis Data Streams でバッファリング
AWS Lambda でデータを処理し、必要に応じてバッチ書き込みすることで DB への負荷を軽減
リアルタイムデータ処理が可能になり、パフォーマンスが向上

最終結論

APIサーバー負荷の根本的な解決: Kinesis Data Streams + Lambda で効率的なデータ処理
データベースのスケーリング: Aurora + リードレプリカで高負荷を処理可能に
将来的なスケールアップにも対応できる、コスト効率の良いアーキテクチャ

ポイントまとめ

✅ Aurora は RDS MySQL よりスケーラブルで、書き込み性能が向上
✅ リードレプリカを追加することで、読み込み負荷を分散できる
✅ Kinesis Data Streams を使うと、IoTデータをバッファリングでき、DBの負荷軽減が可能
✅ Lambda を活用すると、リアルタイム処理ができるため、IoT ワークロードに最適

結論

「B. Amazon Aurora + リードレプリカ」 ✅ 「C. Amazon Kinesis Data Streams + AWS Lambda」 ✅
この 2 つを組み合わせることで、スケーラブルかつコスト効率の良い IoT プラットフォーム を実現できます！ 🚀

問題（和訳）

ある企業が 電子文書管理システム を構築中です。

完全にサーバーレス（AWS 上で稼働）
リージョン: eu-central-1（ヨーロッパ）
構成:
- CloudFront + S3（Web アプリ配信）
- API Gateway（Regionalエンドポイント） → Lambda → Aurora Serverless（メタデータ管理）
- S3 バケット にドキュメントを保存

課題:
企業は成長しており、大手顧客との概念実証（PoC）を完了。
→ ヨーロッパ以外の地域でのレイテンシを改善する必要がある。

選択肢（和訳）

A. S3 Transfer Acceleration を有効化 し、Web アプリが Transfer Acceleration の署名付き URL を使用するようにする。

B. AWS Global Accelerator を作成し、CloudFront ディストリビューションにアタッチする。

C. API Gateway の Regional エンドポイントを Edge-Optimized に変更する。

D. システム全体を世界中の2つのリージョンにデプロイし、Aurora Serverless の Global Database を使用する。

E. Lambda と Aurora Serverless の間に Amazon RDS Proxy を追加する。

回答: ✅ A（S3 Transfer Acceleration） & ✅ C（API Gateway Edge-Optimized）

解説:

ヨーロッパ以外のリージョンのレイテンシ改善には？

S3 へのアップロード遅延の問題
- S3 へのドキュメントアップロード時に、ユーザーが地理的に遠いと遅延が発生
- ✅ 解決策 → 「S3 Transfer Acceleration」
  - 世界中のエッジロケーションを経由 して最適なパスで S3 にアップロード
  - 高速なデータ転送 を実現
API Gateway の遅延の問題
- API Gateway（Regionalエンドポイント） → Lambda の遅延が発生
- ✅ 解決策 → 「API Gateway の Edge-Optimized エンドポイント」
  - CloudFront を活用して API のエッジ最適化
  - グローバルに分散した AWS のエッジロケーション経由で API を高速化

各選択肢の評価

選択肢	方法	正誤	理由
A	S3 Transfer Acceleration を有効化	✅	S3 へのアップロードをエッジロケーション経由で高速化。グローバルなユーザーに有効。
B	Global Accelerator を CloudFront にアタッチ	❌	CloudFront にはすでに最適化されたエッジロケーションがあるため、不要。
C	API Gateway を Edge-Optimized に変更	✅	API を CloudFront のエッジロケーション経由で最適化し、グローバルユーザーの遅延を改善。
D	全リージョンにデプロイ + Aurora Global Database	❌	フルグローバル展開はコストが高く、管理負担が大きい。遅延の改善にはオーバースペック。
E	RDS Proxy を追加	❌	RDS Proxy はDB接続最適化向けであり、グローバルレイテンシの改善には関係ない。

最適な解決策

✅ A: S3 Transfer Acceleration

世界中のエッジロケーション経由で最適な経路でS3にデータ転送
ヨーロッパ以外の地域のユーザーも高速にアップロード可能

✅ C: API Gateway を Edge-Optimized に変更

CloudFrontのエッジロケーションを活用し、APIのレスポンス速度を向上
ヨーロッパ以外のユーザーにも低遅延で API を提供可能

最終結論

S3 のアップロード遅延 → ✅ S3 Transfer Acceleration で改善
API のレスポンス遅延 → ✅ API Gateway Edge-Optimized で解決
コストと運用負担を抑えつつ、グローバルなパフォーマンスを向上

この 2 つを組み合わせれば、ヨーロッパ以外のユーザーもスムーズに電子文書をアップロード & アクセスできる！ 🚀

問題（和訳）

あるアドベンチャー企業が、モバイルアプリに新機能を追加しました。

ユーザーはハイキングやラフティングの写真・動画をアップロード可能
データは Amazon S3 Standard に保存、CloudFront で配信
コスト最適化が必要

分析結果:

ほとんどの写真・動画は30日後にアクセス頻度が低下
ただし、一部のファイルは30日後も頻繁にアクセスされる
ミリ秒レベルの即時アクセスを維持しつつ、最低コストにしたい

選択肢（和訳）

A. S3 Intelligent-Tiering を有効化する。
B. S3 ライフサイクルポリシーを設定し、30日後に S3 Glacier Deep Archive に移行する。
C. Amazon S3 の代わりに Amazon Elastic File System（EFS）を使用し、EC2 にマウントする。
D. S3 オブジェクトに Cache-Control: max-age ヘッダーを設定し、30日後までキャッシュする。

回答: ✅ A. S3 Intelligent-Tiering

解説:

要件分析

コスト削減が必要
30日後にアクセス頻度が減るが、一部は高頻度でアクセスされる
ミリ秒レベルの即時アクセスを維持する必要がある

各ストレージクラスの特徴

ストレージクラス	コスト	アクセス速度	用途
S3 Standard	高い	ミリ秒	頻繁にアクセス
S3 Standard-IA	安い	ミリ秒	低頻度アクセス
S3 Intelligent-Tiering	自動最適化	ミリ秒	アクセスパターンが不明な場合に最適
S3 Glacier	非常に安い	数分〜数時間	長期保存向け
S3 Glacier Deep Archive	最安	12時間以上	ほぼアクセスしないデータ

各選択肢の評価

選択肢	方法	正誤	理由
A	S3 Intelligent-Tiering を有効化	✅	自動的にアクセス頻度に応じて適切なストレージクラスに移行し、コスト最適化を実現。即時アクセスも維持可能。
B	S3 Glacier Deep Archive に移行	❌	Glacier Deep Archive は取り出しに数時間かかるため、即時アクセス要件を満たせない。
C	S3 を EFS に変更	❌	EFS はEC2 にマウントする必要があり、サーバーレスアーキテクチャに適さない。また、コストが高い。
D	Cache-Control: max-age を30日に設定	❌	これはCloudFront のキャッシュを長くするだけで、S3 のストレージコストは削減できない。

最適な解決策

✅ S3 Intelligent-Tiering を使用すると、自動的にコスト最適化ができ、即時アクセスも維持可能！

頻繁にアクセスされるデータ → S3 Standard に維持
アクセス頻度が下がったデータ → S3 Standard-IA に自動移行（コスト削減）
30日後にアクセスが減るパターンに最適
データを取り出す際の追加コストなし

最終結論

🚀 「ミリ秒レベルの即時アクセス + 自動コスト最適化」が必要なら S3 Intelligent-Tiering が最適！

問題（和訳）

背景:

会社は Amazon S3 を使用し、さまざまなストレージクラスにファイルや画像を保存している。
S3のコストが過去1年間で大幅に増加。

要求:

過去12か月のデータ傾向を分析し、適切なストレージクラスを特定する。

選択肢（和訳）

A. AWS Cost and Usage Reports をダウンロードし、AWS Trusted Advisor のコスト削減提案を確認する。
B. S3ストレージクラス分析を使用し、データトレンドを Amazon QuickSight ダッシュボードにインポートして分析する。
C. Amazon S3 Storage Lens を使用し、詳細メトリクスを有効化してストレージトレンドを可視化する。
D. Access Analyzer for S3 を使用し、過去12か月のレポートをダウンロード。CSV を QuickSight にインポートして分析する。

回答: ✅ C. Amazon S3 Storage Lens

解説:

S3のコスト分析ツール

ツール	目的	長期間のストレージ分析	適切なストレージクラスの特定
AWS Cost and Usage Reports	コスト分析全般	❌ （過去のコストは分かるが、オブジェクトのアクセス頻度は分からない）	❌
S3 Storage Class Analysis	オブジェクトのアクセスパターン分析	✅ （最大 18か月の分析が可能）	✅
Amazon S3 Storage Lens	ストレージの詳細分析（推奨）	✅ （最大15か月分のデータ保存、トレンド分析可能）	✅ （詳細なメトリクスで適切なクラスを推奨）
Access Analyzer for S3	S3 のアクセス制御とセキュリティ分析	❌ （セキュリティに特化、ストレージコスト分析には不向き）	❌

各選択肢の評価

選択肢	方法	正誤	理由
A	AWS Cost and Usage Reports + Trusted Advisor	❌	コストは分かるが、S3オブジェクトのアクセス頻度や適切なストレージクラスの判断には不十分。
B	S3 ストレージクラス分析 + QuickSight	❌	最大18か月の分析が可能だが、詳細なコストトレンド分析には向かない。Storage Lens の方がより適切。
C	S3 Storage Lens（推奨）	✅	最大15か月のデータ保存が可能で、詳細メトリクスを取得して適切なストレージクラスを特定できる。
D	Access Analyzer for S3 + QuickSight	❌	Access Analyzer はセキュリティ分析ツールであり、ストレージ最適化には向かない。

なぜ「Amazon S3 Storage Lens」が最適なのか？

✅ S3 Storage Lens の強み

15か月分のデータを保存可能（過去のトレンドを長期間分析）
S3全体のストレージ使用状況を詳細に可視化
アクセス頻度や適切なストレージクラスの推奨が可能
詳細メトリクスを有効化すると、より高度な分析ができる

最終結論

🚀 「S3 Storage Lens を使用し、詳細メトリクスを有効化する」ことで、S3のコストを最適化し、適切なストレージクラスを特定できる！

問題（和訳）

背景:

会社のクラウドインフラは AWS上 にある。
Infrastructure as Code（IaC） を定義する必要がある。
現在は 1つのAWSリージョン でデプロイされている。
今後は複数のリージョンと複数のAWSアカウントに展開する計画。

選択肢（和訳）

A. AWS CloudFormation テンプレートを使用する。IAMポリシーを追加して複数のアカウントを制御し、テンプレートを複数のリージョンにデプロイする。

B. AWS Organizations を使用する。CloudFormation テンプレートを管理アカウントからデプロイし、AWS Control Tower を使用して複数のアカウントに管理する。

C. AWS Organizations と AWS CloudFormation StackSets を使用する。必要な IAM 権限を持つアカウントから CloudFormation テンプレートをデプロイする。

D. AWS CloudFormation のネストされたスタック（Nested Stacks） を使用する。ネストされたスタックを利用してリージョンを変更する。

回答: ✅ C. AWS Organizations と AWS CloudFormation StackSets を使用する

解説:

マルチアカウント・マルチリージョンでの CloudFormation デプロイ

方法	マルチリージョン対応	マルチアカウント対応	管理のしやすさ
CloudFormation 単体	✅（可能だが手動での展開が必要）	❌（個別アカウントで実行が必要）	😕 （複数アカウントの管理が難しい）
CloudFormation StackSets	✅ （自動で複数リージョンにデプロイ可能）	✅ （AWS Organizations と連携すると自動で展開できる）	😊 （一括管理が容易）
AWS Control Tower	✅ （マルチリージョンで利用可能）	✅ （アカウントのガバナンス向け）	😕 （新しいアカウント管理向け、既存インフラの展開には不向き）
ネストされたスタック（Nested Stacks）	❌ （特定リージョンにしか適用できない）	❌ （マルチアカウント適用は難しい）	😖 （スケールが難しい）

各選択肢の評価

選択肢	方法	正誤	理由
A	CloudFormation + IAM ポリシー	❌	CloudFormation 単体では、マルチアカウント環境に自動でデプロイする仕組みがない。IAM だけでは展開を管理できない。
B	AWS Organizations + Control Tower	❌	Control Tower は主に「新規アカウントの管理・セットアップ」向け。既存の IaC 展開には向かない。
C	AWS Organizations + CloudFormation StackSets（推奨）	✅	StackSets を使うことで、「複数のAWSアカウント & 複数リージョン」に一括デプロイが可能。IAM制御も組み込める。
D	CloudFormation のネストスタック	❌	ネストスタックはテンプレートの管理を簡単にするが、マルチアカウント & マルチリージョン展開には向かない。

なぜ「AWS Organizations + CloudFormation StackSets」が最適なのか？

✅ CloudFormation StackSets の強み

複数のAWSアカウントに一括デプロイ可能（Organizations と連携）
複数のリージョンにも一括デプロイ可能（リージョンを指定可能）
IAM 権限の管理が可能（管理アカウントから一括実行）
運用がシンプル（StackSet を作成し、対象アカウントに適用するだけ）

最終結論

🚀 「AWS Organizations + CloudFormation StackSets を使用して、複数のAWSアカウント・リージョンに IaC をデプロイする」ことが最も効率的な解決策！

問題（和訳）

背景:

モノリシックなアプリケーションをAWS上でモダンアーキテクチャにリファクタリング する計画がある。
CI/CDパイプラインのアップグレードが必要。
要求事項:
1. 1時間に何回もリリース可能であること（高頻度リリース）。
2. 素早くロールバックできること。

選択肢（和訳）

A. CI/CDパイプラインで Amazon Machine Images (AMI) を活用 し、アプリケーションと設定を含めた AMI を作成。Amazon EC2 インスタンスを差し替えることでデプロイを行う。

B. AWS Elastic Beanstalk のステージング環境をデプロイターゲット に指定。デプロイ時に ステージング環境と本番環境のURLを入れ替える ことでデプロイを行う。

C. AWS Systems Manager を使用して毎回インフラを再プロビジョニング し、Amazon EC2 の ユーザーデータを更新 して S3 から最新のコードを取得。Amazon Route 53 の 加重ルーティング（weighted routing） を使い、新環境へ徐々にトラフィックを向ける。

D. Auto Scalingイベントの一部としてアプリケーションの更新を実施。新バージョンの AMI を使用してインスタンスを追加し、旧バージョンのインスタンスを段階的に削除 する。

回答: ✅ B. AWS Elastic Beanstalk のステージング環境をデプロイターゲットに指定し、URLを入れ替えてデプロイ

解説:

継続的デプロイ（CI/CD）に求められる要件

要件	詳細
高頻度リリース	1時間に数回デプロイできるようにする。デプロイの自動化が必須。
迅速なロールバック	問題発生時にすぐに前のバージョンに戻せるようにする。
影響範囲の最小化	トラフィックを制御しながら、段階的に新しいバージョンへ移行する。

各選択肢の評価

選択肢	メリット	デメリット	評価
A. AMI を使い EC2 インスタンスを置き換える	一貫性のある環境を提供できる	AMI の作成とデプロイに時間がかかる。ロールバックも遅い。	❌
B. Elastic Beanstalk + ステージング環境切り替え	高頻度リリースと即時ロールバックが可能。環境全体の管理が簡単。	Elastic Beanstalk に依存する。	✅ （推奨）
C. Systems Manager + Route 53 weighted routing	柔軟なデプロイと段階的リリースが可能	インフラの再プロビジョニングは時間がかかる。	❌
D. Auto Scaling + AMI を使ったロールアウト	段階的リリースが可能	AMI 作成やインスタンス切り替えに時間がかかる。	❌

なぜ B が最適なのか？

✅ Elastic Beanstalk の特性

ステージング環境と本番環境を簡単に切り替え可能（URLのスワップ）。
Blue/Green デプロイが可能（新バージョンをステージングでテスト → 問題なければ本番とスワップ）。
ロールバックが高速（問題があれば即座に旧バージョンに戻せる）。

最終結論

🚀 「AWS Elastic Beanstalk のステージング環境を使い、本番環境とURLをスワップする方法」が最も適している！

回答: ✅ B. EC2 の SG に Aurora の SG を宛先とするアウトバウンドルールを追加 + C. Aurora の SG に EC2 の SG を送信元とするインバウンドルールを追加

解説:

セキュリティグループの設定に関する基本ルール

EC2 → Aurora への通信を許可するには、EC2 の SG から Aurora の SG へのアウトバウンドルールが必要。
Aurora が EC2 からの通信を受け取るには、Aurora の SG に EC2 の SG を送信元とするインバウンドルールが必要。
アウトバウンドルールは通常、AWS のデフォルト設定で「すべての通信を許可」となっているため、特別な制限がない限り追加しなくても動作することが多い。
Aurora から EC2 へのレスポンスは、セキュリティグループの「ステートフルな特性」により、明示的にアウトバウンドルールを追加しなくても通信が確立できる。

各選択肢の評価

選択肢	メリット	デメリット	評価
A. EC2 の SG に Aurora の SG を送信元とするインバウンドルールを追加	Aurora → EC2 の通信を許可するが、必要なし（EC2 が DB にアクセスするシナリオでは不要）	不適切なルール設定	❌
B. EC2 の SG に Aurora の SG を宛先とするアウトバウンドルールを追加	EC2 → Aurora への通信を許可するために必要	なし	✅ （必要）
C. Aurora の SG に EC2 の SG を送信元とするインバウンドルールを追加	EC2 → Aurora の通信を受け付けるために必要	なし	✅ （必要）
D. Aurora の SG に EC2 の SG を宛先とするアウトバウンドルールを追加	Aurora → EC2 のレスポンス通信を許可するが、SG のステートフル特性により不要	不要な設定	❌
E. Aurora の SG に EC2 の SG を宛先とするアウトバウンドルールを追加（エフェメラルポート）	Aurora からのレスポンス用だが、SG はステートフルなので不要	不適切なルール設定	❌

なぜ B & C が正解か？

✅ B. EC2 の SG に Aurora の SG を宛先とするアウトバウンドルールを追加
→ EC2 から Aurora に接続するために必要（アプリケーションが DB にクエリを送信できるようにする）。

✅ C. Aurora の SG に EC2 の SG を送信元とするインバウンドルールを追加
→ Aurora が EC2 からのリクエストを受け付けるために必要（デフォルトの Aurora ポートで受信）。

最終結論

🎯 正しい組み合わせは「B & C」
「EC2 の SG に Aurora の SG へのアウトバウンドルールを追加」 + 「Aurora の SG に EC2 の SG へのインバウンドルールを追加」

問題（和訳）

背景:

各事業部（ビジネスユニット）ごとのクラウド請求戦略を変更したい。
現在はクラウドガバナンスチームが全体のコストレポートを各事業部の責任者に共有している。
AWS Organizations を使用し、各事業部ごとに別々の AWS アカウントを管理している。
既存のタグ付け標準（application、environment、owner）がある。
要件:
- 各事業部が 毎月のコストレポート を受け取れるようにする。
- コストが設定した閾値（しきい値）を超えた場合に通知が送信されるようにする。
- 中央管理（管理アカウント）で設定できることが望ましい。
- コスト効率の高い方法で実装する。

選択肢（和訳）

各 AWS アカウントに AWS Budgets を設定 し、アプリケーション、環境、オーナーごとに予算アラートを作成。
Amazon SNS を使って事業部ごとに通知を送信。
各アカウントで Cost Explorer を使って月次レポートを作成。

B. ✅（正解）

AWS Organizations の管理アカウントで AWS Budgets を設定。
アプリケーション、環境、オーナーごとに予算アラートを設定。
Amazon SNS を使って事業部ごとに通知を送信。
Cost Explorer を管理アカウントで使用し、各事業部向けに月次レポートを作成。

各 AWS アカウントに AWS Budgets を設定。
Amazon SNS を使って事業部ごとに通知を送信。
AWS Billing and Cost Management ダッシュボードを各アカウントで利用し、月次レポートを作成。

管理アカウントで AWS Cost and Usage Reports を有効化。
アプリケーション、環境、オーナーごとにレポートを作成。
AWS Lambda を使ってレポートを処理し、通知と月次レポートをメールで送信。

回答: ✅ B. AWS Budgets を管理アカウントで設定し、SNS と Cost Explorer を利用する。

解説:

各オプションの評価

選択肢	メリット	デメリット	評価
A. 各アカウントに AWS Budgets を設定し、Cost Explorer でレポートを作成	- 事業部ごとに詳細な管理が可能 - SNS による通知設定ができる	- 管理が分散し、手間がかかる - 事業部ごとに個別設定が必要	❌ （管理が大変）
B. AWS Organizations の管理アカウントで AWS Budgets を設定し、Cost Explorer を利用	- 一元管理が可能 - Organizations 全体でコスト管理ができる - SNS による通知が可能	- 特になし	✅ （最適解）
C. 各アカウントに AWS Budgets を設定し、Billing and Cost Management ダッシュボードを利用	- 事業部ごとに詳細な管理が可能	- 管理アカウントで一元管理できない - 事業部ごとに個別設定が必要	❌ （分散管理になり非効率）
D. Cost and Usage Reports + Lambda を利用	- カスタマイズ性が高い	- Lambda の開発コストがかかる - AWS Budgets のような組み込み機能を活用しない	❌ （コストがかかり過ぎる）

なぜ B が最適なのか？

✅ AWS Organizations の管理アカウントで AWS Budgets を設定できる → 各アカウントで個別に設定する必要がない。
✅ Amazon SNS を活用して、コスト閾値を超えた際に自動通知ができる。
✅ Cost Explorer を管理アカウントで利用すれば、全体のコストレポートを一元管理しつつ、事業部ごとに詳細なレポートを作成できる。
✅ 追加の開発（Lambda のカスタム処理など）が不要なため、最もコスト効率が良い。

最終結論

🎯 最もコスト効率が良く、管理が容易な解決策は「B: AWS Budgets + Cost Explorer を Organizations の管理アカウントで設定する」

問題（和訳）

背景:

AWS CloudFormation を使ってインフラをデプロイしている。
誤って CloudFormation スタックが削除された場合、Amazon RDS や Amazon EBS のデータが失われる可能性がある。
データの誤削除を防ぎたい。

要件:

✅ RDS や EBS のデータを意図せず削除されないようにする。
✅ CloudFormation で適切に制御できる方法を選択する。

選択肢（和訳）

A. CloudFormation テンプレートに DeletionPolicy 属性を追加し、RDS と EBS リソースを保護する。
B. CloudFormation のスタックポリシーを設定し、RDS と EBS リソースの削除を禁止する。
C. IAM ポリシーを変更し、「aws:cloudformation:stack-name」タグが付いた RDS および EBS の削除を拒否する。
D. AWS Config ルールを使用して、RDS および EBS の削除を防ぐ。

回答: ✅ A. CloudFormation の `DeletionPolicy` 属性を設定する。

解説:

各選択肢の評価

選択肢	メリット	デメリット	評価
A. DeletionPolicy を設定 ✅	- CloudFormation のネイティブ機能で、リソース削除を防止可能 - `DeletionPolicy: Retain` を設定すれば、スタック削除時にもデータが残る	- 既存のテンプレートを更新する必要がある	✅ （最適解）
B. スタックポリシーで削除を禁止	- 特定のリソースを削除不可にできる	- CloudFormation のリソース削除は防げるが、手動削除は防げない	❌ （完全な防止策ではない）
C. IAM ポリシーで削除を拒否	- IAM を使って削除権限を制限できる	- CloudFormation 以外の削除（手動操作）にも影響が出る - 細かい管理が必要になる	❌ （運用負荷が高い）
D. AWS Config ルールを使用	- リソース削除をモニタリングできる	- 削除防止ではなく、違反を通知するだけ	❌ （削除そのものは防げない）

なぜ A が最適なのか？

✅ CloudFormation の組み込み機能 (DeletionPolicy: Retain) を活用することで、RDS や EBS のデータ削除を確実に防げる。
✅ CloudFormation スタックが削除されても、RDS や EBS のデータは残る。
✅ 追加の設定や権限管理（IAM 変更など）を必要とせず、シンプルに運用できる。

実装方法（CloudFormation テンプレート例）

yaml

コピーする編集する

Resources: MyDatabase: Type: AWS::RDS::DBInstance Properties: DBInstanceIdentifier: mydatabase AllocatedStorage: 100 DBInstanceClass: db.t3.micro Engine: mysql DeletionPolicy: Retain # スタック削除時にリソースを保持 MyEBSVolume: Type: AWS::EC2::Volume Properties: Size: 100 AvailabilityZone: us-east-1a DeletionPolicy: Retain # スタック削除時にリソースを保持

🚀 この設定により、CloudFormation スタックが削除されても、RDS や EBS のデータが保持される！

最終結論

🎯 CloudFormation の DeletionPolicy: Retain を使用することで、スタック削除時にも RDS や EBS のデータを保持できるため、「A」が最適な選択肢！

問題のポイント

NAT ゲートウェイの VPC フローログに Action = ACCEPT のエントリがある。
送信元 IP: 198.51.100.2（パブリック IP）
宛先 IP: プライベート EC2 インスタンス
VPC の CIDR の最初の 2 オクテット: 203.0.x.x
目的:
- このトラフィックがインターネットからの「予期しない受信接続」かどうかを特定する。
- 適切な方法で NAT Gateway とプライベートインスタンスのログを分析する。

選択肢の評価

選択肢	使用するサービス	フィルター条件（送信元 / 宛先）	問題点	評価
A	AWS CloudTrail	宛先: `like 203.0.x.x`, 送信元: `like 198.51.100.2`	CloudTrail はネットワークトラフィックのログを取得しない。	❌
B	Amazon CloudWatch	宛先: `like 203.0.x.x`, 送信元: `like 198.51.100.2`	正しいログソース（CloudWatch Logs に保存された VPC フローログ）を使用している。	✅
C	AWS CloudTrail	宛先: `like 198.51.100.2`, 送信元: `like 203.0.x.x`	送信元と宛先が逆。CloudTrail も不適切。	❌
D	Amazon CloudWatch	宛先: `like 198.51.100.2`, 送信元: `like 203.0.x.x`	送信元と宛先が逆。	❌

正解: ✅ B. Amazon CloudWatch を使用し、VPC フローログを分析する

解説

NAT ゲートウェイの VPC フローログは、CloudTrail ではなく、CloudWatch Logs に保存される。
- CloudTrail は AWS API コールを記録するが、ネットワークトラフィックの詳細は含まれない。
- ネットワークトラフィックのログを分析するには、CloudWatch Logs で VPC フローログをクエリする必要がある。
VPC の CIDR（203.0.x.x）に向かう通信があるかどうかを確認する必要がある。
- 送信元: 198.51.100.2（パブリック IP）
- 宛先: 203.0.x.x（VPC の CIDR ブロック内 = プライベート EC2 インスタンス）
- これが NAT 経由の想定外のインバウンドトラフィックかどうかを判定する。
CloudWatch Logs Insights でフィルタリング
- CloudWatch のロググループに保存された VPC フローログを対象に、以下のようなクエリを実行できる:
```
 
```
sql

コピーする編集する

fields @timestamp, @message | filter srcAddr like "198.51.100.2" | filter dstAddr like "203.0" | stats sum(bytes) by srcAddr, dstAddr
- これにより、特定の IP から特定の VPC 内宛先へのトラフィック量を分析できる。

間違った選択肢の詳細

A / C. CloudTrail は不適切
- CloudTrail は AWS API コールのログを取得するが、ネットワークトラフィック（VPC フローログ）は記録しない。
D. 送信元と宛先が逆
- 198.51.100.2（パブリック IP）から 203.0.x.x（プライベート VPC）へのトラフィックを調べる必要があるが、逆の条件になっている。

結論

✅ CloudWatch Logs で VPC フローログをクエリし、198.51.100.2 から 203.0.x.x（VPC 内）の通信を分析できる「B」が正解！

問題のポイント

現在の状況：
- 2つのAWSアカウント（各ビジネスユニットごと）。
- 相互にS3バケットをレプリケーションしている。
- 暗号化が有効になっていない（セキュリティ監査で発覚）。
- S3バケットには 数百万のオブジェクト がある。
要件：
- SSE-S3（Amazon S3管理のキー）によるサーバーサイド暗号化を有効化する。
- 最も運用効率の良い方法を選択する。

選択肢の評価

選択肢	暗号化方式	既存オブジェクトの暗号化方法	問題点	評価
A	SSE-S3	S3 Batch Operations で同じ場所にコピー	✅ 運用負荷が低く、最も効率的な方法	✅ 正解
B	SSE-KMS	S3 CLI `cp` コマンドでコピー	❌ KMSキーを新規作成する必要があり、不要な運用コストが増える	❌
C	SSE-S3	S3 CLI `cp` コマンドでコピー	❌ CLI コマンドは非効率（数百万オブジェクトの処理に時間がかかる）	❌
D	SSE-KMS	S3 Batch Operations で同じ場所にコピー	❌ KMSキーを新規作成する必要があり、不要な運用コストが増える	❌

正解: ✅ A. SSE-S3 を有効化し、S3 Batch Operations で暗号化

理由

SSE-S3 は最もシンプルで運用コストが低い
- S3が管理する暗号化キーを使用するため KMSの管理が不要。
- 追加のIAMポリシーやキーの管理が発生しない。
S3 Batch Operations を使用することで、数百万オブジェクトを効率的に処理
- オブジェクトの移動をせずに、そのまま暗号化できる。
- S3バケット間のコピーではなく 同じバケット内で暗号化を適用する ため、コスト効率も良い。
- S3 CLI cp コマンドを使うよりもはるかに高速かつ効率的。
オペレーションがシンプル
- S3 のオプションで SSE-S3 を有効化。
- S3 Batch Operations でオブジェクトを処理（リストを作成し、同じ場所に上書きコピー）。
- 既存のバケット構造を変更せずに済む。

誤った選択肢の問題点

選択肢	問題点
B. SSE-KMS + S3 CLI `cp`	KMSキーの管理が必要（IAMポリシー設定が増える）+ CLIによるコピーは非効率（数百万オブジェクトには適さない）
C. SSE-S3 + S3 CLI `cp`	CLIによるコピーは非効率（処理が遅く、オペレーション負荷が高い）
D. SSE-KMS + S3 Batch Operations	KMSキーの管理が発生（不要な運用コスト）+ KMSを使う必要がない（要件外）

結論

✅ SSE-S3 を有効化し、S3 Batch Operations でオブジェクトを暗号化する「A」が最も運用効率が高く、正解！

問題のポイント

現在の状況：
- AWS上のアプリケーションが 大量の非構造化データをS3に保存。
- S3 Standard を使用し、データは毎日数GBずつ増加。
- データ量は 数TB に達している。
要件：
- データのクエリと分析を行う必要がある。
- 1年以上前のデータにはアクセスしない。
- コンプライアンスのためデータは無期限で保持する必要がある。
- コストを最小限に抑えたい。

選択肢の評価

選択肢	クエリ方法	データの移行先	メリット	デメリット	評価
A	S3 Select	S3 Glacier Deep Archive	低コストのデータ保存	S3 Selectはオブジェクト単位のフィルタリングのみ可能 → ビッグデータ分析には不向き	❌
B	Redshift Spectrum	S3 Glacier Deep Archive	大規模クエリ対応	Redshift Spectrumのコストが高い	❌
C	Athena	S3 Glacier Deep Archive	低コストかつクエリ可能	なし	✅ 正解
D	Redshift Spectrum	S3 Intelligent-Tiering	一部のデータを頻繁に利用可能	コストが高い（Intelligent-Tieringは長期保存には不向き）	❌

正解: ✅ C. AWS Glue Data Catalog + Amazon Athena + S3 Glacier Deep Archive

理由

Athena は低コストで大規模なS3データを直接クエリ可能
- データを移動せずにS3上で直接クエリできる。
- Redshift Spectrumと比較すると Athenaは料金が安い（スキャンしたデータ量に対する課金）。
- 非構造化データの分析にも適している。
S3 Glacier Deep Archive は最もコスト効率の良い長期保存オプション
- 1年以上アクセスしないデータを最も低コストで保管できる。
- コンプライアンス要件に対応（長期保存が可能）。
- S3 Intelligent-Tiering は 一定のアクセスがあるデータ向けなので、適さない。
AWS Glue Data Catalog を使えば、Athena でスキーマ管理が可能
- データをより扱いやすくするために Glue Data Catalog でメタデータを管理。
- Athenaのパフォーマンス向上につながる。

誤った選択肢の問題点

選択肢	問題点
A. S3 Select + S3 Glacier Deep Archive	S3 Select はオブジェクト単位のフィルタリングしかできず、データ分析には不向き。
B. Redshift Spectrum + S3 Glacier Deep Archive	Redshift Spectrum はコストが高く、Athena の方がコスト効率が良い。
D. Redshift Spectrum + S3 Intelligent-Tiering	Intelligent-Tieringはアクセス頻度が不明なデータ向けであり、1年以上アクセスしないデータには不適切。

結論

✅ 最もコスト効率が高く、クエリ性能も確保できる「C. Athena + Glue Data Catalog + S3 Glacier Deep Archive」が正解！

問題のポイント

現在の状況：
- 600 TBのデータ をオンプレミスのNASに保存。
- MLモデルのためAWSにデータを転送したい。
- 必要な計算リソースはAWSにしかない。
- 3週間以内にデータ転送を完了 する必要がある。
- データは転送中に暗号化する必要がある。
- 会社のインターネット速度は100 Mbps（共用回線）。

各選択肢の評価

選択肢	方法	データ転送速度・時間	コスト	メリット	デメリット	評価
A. AWS Snowball Edge	専用デバイスでオフライン転送	高速（約1週間）	低コスト	インターネット回線不要、帯域制限なし	物理的な取り扱いが必要	✅ 正解
B. AWS Direct Connect (10 Gbps) + VPN	高速専用回線を構築	構築に1か月以上かかる	高コスト	継続的なデータ転送向け	3週間では間に合わない	❌
C. VPN over Internet (100 Mbps)	既存のインターネット回線経由で転送	約556日 (1.5年以上)	低コスト	構築不要	3週間では到底間に合わない	❌
D. AWS Storage Gateway (File Gateway)	継続的なクラウド同期	回線速度に依存（遅い）	中コスト	データ継続転送向け	大量データの一括転送には向かない	❌

計算: インターネット転送の所要時間

インターネット速度 = 100 Mbps
データ量 = 600 TB
1 TB = 8,000 Gbps（bit換算）
所要時間 = (600 × 8,000) ÷ 100 (Mbps) = 48,000時間 ≈ 556日
VPNやStorage Gatewayでは間に合わない！

正解: ✅ A. AWS Snowball Edge

理由

データ転送速度の問題を解決
- インターネット経由では 3週間で600 TB転送は不可能（VPNやStorage Gatewayでは遅すぎる）。
- Snowball Edge は 80 TB/台の転送容量を持ち、複数台を並行利用可能。
- 数台を使えば 1週間程度でデータ転送が完了可能。
低コスト
- Direct Connect (10 Gbps) は 構築に時間と高コストがかかるため不適切。
- Snowball Edge は データ転送量に応じたコストで、専用回線不要。
転送中の暗号化
- Snowball Edge はデフォルトでデータを暗号化（AES-256） して保存・転送。
使い方が簡単
- AWS管理コンソールでデバイスを発注し、データコピー後にAWSへ返送するだけ。
- 返送後、AWSがS3にデータをアップロード。

誤った選択肢の問題点

選択肢	問題点
B. Direct Connect (10 Gbps) + VPN	専用回線のセットアップに1か月以上かかり、3週間以内の要件に間に合わない
C. VPN over Internet (100 Mbps)	転送に約556日かかるため、非現実的
D. AWS Storage Gateway (File Gateway)	一括転送ではなく、継続的なデータ同期向けであり不適切

結論

✅ AWS Snowball Edge を使えば、3週間以内に600 TBを安全かつ高速に転送可能！

問題のポイント

現在のシステム構成
- スキャンしたフォームをS3に保存。
- EC2上のWebアプリがRDS PostgreSQLを利用。
- フォームがアップロードされると、SNS通知を送信。
- 手作業でフォームを処理（データ抽出・入力）。
- 抽出したデータを外部APIへ送信。
要件
1. 手作業を自動化する。
2. 正確なデータ抽出（OCR）。
3. 迅速な市場投入（短期間で導入）。
4. 長期的な運用コストを最小化。

各選択肢の評価

選択肢	OCR 方法	アーキテクチャ	短期間導入	運用コスト	評価
A. カスタムOCRライブラリ + EKS	独自開発	EKS+EC2+DynamoDB	❌ 遅い（開発時間がかかる）	❌ 高い（EKS運用コスト）	❌
B. Step Functions + Lambda + 独自MLモデル	独自トレーニング済みモデル	EC2+Step Functions+Lambda	❌ 遅い（MLモデル開発が必要）	❌ 高い（MLモデル運用）	❌
C. SageMaker AI/MLモデル + EC2	SageMakerトレーニング済みモデル	EC2+SageMaker+ElastiCache	❌ 遅い（モデル開発・訓練が必要）	❌ 高い（SageMaker運用）	❌
D. Textract + Comprehend + Step Functions	Textract + Comprehend（AWS提供）	Step Functions+Lambda+S3	✅ 早い（既存サービス活用）	✅ 低コスト（サーバーレス）	✅ 正解

正解: ✅ D. Textract + Comprehend + Step Functions

理由

OCRをAWS Textractで簡単に実装
- Amazon Textract は 手書き・印刷されたテキストを高精度で抽出 可能。
- MLトレーニング不要で すぐに利用可能。
- 手作業のデータ入力を完全自動化 できる。
データの意味解析をAmazon Comprehendで実施
- Amazon Comprehend は 自然言語処理（NLP） を活用して データの意味を抽出。
- 例えば、請求書や契約書から特定の項目（名前・日付・金額）を自動抽出 可能。
Step Functions + Lambda でサーバーレス処理
- Step Functions によるワークフロー管理:
  - S3へのアップロードをトリガー に処理を開始。
  - Textract → Comprehend → 外部API送信 を順番に実行。
- Lambda を使用し、フルマネージドな運用:
  - EC2やEKSの管理不要で低コスト。
導入が迅速で、運用コストも最小化
- カスタムMLモデルの開発不要（短期間で実装可能）。
- サーバーレスアーキテクチャ（Lambda & Step Functions） により 管理・運用負担が少ない。

誤った選択肢の問題点

選択肢	問題点
A. カスタムOCRライブラリ + EKS	OCRエンジンをゼロから開発するため時間がかかる。EKS運用コストも高い。
B. 独自MLモデル + EC2 + Step Functions	MLモデルを自前で訓練・ホスティングする必要があり、時間とコストがかかる。
C. SageMaker MLモデル + EC2	SageMakerを活用してもMLモデルのトレーニングが必要。EC2運用コストも増加。

結論

✅ AWS Textract + Comprehend + Step Functions を使用したサーバーレスアーキテクチャが、迅速かつ低コストで要件を満たすベストな選択肢！

問題のポイント

既存のオンプレミス構成
- Webフロントエンド → VM群でホスト。
- メッセージキュー → RabbitMQ でフロントエンドとバックエンドを接続。
- バックエンド → Kubernetes クラスター で注文処理を実行。
要件
1. アプリケーションに大きな変更を加えない（リファクタリングのみ）。
2. AWSクラウドへ移行（最小限の運用負担で）。
3. RabbitMQの代替サービスを使用（適切なマネージドサービス）。
4. KubernetesをAWSで運用。

各選択肢の評価

選択肢	Web フロントエンド	メッセージキュー	バックエンド	適合性
A. ✅ EC2 + ALB + Amazon MQ + EKS	EC2 Auto Scaling + ALB	Amazon MQ（RabbitMQ互換）	EKS（フルマネージドK8s）	最適解 ✅
B. ❌ Lambda + API Gateway + Amazon MQ + EKS	Lambdaに書き換え（大幅な変更）	Amazon MQ	EKS（フルマネージドK8s）	アプリの大幅変更が必要 ❌
C. ❌ EC2 + ALB + Amazon MQ + 手動Kubernetes	EC2 Auto Scaling + ALB	Amazon MQ（RabbitMQ互換）	EC2上のKubernetes（手動運用）	運用負担が大きい ❌
D. ❌ EC2 + ALB + SQS + EKS	EC2 Auto Scaling + ALB	SQS（RabbitMQと互換性なし）	EKS（フルマネージドK8s）	メッセージングシステムが変わる ❌

正解: ✅ A. EC2 + ALB + Amazon MQ + EKS

理由

Webフロントエンドの最適な移行
- EC2 Auto Scaling + ALB を使用することで、現在のVM環境を最小限の変更で移行可能。
- 既存のアプリケーションコードを大きく変更せずにクラウド移行できる。
RabbitMQをAmazon MQで置き換え
- Amazon MQ は RabbitMQ と互換性があるため、コードの変更がほぼ不要。
- フルマネージドで運用負担が最小（RabbitMQの手動運用が不要）。
バックエンドの Kubernetes を EKS に移行
- Amazon EKS を使うことで Kubernetes の管理負担を削減。
- 既存のコンテナをほぼそのまま移行可能。
運用負担が最小
- EC2 + ALB → Auto Scaling対応で最適化。
- Amazon MQ → RabbitMQ互換のマネージドサービス。
- EKS → Kubernetes環境をそのまま活用。

誤った選択肢の問題点

選択肢	問題点
B. Lambda + API Gateway + Amazon MQ + EKS	Lambdaに変更すると大規模なリファクタリングが必要（REST API前提の構成になる）。
C. EC2 + ALB + Amazon MQ + 手動Kubernetes	EC2上で手動Kubernetes運用は管理コストが高い（EKSを使うべき）。
D. EC2 + ALB + SQS + EKS	RabbitMQ を SQS に変更するとアプリケーションのコード変更が必要（非互換）。

結論

✅ A. Amazon MQ（RabbitMQ互換）+ EKS（Kubernetes移行）を採用するのが、最小限の変更で済むベストな選択肢！

問題のポイント

AWS WAF を使用して Web アプリケーションのセキュリティを向上させる
正規のトラフィックに影響を与えないようにする
適切な Web ACL（アクセス制御リスト）の設定が必要

各選択肢の評価

選択肢	ルール設定	初期アクション	検証方法	課題
A. ✅ Count → Block	AWS Managed + Custom Rules	初期は Count（ログ取得）	WAFログを分析し、誤検知を減らしてから Block へ移行	最適解 ✅
B. ❌ Rate-Based のみ	Rate-Based ルールのみ	高いしきい値で一時ブロック	しきい値超過で即ブロック	異常検知には向くが、誤検知が多くなる可能性大 ❌
C. ❌ いきなり Block	AWS Managed ルールのみ	最初から Block	CloudWatch メトリクスと WAF ログを確認	誤検知のリスクが高い ❌
D. ❌ Allow → Block	Custom ルールのみ	初期は Allow（全通過）	WAF ログを分析し、誤検知を減らしてから Block へ移行	初期のセキュリティが不十分 ❌

正解: ✅ A. Set the action of the web ACL rules to Count → Block

理由

最初に Count に設定することで、誤検知（false positive）を防ぐ
- いきなり Block すると正規のリクエストが誤ってブロックされるリスクがある。
- 「Count」モードで WAF のログを確認し、誤検知を減らしてから Block に変更するのが安全なアプローチ。
AWS WAF のロギングを有効にして分析
- ログを使ってどのリクエストがブロックされる可能性があるかを把握。
- ルールの調整がしやすくなる。
AWS Managed ルール + カスタムルールの組み合わせ
- AWS Managed ルールを活用することで、一般的な攻撃（SQL Injection、XSS など）を自動で防御。
- 必要に応じて カスタムルール を追加し、より細かい制御が可能。
最終的に Count → Block に移行
- 問題がなければ Block へ移行し、本格的にセキュリティ対策を有効化。

誤った選択肢の問題点

選択肢	問題点
B. Rate-Based ルールのみ	異常検知（DoS対策）には向くが、正規のユーザーがブロックされる可能性がある。
C. 最初から Block	誤検知のリスクが高い。正規のトラフィックを誤ってブロックする可能性がある。
D. Allow → Block	初期のセキュリティが不十分。最初から Allow だと攻撃を防げない。

結論

✅ 「A. Count → Block に段階的に移行するアプローチ」が、セキュリティと正規トラフィックのバランスを最適化できるベストな選択肢！

問題のポイント

AWS Organizations を利用して多数の AWS アカウントを管理
すべての AWS アカウントで共通の IP CIDR 設定を適用
開発者が個別にセキュリティグループを管理している
セキュリティチームが変更を一元管理
最小の運用負荷で管理を効率化する必要がある

選択肢の評価

選択肢	方法	運用負荷	問題点
A. SNS + Lambda で各アカウントに変更を配布	SNS 通知を受信した Lambda が CIDR を各セキュリティグループに追加	各アカウントに Lambda をデプロイする必要があるため運用負荷が高い	複数の Lambda の管理が必要で、運用負担が増加
B. 各アカウントに個別の Prefix List を作成	各アカウントが独自に Prefix List を管理する	各アカウントで手動設定が必要（運用負荷が高い）	各アカウントごとに Prefix List を管理する必要があり、統制が難しい
C. セキュリティチームの AWS アカウントで Prefix List を一元管理	Prefix List を作成し、AWS Resource Access Manager（RAM）で共有	一元管理できるため運用負荷が最も低い	セキュリティグループで Prefix List を参照する設定が必要
D. IAM ロール + Lambda で一括更新	セキュリティアカウントの Lambda が IAM ロールを Assume してセキュリティグループを更新	各アカウントに IAM ロールを作成・管理する手間がある	IAM ロールの権限管理が複雑になり、運用負荷が高い

正解: ✅ C. セキュリティチームの AWS アカウントで Prefix List を一元管理

理由

Prefix List を利用して共通の CIDR を管理できる
- Prefix List は IP CIDR の集合 を定義できる AWS の機能。
- これをセキュリティグループに直接設定すれば、一元管理されたリストを各アカウントのセキュリティグループに適用可能。
AWS Resource Access Manager（RAM）を使用して共有
- AWS RAM を使えば、AWS Organizations 内のすべてのアカウントと Prefix List を共有可能。
- 各アカウントでセキュリティグループのルールに Prefix List を設定すれば、新しい CIDR の追加・削除が一括で適用される。
運用負荷が最も低い
- 一度設定すれば、変更は Prefix List に加えるだけで全アカウントに即反映。
- 各アカウントで個別にセキュリティグループを手動更新する必要がなくなる。

誤った選択肢の問題点

選択肢	問題点
A. SNS + Lambda で各アカウントを更新	各アカウントに Lambda をデプロイし、SNS 経由で変更を適用する必要があり、管理コストが高い。
B. 各アカウントで個別に Prefix List を作成	各アカウントで手動管理が必要であり、共通ルールの統制が取りにくい。
D. IAM ロール + Lambda で一括更新	各アカウントに IAM ロールを作成・管理する手間がかかり、運用負荷が高い。

結論

✅ 「C. セキュリティチームの AWS アカウントで Prefix List を一元管理し、AWS RAM で共有」が最適解！

中央管理が可能で、全アカウントに即時適用できるため、運用負荷が最小限に抑えられる。

問題のポイント

従業員が VPN を使用して在宅勤務する必要がある
複数の AWS アカウントに VPC が存在
現在は Site-to-Site VPN でオンプレミスからアクセス
VPC ピアリングを使用して AWS アカウント間で通信

要件:

スケーラブルな AWS Client VPN ソリューション
社内アプリケーションへのアクセスを許可
最もコスト効率が高い解決策

選択肢の評価

選択肢	方法	メリット	デメリット
A. 各 AWS アカウントに Client VPN エンドポイントを作成	各 AWS アカウントで独自に Client VPN を作成し、アプリケーションへのルーティングを設定	各アカウントで VPN を直接管理できる	コストが高い（アカウントごとに VPN エンドポイントが必要）
B. メイン AWS アカウントに Client VPN を作成し、ルーティング設定を行う	メイン AWS アカウントに Client VPN を 1 つ作成し、VPC ピアリングで他のアカウントの VPC へルーティング	シンプルでコスト効率が高い（VPN エンドポイントは 1 つのみ）	VPC ピアリングはスケーラビリティに制限がある（フルメッシュ構成が必要）
C. メイン AWS アカウントに Client VPN を作成し、AWS Transit Gateway 経由でルーティング	メイン AWS アカウントに Client VPN を作成し、Transit Gateway を使って他の VPC に接続	スケーラブルで将来の拡張が容易	Transit Gateway のコストがかかる
D. メイン AWS アカウントに Client VPN を作成し、AWS Site-to-Site VPN に接続	Client VPN をメイン AWS アカウントに作成し、オンプレミスとの Site-to-Site VPN を経由して接続	オンプレミスからのアクセスと統一できる	二重の VPN 接続になり、レイテンシが増える可能性がある

正解: ✅ B. メイン AWS アカウントに Client VPN を作成し、ルーティング設定を行う

理由

コスト効率が高い
- Client VPN エンドポイントを 1 つだけ作成すれば済むので、コストを抑えられる。
- 各 AWS アカウントごとに VPN エンドポイントを作成する（A）よりも安価。
既存の VPC ピアリングを活用
- すでに VPC ピアリングが設定されているので、そのネットワークを利用すれば追加コストなしでルーティング可能。
設定がシンプル
- メイン AWS アカウントの VPN エンドポイントでルーティングを設定するだけで、他の AWS アカウントの VPC にアクセス可能。

誤った選択肢の問題点

選択肢	問題点
A. 各 AWS アカウントに VPN エンドポイントを作成	コストが高すぎる（アカウントごとに VPN エンドポイントを作成すると、管理とコストが増加）
C. Transit Gateway を使用	スケーラビリティはあるがコストが高い（Transit Gateway は高額なため、小規模環境ではオーバースペック）
D. Site-to-Site VPN 経由で接続	二重 VPN になり、不要な遅延が発生（AWS 内の通信に Site-to-Site VPN を使うのは非効率）

結論

✅ 「B. メイン AWS アカウントに Client VPN を作成し、VPC ピアリングを活用してルーティング」が最もコスト効率が高く、シンプルなソリューション！

問題（和訳）

ある企業がマルチアカウント環境で AWS 上のアプリケーションを運用している。

**営業チーム（Sales）とマーケティングチーム（Marketing）**は、それぞれ別の AWS アカウントを使用。
Sales チームは Amazon S3 バケットにペタバイト級のデータを保存している。
Marketing チームは Amazon QuickSight を使用してデータの可視化を行う。
S3 バケットは AWS KMS キーで暗号化されている。
Marketing チームは既に QuickSight 用の IAM サービスロールを作成済み。
Marketing チームが Sales チームの S3 バケットに安全にアクセスする必要がある。

最も運用負担が少ない（LEAST operational overhead）方法は？

選択肢（和訳）

A. 新しい S3 バケットを Marketing アカウントに作成し、Sales アカウントで S3 レプリケーションルールを設定して、新しいバケットにオブジェクトをコピーする。Marketing アカウントの QuickSight のアクセス許可を更新する。

B. **SCP（サービスコントロールポリシー）**を作成し、Marketing アカウントに S3 バケットのアクセスを許可する。AWS Resource Access Manager（AWS RAM） を使用して、Sales アカウントの KMS キーを Marketing アカウントと共有する。Marketing アカウントの QuickSight アクセス許可を更新する。

C. Marketing アカウントの S3 バケットポリシーを更新し、QuickSight ロールにアクセスを許可する。S3 バケットの暗号化に使用される KMS キーに対して KMS グラント（Grant） を作成し、QuickSight ロールに復号権限を付与する。QuickSight アクセス許可を更新する。

D. Sales アカウントに IAM ロールを作成し、S3 バケットへのアクセスを許可する。Marketing アカウントから、その IAM ロールを Assume Role（ロールの引き受け）して S3 バケットにアクセスする。Marketing アカウントの QuickSight ロールを更新し、新しい IAM ロールとの信頼関係を作成する。

正解: ✅ D. Sales アカウントに IAM ロールを作成し、Marketing アカウントが Assume Role する方法

解説

🔹 問題のポイント

QuickSight（Marketing アカウント）から Sales アカウントの S3 データにアクセスする必要がある
S3 バケットは AWS KMS で暗号化されている → KMS キーの共有も必要
運用負担を最小限に抑える → シンプルでスケーラブルな解決策が求められる

🔹 各選択肢の評価

選択肢	メリット	デメリット
A. S3 レプリケーションを使用	✔️ 明示的なアクセス設定不要 ✔️ データのコピーを保持できる	❌ データを二重に保存するためコストが高い ❌ データ同期の遅延が発生する可能性がある ❌ Marketing アカウントがバケットを管理する必要がある
B. SCP + AWS RAM を使用	✔️ 組織全体でのアクセス管理が可能	❌ SCP は「アクセス制限」には使えるが、「アクセス許可」には使えない ❌ AWS RAM で KMS キー共有はできるが、QuickSight のアクセス制御が複雑になる
C. S3 バケットポリシー + KMS Grant を使用	✔️ S3 のポリシーでアクセス制御が可能 ✔️ KMS Grant で暗号化データへのアクセスを制御できる	❌ Marketing アカウントの QuickSight ロールと S3 の関係を個別に設定する必要がある ❌ IAM のアクセス管理よりも柔軟性が低い
D. Assume Role（✅正解）	✔️ 最もセキュアなベストプラクティス ✔️ IAM ロールを使うことでアクセス管理がシンプルになる ✔️ KMS キーのアクセスもロール経由で制御できる	なし（AWS の標準的な方法で、運用負担が最も低い）

🔹 なぜ D（IAM ロール + AssumeRole）が最適なのか？

IAM ロールを使うことで、Marketing アカウントから S3 への安全なクロスアカウントアクセスが可能
- Sales アカウントに IAM ロール（例: SalesS3AccessRole）を作成し、S3 バケットへのアクセスを許可する
- Marketing アカウントの QuickSight は Assume Role（ロール引き受け） を使って Sales アカウントの S3 バケットにアクセスできる
KMS の暗号化を考慮
- IAM ロールに KMS の復号（Decrypt）権限 を付与することで、QuickSight が S3 のデータを正しく処理できる
最も運用負担が少ない
- データのコピー不要（Aのデメリット回避）
- SCP ではアクセス許可を与えられないため不要（Bのデメリット回避）
- S3 バケットポリシーや KMS Grant を細かく管理しなくて済む（Cのデメリット回避）
- IAM ロールの設定だけで完了するため、管理がシンプルでスケーラブル

結論

✅ 「Sales アカウントに IAM ロールを作成し、Marketing アカウントが Assume Role して S3 にアクセスする」方法が最適！

クロスアカウントアクセスのベストプラクティス
運用負担が最小限
セキュアでスケーラブル
KMS 暗号化の考慮も可能

問題（和訳）

企業がオンプレミスの Microsoft SQL Server Always On クラスターを AWS のマネージドデータベースサービス に移行する計画を立てている。

ヘテロジニアス（異種間）データベース移行 を設計する必要がある。
移行先は Amazon RDS for MySQL（SQL Server → MySQL への移行）

この要件を満たすソリューションは？

選択肢（和訳）

A. バックアップとリストアを使用して SQL Server データベースを Amazon RDS for MySQL に移行する。

B. AWS Snowball Edge Storage Optimized を使用してデータを Amazon S3 に転送 し、Amazon RDS for MySQL をセットアップする。SQL Server の BULK INSERT 機能を活用する。

C. AWS Schema Conversion Tool（AWS SCT） を使用してデータベーススキーマを Amazon RDS for MySQL に変換する。その後、AWS Database Migration Service（AWS DMS） を使用してオンプレミスのデータを Amazon RDS に移行する。

D. AWS DataSync を使用してオンプレミスストレージと Amazon S3 の間でデータを移行する。Amazon RDS for MySQL をセットアップし、SQL Server の BULK INSERT 機能を活用する。

正解: ✅ C. AWS Schema Conversion Tool（SCT）+ AWS Database Migration Service（DMS）を使用する方法

解説

🔹 問題のポイント

SQL Server（Windows環境）から MySQL（Linux環境）への移行 → "異種間（Heterogeneous）移行"
AWS マネージドデータベース（Amazon RDS for MySQL）に移行
スキーマ変換が必要（SQL Server と MySQL は構造が異なる）
データをオンラインまたはバッチで安全に移行する必要がある

🔹 各選択肢の評価

選択肢	メリット	デメリット
A. バックアップとリストア	❌ 異種間移行では使えない（SQL Server → MySQL には適用不可）	バックアップ・リストアは「同種（Homogeneous）」移行向け
B. Snowball Edge + BULK INSERT	✔️ オフライン移行で大量データ転送に対応可能	❌ スキーマ変換に対応していないため、手動で MySQL 用のスキーマを作成する必要がある
C. SCT + DMS（✅正解）	✔️ スキーマ変換（SQL Server → MySQL）を自動化できる ✔️ DMS でオンライン移行・継続的レプリケーションが可能 ✔️ AWS 推奨の異種間移行パターン	なし（AWS のベストプラクティス）
D. DataSync + BULK INSERT	✔️ データ転送は可能	❌ スキーマ変換に対応していないため手動で変換が必要 ❌ DataSync は「ストレージ間のファイル転送向け」で、DB 移行には不向き

🔹 なぜ C（AWS SCT + DMS）が最適なのか？

AWS Schema Conversion Tool（SCT）を使用すると、自動で SQL Server のスキーマを MySQL 互換に変換できる
- SQL Server の データ型・ストアドプロシージャ・トリガー などを MySQL 用に変換
- 手動でのスキーマ修正の工数を大幅に削減
AWS Database Migration Service（DMS）を使用すると、SQL Server から MySQL にデータを移行できる
- 継続的レプリケーション に対応（ダウンタイム最小化）
- 異種間（Heterogeneous）移行 に適している
- インデックス・パーティションなども適切に移行
AWS のベストプラクティスとして推奨されている
- 公式ドキュメント でも SQL Server → MySQL の移行には SCT + DMS が推奨
- 実績のある AWS サービスを活用できるため、運用負担が最小限

結論

✅ 「AWS Schema Conversion Tool（SCT）+ AWS Database Migration Service（DMS）」を使用する方法が最適！

スキーマ変換を自動化できる
異種間（Heterogeneous）データベース移行に対応
オンライン移行・継続的レプリケーションが可能
AWS 推奨の移行方法

問題（和訳）

企業が AWS Elastic Beanstalk と Java を使ってパイロットアプリケーションを開発した。

開発中のコスト削減のため、単一インスタンス環境でデプロイ
CPU 使用率が 85% を超えることが頻繁に発生し、パフォーマンス問題が発生している
本番環境に移行する前に、これらのパフォーマンス問題を解決する必要がある

最小の運用負担でこの要件を満たす解決策はどれか？

選択肢（和訳）

✅ A. 新しい Elastic Beanstalk アプリケーションを作成する。ロードバランサー付きの環境を選択し、全ての AZ（アベイラビリティゾーン）にデプロイする。CPU 使用率が 85% を超えたらスケールアウトするように設定する。
❌ B. 2つ目の Elastic Beanstalk 環境を作成し、トラフィック分割ポリシーを適用する。CPU 使用率が 85% を超えたら、新しい環境に一定のトラフィックを送るように設定する。
✅ C. 既存の Elastic Beanstalk 環境の「キャパシティ設定」を変更し、ロードバランサー付きの環境を使用する。全ての AZ にデプロイし、CPU 使用率が 85% を超えたらスケールアウトするように設定する。
❌ D. 「環境の再構築」アクションを実行し、ロードバランシングオプションを選択する。1つの AZ にデプロイし、CPU 使用率が 85% を超えたらスケールアウトするように設定する。

正解: ✅ A, ✅ C

解説

🔹 何を解決する必要があるのか？

現在の Elastic Beanstalk 環境は単一インスタンスなので負荷が高い
本番環境向けにスケーラブルなアーキテクチャに変更する
運用負担を増やさず、自動的にスケールアウトできる仕組みを導入する

🔹 各選択肢の評価

選択肢	説明	採用 / 不採用
A. 新しい Elastic Beanstalk 環境を作成し、ロードバランサー付きでスケールアウト	スケーラブルな構成に移行するための正しいアプローチ	✅ 必要
B. 2つ目の Elastic Beanstalk 環境を作成し、トラフィック分割ポリシーを適用	本番環境の Canary デプロイには有効だが、単純なスケールアウトには不要	❌ 不要
C. 既存環境の設定を変更し、ロードバランサー付き環境にする	現在の環境を変更するだけで済み、最小の運用負担で済むため有効	✅ 必要
D. 環境の再構築（Rebuild）を実行し、単一 AZ でロードバランシングを適用	「Rebuild」では環境が初期化されるため、データ損失のリスクがある。また、単一 AZ では冗長性が低い	❌ 不要

🔹 正解のアプローチ

✅ 方法 1: A (新しい Elastic Beanstalk 環境を作成)

新しい環境を作成（本番環境向け）
ロードバランサー（ALB）を適用
全ての AZ にデプロイし、可用性を向上
スケールアウトルールを設定（CPU 85% 超でスケールアウト）

✅ 方法 2: C (既存の環境を修正)

現在の環境をそのまま利用
ロードバランサー付き環境に変更
全ての AZ にデプロイ
スケールアウトルールを設定（CPU 85% 超でスケールアウト）

結論

✅ 正解は A, C

A: 新しい環境を作成して本番向けに構築
C: 既存環境の設定を変更してスケールアウト
どちらも Elastic Beanstalk のロードバランシング機能を活用し、最小の運用負担でスケーラブルにする最適な解決策

問題（和訳）

ある金融会社が、最新世代の Linux EC2 インスタンス で ビジネスクリティカルなアプリケーション を運用している。

MySQL データベースは自己管理（Self-Managed）であり、I/O 負荷が高い
通常のトラフィックには対応できているが、月末の3日間はレポート処理の影響でアプリケーションが遅くなる
Elastic Load Balancer（ELB）と Auto Scaling は導入済み

このデータベースが月末の負荷を最小限のパフォーマンス影響で処理できるようにするための最適な対応策はどれか？

選択肢（和訳）

✅ A. Elastic Load Balancer のプリウォーミングを実施し、より大きなインスタンスタイプに変更する。また、すべての Amazon EBS ボリュームを GP2 に変更する。
✅ B. データベースを一度 Amazon RDS に移行し、月末の負荷に対応するために複数のリードレプリカを作成する。
✅ C. Amazon CloudWatch と AWS Lambda を使用して、特定の CloudWatch メトリクスに基づき、Amazon EBS ボリュームの種類、サイズ、または IOPS を変更する。
✅ D. すべての既存の Amazon EBS ボリュームを、新しい PIOPS（プロビジョンド IOPS）ボリュームに変更する。月末の負荷増加前にスナップショットを取得し、負荷増加後に元に戻す。

回答 & 解説

✅ 正解: B

🔹 選択肢の評価

選択肢	説明	採用 / 不採用
A. ELB プリウォーミングとインスタンスタイプ変更 & EBS を GP2 に変更	ELB のプリウォーミングはアプリのスケール対応には有効だが、DB の I/O 負荷とは無関係。また、GP2 はピーク負荷に耐えられない可能性がある。	❌ 不採用
B. RDS に移行し、リードレプリカを作成	最適なスケーラビリティと管理性を提供。RDS は負荷増加時にリードレプリカを簡単に追加できるため、月末の負荷増加にも対応しやすい。	✅ 採用
C. CloudWatch & Lambda を使って EBS 設定を変更	動的なスケーリングには向くが、EBS の IOPS 変更には制限があり、即時対応は難しい。	❌ 不採用
D. PIOPS EBS に変更し、スナップショットを取得して負荷後に元に戻す	PIOPS は I/O 負荷の解決には有効だが、コストが高く、運用負担が増加する。また、毎月の切り替えは現実的でない。	❌ 不採用

🔹 正解のアプローチ（B: RDS への移行 & リードレプリカ）

Amazon RDS に移行（自己管理不要でパフォーマンス管理が容易）
リードレプリカを追加（月末の負荷増加時のみスケールアウトが可能）
オートスケーリングによる負荷分散（Auto Scaling + RDS で最適なパフォーマンスを維持）
負荷の軽減と高可用性を確保

🔹 結論

✅ B が最も効果的な解決策

最小の運用負担で、パフォーマンスを向上
月末の負荷増加に対応可能
スケーラブルなリードレプリカを活用できる
RDS の管理機能を活用することで、最適なパフォーマンスを維持できる

問題（和訳）

ある企業が、複雑な依存関係を持つ Java アプリケーション を オンプレミスの仮想マシン（VM） で運用している。

アプリケーションは安定稼働している
技術スタックのモダナイズを目指している
AWS に移行したい
サーバーの管理負担を最小限にしたい
コードの変更を最小限に抑えたい

最小のコード変更で、管理負担を減らしつつ AWS へ移行する最適なソリューションはどれか？

選択肢（和訳）

✅ A. AWS App2Container を使用してアプリケーションを Amazon ECS（AWS Fargate）に移行する。

コンテナイメージは Amazon Elastic Container Registry（ECR）に保存する。
ECS タスク実行ロールに ECR のアクセス権限を付与する。
Amazon ECS で Application Load Balancer（ALB）を使用し、アプリケーションとやり取りする。

✅ B. アプリケーションコードを AWS Lambda で実行可能なコンテナに移行する。

Amazon API Gateway（REST API）を構築し、Lambda と統合する。
API Gateway を介してアプリケーションとやり取りする。

✅ C. AWS App2Container を使用してアプリケーションを Amazon EKS（EKS マネージドノード）に移行する。

コンテナイメージを Amazon ECR に保存する。
EKS ノードに ECR のアクセス権限を付与する。
Amazon API Gateway を使用してアプリケーションとやり取りする。

✅ D. アプリケーションコードを AWS Lambda で実行可能なコンテナに移行する。

Lambda を ALB に統合し、ALB 経由でアプリケーションとやり取りする。

回答 & 解説

✅ 正解: A

🔹 選択肢の評価

選択肢	説明	採用 / 不採用
A. ECS（Fargate）+ App2Container + ALB	App2Container を使うことで、最小限のコード変更でコンテナ化が可能。Fargate を使うことでサーバー管理も不要になる。ALB でスムーズにルーティングできる。	✅ 採用
B. Lambda + API Gateway	Lambda はサーバーレスで管理負担は少ないが、アプリの複雑な依存関係や Java の長時間実行に不向き。アプリを Lambda に適応させるにはコード変更が多くなる。	❌ 不採用
C. EKS（マネージドノード）+ App2Container + API Gateway	EKS は Kubernetes の管理が必要で、ECS（Fargate）より運用負担が大きい。コード変更は少ないが、管理コストを最小限にする要件に合わない。	❌ 不採用
D. Lambda + ALB	Lambda での実行にはアプリのリファクタリングが必要で、サーバーレスのメリットを活かしづらい。ALB との統合は可能だが、適切なスケール調整が難しい。	❌ 不採用

🔹 正解のアプローチ（A: App2Container + ECS Fargate）

App2Container を利用 → 最小限のコード変更でコンテナ化
ECS（Fargate）にデプロイ → EC2 や Kubernetes の管理不要
ECR にコンテナイメージを保存 → セキュアに管理可能
ALB で負荷分散とトラフィック管理 → 既存のアプリ設計に影響を与えず移行可能

🔹 結論

✅ A が最適な選択肢

最小のコード変更で AWS に移行可能
ECS（Fargate）を利用することでサーバーレス化が可能（管理負担を軽減）
ALB による負荷分散でアプリの安定稼働を維持できる
App2Container を活用することで、移行作業を効率化できる

問題（和訳）

ある企業が 非同期 HTTP アプリケーション を AWS Lambda でホストしている。

Amazon API Gateway の公開エンドポイント が Lambda 関数を呼び出す。
現在のデプロイ場所は us-east-1。
別の AWS リージョンにフェイルオーバーを実装したい。

フェイルオーバーをサポートするための最適なソリューションはどれか？

選択肢（和訳）

✅ A. us-west-2 に API Gateway エンドポイントを作成し、トラフィックを us-east-1 の Lambda 関数に転送する。

Amazon Route 53 にフェイルオーバールーティングポリシーを設定し、2つの API Gateway エンドポイントを利用する。

✅ B. Amazon Simple Queue Service（SQS）キューを作成し、API Gateway から Lambda へのトラフィックを SQS に送る。

Lambda は SQS からメッセージを取得し、非同期処理を行う。

✅ C. us-west-2 にも Lambda 関数をデプロイし、API Gateway エンドポイントを作成する。

AWS Global Accelerator と Application Load Balancer（ALB）を利用して、両方の API Gateway エンドポイントにトラフィックを分散させる。

✅ D. us-west-2 に Lambda 関数と API Gateway エンドポイントをデプロイする。

Amazon Route 53 のフェイルオーバールーティングポリシーを使用し、2つの API Gateway エンドポイントをルーティングする。

回答 & 解説

✅ 正解: D

🔹 選択肢の評価

選択肢	説明	採用 / 不採用
A. us-west-2 に API Gateway を作成し、us-east-1 の Lambda を呼び出す	us-west-2 で API Gateway を作成しても、Lambda が us-east-1 にしかないため、フェイルオーバーにならない。us-east-1 で障害が発生した場合、API Gateway から Lambda を呼び出せず、アプリが停止する。	❌ 不採用
B. SQS を使い、API Gateway → SQS → Lambda の構成にする	SQS を使用すると非同期処理の耐障害性は向上するが、別リージョンの Lambda へフェイルオーバーする仕組みにはならない。本来の要件である「リージョン間のフェイルオーバー」を実現できない。	❌ 不採用
C. AWS Global Accelerator + ALB を使用	Global Accelerator はレイテンシーを最適化できるが、フェイルオーバーの主要要件である「Route 53 による DNS フェイルオーバー」を考慮していない。ALB は API Gateway を直接ターゲットにできず、設計が複雑になる。	❌ 不採用
D. us-west-2 に Lambda と API Gateway をデプロイし、Route 53 でフェイルオーバー	Route 53 のフェイルオーバールーティングを使用して、リージョンごとに API Gateway を切り替えられるため、最適なフェイルオーバー構成になる。	✅ 採用

🔹 正解のアプローチ（D: Lambda + API Gateway + Route 53 フェイルオーバー）

us-west-2 に Lambda と API Gateway をデプロイ
- us-east-1 の Lambda を us-west-2 にデプロイ（同じコード）
- API Gateway も us-west-2 にデプロイ
Route 53 のフェイルオーバールーティングポリシーを設定
- プライマリエンドポイント: us-east-1 の API Gateway
- セカンダリエンドポイント: us-west-2 の API Gateway
- ヘルスチェックを設定し、us-east-1 がダウンした場合は us-west-2 にフェイルオーバー

🔹 結論

✅ D が最適な選択肢

Lambda & API Gateway を両リージョンにデプロイ → 障害時に切り替え可能
Route 53 のフェイルオーバールーティング → 自動的に健康なリージョンにルーティング
構成がシンプルで、管理の手間が少ない

🔥 この方法なら、AWS のリージョン障害時にも API は継続動作できる！

問題（和訳）

小売企業が AWS Organizations を使用 して AWS アカウントを管理している。

部門ごとに OU（組織単位）を設定（Finance, Sales, HR, Marketing, Operations）。
各 OU の下に複数の AWS アカウント（開発, テスト, 本番など）
HR 部門は 3 か月後に新システムをリリース予定で、本番アカウントで RIs（リザーブドインスタンス）を購入。
他の部門が RI 割引を利用できないようにしたい。

この要件を満たす適切なソリューションは？

選択肢（和訳）

✅ A. HR 部門の本番アカウントの AWS Billing and Cost Management コンソールで RI 共有をオフにする。

✅ B. HR 部門の本番 AWS アカウントを Organizations から削除し、統合請求の設定のみに追加する。

✅ C. Organizations の管理アカウントを使用し、HR 部門の本番 AWS アカウントの RI 共有をオフにする。

✅ D. Organizations で SCP（サービスコントロールポリシー）を作成し、他部門の OU に適用して RI へのアクセスを制限する。

回答 & 解説

✅ 正解: C

🔹 選択肢の評価

選択肢	説明	採用 / 不採用
A. HR 部門の本番アカウントで RI 共有をオフにする	RI 共有の設定変更は Organizations の管理アカウントでのみ可能。HR 部門の本番アカウント単体では設定できない。	❌ 不採用
B. HR 部門の本番アカウントを Organizations から削除する	Organizations から外すと統合請求のメリット（コスト最適化、請求の一元管理）が失われるため、非効率的。	❌ 不採用
C. Organizations の管理アカウントで RI 共有をオフにする	RI 共有の設定は Organizations の管理アカウントで制御できる。適切な設定変更が可能。	✅ 採用
D. SCP で RI へのアクセスを制限する	SCP は AWS 請求の設定を制御できないため、RI 共有の制御には適用できない。	❌ 不採用

🔹 正解のアプローチ（C: Organizations の管理アカウントで RI 共有をオフにする）

AWS Organizations の管理アカウントにログインする
[Billing and Cost Management] → [Billing preferences] を開く
HR 部門の本番アカウントに対して RI 共有を無効化する
- デフォルトでは RI は Organizations 内のすべてのアカウントで共有されるが、特定のアカウントのみオフにできる。

🔹 結論

✅ C が最適な選択肢

AWS Organizations の管理アカウントを使用することで、RI 共有を正しく制御可能
他部門のアカウントが RI 割引を利用することを防ぐ設定が可能
Organizations からアカウントを削除する必要がなく、統合請求のメリットを維持できる

🔥 最もシンプルかつ AWS のベストプラクティスに従った方法！

問題（和訳）

大企業が 人気のある Web アプリケーションを AWS 上で運用 している。

EC2 Linux インスタンスが Auto Scaling Group（ASG）によって管理
プライベートサブネット内で実行され、Application Load Balancer（ALB）が対象に設定されている
AWS Systems Manager Session Manager を設定済みで、すべての EC2 インスタンスに SSM Agent がインストール済み
新バージョンのアプリをリリースしたが、一部の EC2 インスタンスが Unhealthy 判定を受け、終了される
その結果、アプリの稼働能力が低下

🔍 問題点:

CloudWatch ログを分析したが、明確な原因が特定できない。
EC2 インスタンスを手動で調査する必要がある。

👉 どの方法で Unhealthy な EC2 インスタンスにアクセスしてトラブルシューティングを行うべきか？

選択肢（和訳）

✅ A. Auto Scaling グループの HealthCheck スケーリングプロセスを一時停止する。Session Manager を使用して、Unhealthy とマークされたインスタンスにログインする。

✅ B. EC2 インスタンスの終了保護を有効にする。Session Manager を使用して、Unhealthy とマークされたインスタンスにログインする。

✅ C. Auto Scaling グループの終了ポリシーを「OldestInstance」に設定する。Session Manager を使用して、Unhealthy とマークされたインスタンスにログインする。

✅ D. Auto Scaling グループの「Terminate」プロセスを一時停止する。Session Manager を使用して、Unhealthy とマークされたインスタンスにログインする。

回答 & 解説

✅ 正解: D. Suspend the Auto Scaling group’s Terminate process. Use Session Manager to log in to an instance that is marked as unhealthy.

🔹 選択肢の評価

選択肢	説明	採用 / 不採用
A. HealthCheck プロセスを停止する	HealthCheck は Unhealthy の判断に影響を与えるが、インスタンスの終了を防ぐものではない。したがって、Unhealthy 状態のインスタンスは終了される可能性があり、ログインして調査できない。	❌ 不採用
B. インスタンスの終了保護を有効にする	すでに Unhealthy とマークされたインスタンスに対しては機能しない（事前に設定が必要）。また、終了保護はスケールイン時にのみ影響するため、HealthCheck による終了は防げない。	❌ 不採用
C. 終了ポリシーを OldestInstance に変更	これはスケールイン時に最も古いインスタンスを削除する設定であり、Unhealthy なインスタンスの終了を防ぐものではない。	❌ 不採用
D. Terminate プロセスを停止する	Auto Scaling による EC2 インスタンスの削除を防ぎ、Session Manager でログインしてトラブルシューティングが可能。 Unhealthy な原因を調査する最適な方法。	✅ 採用

🔹 正解のアプローチ（D: Auto Scaling の Terminate プロセスを一時停止）

Auto Scaling グループの "Terminate" プロセスを一時停止
- これにより、Unhealthy なインスタンスが削除されず、調査できる。
- AWS CLI を使用する場合:
```
 
```
  sh
  
  コピーする編集する
  
  aws autoscaling suspend-processes --auto-scaling-group-name <YOUR_ASG_NAME> --scaling-processes Terminate
Session Manager で Unhealthy なインスタンスにログイン
- AWS Systems Manager → Session Manager から対象のインスタンスにログイン。
トラブルシューティング
- CloudWatch ログの詳細確認
- アプリケーションログの確認（例: /var/log/）
- リソース使用状況の確認（CPU, メモリ, ディスク）
- ネットワーク接続の確認（ALB, VPC 設定）
原因が特定できたら Terminate プロセスを再開
- 修正後、Auto Scaling の Terminate プロセスを再開:
```
 
```
  sh
  
  コピーする編集する
  
  aws autoscaling resume-processes --auto-scaling-group-name <YOUR_ASG_NAME> --scaling-processes Terminate

🔹 結論

✅ D が最適な選択肢

Unhealthy なインスタンスの終了を防ぎ、調査できるようにする
Session Manager でインスタンスにアクセス可能
Auto Scaling の設定を変更する必要がなく、最小限の操作で済む

🔥 AWS のトラブルシューティングのベストプラクティスに従った、最も実用的なアプローチ！

問題（和訳）

ある企業が AWS WAF のルール管理を複数の AWS アカウントで統一的に管理 したい。

✅ 要件:

複数の AWS アカウントで AWS WAF ルールを管理する
AWS Organizations の異なる OU（組織単位）にまたがる管理が必要
管理者がアカウントや OU を自由に追加・削除できる
非準拠の AWS WAF ルールを自動的に更新・修正する機能が必要
運用負荷を最小限に抑えることが求められる

👉 どのソリューションが、最小限の運用負荷で要件を満たすか？

選択肢（和訳）

✅ A. AWS Firewall Manager を使用して AWS WAF ルールを統一管理する。

AWS Systems Manager Parameter Store に対象のアカウント番号や OU を保存。
変更があると Amazon EventBridge が検出し、AWS Lambda が AWS Firewall Manager のセキュリティポリシーを更新。

✅ B. AWS Config ルールを使い、OU 内のすべてのリソースが WAF ルールを適用するよう強制する。

非準拠リソースを AWS Lambda で自動修正。
AWS CloudFormation StackSet で WAF ルールを適用。

✅ C. 管理アカウントで AWS WAF ルールを作成。

管理するアカウント番号と OU を AWS Lambda の環境変数に保存。
各メンバーアカウントにクロスアカウント IAM ロールを作成し、AWS STS を使用して WAF ルールを更新。

✅ D. AWS Control Tower を使って AWS WAF ルールを管理。

AWS KMS にアカウント番号や OU を保存。
各メンバーアカウントに IAM ユーザーを作成し、AWS Control Tower がアクセスキーを使って WAF ルールを更新。

回答 & 解説

✅ 正解: A. AWS Firewall Manager を使用して AWS WAF ルールを統一管理する。

🔹 選択肢の評価

選択肢	説明	採用 / 不採用
A. AWS Firewall Manager + Parameter Store + EventBridge	AWS Firewall Manager は AWS Organizations の全アカウントに WAF ルールを一元適用できる。 Parameter Store にアカウント情報を保存し、EventBridge + Lambda で動的更新が可能。運用負荷が最小限。	✅ 採用（最適）
B. AWS Config + Lambda + CloudFormation	AWS Config でコンプライアンス監視が可能だが、リアルタイムのポリシー更新が難しく、CloudFormation での展開も手間。 AWS Firewall Manager に比べると運用負荷が高い。	❌ 不採用
C. Lambda + STS + IAM Roles	クロスアカウント IAM ロールの管理が煩雑で、管理アカウントで全アカウントの WAF ルールを更新するためのカスタムロジックが必要。 AWS Firewall Manager を使えばより簡単に管理できる。	❌ 不採用
D. AWS Control Tower + KMS + IAM Users	AWS Control Tower は WAF の直接管理に向いていない。 IAM ユーザーを手動で作成し、アクセスキーを管理するのは運用負荷が高い。	❌ 不採用

🔹 AWS Firewall Manager を使う理由

✅ AWS Firewall Manager は AWS Organizations に統合されており、組織全体の WAF ルールを一元管理できる。
✅ アカウントの追加・削除時も、自動で適用範囲を更新できる。
✅ EventBridge + Lambda を活用することで、OU の変更も動的に反映可能。
✅ 最小限のカスタムコードで済み、管理の手間が少ない。

🔹 正解のアプローチ（A: AWS Firewall Manager の活用）

AWS Organizations で AWS Firewall Manager を有効化
- AWS Organizations の管理アカウントで Firewall Manager を設定。
- 各メンバーアカウントに AWS WAF ルールを適用。
AWS Systems Manager Parameter Store に対象アカウント / OU を保存
- 動的に変更できるように、Parameter Store にリストを格納。
Amazon EventBridge で変更を検出
- Parameter Store の変更を EventBridge ルールで監視。
AWS Lambda で AWS Firewall Manager を更新
- Parameter Store の変更を検出したら、Lambda で Firewall Manager のセキュリティポリシーを更新。

🔹 結論

✅ A が最適な選択肢

AWS Firewall Manager により、AWS Organizations 全体の WAF ルールを一元管理可能。
アカウントや OU の追加・削除も容易。
EventBridge + Lambda により、ルールの動的更新が可能。
最小限の運用負荷で、要件をすべて満たす！

🔥 AWS の推奨アーキテクチャに従った、効率的でスケーラブルなソリューション！

問題（和訳）

ある会社が AWS Lambda のセキュリティを監査 している。Lambda は Aurora データベースの最新データを取得 し、それを Amazon S3（SSE-KMS で暗号化）に保存 する。

Lambda と Aurora は同じ VPC 内 にある。
データはインターネットを経由しないことが必須。
Aurora への接続には 環境変数でデータベース認証情報を渡している。
認証情報が漏洩した場合、影響を最小限にする必要がある。

✅ 最適なセキュリティ強化策を選択する必要がある。

選択肢（和訳）

✅ A. IAM 認証 + S3 VPC エンドポイント

Aurora で IAM データベース認証を有効化 し、Lambda の IAM ロールを更新して IAM 認証を使用する。
S3 のゲートウェイ VPC エンドポイント を導入し、データ転送を VPC 内で完結させる。

✅ B. IAM 認証 + HTTPS

Aurora で IAM データベース認証を有効化 し、Lambda の IAM ロールを更新して IAM 認証を使用する。
S3 へのデータ転送を HTTPS で強制。

✅ C. Parameter Store + VPC エンドポイント

AWS Systems Manager Parameter Store にデータベース認証情報を保存。
パスワードの自動ローテーションを有効化。
Lambda で Parameter Store から認証情報を取得するように変更。
S3 のゲートウェイ VPC エンドポイントを導入。

✅ D. Secrets Manager + HTTPS

AWS Secrets Manager にデータベース認証情報を保存。
パスワードの自動ローテーションを有効化。
Lambda で Secrets Manager から認証情報を取得するように変更。
S3 へのデータ転送を HTTPS で強制。

回答 & 解説

✅ 正解: A. IAM 認証 + S3 VPC エンドポイント

🔹 選択肢の評価

選択肢	説明	採用 / 不採用
A. IAM 認証 + VPC エンドポイント	IAM データベース認証は、認証情報の漏洩リスクを最小化できる最善の方法。 S3 の VPC エンドポイントを追加すれば、データ転送を VPC 内に限定できる。	✅ 採用（最適）
B. IAM 認証 + HTTPS	IAM 認証は良いが、S3 との通信が HTTPS のみで VPC 内で完結しないため、不完全な解決策。	❌ 不採用
C. Parameter Store + VPC エンドポイント	IAM 認証よりもセキュリティレベルが低く、認証情報が漏洩するリスクが残る。ただし、VPC エンドポイントの設定は適切。	❌ 不採用
D. Secrets Manager + HTTPS	Secrets Manager は適切なソリューションだが、IAM 認証の方がより安全で運用コストが低い。また、VPC エンドポイントがないため S3 のデータ転送がインターネットを経由する可能性がある。	❌ 不採用

🔹 IAM データベース認証を選ぶ理由

✅ IAM 認証を有効化することで、Lambda が一時的な IAM 認証情報を使って Aurora に接続できる。
✅ IAM 認証なら、固定のデータベースユーザー名・パスワードを管理する必要がなく、漏洩リスクが低い。
✅ AWS IAM は AWS の他のサービスと統合されており、アクセス制御がシンプル。

🔹 VPC エンドポイントを導入する理由

✅ 通常、S3 へのアクセスはパブリックインターネット経由だが、VPC エンドポイントを使うことで VPC 内で完結できる。
✅ セキュリティが向上し、データの外部流出リスクを最小限にできる。
✅ コスト削減（NAT ゲートウェイ経由の通信コストを抑えられる）。

🔹 正解のアプローチ（A: IAM 認証 + VPC エンドポイント）

Aurora に IAM データベース認証を有効化
- aws rds modify-db-cluster --db-cluster-identifier my-cluster --enable-iam-database-authentication
Lambda の IAM ロールを更新し、IAM 認証を許可
```
 
```
json

コピーする編集する

{ "Effect": "Allow", "Action": "rds-db:connect", "Resource": "arn:aws:rds-db:us-east-1:123456789012:dbuser/my-cluster/lambda-user" }
Lambda 関数を更新して IAM 認証を使用
```
 
```
python

コピーする編集する

import boto3 import pymysql from botocore.credentials import InstanceMetadataProvider, InstanceMetadataFetcher session = boto3.Session() client = session.client('rds') token = client.generate_db_auth_token( DBHostname="my-cluster.cluster-xyz.us-east-1.rds.amazonaws.com", Port=3306, DBUsername="lambda-user" ) connection = pymysql.connect( host="my-cluster.cluster-xyz.us-east-1.rds.amazonaws.com", user="lambda-user", password=token, ssl={'ssl': {}} )
S3 のゲートウェイ VPC エンドポイントを作成
```
 
```
sh

コピーする編集する

aws ec2 create-vpc-endpoint \ --vpc-id vpc-abc123 \ --service-name com.amazonaws.us-east-1.s3 \ --route-table-ids rtb-xyz456

🔹 結論

✅ A が最適な選択肢

IAM 認証により、固定の認証情報を排除し、漏洩リスクを最小化。
S3 の VPC エンドポイントを活用して、データの転送を VPC 内で完結。
AWS ベストプラクティスに準拠し、運用コストを抑えながら高セキュリティを実現。

🔥 最も安全で、運用負荷が低い AWS 標準のアーキテクチャを実現！ 🚀

問題（和訳）

あるモバイルゲーム企業が オンプレミス環境から AWS へ移行 した。

ソリューションアーキテクトが環境を Well-Architected Framework に準拠しているかレビュー している。
Cost Explorer を確認すると、大きなインスタンスタイプの 作成と終了 が頻繁に行われ、コストが高くなっている。
開発者がテスト目的で適切でないインスタンスタイプを起動していることが判明。

✅ 開発者が起動できる EC2 インスタンスタイプを制限する仕組みを導入する必要がある。

選択肢（和訳）

✅ A. AWS Config のルールを使用

AWS Config の 「desired-instance-type」マネージドルール を作成し、許可するインスタンスタイプを指定。
新しい EC2 インスタンスが起動されるたびにルールを評価し、制限を適用。

✅ B. EC2 のローンチテンプレートを使用

特定のインスタンスタイプのみを許可するローンチテンプレートを作成。
開発者の IAM アカウントにこのテンプレートの使用を義務付ける。

✅ C. IAM ポリシーで制御

許可するインスタンスタイプを IAM ポリシーに定義。
開発者が所属する IAM グループにポリシーをアタッチ。

✅ D. EC2 Image Builder を使用

「ゴールデンイメージ」を作成し、開発者に提供。
開発者はこのゴールデンイメージからのみ EC2 インスタンスを作成できるようにする。

回答 & 解説

✅ 正解: C. IAM ポリシーで制御

🔹 選択肢の評価

選択肢	説明	採用 / 不採用
A. AWS Config で監視	AWS Config は「設定の監視」は可能だが、「事前に起動をブロックする」ことはできないため、不完全な解決策。	❌ 不採用
B. EC2 のローンチテンプレート	開発者がローンチテンプレートを無視して別の方法でインスタンスを起動できてしまうため、不完全な解決策。	❌ 不採用
C. IAM ポリシーで制御	開発者の権限レベルでインスタンスの種類を制限でき、事前にブロック可能。最も適した方法。	✅ 採用（最適）
D. EC2 Image Builder	ゴールデンイメージは標準化には有効だが、開発者が自由に異なるインスタンスタイプを選択するのを防げない。	❌ 不採用

🔹 IAM ポリシーでの実装方法

IAM ポリシーを使うことで、開発者が起動できるインスタンスタイプを事前に制限できる。
以下のポリシーを開発者用の IAM グループに適用すれば、特定のインスタンスタイプ（例: t3.micro, t3.small）のみ起動を許可する。

IAM ポリシーのサンプル

json

コピーする編集する

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "StringNotEqualsIfExists": { "ec2:InstanceType": [ "t3.micro", "t3.small" ] } } } ] }

✅ このポリシーのポイント:

ec2:RunInstances を Deny することで、許可されていないインスタンスタイプの起動を防ぐ。
StringNotEqualsIfExists を使用することで、許可リスト (t3.micro, t3.small) 以外のインスタンスの起動を拒否。
IAM グループにこのポリシーを適用すれば、すべての開発者に制限がかかる。

🔹 なぜ他の選択肢は不適切なのか？

A. AWS Config

AWS Config は「設定の監視」には向いているが、「事前に制御」する機能はない。
例えば、開発者が間違ったインスタンスタイプを起動しても、Config でアラートが出るだけでブロックできない。
ブロックしたい場合は、IAM ポリシーを使う必要があるため、IAM を直接適用する方が効率的。

B. EC2 のローンチテンプレート

ローンチテンプレートは開発者が使わなくても EC2 インスタンスを起動できるため、強制力がない。
IAM ポリシーなら EC2 コンソールでも CLI でも制限が適用されるため、より確実。

D. EC2 Image Builder

ゴールデンイメージは「OS の設定やアプリケーションの標準化」には適しているが、インスタンスタイプの制御には適さない。
例えば、開発者は t3.micro のゴールデンイメージを作成しても、そのイメージを m5.large などのインスタンスで起動できてしまう。
EC2 インスタンスタイプを制限するには IAM ポリシーの方が適切。

🔹 結論

✅ C. IAM ポリシーを適用するのが最適解！

開発者の権限レベルでインスタンスタイプの制御が可能。
EC2 コンソール、CLI、SDK すべてに適用され、確実に制限できる。
運用の負担も少なく、AWS のベストプラクティスに適合。 🚀

問題（和訳）

ある会社が AWS Organizations 配下の複数の AWS アカウントでプロジェクトを開発・ホスティングしている。

各プロジェクトの AWS コストをプロジェクトごとに正しく割り当てる必要がある。
しかし、「Project」タグが設定されていない EC2 インスタンスがあることが判明。
タグの不足を検出し、将来的に発生しないようにする必要がある。

✅ タグの欠落を検出し、未設定のままインスタンスを起動させない仕組みを構築する。

選択肢（和訳 & 評価）

✅ A. AWS Config ルールを作成して、タグが不足しているリソースを検出する。
➡ 適切 ✅（監視に有効）

AWS Config を使用すると、タグのないリソースを検出可能。
タグのコンプライアンスルールを設定し、違反リソースを可視化できる。

✅ B. AWS Organizations の SCP（Service Control Policy）で、Project タグがない場合に EC2 インスタンスの作成を拒否する。
➡ 適切 ✅（強制力がある）

SCP を使用すると、組織全体で「Project」タグが設定されていない場合のインスタンス作成を防止できる。
IAM ポリシーよりも組織レベルで適用できるため、効果的。

❌ C. Amazon Inspector を使用してタグが不足しているリソースを検出する。
➡ 不適切 ❌（Amazon Inspector は脆弱性スキャンツール）

Amazon Inspector はセキュリティ脆弱性やベストプラクティスの違反を検出するためのツールであり、タグ監視には適していない。

✅ D. 各アカウントの IAM ポリシーで、Project タグがない場合に EC2 インスタンスの作成を拒否する。
➡ 適切 ✅（SCP より粒度が細かい制御）

IAM ポリシーを使って、各アカウント単位で「Project」タグがない場合の EC2 作成を拒否可能。
SCP と似ているが、IAM ポリシーはアカウント単位、SCP は組織単位で適用。
SCP を組織全体で適用し、IAM ポリシーを特定のアカウントで適用するのがベスト。

✅ E. AWS Config アグリゲーターを作成し、組織全体で Project タグが欠落している EC2 インスタンスを収集する。
➡ 適切 ✅（組織全体での可視化に有効）

複数の AWS アカウントの Config データを 1 か所に集約し、未設定のリソースを一括管理可能。
全体の監視が必要なため、これは重要。

❌ F. AWS Security Hub を使用して、Project タグが不足している EC2 インスタンスを集約する。
➡ 不適切 ❌（Security Hub はセキュリティ異常検出ツール）

Security Hub はセキュリティ異常（脆弱性、コンプライアンス違反）を検出するツールであり、タグ管理には適していない。

回答（正解の3つ）

✅ A. AWS Config ルールを作成してタグ不足を監視する。
✅ B. SCP を適用し、タグなしの EC2 インスタンス作成をブロックする。
✅ E. AWS Config アグリゲーターを使用し、組織全体でタグ不足を可視化する。

🔹 なぜこれがベストな組み合わせか？

A（AWS Config） → タグ不足のリソースを検出。
B（SCP） → 「Project」タグなしの EC2 作成をブロック。（組織全体の強制）
E（Config アグリゲーター） → 全アカウントの EC2 インスタンスのタグ状態をまとめて確認可能。

✅ 監視（A & E） + 制限（B）の組み合わせが最適！ 🚀

問題（和訳）

オンプレミスの監視ソリューションで PostgreSQL を使用してイベントを保存しているが、スケールができずストレージ不足に陥っている。
すでに AWS との VPN 接続があり、以下の要件を満たす ハイブリッドソリューションを構築したい。

要件:

✅ 運用負担を最小限にする AWS マネージドサービスを活用
✅ スケーラブルなバッファを設置し、自動でスループットに適応
✅ リアルタイムダッシュボードを用いてイベントを可視化
✅ JSON のような半構造化データや動的スキーマに対応

選択肢（和訳 & 評価）

✅ A. Amazon Kinesis Data Firehose をバッファとして使用し、AWS Lambda でイベントを処理・変換する。
➡ 適切 ✅（完全マネージド & 自動スケーリング & 運用不要）

Kinesis Data Firehose は、データを自動でバッファリングし、ストレージやデータストアへ送信。
管理不要 & スケーラブル（AWS がスループットを自動調整）
Lambda でデータ変換も可能（JSON を扱う場合にも適用しやすい）

✅ D. Amazon Elasticsearch Service (Amazon ES) をイベント受信先とし、Kibana でリアルタイム可視化する。
➡ 適切 ✅（リアルタイム分析 & JSON に最適 & Kibana によるダッシュボード）

Elasticsearch は JSON のような半構造化データの処理が得意。
スキーマレスで動的データに対応。
Kibana（Amazon ES に組み込み）がダッシュボード作成に適している。
リアルタイム可視化も可能！

他の選択肢の評価（不適切な理由）

❌ B. Amazon Kinesis Data Streams をバッファとして使用し、AWS Lambda でイベントを処理・変換する。
➡ 不適切 ❌（Kinesis Data Streams は管理負担が増える）

Kinesis Data Streams は手動でシャード管理が必要 → 運用負担が増加。
要件の「運用管理の負担を減らす」に反するため不適切。

❌ C. Amazon Aurora PostgreSQL を受信先として使用し、Amazon QuickSight で可視化する。
➡ 不適切 ❌（Aurora は JSON に最適ではなく、スキーマ変更が手間）

Aurora PostgreSQL は JSON データを格納できるが、スキーマレスではないため、データ構造が頻繁に変わる場合に適さない。
Elasticsearch の方が動的スキーマや JSON に適しているため、より良い選択肢がある。

❌ E. Amazon Neptune を受信先として使用し、Amazon QuickSight で可視化する。
➡ 不適切 ❌（Neptune はグラフデータ向けで、監視用途には不適切）

Amazon Neptune はグラフデータベース（ノードとリレーション）を扱う。
JSON ベースの監視データやログ保存には適していない。
リアルタイム可視化には Elasticsearch + Kibana の方が適切。

回答（正解の2つ）

✅ A. Kinesis Data Firehose + Lambda（スケーラブルなデータバッファ）
✅ D. Amazon Elasticsearch + Kibana（JSON & ダッシュボード & リアルタイム可視化）

🔹 なぜこの組み合わせが最適か？

A（Kinesis Firehose） → スケーラブルなデータバッファを提供し、管理不要でデータ変換も可能。
D（Elasticsearch + Kibana） → JSON に最適なデータストア & Kibana でリアルタイム可視化が可能。
✅ 運用負担を減らしつつ、リアルタイムの監視とデータ管理が可能なベストソリューション！ 🚀

問題（和訳）

あるチームが、企業全体の行動データを収集してルーティングしています。企業は Multi-AZ VPC 環境 を運用しており、以下の構成を持っています。

パブリックサブネット、プライベートサブネット、インターネットゲートウェイ を含む
各パブリックサブネットには NAT ゲートウェイが配置されている
ほとんどのアプリケーションが Amazon Kinesis Data Streams を利用
ほとんどのワークロードがプライベートサブネット内で動作

ソリューションアーキテクトは インフラの見直しを行い、コスト削減とアプリケーションの機能維持を目指す必要があります。
Cost Explorer を確認したところ、EC2-Other カテゴリのコストが一貫して高額 であることが判明しました。さらに調査すると、NAT Gateway の "NatGateway-Bytes" による課金が増加している ことがわかりました。

✅ ソリューションアーキテクトは、コスト削減をしながらアプリケーションの機能を維持するために、どの対応を行うべきか？

選択肢（和訳）

A. VPC Flow Logs を有効化する。Amazon Athena を使用してログを分析し、不要なトラフィックを特定する。高コストの原因となるトラフィックをブロックするようにセキュリティグループを設定する。

B. Kinesis Data Streams のインターフェース VPC エンドポイントを VPC 内に追加する。アプリケーションが適切な IAM パーミッションを持っていることを確認する。

C. VPC Flow Logs と Amazon Detective を有効化する。Detective の分析結果をもとに、Kinesis Data Streams に関係のないトラフィックを特定し、セキュリティグループを設定してブロックする。

D. Kinesis Data Streams のインターフェース VPC エンドポイントを VPC 内に追加する。VPC エンドポイントポリシーを設定し、アプリケーションが適切にアクセスできるようにする。

回答と解説

✅ 正解: B, D

解説:

現在、プライベートサブネットのアプリケーションが Kinesis Data Streams にアクセスする際、NAT ゲートウェイを経由している。このため、NAT ゲートウェイのデータ転送コスト (NatGateway-Bytes) が高くなっている。
Kinesis Data Streams のインターフェース VPC エンドポイント（AWS PrivateLink）を導入することで、NAT ゲートウェイを経由せずに Kinesis へ直接アクセスできるようになり、コストを削減できる。
B は IAM パーミッションを考慮した適切なアプローチ。
D は VPC エンドポイントポリシーを適切に設定することで、必要なアプリケーションだけが Kinesis にアクセスできるようにする。
B と D を組み合わせることで、NAT ゲートウェイのコストを削減しつつ、アクセス制御を適切に行うことが可能。

❌ 誤答の理由

A. VPC Flow Logs を有効化し、不要なトラフィックを特定するのは有効な手段だが、根本的な解決策ではない。NATゲートウェイ経由で Kinesis にアクセスしている限り、コストは削減できない。

C. Amazon Detective を活用した分析は役立つが、NAT ゲートウェイを経由する Kinesis への通信が問題の主要因であるため、トラフィックの分析だけでは本質的な解決にはならない。

問題（和訳）

小売会社が ヨーロッパにオンプレミスのデータセンター を持ち、AWS では eu-west-1（ヨーロッパ）と us-east-1（アメリカ） の 2 つのリージョンに展開している。

✅ 要件:

オンプレミスのネットワークから AWS の VPC へルーティングできること（eu-west-1 および us-east-1 の両方にルーティング可能）
2 つのリージョン（eu-west-1 ⇔ us-east-1）間で VPC 間の通信ができること
ネットワークの単一点障害 (SPOF) をなくすこと

✅ 既存の構成:

オンプレミスと AWS 間の接続は、2 本の 1 Gbps AWS Direct Connect (DX) 回線
- DX-A（Direct Connect ロケーション A）
- DX-B（Direct Connect ロケーション B）
- 両方ともヨーロッパのデータセンターから接続し、高可用性を確保
各リージョン（eu-west-1, us-east-1）にそれぞれ 1 つの AWS Transit Gateway を配置
- リージョン内の VPC 間通信は Transit Gateway で制御

✅ 最適なソリューションを選択せよ。

選択肢（和訳）

DX-A に Private VIF を作成し、Direct Connect Gateway（DXGW）に接続
DX-B に Private VIF を作成し、同じ DXGW に接続（高可用性）
eu-west-1 と us-east-1 の Transit Gateway を DXGW に関連付ける
Transit Gateway 同士をピアリングし、リージョン間通信を可能にする

DX-A に Transit VIF を作成し、1 つ目の DXGW に接続
eu-west-1 の Transit Gateway を 1 つ目の DXGW に関連付け
DX-B に Transit VIF を作成し、2 つ目の DXGW に接続
us-east-1 の Transit Gateway を 2 つ目の DXGW に関連付け
DXGW 同士をピアリングし、リージョン間通信を可能にする

DX-A に Transit VIF を作成し、1 つの DXGW に接続
DX-B に Transit VIF を作成し、同じ DXGW に接続（高可用性）
eu-west-1 と us-east-1 の Transit Gateway を DXGW に関連付ける
DXGW を経由してリージョン間通信を行う

DX-A に Transit VIF を作成し、1 つの DXGW に接続
DX-B に Transit VIF を作成し、同じ DXGW に接続（高可用性）
eu-west-1 と us-east-1 の Transit Gateway を DXGW に関連付ける
Transit Gateway 同士をピアリングし、リージョン間通信を可能にする

回答と解説

✅ 正解: D

理由:

オンプレミスから AWS への高可用性を確保
- DX-A と DX-B の 2 本の Direct Connect を 1 つの Direct Connect Gateway（DXGW）に接続
- Transit VIF を使用することで AWS Transit Gateway にルーティング可能
リージョン間通信を可能にする
- eu-west-1 の Transit Gateway ⇔ us-east-1 の Transit Gateway をピアリング することで、リージョン間の VPC 通信が可能
Direct Connect Gateway ではリージョン間の Transit Gateway ルーティングができないため、Transit Gateway ピアリングが必要

❌ 誤答の理由

A.（誤り）

Private VIF は 1 つの VPC または AWS Direct Connect Hosted VIF に接続するためのものであり、Transit Gateway には適していない
Transit Gateway のピアリングは正しいが、Direct Connect Gateway を適切に利用していない

B.（誤り）

2 つの Direct Connect Gateway を作成する必要はない
Direct Connect Gateway 同士のピアリングはできないため、リージョン間通信ができない

C.（誤り）

Direct Connect Gateway は Transit Gateway 同士のリージョン間ルーティングには使用できない
Transit Gateway ピアリングがないため、リージョン間通信が実現できない

問題（和訳）

ある企業が AWS クラウドでアプリケーションを運用している。

✅ 要件:

IAM ユーザーが作成されたら、すべてのアクセスを自動的に削除する
セキュリティチームが承認するまでアクセスできないようにする
セキュリティチームに通知を送信する
CloudTrail はマルチリージョンで設定されている

✅ 最適なソリューションを選択せよ（3 つ選択）

選択肢（和訳）

Amazon EventBridge（旧 CloudWatch Events）のルールを作成
CreateUser イベントを検知（CloudTrail 経由で取得）

CloudTrail の CreateUser イベントを Amazon SNS に送信する

Amazon ECS（AWS Fargate）上のコンテナを実行し、ユーザーのアクセスを削除

AWS Step Functions のステートマシンを実行し、ユーザーのアクセスを削除

Amazon SNS を使用してセキュリティチームに通知

Amazon Pinpoint を使用してセキュリティチームに通知

回答と解説

✅ 正解: A, D, E

A. EventBridge ルールで IAM ユーザー作成を検知（必須）
- IAM ユーザー作成イベント（CreateUser）を検知するために必要
- CloudTrail のログを Amazon EventBridge でモニタリングし、次のアクションをトリガー
D. AWS Step Functions で IAM ユーザーのアクセスを削除（適切）
- Step Functions は AWS SDK を利用して IAM ポリシーの削除を実行可能
- ECS のコンテナを使うよりシンプルで運用コストも低い
E. SNS でセキュリティチームに通知（適切）
- SNS はイベント通知の一般的な手段
- メール、SMS、または Lambda での処理が可能

❌ 誤答の理由

B.（誤り）

CloudTrail から直接 SNS に通知を送る設定はない
CloudTrail のログを監視するには EventBridge を使用するのが適切（A の方が正解）

C.（誤り）

ECS + Fargate でコンテナを起動するのはオーバーヘッドが大きい
Step Functions（D）の方が軽量で適切

F.（誤り）

Amazon Pinpoint は主にマーケティング向けの通知サービス
運用向け通知は SNS（E）の方が適切

問題（和訳）

企業の環境:

SaaS ソリューションを AWS 上に構築
API Gateway (REST API) + AWS Lambda の統合
複数の AWS リージョンに展開
プレミアムプラン: 1 秒あたり 最大 3,000 API リクエスト
顧客識別: APIキー
エラー状況:
- 429 Too Many Requests（レート制限エラー）が発生
- Lambda 関数は実行されていない（ログに記録なし）

✅ 問題:
なぜ 429 エラーが発生し、Lambda が呼ばれていないのか？

選択肢（和訳）

A. Lambda 関数の同時実行数の上限に達した。
B. Lambda 関数のリージョンごとの同時実行数の上限に達した。
C. API Gateway のアカウント単位の呼び出し制限に達した。
D. API Gateway のデフォルトのメソッド単位の呼び出し制限に達した。

回答と解説

✅ 正解: D (API Gateway のデフォルトのメソッド単位の呼び出し制限)

解説（なぜ D が正解か？）

1. 429 Too Many Requests の発生要因

429 Too Many Requests は、API Gateway や Lambda の レート制限 (Throttle Limit) に達した場合に発生。
ログを見ると Lambda は実行されていない → API Gateway で制限が発生している。

2. API Gateway のレート制限

API Gateway には 2 種類のレート制限がある
1. アカウント単位の API 呼び出し制限
2. メソッド単位のデフォルト制限（50 RPS）
デフォルトでは、API Gateway の各メソッドの制限は 50 リクエスト/秒 しかない。
プレミアム顧客は 3,000 RPS の利用が可能なはずだが、デフォルト設定のままだと 50 RPS で制限される。

3. なぜ C ではないのか？

C（アカウント単位の制限）はデフォルトで "10,000 RPS"（リージョンごと）。
3,000 RPS の顧客が数人いるだけではこの制限には達しにくい。

4. なぜ A/B ではないのか？

Lambda が実行されていないので、Lambda の同時実行数制限（A/B）は関係ない。

解決策

API Gateway の「メソッド単位のレート制限」を引き上げる
- AWS コンソール: API Gateway → Usage Plans
- API キーごとのクォータ（Throttle, Burst Limit）を増加
必要に応じて API Gateway のアカウント単位のレート制限も確認
サービスごとのスロットリング（Rate Limit）をモニタリングする

結論

プレミアム顧客の 3,000 RPS に対応するために、API Gateway のデフォルトメソッド制限を増加させる必要がある（D が正解）。
Lambda の問題ではないため、A/B は除外。
アカウント単位の制限には達していないため、C も除外。

問題（和訳）

企業の状況:

金融会社がオンプレミスの Web アプリを AWS に移行予定
サードパーティのセキュリティツールを使用し、15年間利用
そのセキュリティツールはクラウド対応なし（AWS にネイティブなソリューションは提供されていない）
セキュリティチームは AWS との統合方法を懸念している

✅ 要件:

EC2 + Auto Scaling Group + VPC にデプロイ
セキュリティツールを使用して、VPC の全トラフィックをリアルタイムで検査
アプリのパフォーマンスを損なわない
高可用性（HA）が必要

✅ 問題:
AWS 上でどのようにセキュリティツールを統合し、高可用性を確保するか？

選択肢（和訳）

✅ A. 既存の VPC に、新しい Auto Scaling Group を作成し、その中でセキュリティツールを実行する。
✅ B. Web アプリを Network Load Balancer（NLB）の背後に配置する。
❌ C. Application Load Balancer（ALB）をセキュリティツールの前に配置する。
✅ D. 各アベイラビリティゾーン（AZ）に Gateway Load Balancer（GWLB）をデプロイし、セキュリティツールへトラフィックをリダイレクトする。
❌ E. Transit Gateway（TGW）をプロビジョニングし、VPC 間通信を促進する。

回答と解説

✅ 正解: A, D

解説（なぜ A と D が正解か？）

1. A（セキュリティツールを EC2 + Auto Scaling Group でデプロイ） ✅

オンプレで利用していたセキュリティツールを AWS 上で動作させる必要がある。
AWS ネイティブのセキュリティサービス（AWS WAF、Network Firewall など）に移行できないため、EC2 にデプロイする必要がある。
Auto Scaling Group を使用すると、スケールアウト/スケールインによる可用性と冗長性を確保できる。

2. D（Gateway Load Balancer でセキュリティツールにトラフィックを流す） ✅

Gateway Load Balancer（GWLB）は、セキュリティ検査を行うための専用ロードバランサーで、VPC 内のトラフィックをインスペクション用インスタンスにルーティングできる。
GWLB は高可用性を提供し、負荷分散が可能。
セキュリティツールの負荷分散やスケールアウトに最適。
この方法なら、すべてのトラフィックをリアルタイムで監視しながらアプリのパフォーマンスを最適化できる。

なぜ B, C, E は不正解か？

❌ B（Network Load Balancer をアプリの前に配置）

NLB は L4（TCP/UDP）ロードバランサーなので、セキュリティツールとは無関係。
アプリの可用性向上には役立つが、セキュリティツールの統合には寄与しない。
セキュリティツールの検査対象トラフィックをルーティングする仕組みがない。

❌ C（Application Load Balancer をセキュリティツールの前に配置）

ALB は L7（HTTP/S）専用であり、全トラフィックを検査するセキュリティツールとは適合しない。
セキュリティツールは L3/L4 のパケットインスペクションを行う可能性が高く、ALB では適用できない。

❌ E（Transit Gateway を利用する）

Transit Gateway（TGW）は VPC 間通信を最適化するが、トラフィックの検査はしない。
TGW は WAN 接続やハイブリッドクラウド構成には適しているが、セキュリティツールとの統合には不要。

結論

A.（セキュリティツールを EC2 にデプロイ） + D.（Gateway Load Balancer でトラフィックをルーティング）が最適解。
この方法により、AWS におけるレガシーセキュリティツールの統合と高可用性が確保できる。

問題（和訳）

企業の状況:

異なるベンダーの IoT センサー付きアプライアンスを購入
各ベンダーのセンサーが「独自フォーマット」でステータス情報を送信
レガシーアプリが JSON に変換し、データベースに保存（解析のため）
現在は 1 日 1 回処理を実行（バッチ処理）
新しいソリューションでは「より高速に」&「コスト最適化」する必要がある

選択肢（和訳）

✅ A.

IoT センサーを AWS IoT Core に接続
AWS Lambda でデータを解析し、Amazon S3 に .csv として保存
AWS Glue を使ってデータをカタログ化し、Amazon Athena と QuickSight で分析

✅ B.

AWS Fargate 上にアプリを移行（IoT センサーからデータ受信 & パース）
データをリレーショナルフォーマットに変換し、Amazon Redshift に保存して分析

✅ C.

IoT センサーのコードを変更し、SFTP 経由で .csv ファイルを送信
AWS Transfer for SFTP を使用してデータを保存
AWS Glue + Amazon Athena で分析

✅ D.

AWS Snowball Edge を使って IoT データをローカル収集 & 分析
定期的にデータを Amazon Redshift に送信し、グローバル分析

正解と解説

✅ 正解: A

解説（なぜ A が正解か？）

✅ 1. AWS IoT Core を使用して IoT デバイスから直接データを収集できる

IoT Core は MQTT / HTTPS をサポートしており、異なるフォーマットのデータを受信しやすい
「独自フォーマットのデータ」を Lambda で JSON に変換できる

✅ 2. Lambda を活用してリアルタイム処理が可能

現在の「1 日 1 回バッチ処理」ではなく、「ストリーム処理」が可能
Lambda なら IoT センサーごとに異なる処理ロジックを適用可能

✅ 3. S3 + AWS Glue + Athena + QuickSight で、サーバーレスでコスト最適化

S3 はデータレイクとして最適で、ストレージコストが低い
Athena は S3 のデータを直接クエリでき、Redshift よりもコスト効率が高い
QuickSight で可視化できるため、分析の柔軟性が高い

なぜ B, C, D は不正解か？

❌ B. AWS Fargate + Redshift

Fargate は「コンテナ管理が不要」だが、IoT 向けのネイティブサービスではない
IoT のリアルタイムデータ処理には適していない（Lambda の方が適切）
Redshift はバッチ処理向きであり、ストリーミングデータには向いていない
結果として、「リアルタイム処理 & コスト最適化」に反する

❌ C. SFTP を経由して .csv ファイルを送信

IoT デバイスのコード変更が必要（センサーのプログラム変更は高コスト & リスクが高い）
SFTP は「バッチ処理」に向いているため、リアルタイム処理にならない
現在の課題は「リアルタイム処理 & コスト最適化」なので不適切

❌ D. AWS Snowball Edge

Snowball Edge は「エッジコンピューティング（オフライン環境）」向け
問題文では AWS クラウド上で処理する前提なので、Snowball Edge は不要
Redshift を使うため、Athena よりコストが高くなる
結局、「より速く & コスト最適化」の要件に合わない

結論

最適解は ✅ A（AWS IoT Core + Lambda + S3 + Athena + QuickSight）

リアルタイム処理
サーバーレスでコスト最適化
柔軟なデータ分析

問題（和訳）

企業の状況:

アプリケーションを AWS に移行し、モダナイズしたい
AWS Direct Connect を中央ネットワークアカウントに設定済み
将来的に「数百の AWS アカウント & VPC」を想定
オンプレミスと AWS のシームレスな接続が必要
オンプレミス経由でインターネットに出るルーティングが必要

選択肢（和訳）

✅ A.

中央ネットワークアカウントに Direct Connect ゲートウェイを作成
各 AWS アカウントで「仮想プライベートゲートウェイ（VGW）」を使用し、Direct Connect ゲートウェイに接続

✅ B.

中央ネットワークアカウントに「Direct Connect ゲートウェイ」と「Transit Gateway」を作成
Direct Connect ゲートウェイを Transit Gateway に「Transit VIF」で接続

✅ C.

インターネットゲートウェイをプロビジョニングし、サブネットにアタッチ
インターネットトラフィックをゲートウェイ経由で許可

✅ D.

Transit Gateway を他の AWS アカウントと共有（AWS Resource Access Manager）
各 VPC を Transit Gateway に接続

✅ E.

VPC ピアリングを必要に応じて設定

✅ F.

プライベートサブネットのみを使用
Transit Gateway & Customer Gateway のルート設定を変更し、オンプレミス NAT 経由で AWS からインターネットに出るようにする

正解と解説

✅ 正解: B, D, F

解説（なぜ B, D, F が正解か？）

✅ B. Direct Connect Gateway + Transit Gateway の組み合わせが最適

Direct Connect Gateway は「オンプレミス ⇄ AWS 間」の接続を管理
Transit Gateway は「VPC 間 & Direct Connect Gateway のルーティング」を管理
Transit VIF を使って Direct Connect Gateway と Transit Gateway を接続すれば、全 VPC にアクセス可能

✅ D. Transit Gateway をアカウント間で共有し、VPC 接続を管理

数百の AWS アカウント & VPC をサポートするためには、VPC Peering よりも Transit Gateway の方がスケーラブル
AWS Resource Access Manager（RAM）を使えば、Transit Gateway を他のアカウントと共有可能

✅ F. プライベートサブネットを使用し、オンプレミス経由でインターネットにルーティング

セキュリティポリシーを考慮し、パブリックサブネットは不要
Transit Gateway + Customer Gateway のルートを設定すれば、オンプレミスの NAT 経由でインターネットにアクセス可能

なぜ A, C, E は不正解か？

❌ A. Direct Connect Gateway のみを使うとスケーラビリティが低い

Direct Connect Gateway は VPC 間ルーティングを提供しないため、全 VPC に接続できない
Transit Gateway なしでは、VPC 間通信が複雑になりすぎる

❌ C. インターネットゲートウェイを使うと、オンプレミス経由のルーティング要件を満たさない

要件として「オンプレミス経由でインターネットに出る」ことが必要
インターネットゲートウェイを使うと、AWS 内で直接インターネットに出てしまうため要件に合わない

❌ E. VPC ピアリングはスケールしない

VPC Peering は「1 対 1 の接続」しかできず、数百の VPC を接続するのは非現実的
Transit Gateway を使った方が大規模なネットワーク構成に適している

結論

✅ B, D, F（Direct Connect Gateway + Transit Gateway + オンプレ経由のインターネットルーティング） が最適なアーキテクチャ

スケーラブル & シームレスなオンプレ接続
全 VPC との接続を確立
オンプレ経由でインターネットに出るセキュリティ要件を満たす

問題（和訳）

企業の状況:

AWS アカウントが数百個存在
以前は各ビジネスユニットが Reserved Instances（RI）の購入・変更を自主的に実施
現在は中央チームが「RI の購入・変更」を管理するルールを導入
全 AWS アカウントでこのルールを強制する必要がある

選択肢（和訳）

✅ A.

全 AWS アカウントを AWS Organizations に統合し、「全機能を有効」にする

✅ B.

AWS Config を使用し、「IAM ポリシーに ec2:PurchaseReservedInstancesOffering & ec2:ModifyReservedInstances を拒否する設定があるか」監視

✅ C.

各 AWS アカウントに IAM ポリシーを作成し、ec2:PurchaseReservedInstancesOffering & ec2:ModifyReservedInstances のアクションを拒否

✅ D.

組織の「全ての OU」に SCP（Service Control Policy）を適用し、ec2:PurchaseReservedInstancesOffering & ec2:ModifyReservedInstances のアクションを拒否

✅ E.

全 AWS アカウントを AWS Organizations に統合し、「統合請求（Consolidated Billing）」を有効化

正解と解説

✅ 正解: A, D

解説（なぜ A, D が正解か？）

✅ A. AWS Organizations を「全機能有効」にするのが必須

SCP（Service Control Policy）を適用するには AWS Organizations の「全機能（All Features）」を有効化する必要がある
全 AWS アカウントを統合することで、セキュリティ & ポリシー管理が容易になる

✅ D. SCP で「RI 購入・変更のアクションを拒否」すれば、一括管理が可能

SCP は AWS Organizations 内の「すべての AWS アカウント」に適用可能
IAM ポリシーとは異なり、「組織全体」に強制適用できるため、最もセキュアな方法
SCP により「どの IAM ユーザー・ロールでも RI の購入・変更が不可能」となる

なぜ B, C, E は不正解か？

❌ B. AWS Config は監視はできるが、強制はできない

AWS Config は「IAM ポリシーを正しく設定しているか」の監視には使える
ただし、「ポリシーの適用強制」はできないため、ポリシー違反を防ぐことができない
SCP を使えば、監視ではなく「完全なアクセス制御」が可能

❌ C. IAM ポリシーの適用はアカウントごとになり、管理が困難

IAM ポリシーは「各 AWS アカウントごとに設定」する必要があり、管理負担が増大
ユーザーが IAM ポリシーを編集してしまう可能性もあるため、完全な強制力はない
SCP を適用すれば、「IAM ポリシーの変更の余地なく」強制的に RI の購入・変更をブロックできる

❌ E. 統合請求（Consolidated Billing）のみでは、SCP の適用はできない

AWS Organizations の「統合請求（Consolidated Billing）」機能だけでは、SCP を適用できない
「全機能（All Features）」を有効にしないと SCP を適用できないため、A の方が正しい

結論

✅ A（AWS Organizations の全機能有効化）+ D（SCP による RI 購入・変更の強制ブロック）が最適解

SCP を使えば、「すべての AWS アカウント」で RI の購入・変更を完全にブロック可能
IAM ポリシーではなく SCP を使うことで、より強力な制御ができる
AWS Config（B）や IAM ポリシー（C）は管理負担が増えるため、最適ではない

問題（和訳）

企業の状況:

Amazon RDS for MySQL（Multi-AZ）を使用
フェイルオーバー時に 40 秒のダウンタイムが発生
ダウンタイムを 20 秒未満に短縮する必要がある

選択肢（和訳）

✅ A. Amazon ElastiCache for Memcached を DB の前に配置
✅ B. Amazon ElastiCache for Redis を DB の前に配置
✅ C. RDS Proxy を DB の前に配置
✅ D. Amazon Aurora MySQL に移行
✅ E. Amazon Aurora レプリカを作成
✅ F. RDS for MySQL のリードレプリカを作成

正解と解説

✅ 正解: C, D, E

解説（なぜ C, D, E が正解か？）

✅ C. RDS Proxy を導入すると、フェイルオーバー時間を短縮可能

RDS Proxy はデータベース接続を管理し、フェイルオーバー時の影響を最小化
通常のフェイルオーバーでは「新しい DB インスタンスへ再接続」が必要だが、RDS Proxy を使えば「既存の接続を維持しつつ、バックエンドを自動で切り替えられる」
フェイルオーバー時間を 20 秒未満に短縮可能

✅ D. Amazon Aurora MySQL へ移行すると、フェイルオーバーが 10 秒未満に短縮

Aurora MySQL は RDS MySQL よりも高速なフェイルオーバーを提供（通常 5〜10 秒）
RDS MySQL はストレージの同期コピーを行うため、フェイルオーバーに時間がかかる（30〜60 秒）
Aurora はストレージ層が共有されるため、フェイルオーバーが即時実行される

✅ E. Aurora レプリカを作成すると、フェイルオーバーがさらに高速化

Aurora には「Aurora レプリカ」という専用のリードレプリカがあり、プライマリ DB のフェイルオーバー先として利用可能
通常の RDS Multi-AZ は「同期レプリケーション」を行うが、Aurora の場合はストレージが共有されているため、DB の昇格がより高速に行われる
Aurora レプリカを利用すると、フェイルオーバーが 2 秒未満になることもある

なぜ A, B, F は不正解か？

❌ A, B. ElastiCache（Memcached / Redis）は DB の負荷を軽減するが、フェイルオーバー時間を短縮しない

ElastiCache は「データのキャッシュ化」によって DB への負荷を軽減するが、フェイルオーバー時の DB 停止時間には直接影響しない
フェイルオーバーの時間短縮には、DB の構成を変更する必要がある

❌ F. RDS for MySQL のリードレプリカはフェイルオーバーには使えない

RDS の「リードレプリカ」はフェイルオーバー用ではなく、「リードクエリの負荷分散用」
リードレプリカは自動でプライマリ DB に昇格しないため、フェイルオーバー短縮にはならない
Aurora レプリカ（E）の方がフェイルオーバーの最適解

結論

✅ C（RDS Proxy）+ D（Aurora へ移行）+ E（Aurora レプリカ）で、20 秒未満のフェイルオーバーが可能

RDS Proxy により接続の再確立を高速化
Aurora へ移行することで、フェイルオーバーを 5〜10 秒に短縮
Aurora レプリカを活用すると、フェイルオーバーが 2 秒未満になることもある

質問の要約

シナリオ:
- パートナー企業（org1）が顧客アカウント（org2）のAWSリソースにアクセスする必要がある。
- 要件: API または CLI を使用して最小特権のセキュリティアクセスを確立する。
- AWSのベストプラクティス: IAMの資格情報を直接共有してはならない。

選択肢の評価

❌ A. 顧客がアクセスキーをパートナー企業に提供する（悪い方法）

なぜ間違いなのか？
- AWSアクセスキーを外部と共有することは厳禁。
- セキュリティリスク: アクセスの範囲を制御したり、簡単に取り消したりできない。
- AWSのセキュリティベストプラクティスに違反している。

❌ B. 顧客がIAMユーザーを作成し、認証情報を提供する（悪い方法）

なぜ間違いなのか？
- (A)と同様に、IAMユーザーの資格情報を共有するのはセキュリティ上のリスクが高い。
- IAMユーザーは常に有効なため、アクセスを動的に制限することができない。
- セッションの制限ができず、適切なアクセス管理が困難。

✅ C. 顧客がIAMロールを作成し、パートナー企業がそのARNを使用する（部分的に正解）

なぜ部分的に正解なのか？
- IAMロールを使用して必要な権限を付与するのは正しい方法。
- しかし、外部ID（external ID）がないため、セキュリティリスクがある。
- 外部IDを使わないと「混乱した副官（Confused Deputy）攻撃」のリスクが発生する。
  - （攻撃者が別のエンティティをだましてロールを引き受けさせる攻撃）

✅ D. 顧客が外部ID付きのIAMロールを作成する（ベストプラクティス）

なぜ正解なのか？
- IAMロール + 信頼ポリシー:
  - 顧客（org2）が最小限の権限を持つIAMロールを作成。
  - 信頼ポリシーでorg1がこのロールを引き受けることを許可。
- 外部IDでセキュリティ強化:
  - 外部IDを使うことで、Confused Deputy攻撃を防ぐ。
  - AWSのベストプラクティスでは、サードパーティへのアクセス許可時に外部IDの使用を推奨。
- 一時的なアクセス:
  - パートナーはロールを一時的に引き受けるだけなので、アクセスキーのように恒久的な権限が付与されない。
  - セッションが自動的に期限切れになるため、セキュリティリスクが低減する。

最終的な回答

✅ D. 顧客はIAMロールを作成し、必要な権限を付与し、IAMロールの信頼ポリシーに外部IDを追加して、パートナーがアクセスする際に外部IDを使用するようにする。

これは、最小特権の原則を守りつつ、最も安全にクロスアカウントアクセスを提供できる方法である。🚀

問題（和訳）

あるソフトウェア会社が、複数の AWS アカウントとリージョンにまたがるリソースを使用して AWS 上でアプリケーションをホストしている。
このアプリケーションは us-east-1 リージョン の アプリケーション VPC（CIDR: 10.10.0.0/16） 上の Amazon EC2 インスタンス群で稼働している。
別の AWS アカウントには、us-east-2 リージョン にある 共有サービス VPC（CIDR: 10.10.10.0/24） が存在する。
クラウドエンジニアが AWS CloudFormation を使用してアプリケーション VPC と共有サービス VPC をピアリングしようとしたところ、エラーメッセージが表示され、接続に失敗 した。

このエラーの原因となり得る要因はどれか？ （2つ選択）

選択肢（和訳）

A. 2つの VPC の IPv4 CIDR 範囲が重複 している。
B. VPC が 異なるリージョンに存在 している。
C. いずれかまたは両方のアカウントで インターネットゲートウェイにアクセスできない。
D. どちらかの VPC が AWS Resource Access Manager（RAM）を通じて共有されていない。
E. ピア受信者（peer accepter） の IAM ロールに 適切な権限がない。

回答

✅ A. 2つの VPC の IPv4 CIDR 範囲が重複 している。
✅ B. VPC が 異なるリージョンに存在 している。

解説

1. VPC ピアリングの基本要件

AWS では VPC ピアリング を作成する際、以下の要件を満たしている必要がある。

CIDR 範囲が重複していないこと（オーバーラップしているとルーティングができない）
同じリージョンにある場合は、直接ピアリング可能
異なるリージョンの場合は、リージョン間ピアリング（inter-region VPC peering）を使用する必要がある
ピア承認側の IAM 権限が適切であること

A. CIDR 範囲の重複（✅ 正解）

アプリケーション VPC: 10.10.0.0/16
共有サービス VPC: 10.10.10.0/24

10.10.10.0/24 は 10.10.0.0/16 の範囲内に 含まれているため、CIDR 範囲が重複 しており、VPC ピアリングができない。
👉 CIDR が重複しているため、ピアリングは失敗する。

B. VPC が異なるリージョンに存在する（✅ 正解）

アプリケーション VPC: us-east-1
共有サービス VPC: us-east-2

異なるリージョン間で VPC ピアリングを作成する場合は、リージョン間 VPC ピアリングが有効化されている必要がある。
👉 適切に設定されていないと、ピアリングは失敗する可能性がある。

C. インターネットゲートウェイの有無（❌ 不正解）

VPC ピアリングは プライベート接続 であり、インターネットゲートウェイは不要。
👉 VPC ピアリング自体の失敗には関係しないため、誤り。

D. AWS Resource Access Manager（RAM）の共有（❌ 不正解）

AWS Resource Access Manager（RAM）は VPC ピアリングには不要。
RAM は AWS Transit Gateway のようなリソースを共有する際に使用されるが、VPC ピアリングには直接関係しない。
👉 誤り。

E. ピア受信者の IAM 権限の不足（❌ 不正解）

VPC ピアリングを作成する際、ピア受信者のアカウントには適切な IAM 権限が必要。
ただし、「IAM ロールが原因でピアリングが完全に失敗する」というよりも、手動で承認すれば問題は解決できる。
今回のエラーが 「即時にピアリング失敗」となっている ため、IAM の問題ではなく、CIDR やリージョンの制約が主な原因 となる可能性が高い。
👉 誤り。

結論

VPC ピアリングが失敗する原因として、最も可能性が高いのは以下の 2 つ。
✅ A. CIDR 範囲の重複（重複しているとピアリングできない）
✅ B. VPC が異なるリージョンにある（リージョン間ピアリングの適切な設定が必要）

正解: A, B 🎯

問題（和訳）

あるソリューションアーキテクトが、企業の Amazon EC2 インスタンスと Amazon Elastic Block Store (Amazon EBS) ボリュームの利用状況を分析し、リソースが効率的に使用されているかどうかを判断する必要があります。

この企業では、データベースクラスターをホストするために、大容量メモリの EC2 インスタンスをアクティブ/パッシブ構成で実行 しています。データベースを利用するアプリケーションによって EC2 インスタンスの使用率が変動しますが、特定のパターンはまだ特定されていません。

ソリューションアーキテクトは、環境を分析し、分析結果に基づいて適切な対応を行う必要があります。

この要件を最もコスト効率よく満たすソリューションはどれですか？

選択肢（和訳）

A. AWS Systems Manager OpsCenter を使用してダッシュボードを作成する。EC2 インスタンスと EBS ボリュームに関連付けられた Amazon CloudWatch メトリクスの可視化 を構成する。定期的にダッシュボードを確認し、使用パターンを特定する。メトリクスのピークに基づいて EC2 インスタンスのサイズを適正化する。

B. Amazon CloudWatch の詳細モニタリング を EC2 インスタンスと EBS ボリュームに対して有効にする。メトリクスを基にしたダッシュボードを作成し、確認する。使用パターンを特定し、メトリクスのピークに基づいて EC2 インスタンスのサイズを適正化する。

C. 各 EC2 インスタンスに Amazon CloudWatch エージェント をインストールする。AWS Compute Optimizer を有効化し、少なくとも 12 時間稼働させる。 Compute Optimizer の推奨事項を確認し、推奨されるサイズに EC2 インスタンスを適正化する。

D. AWS Enterprise Support プランにサインアップ する。AWS Trusted Advisor を有効化し、12 時間待機する。 Trusted Advisor の推奨事項を確認し、推奨されるサイズに EC2 インスタンスを適正化する。

回答と解説

回答：C. 各 EC2 インスタンスに Amazon CloudWatch エージェントをインストールする。AWS Compute Optimizer を有効化し、少なくとも 12 時間稼働させる。Compute Optimizer の推奨事項を確認し、推奨されるサイズに EC2 インスタンスを適正化する。

解説

なぜ C が最適なのか？

AWS Compute Optimizer は、EC2 インスタンスと EBS ボリュームの使用状況を自動的に分析し、推奨設定を提供するサービスです。
- CPU、メモリ、ディスク I/O などのメトリクスを収集し、最適なインスタンスサイズを提案する。
- 最低 12 時間のデータ収集 で信頼性のある推奨事項を生成できる。
- 手作業なしで最小権限のリソース最適化が可能。
Compute Optimizer は無料で使用できる（デフォルトの範囲内では追加コストなし）。
- CloudWatch の詳細モニタリングを有効化する B に比べてコスト効率が良い。

他の選択肢との比較

選択肢	理由
A. AWS Systems Manager OpsCenter を使用	OpsCenter は主に運用インシデントの管理ツールであり、リソース最適化のための分析には適していない。手作業が多くなり、コスト効率が悪い。
B. CloudWatch 詳細モニタリングを有効化	詳細モニタリングは追加コストが発生する。また、Compute Optimizer のように自動的に推奨事項を生成する機能はないため、手作業が多くなる。
D. AWS Trusted Advisor を使用	Trusted Advisor の高度な最適化機能は AWS Enterprise Support プランが必要（追加コストが大きい）。また、Compute Optimizer に比べて推奨精度が低い。

結論

AWS Compute Optimizer を使用すると、最小限の労力とコストで EC2 インスタンスのサイズを適正化できる。
そのため、C が最もコスト効率の良い選択肢となる。

【完全自分用】 解説べた張り

理由：

他の選択肢が不適切な理由：

誤りの選択肢:

誤りの選択肢:

誤りの選択肢:

回答:

誤りの選択肢:

誤りの選択肢:

回答:

誤りの選択肢:

回答:

誤りの選択肢:

回答:

誤りの選択肢:

回答:

誤りの選択肢:

正解: ✅ A. AWS Secrets Manager + RotationSchedule を使用

誤りの選択肢:

回答：

解説：

誤りの選択肢：

回答：

解説：

誤りの選択肢：

回答：

解説：

誤りの選択肢：

回答：

解説：

誤りの選択肢：

回答：

解説：

誤りの選択肢：

回答：

解説：

誤りの選択肢：

回答：

解説：

誤りの選択肢：

回答：

解説：

1. スケーラブルで高可用性のある Web 層

2. 高可用性のデータベース層

3. Infrastructure as Code（IaC）による自動管理

誤りの選択肢：

選択肢の分析

A.

B.

C.（正解 ✅）

D.

正解:

解説：

1. なぜ AWS Organizations の管理アカウントで StackSet を作成するのか？

2. なぜ「サービス管理の権限（service-managed permissions）」を使用するのか？

3. なぜ「自動デプロイ（automatic deployment）」を有効にするのか？

解説

各選択肢の評価

A. AWS Application Auto Scaling を使用してピーク時にキャパシティを増加。平均負荷に合わせた予約キャパシティ（Reserved Capacity）を購入する。

B. テーブルのキャパシティモードをオンデマンド（On-Demand）に設定する。

C. DynamoDB Accelerator (DAX) を導入し、プロビジョニングされた読み込みキャパシティを削減する。

D. DynamoDB Accelerator (DAX) を導入し、オンデマンドモードにする。

結論（正解）

補足

オンデマンドモードとプロビジョンドモードの使い分け

解説

各選択肢の評価

A. Amazon SQS を使用し、メッセージがあるときに AWS Lambda を起動して処理を行う

B. Amazon MQ を使用し、メッセージを受信したときに EC2 インスタンスを起動して処理を行う

C. Amazon MQ を使用し、AWS Lambda で処理を行う

D. Amazon SQS を使用し、EC2 Auto Scaling グループでスケールアウトして処理を行う

結論（正解）

補足

Amazon SQS と Amazon MQ の使い分け

解説

選択肢の評価

結論（正解）

補足：UltraWarm と Cold Storage の違い

解説

要件整理