Q73 — AWS SAP-C02 第1章

第 73/75 問 | ← 第1章

Q148. ある企業は、AWS Organizations 内の開発者アカウント間で AWS のデータ転送料金およびコンピューティング料金を最適化したいと考えています。開発者は単一の AWS リージョン内で VPC を設定し、Amazon EC2 インスタンスを起動できます。これらの EC2 インスタンスは、毎日約 1 TB のデータを Amazon S3 から取得します。この開発者による活動により、EC2 インスタンスと S3 バケット間の月次データ転送料金および NAT ゲートウェイ処理料金が過剰に発生しており、さらにコンピューティングコストも高くなっています。企業は、開発者が AWS アカウント内にデプロイするすべての EC2 インスタンスおよび VPC インフラストラクチャに対して、承認済みのアーキテクチャパターンを能動的に適用したいと考えています。ただし、この適用によって開発者の作業スピードが損なわれてはなりません。これらの要件を最も費用対効果よく満たすソリューションはどれですか？

• A. 開発者が承認されていない EC2 インスタンスタイプを起動できないよう、SCP（Service Control Policy）を作成します。開発者には、S3 インターフェイスエンドポイントを含む承認済み VPC 構成をデプロイするための AWS CloudFormation テンプレートを提供します。また、開発者の IAM 権限を制限して、CloudFormation を使用した場合のみ VPC リソースの起動を許可します。
• B. AWS Budgets を使用して、開発者アカウント全体の EC2 コンピューティングコストおよび S3 データ転送料金を監視するための日次予測予算を作成します。予測コストが実際の予算の 75% に達した時点で、開発者チームにアラートを送信します。実際の予算コストが 100% に達した場合は、予算アクションとして開発者の EC2 インスタンスおよび VPC インフラストラクチャを終了させます。
• C. S3 ゲートウェイエンドポイントおよび承認済み EC2 インスタンスを含む承認済み VPC 構成をデプロイできる AWS Service Catalog ポートフォリオを作成し、開発者アカウントと共有します。AWS Service Catalog の起動制約を設定して、承認済みの IAM ロールを使用するように構成します。また、開発者の IAM 権限を制限して、AWS Service Catalog へのアクセスのみを許可します。 ✓
• D. 開発者アカウント内の EC2 および VPC リソースのコンプライアンスを監視するための AWS Config ルールを作成・展開します。開発者が承認されていない EC2 インスタンスを起動したり、S3 ゲートウェイエンドポイントなしで VPC を作成した場合、非承認リソースを自動的に終了する修復アクションを実行します。

正解: C. S3 ゲートウェイエンドポイントおよび承認済み EC2 インスタンスを含む承認済み VPC 構成をデプロイできる AWS Service Catalog ポートフォリオを作成し、開発者アカウントと共有します。AWS Service Catalog の起動制約を設定して、承認済みの IAM ロールを使用するように構成します。また、開発者の IAM 権限を制限して、AWS Service Catalog へのアクセスのみを許可します。

解説

最も費用対効果の高いソリューションは、データ転送コスト（特に S3 との通信）とコンピューティングコストの両方を根本的に削減しつつ、開発者の自律性とスピードを損なわないものです。S3 ゲートウェイエンドポイント（オプション C）は、VPC 内の EC2 インスタンスが S3 と通信する際にインターネット経由や NAT ゲートウェイを経由せず、AWS ネットワーク内部で直接接続できるため、データ転送料金および NAT ゲートウェイ料金をゼロに近づけます。また、AWS Service Catalog は、事前に検証・承認されたインフラテンプレート（VPC + S3 ゲートウェイエンドポイント + 適切な EC2 インスタンスタイプなど）を安全かつ一貫性のある形で提供し、開発者はクリック一発でデプロイ可能であり、運用速度を維持できます。一方、オプション A の S3 インターフェイスエンドポイントは、S3 へのアクセスに PrivateLink を使用するもので、S3 ゲートウェイエンドポイントと異なり、追加のコスト（Data Processing Fee）が発生し、かつ VPC ルートテーブルへのルート追加が必要です。オプション B はコスト監視・強制終了であり、根本的なコスト削減ではなく、開発者体験を著しく損ないます。オプション D は修復（リソース削除）という後手の対応であり、コスト発生後に介入するため、予防的・費用対効果的とは言えません。したがって、C が正解です。