【無料】AWS SAP-C02練習問題10問｜図解解説付き｜Udemy講師作成

AWS SAP無料問題集です。正解と解説を確認する際は右側のボタンを押下してください。

問題集の完全版は以下Udemyにて発売しているためお買い求めください。問題集への質問はUdemyのQA機能もしくはUdemyのメッセージにて承ります。Udemyの問題1から10問抜粋しております。

多くの方にご好評いただき、講師評価 4.5/5.0 を獲得できております。ありがとうございます。

特別価格： 通常2,600円 → 1,500円

講師クーポン適用で42%OFF

【図解付き】AWS SAP-C02完全対応 2025年版本番同等演習問題集+詳細解説

この資格を活かしたキャリア情報

SAP資格の取得後にどんなキャリアが開けるか、詳しくはこちら：
→ SAP合格者の転職市場価値と求人傾向

AWS資格全体のキャリア活用法：
→ AWS資格は転職・キャリアアップでどう活きる？資格別市場価値と実体験

問題文：
医療機関向けにオンライン診療予約サービスを提供する企業が、自社データセンターで2階層のWeb予約システムを稼働させています。アプリケーション層は、セッション情報をサーバーのメモリ内に保持するステートフルなアプリケーションを実行する単一サーバーです。アプリケーションは別サーバーのMySQLデータベースに接続しています。提携医療機関の拡大により予約参照の読み取り処理が数倍に増える見込みであるため、同社はアプリケーションとデータベースをAWSへ移行します。移行後の構成にはAmazon Aurora MySQL、Amazon EC2 Auto Scaling、Elastic Load Balancingを使用します。
予約中の利用者がログイン状態を失うことなく、アプリケーション層とデータベース層の両方をスケールできるソリューションはどれでしょうか。

選択肢：
A. データベース層では、Auroraライターインスタンスを対象にAurora Auto Scalingのターゲット追跡ポリシーを構成する。アプリケーション層にはNetwork Load Balancerを置き、ターゲットグループのルーティングアルゴリズムに加重ランダムを指定したうえでスティッキーセッションを有効にする。
B. データベース層では、Auroraライターインスタンスを対象にAurora Auto Scalingのターゲット追跡ポリシーを構成する。アプリケーション層にはApplication Load Balancerを置き、ターゲットグループのルーティングアルゴリズムにラウンドロビンを指定したうえでスティッキーセッションを有効にする。
C. データベース層では、Aurora Replicasを対象にAurora Auto Scalingのターゲット追跡ポリシーを構成する。アプリケーション層にはApplication Load Balancerを置き、ターゲットグループのルーティングアルゴリズムにラウンドロビンを指定してスティッキーセッションを有効にする。
D. データベース層では、Aurora Replicasを対象にAurora Auto Scalingのターゲット追跡ポリシーを構成する。アプリケーション層にはNetwork Load Balancerを置き、ターゲットグループのルーティングアルゴリズムに加重ランダムを指定したうえでスティッキーセッションを有効にする。

正解：C

A. データベース層では、Auroraライターインスタンスを対象にAurora Auto Scalingのターゲット追跡ポリシーを構成する。アプリケーション層にはNetwork Load Balancerを置き、ターゲットグループのルーティングアルゴリズムに加重ランダムを指定したうえでスティッキーセッションを有効にする。

不正解ライターインスタンスを対象としたAurora Auto Scalingは設定できず、読み取り負荷の増加に追従できません。加えてNetwork Load Balancerは加重ランダムを含むルーティングアルゴリズムの選択に対応しておらず、クッキーベースのセッション親和性も提供しないため、アプリケーション層とデータベース層のどちらの要件も満たしません。

B. データベース層では、Auroraライターインスタンスを対象にAurora Auto Scalingのターゲット追跡ポリシーを構成する。アプリケーション層にはApplication Load Balancerを置き、ターゲットグループのルーティングアルゴリズムにラウンドロビンを指定したうえでスティッキーセッションを有効にする。

不正解 Aurora Auto Scalingはリーダーインスタンスの台数を増減する機能であり、ライターインスタンスを対象に台数を増やす設定はできません。Auroraクラスターは書き込みを受け付けるインスタンスを常に1つだけ持つため、この指定ではデータベース層の読み取りスケーリングが行われません。ロードバランサー側の指定は妥当ですが、要件の半分しか満たしません。

C. データベース層では、Aurora Replicasを対象にAurora Auto Scalingのターゲット追跡ポリシーを構成する。アプリケーション層にはApplication Load Balancerを置き、ターゲットグループのルーティングアルゴリズムにラウンドロビンを指定してスティッキーセッションを有効にする。

正解 Aurora Auto Scalingは読み取りレプリカの台数をメトリクスに応じて増減させ、予約参照の読み取り負荷に追従します。Application Load Balancerはラウンドロビンをターゲットグループの既定アルゴリズムとして提供し、クッキーによるスティッキーセッションでログイン中の利用者を同じインスタンスに固定できます。この組み合わせで両層のスケーリングとセッション継続を同時に満たせます。

D. データベース層では、Aurora Replicasを対象にAurora Auto Scalingのターゲット追跡ポリシーを構成する。アプリケーション層にはNetwork Load Balancerを置き、ターゲットグループのルーティングアルゴリズムに加重ランダムを指定したうえでスティッキーセッションを有効にする。

不正解 Aurora Replicasに対するAuto Scalingの部分は妥当ですが、Network Load Balancerのターゲットグループにはルーティングアルゴリズムを選択する属性そのものが存在せず、接続はフローハッシュで振り分けられます。加重ランダムは指定できません。NLBのスティッキーセッションもソースIPベースの維持のみで、HTTPクッキーによるセッション親和性は提供されません。

全体的な説明

問われている要件

予約手続き中の利用者のセッションを維持したままの水平スケーリング
アプリケーション層とデータベース層の両方でのスケーラビリティ
MySQLデータベースのAurora MySQLへの移行対応
EC2 Auto Scalingを活用した動的なアプリケーション層スケーリング
適切なロードバランサーの選択とルーティングアルゴリズム設定

前提知識

Amazon Aurora Auto Scalingの特徴

Aurora Auto Scalingは読み取り専用のAurora Replicasを対象とし、ワークロードに応じてレプリカを自動的に追加・削除します。平均CPU使用率や平均接続数のターゲット追跡ポリシーで制御し、クラスターあたり最大15個のレプリカまで拡張できます。読み取りエンドポイントに新しいレプリカが自動で組み込まれるため、アプリケーション側の接続先変更は不要です。
Aurora Auto Scalingの対象はリーダーインスタンスに限られます。Auroraクラスターは書き込みを受け付けるライターインスタンスを1つだけ持ち、その台数を自動で増やす設定は用意されていません。書き込み能力の拡張はインスタンスクラスの変更やAurora Serverless v2による容量調整といった別の手段で行います。

Load Balancerのルーティング機能について

Application Load Balancer（ALB）はターゲットグループの属性でルーティングアルゴリズムを選択でき、ラウンドロビン（既定）、最小未処理リクエスト、加重ランダムの3種類をサポートします。スティッキーセッションはロードバランサー生成クッキーとアプリケーションクッキーの両方に対応し、同一利用者のリクエストを同じターゲットに固定できます。
Network Load Balancer（NLB）はTCP/UDPレイヤーで動作し、接続をフローハッシュで振り分けます。ターゲットグループにルーティングアルゴリズムを選択する属性はなく、スティッキーセッションの種類もソースIPのみです。超高スループットと低レイテンシに最適化されている一方、HTTPクッキーに依存するセッション親和性は扱えません。

ステートフルアプリケーションの要件について

ステートフルアプリケーションは、ユーザーセッション情報やアプリケーション状態をサーバー側で保持するため、同一ユーザーのリクエストを一貫して同じサーバーインスタンスに送信する必要があります。スティッキーセッション機能により、ロードバランサーがクッキーを使用して特定のクライアントを特定のバックエンドサーバーに関連付けます。これにより、セッション情報の一貫性が保たれ、予約入力の途中でログイン状態が失われる事態を防げます。

解くための考え方

この問題を解く際の核心は、Aurora Auto Scalingの対象範囲と、ロードバランサーごとに設定できる項目の違いを正確に押さえることです。

まず、Aurora Auto Scalingの対象が読み取りレプリカ（Aurora Replicas）に限られる点を確認します。Auroraクラスターでは書き込みを受け付けるインスタンスが常に1つであり、ライターを対象にした台数の自動増減は選べません。予約参照が増えるという要件は、レプリカの追加によって吸収します。

次に、ステートフルアプリケーションの要件を考慮すると、スティッキーセッション機能が必須となります。ユーザーセッション情報がサーバー側で管理されているため、同一ユーザーからのリクエストは一貫して同じアプリケーションインスタンスに送信される必要があります。

Network Load BalancerとApplication Load Balancerの比較では、NLBのターゲットグループにルーティングアルゴリズムの選択肢がなく、フローハッシュで固定される点が決め手になります。ALBはラウンドロビンを含む3種類のアルゴリズムとクッキーベースのスティッキーセッションを設定できるため、HTTPで動作する予約システムの要件に合致します。

アーキテクチャ図

アーキテクチャ図の解説

スケーラブルなアプリケーション層の構成

このアーキテクチャでは、Application Load Balancerがスティッキーセッション機能を使用して、予約手続き中の利用者からのリクエストを一貫して同じEC2インスタンスにルーティングします。ラウンドロビンアルゴリズムにより、新規ユーザーのトラフィックは利用可能なインスタンス間で均等に分散され、EC2 Auto Scaling Groupが需要に応じてインスタンス数を動的に調整します。この設計により、ステートフルアプリケーションのセッション一貫性を維持しながら、水平スケーリングを実現できます。

データベース層の読み取りスケーリング戦略

Aurora MySQLクラスターでは、単一のライターインスタンスがすべての書き込み処理を担当し、複数のAurora Replicasが予約参照などの読み取り処理を分担します。Aurora Auto Scalingが平均CPU使用率や平均接続数のメトリクスを監視し、読み取り負荷に応じてレプリカの数を自動的に調整します。この構成により、読み取り集約的なワークロードに対して効率的なスケーリングを提供し、アプリケーションの応答性能を向上させます。

他のソリューションとの比較

Network Load Balancerとの機能的差異

Network Load Balancerは超高性能なTCPレベルでの負荷分散を提供しますが、ターゲットの選択方法はフローハッシュに固定されており、ルーティングアルゴリズムを指定する属性がありません。加重ランダムや最小未処理リクエストといった選択はALB側の機能です。スティッキーセッションもソースIPベースの維持に限られるため、NATやモバイル回線でIPが変わる利用者のセッションは維持できません。

Application Load Balancerは、HTTP/HTTPSトラフィックに特化した高度な機能を提供し、アプリケーションレベルでのルーティング決定、コンテンツベースルーティング、クッキーによるスティッキーセッション管理を実現します。Web予約システムの要件には、ALBの方が技術的に適合します。

Aurora ライターを対象としたAuto Scalingの制約

一部の選択肢で示されているライターインスタンスへのAurora Auto Scalingは設定できません。Auroraクラスターでは書き込みを受け付けるインスタンスが常に1つに保たれ、書き込みの整合性が保証されます。書き込み能力を伸ばす場合はインスタンスクラスの引き上げやAurora Serverless v2の容量調整を用い、台数の自動増減が使えるのは読み取りレプリカだけです。

実装の考慮事項

セッション管理とスティッキーセッション設定ステートフルアプリケーションの移行時には、セッション情報の永続化戦略を慎重に検討する必要があります。インメモリセッション管理から、外部セッションストア（ElastiCache等）の利用への移行を検討することで、より堅牢なスケーリング対応が可能になります。ALBのスティッキーセッション設定では、クッキーの有効期間を診療予約の入力時間に見合う長さにし、インスタンス障害時のセッション継続性を確保します。

Aurora Auto Scalingのメトリクス調整 Aurora Auto Scalingの設定では、平均CPU使用率や平均接続数のターゲット値を、アプリケーションの実際の負荷パターンに基づいて調整することが重要です。スケールアウト・スケールインのクールダウン期間を適切に設定し、頻繁なスケーリング動作によるコスト増加や性能低下を防止します。また、読み取り専用クエリとトランザクション処理を適切に分離し、レプリカでの読み取り処理を最大化するアプリケーション設計の見直しも推奨されます。

参考資料

問題文：
デジタル出版企業が電子書籍の配信サイトをAWS上で運用しています。サイトはApplication Load Balancer（ALB）の背後にあるAmazon EC2インスタンス上で動作し、書誌情報はAmazon RDS DBインスタンスに保存されています。Amazon CloudFrontはALBを唯一のオリジンとして設定され、表紙画像やスタイルシートなどの静的コンテンツをキャッシュしています。books.example.comを含むすべてのパブリックゾーンはAmazon Route 53でホストされています。
配信基盤のリリース後、ALBが不定期に502ステータスコード（Bad Gateway）を返すようになりました。原因は、アプリケーションがALBへ返す不正な形式のHTTPヘッダーです。エラーが表示された直後に読者が同じページを再読み込みすると、ページは正常に表示されます。
開発チームがアプリケーションの修正を進める間、ソリューションアーキテクトはALBの既定のエラーページではなく、自社ブランドのカスタムエラーページを読者に表示する必要があります。
最小の運用オーバーヘッドでこの要件を満たす手順の組み合わせはどれですか。（2つ選択）

選択肢：
A. Amazon S3バケットを作成する。バケットで静的ウェブサイトホスティングを有効にする。カスタムエラーページのHTMLファイルをバケットにアップロードする。
B. CloudFrontディストリビューションにカスタムエラーレスポンスを追加する。502応答に対して返すエラーページのパスと応答コードを指定する。
C. Amazon Route 53にフェイルオーバールーティングのレコードを作成する。ALBを監視するヘルスチェックを設定する。ヘルスチェックが失敗したときにエラーページをホストするエンドポイントへ切り替えるように設定する。
D. ALBのリスナーにルールを追加する。ターゲットが502を返した場合に一致する条件を設定する。カスタムHTMLを返す固定レスポンスアクションをルールに設定する。
E. Amazon CloudWatch Syntheticsのカナリアを作成する。502応答を検知したときにAWS Lambda関数を呼び出すアラームを設定する。エラーページ用のターゲットグループへALBのリスナールールを切り替えるようにLambda関数を設定する。

正解：A、B

A. Amazon S3バケットを作成する。バケットで静的ウェブサイトホスティングを有効にする。カスタムエラーページのHTMLファイルをバケットにアップロードする。

正解 Amazon S3の静的ウェブサイトホスティングは、HTMLファイルを配置するだけでエラーページを公開でき、サーバーの構築も保守も不要です。CloudFrontのカスタムエラーレスポンスから参照するエラーページの置き場所として、可用性、コスト、設定の簡単さのいずれの面でも要件に合致します。文面の更新はバケット上のHTMLを差し替えるだけで完了するため、運用の負担も小さく済みます。

B. CloudFrontディストリビューションにカスタムエラーレスポンスを追加する。502応答に対して返すエラーページのパスと応答コードを指定する。

正解 CloudFrontのカスタムエラーレスポンスは、オリジンが返したHTTPステータスコードごとに、代わりに返すページのパスと応答コードを指定できる標準機能です。502を返したリクエストだけがカスタムエラーページに置き換わり、正常なリクエストには影響しません。ディストリビューションの設定変更だけで完結するため、運用オーバーヘッドが最も小さくなります。

C. Amazon Route 53にフェイルオーバールーティングのレコードを作成する。ALBを監視するヘルスチェックを設定する。ヘルスチェックが失敗したときにエラーページをホストするエンドポイントへ切り替えるように設定する。

不正解 Route 53のヘルスチェックはエンドポイント全体の稼働状態を判定する仕組みです。散発的な502が発生していてもALBへのヘルスチェックは成功するため切り替えは発動しません。仮に発動した場合もDNSのTTLが切れるまで反映されず、切り替え後はサイト全体がエラーページに置き換わるため、要件に適していません。

D. ALBのリスナーにルールを追加する。ターゲットが502を返した場合に一致する条件を設定する。カスタムHTMLを返す固定レスポンスアクションをルールに設定する。

不正解 ALBのリスナールールが評価できる条件は、ホストヘッダー、パスパターン、HTTPメソッド、送信元IP、HTTPヘッダー、クエリ文字列といったリクエスト側の属性に限られます。ターゲットが返した応答のステータスコードを条件にルールを分岐させることはできないため、502が返ったリクエストだけに固定レスポンスを返す設定は作成できません。

E. Amazon CloudWatch Syntheticsのカナリアを作成する。502応答を検知したときにAWS Lambda関数を呼び出すアラームを設定する。エラーページ用のターゲットグループへALBのリスナールールを切り替えるようにLambda関数を設定する。

不正解 CloudWatch Syntheticsのカナリアは一定間隔で合成監視を行う仕組みであり、再読み込みすれば成功する散発的な502をリクエスト単位で捉えることはできません。リスナールールを切り替える方式では、エラーに遭遇していない読者を含む全リクエストがエラーページ側へ流れます。Lambda関数の開発と保守という運用オーバーヘッドも増えます。

全体的な説明

問われている要件

ALBが502を返したときの自社ブランドのカスタムエラーページ表示
最小限の運用オーバーヘッドでの実装
既存のCloudFront配信構成を活用した解決策
アプリケーション修正が完了するまでの一時的な対応
エラーが発生した特定のリクエストのみを対象とした制御

前提知識

CloudFrontカスタムエラーレスポンスについて

CloudFrontは、オリジンから返された4xx、5xx系のHTTPステータスコードを検知すると、設定されたカスタムエラーページを代わりに返す機能を提供します。
設定では、特定のエラーコード（例：502）に対して、代替のHTTPステータスコード（例：200）とエラーページのパスを指定できます。
エラーページはオリジンとして登録した場所から取得されるため、専用のキャッシュビヘイビアを用意してエラーページの置き場所を指定します。
エラーキャッシュ最小TTLを設定でき、エラーが多発した場合のオリジンへのリクエスト数を抑えられます。

Amazon S3静的ウェブサイトホスティングについて

S3の静的ウェブサイトホスティング機能は、HTMLファイル、CSS、JavaScript、画像などの静的コンテンツを高い可用性で配信するマネージドサービスです。
インデックスドキュメントとエラードキュメントを指定し、アクセス許可を設定するだけで運用を開始できます。
99.999999999%（11 9’s）の耐久性を提供し、データは自動的に複数のアベイラビリティーゾーンへ冗長化されます。
コスト効率が高く、使用した分のみの課金で、静的コンテンツの配信に最適化されています。

ALBのリスナールールが評価する条件について

リスナールールの条件に指定できるのは、ホストヘッダー、パスパターン、HTTPリクエストメソッド、送信元IP、HTTPヘッダー、クエリ文字列です。いずれもクライアントから届いたリクエストの属性です。
ルールの評価はリクエストがターゲットへ転送される前に行われるため、ターゲットが返した応答のステータスコードでアクションを分岐させることはできません。
固定レスポンスアクションは、リクエスト条件に一致した時点で定型の応答を返す用途に使うものです。

解くための考え方

この問題の核心は「最小の運用オーバーヘッド」という要件です。ALBが不定期に502を返し、再読み込みすると成功するという状況から、これは一部のリクエストにだけ現れる散発的な事象であることが分かります。

つまり、サービス全体を切り替える仕組みではなく、エラーが返った個々のリクエストだけをカスタムエラーページに置き換える仕組みが必要です。全体を切り替える方式は、正常に処理できているリクエストまで巻き込んでしまいます。

CloudFrontのカスタムエラーレスポンスは、まさにこの用途のための標準機能です。オリジンが返した502を検知して、あらかじめ用意したページを代わりに返すため、設定だけで要件を満たせます。

エラーページの配置先としては、可用性、コスト、設定の簡単さのすべてを満たすAmazon S3が適しています。静的ウェブサイトホスティングを有効にしてHTMLファイルをアップロードすれば、そのまま配信を開始できます。

監視サービスからの自動化やDNSの切り替えを伴う選択肢は、検知の粒度が粗いうえに運用オーバーヘッドが大きく、この事象への対応としては過剰です。

アーキテクチャ図

アーキテクチャ図の解説

通常時のトラフィックフローと502エラー発生メカニズム

通常時、読者のリクエストはRoute 53でbooks.example.comが解決され、CloudFrontを経由してALBに転送されます。ALBは複数のEC2インスタンスに負荷を分散し、EC2インスタンスがRDSから書誌データを取得してレスポンスを生成します。リリース後は不正な形式のHTTPヘッダーが原因で502 Bad Gatewayが不定期に発生しますが、このエラーは散発的で、再読み込みすると成功する性質があります。

CloudFrontカスタムエラーレスポンスによる自動エラー処理

CloudFrontにカスタムエラーレスポンスを追加することで、ALBからの502を検知し、あらかじめ用意したページで置き換えられます。502が返ると、CloudFrontは設定に従ってS3にホストされたnotice.htmlを取得し、HTTPステータスコード200で読者に返却します。これにより、読者は技術的なエラーメッセージではなく、自社ブランドのエラーページを見ることになります。

運用オーバーヘッドを最小化する設計思想

この構成では、既存のCloudFront配信インフラを活用し、新たに追加するのはS3バケットとHTMLファイルだけです。Lambda関数や追加の監視は不要で、CloudFrontの標準機能だけでエラー処理が完結します。S3は可用性が高くコスト効率も良いため、静的ファイルの置き場所として適しています。この方式により、アプリケーションの修正を並行して進めながら、読者の体験を即座に改善できます。

他のソリューションとの比較

ALBのリスナールールで固定レスポンスを返すアプローチは、そもそも設定として作れません。リスナールールはリクエストがターゲットへ転送される前に評価されるため、ターゲットが返した502という結果を条件にできないからです。固定レスポンスは、特定のパスへのアクセスに定型の応答を返すといった用途のものです。

CloudWatch Syntheticsのカナリアで検知してリスナールールを切り替えるアプローチは、検知の粒度が合いません。カナリアは決められた間隔で実行される合成監視であり、散発的な502を取りこぼします。切り替えが起これば正常に処理できていたリクエストまでエラーページに置き換わり、Lambda関数の保守も必要になります。

Route 53のヘルスチェックとフェイルオーバーによるアプローチは、エンドポイント全体の稼働状態しか見ていません。散発的な502ではALBへのヘルスチェックは成功し続けるため切り替えは起きず、切り替わった場合はサイト全体がエラーページになり、DNSのTTLが切れるまで元に戻せません。

CloudFrontのカスタムエラーレスポンスは、エラーが返ったリクエストだけを対象とし、他のリクエストには影響しません。設定も短時間で完了するため、事象の性質と運用オーバーヘッドの要件の双方に適しています。

実装の考慮事項

実装時には、静的ウェブサイトホスティングを有効にしたS3バケットのウェブサイトエンドポイントをCloudFrontの2つ目のオリジンとして登録し、エラーページのパス（例として/errors/*）に対するキャッシュビヘイビアを作成しておく必要があります。S3のウェブサイトエンドポイントはHTTPSに対応していないため、このオリジンのプロトコルポリシーはHTTPのみに設定します。バケットポリシーではエラーページの読み取りのみを許可し、書き込み権限は配信担当者に限定します。

CloudFrontのカスタムエラーレスポンスでは、エラーキャッシュ最小TTLも設定できます。502が多発する時間帯にはエラーページをある程度キャッシュすることでS3へのリクエストを抑えられますが、修正の反映後に古いページが表示され続けないよう、TTLは短めに設定します。

エラーページの内容は、読者に状況を伝えたうえで、再読み込みへの導線や問い合わせ先などの次の行動を示す構成にします。アクセシビリティに配慮した設計にしておくことで、エラー発生時の離脱を抑えられます。

参考資料

問題文：
オンライン語学学習サービスを運営する企業では、受講者向けの学習サイトがAuto Scalingグループ内のAmazon EC2インスタンス群で動作しており、その前段にApplication Load Balancerを配置しています。レッスン教材はテキストも画像もすべてAmazon EFSファイルシステム上に置かれ、各インスタンスからマウントして読み出されています。
四半期前に、講師がレッスンへ解説動画を添付できる機能をリリースしたところ、アクセス数はそれまでの10倍に伸びました。その一方で、受講が集中する平日夜のあいだ、海外在住の受講者から動画の再生が頻繁に止まる、ページが応答せず接続が切れるといった申告が相次いでいます。
この状況を改善するうえで、最もコスト効率が高くスケーラブルな構成はどれですか。

選択肢：
A. 動画をEFSからAmazon S3に移行し、そのS3バケットをオリジンとするAmazon CloudFrontディストリビューションを設定する。
B. サイトのすべてのコンテンツを対象にAmazon CloudFrontディストリビューションを設定し、オリジンをApplication Load Balancerに向ける。
C. 各EC2インスタンスのAmazon EBSボリュームにコンテンツを配置するようにサイトを更新する。インスタンス起動時にAmazon S3からボリュームへコピーし、シャットダウン時にS3へ書き戻す。
D. Amazon EFSのスループットモードをプロビジョニングに変更する。ピーク時間帯に必要な帯域を見積もり、その値をファイルシステムに割り当てる。

正解：A

A. 動画をEFSからAmazon S3に移行し、そのS3バケットをオリジンとするAmazon CloudFrontディストリビューションを設定する。

正解動画は世界中のエッジロケーションにキャッシュされ、受講者に最も近い拠点から配信されるため、バッファリングとタイムアウトが解消されます。S3は大容量の静的オブジェクトに対してEFSより大幅に安価で、保存量に応じた従量課金のみで済みます。静的コンテンツである動画と、EC2が生成する動的なレッスンページを分離することで、それぞれに適したインフラへ負荷を振り分けられます。

B. サイトのすべてのコンテンツを対象にAmazon CloudFrontディストリビューションを設定し、オリジンをApplication Load Balancerに向ける。

不正解エッジキャッシュにより配信性能は改善しますが、動画がEFSに残るためストレージ費用は高いままで、コスト効率の要件を満たしません。オリジンフェッチのたびにEC2インスタンスがEFSから動画を読み出して転送するため、Webフリートの負荷とEFSのスループット消費も続きます。受講者ごとに内容が変わる動的なページまでCDN経由にすると、キャッシュされないリクエストの転送料が上乗せされます。

C. 各EC2インスタンスのAmazon EBSボリュームにコンテンツを配置するようにサイトを更新する。インスタンス起動時にAmazon S3からボリュームへコピーし、シャットダウン時にS3へ書き戻す。

不正解 Auto Scalingでインスタンスが追加されるたびに動画一式をコピーする必要があり、起動が遅くなるうえデータ転送量も増えます。複数インスタンスが同じS3のオブジェクトへ書き戻すため、コンテンツの版がインスタンス間で食い違います。配信は引き続き各インスタンスのネットワーク帯域に依存し、エッジキャッシュがないため遠隔地の受講者の再生品質は改善されません。

D. Amazon EFSのスループットモードをプロビジョニングに変更する。ピーク時間帯に必要な帯域を見積もり、その値をファイルシステムに割り当てる。

不正解プロビジョニングスループットは、ストレージ量に応じたベースラインを超えて割り当てた分が追加で課金されます。10倍のトラフィックに合わせて帯域を確保するとストレージ費用が大きく膨らみ、コスト効率の要件を満たしません。また動画の配信経路はEC2インスタンス経由のまま変わらないため、受講者との地理的距離に起因するレイテンシーとオリジン側の帯域の逼迫は解消されません。

全体的な説明

問われている要件

解説動画の追加による10倍のトラフィック増加への対応
夜間ピーク時のバッファリングとタイムアウト問題の解決
コスト効率性とスケーラビリティの両立
既存のAuto Scalingアーキテクチャとの統合
世界各地の受講者に対する安定した再生品質の確保

前提知識

CloudFrontとコンテンツ配信について

Amazon CloudFrontは世界中に分散されたエッジロケーションを持つコンテンツ配信ネットワーク（CDN）サービスです。静的コンテンツをユーザーに最も近いエッジロケーションにキャッシュすることで、レイテンシを大幅に削減できます。
動画コンテンツは大容量で帯域幅を多く消費するため、CDNによるエッジキャッシュが特に効果的です。オリジンサーバーへの負荷を軽減し、エンドユーザーエクスペリエンスを向上させます。
CloudFrontは様々なオリジンタイプ（S3、ALB、カスタムオリジン）をサポートし、コンテンツタイプに応じた最適な配信戦略を実装できます。

Amazon S3による静的コンテンツ保存について

S3は11 9’s（99.999999999%）の耐久性を提供し、静的コンテンツの保存に最適化されています。動画ファイルのような大容量コンテンツに対してコスト効率的なストレージを提供します。
複数のストレージクラス（Standard、IA、Glacier等）により、アクセス頻度に応じたコスト最適化が可能です。
CloudFrontとの統合により、オリジンフェッチの最適化とキャッシュ効率の向上が実現されます。

Amazon EFSのスループットモードとコストについて

EFSは共有ファイルシステムとして設計されており、複数のEC2インスタンスから同時にマウント可能です。アプリケーションファイルや設定ファイルの共有には適していますが、大容量の静的コンテンツの配信基盤には向きません。
スループットモードにはElastic、Provisioned、Burstingがあります。Provisionedを選ぶと、ストレージ量に応じたベースラインを超えて割り当てた分のスループットが追加課金の対象になります。
スループットを引き上げてもファイルシステムはリージョン内に閉じたリソースであり、遠隔地の利用者との往復遅延を短縮する仕組みは持ちません。動画配信のようなワークロードでは、S3とCloudFrontの組み合わせが適切なソリューションとなります。

解くための考え方

この問題の核心は、解説動画の追加による急激なトラフィック増加とそれに伴うパフォーマンス問題への対処です。動画コンテンツは大容量で帯域幅を多く消費するため、従来のWebサーバーベースの配信では限界があります。

問題分析から、現在の構成（EFS + EC2 + ALB）は動的なWebコンテンツには適していますが、静的な大容量動画コンテンツの配信には最適化されていないことが分かります。バッファリングやタイムアウト問題は、主にオリジン側のネットワーク帯域の制約と、受講者に近い位置でのキャッシュが存在しないことによるものです。

解決策として、静的コンテンツ（動画）と動的コンテンツ（レッスンページ）を分離し、それぞれに最適化されたインフラを使用するアプローチが最も効果的です。動画をS3に移行してCloudFrontで配信することで、世界中のエッジロケーションからの高速配信が可能になり、オリジンサーバーの負荷も軽減されます。

コスト効率性の観点では、S3はEFSよりも大幅に安価で、CloudFrontの従量課金モデルにより必要な分だけの費用で済みます。ストレージ側の帯域だけを増やす方法や、すべてのコンテンツをCDN経由にする方法は、動画をEFSに残したまま費用を積み増すことになるため最適ではありません。

アーキテクチャ図

アーキテクチャ図の解説

静的・動的コンテンツの最適化分離

このアーキテクチャでは、動画コンテンツ（静的）とレッスンページ（動的）を異なるインフラで処理することで、それぞれに最適化された配信を実現しています。受講者からの動画リクエストはCloudFrontが処理してS3から配信し、ページリクエストは従来通りALBがAuto ScalingされたEC2インスタンス群に振り分けます。EC2インスタンスは引き続きレッスン教材をEFSから読み出しますが、大容量動画による負荷は既存のWebアプリケーションインフラから切り離されます。

グローバルエッジキャッシュによる性能向上

CloudFrontの世界中に分散されたエッジロケーションにより、動画コンテンツは受講者に最も近い場所から配信されます。初回アクセス時にS3からオリジンフェッチされた動画は、その後のアクセスではエッジキャッシュから高速配信されるため、バッファリングやタイムアウト問題が大幅に改善されます。また、オリジンサーバーへの負荷も軽減され、EC2インスタンスは動的コンテンツ処理に専念できます。

他のソリューションとの比較

EFSのスループットモードを変更するアプローチでは、ベースラインを超えた分が追加課金されるため費用が大きく増えます。配信経路はEC2インスタンス経由のままで、受講者との距離に起因するレイテンシーも改善されません。

EBSボリュームにコンテンツを配置してS3と同期するアプローチは、新しいインスタンスの起動のたびに動画一式のコピーが発生します。複数インスタンスからの書き戻しでコンテンツの版が食い違い、エッジキャッシュがないため地理的分散配信の課題も残ります。

全サイトコンテンツをCloudFrontで配信するアプローチは性能向上をもたらしますが、動画を高コストなEFSに保存し続けることでコスト効率性が損なわれます。オリジンフェッチのたびにEC2インスタンスとEFSに負荷がかかる点も変わりません。

実装の考慮事項

動画コンテンツのS3移行では、既存のEFSからS3への一括移行スクリプトを作成し、ダウンタイムを最小限に抑えた移行戦略が必要です。また、Webアプリケーションの動画リンクをCloudFrontのURLに更新する必要があります。

CloudFrontの設定では、動画コンテンツに適したキャッシュポリシー（長期キャッシュ）を適用し、Origin Access Controlを使ってS3バケットへの直接アクセスを遮断します。有償教材を保護する場合は署名付きURLを併用します。S3では、公開から時間が経った動画を安価なストレージクラスへ移すことで、さらなるコスト最適化が可能です。

監視面では、CloudWatchを使用してCloudFrontのキャッシュヒット率、S3のリクエスト数、エラー率を監視し、パフォーマンスの継続的な最適化を行います。また、コスト監視により、予想外の費用増加を早期に検知する体制も重要です。

参考資料

問題文：
物流テック企業は、加盟店向けに配送追跡APIを公開しています。APIはAmazon API GatewayのREST APIとして構成され、背後ではAWS Lambda関数がAmazon DynamoDBテーブルを更新します。加盟店にはそれぞれAPIキーが発行されており、キーによって呼び出し元を識別できます。
最近、配送ステータスを登録するPOST呼び出しでエラーの返却が目立つようになりました。ソリューションアーキテクトが呼び出し状況を調べたところ、POSTの大半は1社の加盟店が運用する配車管理システムから短時間に送られており、その負荷がシステムリソースを圧迫して他の加盟店への応答まで遅らせていることが分かりました。このAPIは業務上の重要度が高くなく、加盟店側も失敗した呼び出しを再試行できます。ただし、エラーが多くの加盟店の画面に表示されるため、APIの評判が下がっています。
顧客体験を改善し、他の加盟店への影響を最小限にとどめるために、ソリューションアーキテクトは何を推奨すべきでしょうか？

選択肢：
A. API Gatewayの使用量プランでAPIキーごとにレート制限を設定してスロットリングを適用する。上限を超えた加盟店にはコード429（Too Many Requests）応答を返却する
B. トラフィックの急激な増加時に必要なリソースを提供するために、Lambda関数レベルでプロビジョニングされた同時実行数を設定する
C. API Gatewayのゲートウェイ応答をカスタマイズし、エラー時に再試行の目安を含む説明的な本文を返すよう設定する。加盟店側には指数バックオフとジッターを備えたリトライ処理の実装を依頼する
D. 本番ステージでAPIキャッシュを有効にし、10分間のロードテストで応答性の改善を測定する。ワークロードに見合うキャッシュ容量とTTLへ調整する

正解：A

A. API Gatewayの使用量プランでAPIキーごとにレート制限を設定してスロットリングを適用する。上限を超えた加盟店にはコード429（Too Many Requests）応答を返却する

正解使用量プランによるAPIスロットリングは、特定のAPIキーに対してリクエスト率制限を設定できるため、問題の根本原因に直接対処します。大量リクエストを送信する加盟店のみに制限をかけ、他の加盟店への影響を最小化できます。HTTP 429（Too Many Requests）エラーの適切な処理により、制御された形でのエラーハンドリングが可能となり、顧客体験と API評判が向上します。

B. トラフィックの急激な増加時に必要なリソースを提供するために、Lambda関数レベルでプロビジョニングされた同時実行数を設定する

不正解プロビジョニングされた同時実行数は実行環境を事前に初期化してコールドスタートの遅延を抑える機能で、送信元ごとの流量を制御する仕組みではありません。問題は全体的なキャパシティ不足ではなく特定加盟店の過剰リクエストです。事前初期化された実行環境も過剰リクエストに消費されるため、他の加盟店のリクエストが待たされる状態は変わりません。

C. API Gatewayのゲートウェイ応答をカスタマイズし、エラー時に再試行の目安を含む説明的な本文を返すよう設定する。加盟店側には指数バックオフとジッターを備えたリトライ処理の実装を依頼する

不正解ゲートウェイ応答のカスタマイズはエラーの見え方を整えるだけで、送信されてくるリクエスト数は変わりません。指数バックオフは、レート制限で流量を抑えたうえで復旧を助ける手段としては有効ですが、制限の仕組みがないこの構成では単独では流量が減らず、根本原因である特定加盟店からの大量リクエストを解決できません。エラー自体の発生は継続するため、API評判の問題は解決されません。

D. 本番ステージでAPIキャッシュを有効にし、10分間のロードテストで応答性の改善を測定する。ワークロードに見合うキャッシュ容量とTTLへ調整する

不正解ステージでキャッシュを有効にしても、既定でキャッシュされるのはGETメソッドのみで、ステータス更新のPOSTのような書き込みメソッドは対象外です。メソッド設定を上書きしてキャッシュを有効にしても、加盟店が送信するリクエスト数そのものは減りません。ロードテストも特定の加盟店からの大量リクエストという根本原因には対処していません。

全体的な説明

問われている要件

特定加盟店からの大量POSTリクエストによるエラー増加の解決
API評判の改善とエラー表示の削減
正常な加盟店への影響最小化
非重要APIでのリトライ許容環境での最適化
顧客体験の向上

前提知識

API管理とスロットリングの特徴

API Gateway 使用量プラン：特定のAPIキーまたはAPIキーグループに対してリクエスト率制限とクォータ制限を設定。クライアント単位での細かな制御が可能で、burst制限とsteady-state制限の両方を設定できます
API Gateway スロットリング：デフォルトではアカウントおよびステージ単位のスロットリングが適用されるが、使用量プランにより個別クライアント制御が可能。HTTP 429ステータスコードによる標準的な制限通知を提供します

エラーハンドリングと復旧戦略について

ゲートウェイ応答：API Gatewayが返すエラー応答の本文・ヘッダー・ステータスコードをカスタマイズする機能。エラーの伝え方は変えられるが、流量そのものは制御できない
指数バックオフ：AWS SDKでデフォルト実装される再試行戦略。固定間隔ではなく指数的に増加する待機時間でリトライを実行。Jitterによる不規則な変動で thundering herd問題を回避
HTTP 429 Too Many Requests：標準的なHTTPステータスコード。クライアントが送信できるリクエスト数を超えたことを示し、制限を受けたことをクライアント側で判別できる

リソース最適化手法について

プロビジョニングされた同時実行数：Lambda関数の実行環境を事前に初期化してコールドスタートを抑制。応答遅延は改善するが、送信元ごとの流量制御はできない
API Gateway キャッシュ：ステージでキャッシュを有効にしても、既定でキャッシュされるのはGETメソッドのみ。メソッド設定の上書きで他のメソッドも対象にできるが、書き込み処理での利用は推奨されない

解くための考え方

この問題の核心は「特定加盟店からの過剰リクエストによるシステム全体への悪影響」です。問題文から「大部分のPOSTリクエストが1社から発信」「少数の加盟店から大量のリクエスト」という情報が重要な手がかりとなります。

まず、根本原因の特定が必要です。全体的なキャパシティ不足であれば全加盟店が影響を受けるはずですが、特定加盟店に起因する問題であることが明確です。次に、解決策の評価では「問題の根本原因への対処」と「他の加盟店への影響最小化」の両方を考慮する必要があります。

使用量プランによるスロットリングは、APIキー単位での制御により問題のある加盟店のみに制限をかけ、正常な加盟店は引き続きサービスを利用可能です。また、HTTP 429エラーの適切な処理により、制御されたエラーハンドリングが実現され、顧客体験と API評判の改善につながります。

アーキテクチャ図

アーキテクチャ図の解説

階層別制御アーキテクチャ

このアーキテクチャは、API Gateway を中心とした多層制御構造で構成されています。加盟店層では正常な加盟店と過剰送信を行う加盟店が明確に区別され、それぞれ異なる使用量プランが適用されます。API Gateway制御層では、認証されたAPIキーに基づいて加盟店を識別し、適切な使用量プランを適用することで、きめ細かなレート制限が実現されます。正常な加盟店用の標準使用量プランでは通常のレート制限が設定され、過剰送信を行う加盟店用の抑制使用量プランでは厳格なレート制限が適用されます。

スロットリング制御とエラーハンドリングフロー

過剰送信を行う加盟店が大量リクエストを送信した場合、抑制使用量プランによりHTTP 429エラーが生成され、専用のエラーハンドリング機能で適切に処理されます。このエラーハンドリングには、429を受け取った時点での送信抑制と、指数バックオフによる制御されたリトライが含まれます。一方、正常な加盟店のリクエストは通常のフローでLambda関数に転送され、DynamoDBでのデータ処理が継続されます。この仕組みにより、特定加盟店の問題が全体システムに与える影響を最小化し、他の加盟店のサービス利用を保護できます。

他のソリューションとの比較

ゲートウェイ応答のカスタマイズとクライアント側リトライの組み合わせと比較すると、スロットリングアプローチは予防的制御という点で優れています。エラー表示の改善は対症療法であり、流量を抑える仕組みを伴わないリトライは追加リクエストを生むだけです。リトライはスロットリングと組み合わせて初めて、制限後の復旧を助ける手段として機能します。

APIキャッシュ手法との比較では、ステータス更新という書き込み操作の特性上、キャッシュは適用対象になりません。キャッシュはGETメソッドの応答をバックエンドに代わって返す機能であり、送信されるリクエスト数を減らす手段にはなりません。

プロビジョニングされた同時実行数は、コールドスタートによる遅延には有効ですが、特定加盟店による過剰利用という問題の性質上、確保した実行環境も過剰リクエストに消費されてしまい、不適切です。使用量プランによるスロットリングは、問題の根本原因に直接対処し、公平なリソース配分を実現します。

実装の考慮事項

使用量プランの実装では、適切なレート制限値の設定が重要です。通常のビジネス要件を満たしつつ、過剰リクエストを防ぐバランスの取れた制限値を設定する必要があります。また、burst制限とsteady-state制限の両方を適切に設定し、正常な利用パターンを阻害しないよう注意が必要です。

加盟店側でのHTTP 429エラーハンドリングの実装も重要な考慮事項です。適切なリトライロジックとExponential Backoffの実装により、制限後の復旧を効率的に行う必要があります。429を受け取った時点で送信を抑制する実装を各加盟店に周知することで、システム全体の安定性を維持できます。

監視と運用面では、CloudWatch メトリクスを活用したスロットリング状況の継続的な監視と、必要に応じた使用量プラン設定の調整が重要です。

参考資料

問題文：
産業機器メーカーは、世界各地に出荷した設備から届く稼働データを複数のAmazon DynamoDBテーブルに蓄積しています。保守を委託しているパートナー企業がこの稼働データをHTTPSのシンプルなAPIで参照できるようにしたいと考えており、ソリューションアーキテクトはサーバーを一切運用しない構成でAPIを公開するよう求められました。
APIへのリクエスト量は時間帯によって大きく変動するため、負荷に合わせて自動的にスケールする必要があります。
これらの要件を満たすソリューションはどれですか？（2つ選択してください。）

選択肢：
A. Amazon API GatewayでREST APIを構築し、テーブルの項目を読み取るAWS統合タイプの直接統合を設定する
B. Amazon CloudFrontでディストリビューションを構築し、テーブルを読み取って結果を返すCloudFront Functionsをビューワーリクエストイベントに関連付ける
C. Application Load Balancerを構築し、テーブルを読み取って結果を返すAWS Lambda関数をターゲットグループに登録する
D. Amazon API GatewayでHTTP APIを構築し、テーブルを読み取って結果を返すAWS Lambda関数へのLambda統合を設定する
E. Amazon API GatewayでHTTP APIを構築し、テーブルの項目を読み取るAWS統合タイプの直接統合を設定する

正解：A、D

A. Amazon API GatewayでREST APIを構築し、テーブルの項目を読み取るAWS統合タイプの直接統合を設定する

正解 API GatewayのREST APIはAWS統合タイプをサポートし、DynamoDBのAPIを直接呼び出せます。VTL（Velocity Template Language）マッピングテンプレートでリクエストとレスポンスを変換するため、Lambda関数を挟まずにGetItemやQueryを実行できます。構成要素はマネージドサービスのみで、HTTPSエンドポイントとして公開され、需要に応じて自動的にスケールします。

B. Amazon CloudFrontでディストリビューションを構築し、テーブルを読み取って結果を返すCloudFront Functionsをビューワーリクエストイベントに関連付ける

不正解 CloudFront Functionsの実行環境にはネットワークアクセスとファイルシステムアクセスがなく、AWS SDKも利用できません。DynamoDBのテーブルを読み取る処理をエッジ関数の中で実行できないため、この構成は成立しません。エッジで外部サービスの呼び出しが必要な場合はLambda@Edgeを使用します。

C. Application Load Balancerを構築し、テーブルを読み取って結果を返すAWS Lambda関数をターゲットグループに登録する

不正解 Application Load BalancerはLambda関数をターゲットとして登録できますが、サーバーレスアーキテクチャという要件を満たしません。Application Load Balancerはサブネットを指定してVPC内に配置するリソースで、トラフィックの有無にかかわらず時間単位の課金が発生し、ネットワーク設計の管理も必要になります。

D. Amazon API GatewayでHTTP APIを構築し、テーブルを読み取って結果を返すAWS Lambda関数へのLambda統合を設定する

正解 HTTP APIはLambda統合をサポートします。Lambda関数の中でAWS SDKを使ってDynamoDBのテーブルを読み取り、必要な整形を行って返せます。HTTP APIの低コストかつ低レイテンシという特性とLambdaの柔軟性を組み合わせた構成で、全体がマネージドサービスのみで構成され自動的にスケールします。

E. Amazon API GatewayでHTTP APIを構築し、テーブルの項目を読み取るAWS統合タイプの直接統合を設定する

不正解 HTTP APIのAWSサービス統合は、EventBridge、SQS、AppConfig、Kinesis Data Streams、Step Functionsのサブタイプに限定されており、DynamoDBは含まれていません。HTTP APIからDynamoDBのテーブルを直接呼び出す統合は設定できないため、この構成は成立しません。

全体的な説明

問われている要件

DynamoDBに保存した設備稼働データのパブリックなAPI公開
HTTPS対応のシンプルなAPI設計
完全なサーバーレスアーキテクチャの採用
需要に応じた自動スケーリング機能
複数の有効なソリューション選択（2つ選択）

前提知識

API Gateway統合タイプの特徴について

REST API：AWSサービス統合、Lambda統合、HTTPプロキシ統合をサポート。VTLマッピングテンプレート、リクエスト検証、APIキー、使用量プラン、キャッシングなどの高度な機能を提供。DynamoDB、S3、SQSなどのAWSサービスのAPIを直接呼び出せる
HTTP API：Lambda統合とHTTPバックエンド統合に加え、EventBridge、SQS、AppConfig、Kinesis Data Streams、Step Functionsに対するAWSサービス統合サブタイプをサポート。DynamoDBはサブタイプに含まれず、Lambda関数を介したアクセスが必要

DynamoDB統合パターンについて

直接統合：API GatewayからDynamoDBのAPIを直接呼び出す。VTLテンプレートでリクエスト変換とレスポンス整形を実行。コールドスタートがなく、低レイテンシを実現
Lambda統合：Lambda関数内でAWS SDKを使用。複雑なビジネスロジック、データ変換、バリデーション、エラーハンドリングの実装が可能。柔軟性が高いが、Lambda実行時間とコールドスタートを考慮

エッジ関数とロードバランサーの制約について

CloudFront Functions：ヘッダー操作やURL書き換えなどに特化した軽量な関数。ネットワークアクセスとファイルシステムアクセスを持たず、外部サービスの呼び出しはできない
Application Load Balancer：Lambda関数をターゲットにできるが、サブネットを指定してVPC内に配置するリソースであり、時間単位の課金とネットワーク設計の管理が発生する

解くための考え方

この問題の核心は「API Gateway統合タイプの理解」と「サーバーレス要件の厳格な適用」です。まず、「2つ選択」という指示から、異なるアプローチでの有効なソリューションを特定する必要があります。

API Gateway統合の技術的制約を正確に理解することが重要です。REST APIはAWS統合タイプでDynamoDBのAPIを直接呼び出せますが、HTTP APIのAWSサービス統合は限られたサブタイプだけで構成されており、DynamoDBはそこに含まれていません。HTTP APIはコスト効率と低レイテンシに最適化されており、機能セットは意図的に絞り込まれています。

エッジでの処理を持ち出す構成も評価対象です。CloudFront Functionsは実行環境そのものがネットワーク呼び出しを許可していないため、DynamoDBからデータを取得する用途には使えません。エッジで外部呼び出しが必要ならLambda@Edgeを選びます。

サーバーレス要件の評価では、すべてのコンポーネントがマネージドかつ需要に応じて課金される必要があります。Application Load BalancerはLambda関数をターゲットにできますが、VPC内に配置してアイドル時も課金されるリソースであるため、サーバーレス要件には適合しません。

アーキテクチャ図

アーキテクチャ図の解説

2つの異なるサーバーレスアプローチ

このアーキテクチャは、同じ要件を満たす2つの独立したサーバーレスソリューションを示しています。ソリューション Aでは、API Gateway REST APIがVTLマッピングテンプレートを使用して設備稼働データテーブルを直接呼び出し、中間層なしでのデータアクセスを実現します。この直接統合により、Lambda関数のコールドスタートや実行時間を回避し、一貫した低レイテンシでのレスポンスが可能です。

ソリューション Bでは、API Gateway HTTP APIがLambda関数を介して設備稼働データテーブルにアクセスします。HTTP APIの低コスト特性とLambda関数の柔軟なプログラミング環境を組み合わせることで、複雑なデータ変換、ビジネスロジック、バリデーション処理を実装できます。両方のソリューションとも完全にサーバーレスで、需要に応じた自動スケーリングと従量課金モデルを提供します。

他のソリューションとの比較

HTTP APIでDynamoDBを直接呼び出すアプローチとの比較では、技術的実現可能性で明確な違いがあります。HTTP APIのAWSサービス統合はEventBridge、SQS、AppConfig、Kinesis Data Streams、Step Functionsのサブタイプに限られ、DynamoDBを呼び出す統合は設定できません。この制限は、HTTP APIが低コストと低レイテンシに特化するため意図的に機能セットを絞り込んでいることによるものです。

CloudFront Functionsでデータを返すアプローチには、実行環境そのものに制約があります。CloudFront Functionsはネットワークアクセスとファイルシステムアクセスを持たず、AWS SDKも利用できないため、DynamoDBからデータを取得する処理を実装できません。エッジで外部サービスを呼び出す必要がある場合はLambda@Edgeが選択肢になります。

Application Load Balancerは、Lambda関数をターゲットにできますがサーバーレス要件を満たしません。サブネットを指定してVPC内に配置するリソースであり、トラフィックがない時間帯にも時間単位の課金が発生するため、需要に応じた課金というサーバーレスの前提に適合しません。

実装の考慮事項

REST API直接統合の実装では、VTLマッピングテンプレートの適切な設計が重要です。DynamoDBのQuery、Scan、GetItem、PutItemなどの操作に対応したリクエスト変換と、エラーハンドリング、レスポンス整形の実装が必要です。また、API Gatewayの実行ロールに適切なDynamoDBアクセス権限（dynamodb:GetItem、dynamodb:Queryなど）を付与する必要があります。

Lambda統合の実装では、効率的なAWS SDKの使用とコネクション再利用により性能を最適化できます。また、Lambda関数のメモリ設定とタイムアウト値の調整、エラーハンドリングロジックの実装により、安定したサービス提供が可能です。

両方のアプローチで、DynamoDBテーブルの設計（パーティションキー、ソートキー、GSI設定）と読み取り・書き込み容量の適切な設定により、コスト効率と性能のバランスを最適化することが重要です。

参考資料

問題文：
デジタル広告配信サービスを運営する企業が、事業部単位でAWS Organizationsの組織単位（OU）を分けて運用しています。配信基盤OU、データ解析OU、社内システムOUの3つがあり、各OUの配下には検証用と本番用を合わせて数十のAWSアカウントが所属しています。組織全体のアカウント数は600を超えています。
各事業部のリーダーから、自分たちのOUに属するアカウントを横断した利用料金の内訳を、サービス別・アカウント別にセルフサービスで確認したいという要望が出ています。
運用オーバーヘッドを最も小さく抑えてこの要望を満たす構成はどれですか？

選択肢：
A. AWS Control TowerでOUごとにAWS Cost and Usage Report（CUR）を有効化する。事業部の担当者はAmazon QuickSightに取り込んだそのレポートを見る
B. OU配下の各メンバーアカウントでAWS Cost and Usage Report（CUR）を個別に有効化する。事業部の担当者はAmazon QuickSightに取り込んだそれらのレポートを見る
C. 組織の管理アカウントを発行元としてAWS Cost and Usage Report（CUR）を1本設定する。事業部の担当者はAmazon QuickSightに取り込んだそのレポートを見る
D. AWS Configのアグリゲータで組織内の全アカウントのAWS Cost and Usage Report（CUR）を集約する。事業部の担当者はAWS Configのコンプライアンスダッシュボードでそのデータを見る

正解：C

A. AWS Control TowerでOUごとにAWS Cost and Usage Report（CUR）を有効化する。事業部の担当者はAmazon QuickSightに取り込んだそのレポートを見る

不正解 AWS Control Towerはランディングゾーンの構築、アカウントの払い出し、コントロールの適用を担うサービスで、CURを発行する機能を持ちません。Control Towerのダッシュボードに表示されるのはコントロールの準拠状況やOU・アカウントの登録状況であり、課金データではありません。レポートの定義を作成できるのはAWS Billing and Cost Managementのレポート設定だけで、Control TowerのコンソールにもAPIにもその項目は存在しません。

B. OU配下の各メンバーアカウントでAWS Cost and Usage Report（CUR）を個別に有効化する。事業部の担当者はAmazon QuickSightに取り込んだそれらのレポートを見る

不正解メンバーアカウントで発行したCURには、そのアカウント自身の利用明細しか含まれません。事業部が見たいのはOU配下の数十アカウントを横断した内訳であるため、レポートを後段で結合する処理を別途作り込むことになります。600を超えるアカウントそれぞれでレポート定義と保存先バケットを維持する必要があり、アカウントが増えるたびに手作業も積み上がります。

C. 組織の管理アカウントを発行元としてAWS Cost and Usage Report（CUR）を1本設定する。事業部の担当者はAmazon QuickSightに取り込んだそのレポートを見る

正解統合請求により、メンバーアカウントの利用実績はすべて管理アカウントに集約されます。管理アカウントで作成したCURには組織内の全アカウントの明細行が含まれるため、アカウントIDやコスト配分タグを軸にQuickSight側で絞り込めば、各事業部が自分のOUに属するアカウント分だけを見る画面を用意できます。レポートは1本で済み、アカウントが増えても新たな設定作業は発生しません。

D. AWS Configのアグリゲータで組織内の全アカウントのAWS Cost and Usage Report（CUR）を集約する。事業部の担当者はAWS Configのコンプライアンスダッシュボードでそのデータを見る

不正解 AWS Configが記録するのはリソースの設定項目とその変更履歴、そしてルールへの準拠状況であり、課金データは対象外です。アグリゲータは複数アカウント・複数リージョンの設定情報を1か所に集める機能で、CURを取り込む経路そのものがありません。コンプライアンスダッシュボードにも利用料金を金額で分解して見せる表示はなく、求められている内訳を提示できません。

全体的な説明

問われている要件

事業部ごとのOUが配下アカウントを横断した料金内訳を確認できること
600アカウント規模のAWS Organizations環境で無理なく運用できること
サービス別・アカウント別の粒度でセルフサービス参照ができること
課金データの発行元を組織で1本に統一し、結合処理を自作しないこと
アカウント追加時に設定作業が増えず、運用オーバーヘッドが最小であること

前提知識

AWS Cost and Usage Report（CUR）について

明細の粒度：時間単位・日単位・月単位で利用実績を出力し、アカウント、サービス、リソース、購入オプションの列を持つ。コスト配分タグを列として展開できるため多軸の集計に耐える
発行できる場所：Organizations環境では統合請求により全メンバーアカウントの利用実績が管理アカウントに集まる。管理アカウントで発行したレポートは組織内の全アカウント分を含む
保存と分析：レポートはAmazon S3バケットへ自動で書き出され、CSVまたはParquet形式を選べる。Amazon Athena、Amazon Redshift、Amazon QuickSightから直接読み込める

Amazon QuickSightによるコスト可視化について

ダッシュボード：明細データをそのまま取り込み、期間・サービス・アカウントでのドリルダウンや計算フィールドの追加ができる
行レベルセキュリティ：閲覧ユーザーやグループごとに参照できる行を制限する仕組み。アカウントIDやOU名の列を条件にすれば、事業部は自分の範囲だけを見る
SPICE：インメモリのデータセットに取り込んで応答時間を短縮する仕組み。更新スケジュールを設定して定期的に取り込む

組織構造とタグ戦略について

OU階層：アカウントを用途や部門でまとめる単位。OUとアカウントIDの対応表を用意すれば、明細行を事業部に割り当てられる
コスト配分タグ：請求で使うタグキーを有効化することで、部門・案件・環境ごとの按分が明細レベルで可能になる

解くための考え方

判断の分かれ目は「課金データをどこで発行するか」です。600アカウント規模では、レポートの本数がそのまま運用負荷になります。

まず、データが集まる場所を確認します。統合請求の仕組み上、メンバーアカウントの利用実績は管理アカウントに集約されるため、管理アカウントで発行した1本のレポートが組織全体をカバーします。

次に、見せ方を考えます。1本のレポートを共有データソースにして、行レベルセキュリティで閲覧範囲を切り分ければ、事業部ごとにデータを複製せずに参照範囲だけを分けられます。

逆にメンバーアカウント側で発行すると、レポートは自アカウント分に閉じるため、OU横断の内訳を出すには結合処理を自作することになります。アカウントが増えるたびに設定作業も増えます。

最後に、サービスの守備範囲を確認します。Control TowerもConfigも課金データを発行・集約する機能を持たないため、この用途では選べません。

アーキテクチャ図

アーキテクチャ図の解説

課金データの集約経路

図の上段は、配信基盤OUとデータ解析OUに属する各アカウントの利用実績が、統合請求を通じて管理アカウントへ集まる流れを示しています。各アカウントには所属OUを示すコスト配分タグが付けられており、後段での絞り込みに使われます。

Cost and Usage Reportは管理アカウントで定義され、組織内の全アカウントの明細を含むファイルとしてS3バケットへ書き出されます。データソースが1つに統一されるため、集計基準のずれが起きません。

事業部ごとの参照範囲の制御

Amazon QuickSightはS3上の明細を読み込み、行レベルセキュリティによって、各事業部が自分のOUに属するアカウントの行だけを見られるように制御します。事業部別ダッシュボードでは、OUタグで絞り込まれたデータがサービス別・アカウント別に表示されます。

この構成なら、600アカウント規模でもレポートは1本のまま、参照範囲の追加だけで新しい事業部に対応できます。

他のソリューションとの比較

Control Towerでレポートを有効化する案は、サービスの守備範囲で成立しません。Control Towerが扱うのはランディングゾーンの構成、アカウントの払い出し、コントロールの適用状況であり、レポート定義を作る画面もAPIも持ちません。落ちる理由はサービス選定の段階にあります。

メンバーアカウントごとにレポートを発行する案は、機能としては動きますが、出てくるデータの範囲で要件に届きません。1本ごとに自アカウント分しか含まれないため、OU横断の内訳を得るには数十本のファイルを突き合わせる処理を用意することになり、アカウント追加のたびに設定と結合先の更新が発生します。

Configのアグリゲータで集約する案は、集約できるデータの種類で成立しません。アグリゲータが集めるのは設定項目と準拠状況であって金額の明細ではなく、レポートを取り込む入力そのものが用意されていません。

実装の考慮事項

レポート設定では、粒度と出力形式の選び方が後の運用を左右します。時間単位の明細は分析の自由度が高い一方でファイルサイズとクエリ時間が伸びるため、日次で足りる用途と使い分けます。列指向のParquetを選ぶと、AthenaやQuickSightからの読み込みが軽くなります。

行レベルセキュリティは、アカウントIDとOU名の対応表をルールセットとして持たせる形にしておくと、アカウントが増えたときに対応表の更新だけで参照範囲が追随します。閲覧者の管理はIAM Identity CenterやSAMLプロバイダーと連携させ、既存の認証基盤に寄せると運用が軽くなります。

長期運用では、コストデータの保存期間ポリシーの設定と、S3ライフサイクル管理によるストレージコスト最適化が重要です。また、QuickSightのSPICE容量管理と、定期的なデータリフレッシュスケジュールの最適化により、パフォーマンスとコストのバランスを維持できます。

参考資料

問題文：
ある企業が、単一のVPC上でサービスを稼働させています。VPCは3つのアベイラビリティーゾーンにまたがり、各ゾーンにパブリックサブネットとプライベートサブネットを1つずつ持ちます。処理ワーカーはプライベートサブネットのAmazon EC2インスタンス群で動作し、パブリックサブネットに配置したApplication Load Balancerが顧客からのリクエストを受け付けます。
ワーカーは外部ライセンスの認証やOSパッケージの更新のためにインターネットへ出る経路を必要とし、3つのNATゲートウェイ経由でこれを行っています。画像データはAmazon S3に保管されており、ワーカーは1日あたり約2TBを同じバケットから読み出します。企業は取り扱うデータの性質から、厳格なセキュリティ水準を顧客に約束しています。
ソリューションアーキテクトは、この水準を下げず、日々の運用作業も増やさないまま、月々のクラウド費用を最大限に圧縮しなければなりません。
これらの要件を満たすソリューションはどれでしょうか。

選択肢：
A. 画像データを格納するS3バケットでTransfer Accelerationを有効化する。ワーカーからの取得先を高速化用のエンドポイントに切り替える。
B. パブリックサブネットにNATインスタンス用のEC2を構築する。プライベートサブネットのルートテーブルで、既定ルートの向き先をそのインスタンスのネットワークインターフェイスに変更する。
C. 処理ワーカーのEC2インスタンスをパブリックサブネットへ移設し、各インスタンスにElastic IPアドレスを割り当てる。3つのNATゲートウェイを削除する。
D. S3向けのゲートウェイ型VPCエンドポイントをVPCに作成する。対象バケットに対する必要なアクションだけを許可するエンドポイントポリシーをアタッチする。

正解：D

A. 画像データを格納するS3バケットでTransfer Accelerationを有効化する。ワーカーからの取得先を高速化用のエンドポイントに切り替える。

不正解 Transfer AccelerationはCloudFrontのエッジロケーションを起点にS3へ最適化された経路を使う機能で、通信自体はインターネット側のエンドポイント宛てに出ていきます。プライベートサブネットからのリクエストは引き続きNATゲートウェイを通過するため、削りたかった処理料金がそのまま残ります。加えて、高速化が働いた転送には追加のデータ転送料金が発生し得ます。費用削減の方向とは逆に働きます。

B. パブリックサブネットにNATインスタンス用のEC2を構築する。プライベートサブネットのルートテーブルで、既定ルートの向き先をそのインスタンスのネットワークインターフェイスに変更する。

不正解自己管理のNATインスタンスは時間単価こそ安いものの、OSのパッチ適用、スループットに応じたインスタンスタイプの見直し、障害時のフェイルオーバー設計をすべて自前で抱えることになります。3ゾーン構成では冗長化のための監視と切り替えの作りこみも必要で、日々の運用作業を増やさないという条件と正面から衝突します。単一インスタンスに寄せれば可用性が下がり、サービスの継続性も損なわれます。

C. 処理ワーカーのEC2インスタンスをパブリックサブネットへ移設し、各インスタンスにElastic IPアドレスを割り当てる。3つのNATゲートウェイを削除する。

不正解 NATゲートウェイの費用は消えますが、処理ワーカーがグローバルIPアドレスを持ってインターネットに直接面することになります。セキュリティグループだけが唯一の境界となり、プライベートサブネットに閉じ込めるという多層防御の前提が崩れます。厳格なセキュリティ水準を顧客に約束しているサービスで採用できる構成ではありません。

D. S3向けのゲートウェイ型VPCエンドポイントをVPCに作成する。対象バケットに対する必要なアクションだけを許可するエンドポイントポリシーをアタッチする。

正解ゲートウェイ型エンドポイントはプライベートサブネットのルートテーブルにS3のプレフィックスリスト宛て経路を追加し、S3向けの通信をAWSネットワーク内で完結させます。エンドポイント自体に時間料金もデータ処理料金も発生しないため、毎日2TB分のNATゲートウェイ処理料金がそのまま消えます。エンドポイントポリシーで対象バケットと必要な操作に絞れば、インスタンスをプライベートサブネットに置いたまま権限も最小化できます。

全体的な説明

問われている要件

毎日2TBのS3読み出しに伴うNATゲートウェイのデータ処理料金の削減
サービスに求められるセキュリティ水準の維持
日々の運用作業を増やさないこと
処理ワーカーをプライベートサブネットに置き続けること
Application Load Balancerによる受け口の維持

前提知識

ゲートウェイ型VPCエンドポイントの特徴について

S3とDynamoDB向けに提供されるゲートウェイ型エンドポイントは、ルートテーブルにサービスのプレフィックスリスト宛て経路を追加する方式で動作します。インターネットゲートウェイやNATデバイスを経由せずにS3へ到達でき、エンドポイント自体の料金は発生しません。
エンドポイントポリシーによって、経路を通れるプリンシパル、バケット、アクションを限定できます。バケットポリシー側でaws:SourceVpceを条件に指定すれば、エンドポイント経由以外のアクセスを拒否する運用も可能です。

NATゲートウェイの費用構造について

NATゲートウェイは1時間あたりの料金に加えて、通過したデータ量に応じた処理料金がかかります。ゾーンごとに配置すると台数分の時間料金が積み上がり、S3への大量読み出しがあると処理料金が支配的になります。
自己管理のNATインスタンスに置き換えると処理料金は消えますが、パッチ適用、性能の作りこみ、冗長化と障害時の切り替えという運用が戻ってきます。

セキュリティ設計の原則について

受け口をパブリックサブネットのロードバランサーに限定し、処理を担うインスタンスをプライベートサブネットに閉じる構成は、攻撃面を最小化する基本形です。インスタンスにグローバルIPアドレスを与えると、この前提そのものが失われます。
通信経路の制御はネットワーク層だけでなく、エンドポイントポリシーやバケットポリシーによる資源側の制御と組み合わせることで、多層の防御になります。

解くための考え方

出題の中心は、毎日2TBというS3読み出しがNATゲートウェイのデータ処理料金として跳ね返っている点です。まず、この通信をNATゲートウェイから外せるかどうかを考えます。

同時に、セキュリティ水準を下げないという制約により、インスタンスをパブリック側へ出す案は検討の余地なく落ちます。運用作業を増やさないという制約により、自前で面倒を見るコンポーネントを増やす案も落ちます。

ゲートウェイ型VPCエンドポイントは、この二つの制約を守りながら費用だけを削れる唯一の手段です。追加料金なしでS3向け通信をAWSネットワーク内に閉じ、マネージドサービスであるため運用作業も増えません。

エンドポイント導入後も、ライセンス認証やパッケージ更新といったS3以外のインターネット通信はNATゲートウェイを使い続けるため、既存の運用手順に手を入れる必要はありません。

アーキテクチャ図

アーキテクチャ図の解説

プライベート経路による費用の圧縮

図では、処理ワーカーからS3への読み出しがゲートウェイ型VPCエンドポイントを通り、NATゲートウェイを迂回します。導入前はこの2TB分がすべてNATゲートウェイのデータ処理料金として計上されていましたが、エンドポイント経由ではその費目が発生しません。

エンドポイントそのものに時間料金がないため、削減額がそのまま効果として残ります。通信はAWSの内部ネットワークを通り、インターネットへは一切出ません。

セキュリティ水準と運用負荷の維持

処理ワーカーはプライベートサブネットに置かれたままで、外部から直接到達できる経路は生まれません。エンドポイントポリシーは対象バケットと必要な操作だけを許可し、最小権限を資源側でも担保します。

エンドポイントはマネージドで提供され、パッチ適用やスケーリングの作業は発生しません。NATゲートウェイはライセンス認証などS3以外の通信のために残るため、既存の監視やネットワーク設計に変更を加えずに済みます。

他のソリューションとの比較

NATインスタンスへの置き換えは処理料金の面では有利ですが、OSの保守、性能設計、冗長化と障害時の切り替えという作業が恒常的に発生し、運用作業を増やさないという条件を満たせません。

インスタンスをパブリックサブネットへ移す案は費用こそ確実に下がりますが、グローバルIPアドレスを持つ処理ワーカーが直接インターネットに面することになり、企業が顧客に約束したセキュリティ水準と両立しません。

Transfer Accelerationを有効化する案は、通信がエッジロケーション経由でインターネット側のエンドポイントへ向かうため、NATゲートウェイの通過そのものが残ります。処理料金が減らないうえに追加の転送料金が乗り得るため、費用は下がりません。

実装の考慮事項

ゲートウェイ型エンドポイントの作成時には、経路を追加する対象のルートテーブルを取り違えないことが重要です。プライベートサブネットが参照しているルートテーブルすべてにエンドポイントを関連付け、S3向け通信が実際に切り替わったかをVPCフローログで確認します。

エンドポイントポリシーは、アプリケーションが実際に呼び出しているS3のAPI操作を洗い出したうえで記述します。読み出し中心の用途であっても、マルチパートアップロードや一覧取得が必要になる場合があるため、事前にアクセスパターンを整理しておきます。

導入後はCost Explorerでデータ処理料金の推移を追い、想定どおりに費目が減っているかを月次で確認します。あわせてフローログでエンドポイント経由の通信を監査し、意図しない宛先へのアクセスが残っていないかを継続的に点検します。

参考資料

問題文：
化粧品ブランドを展開する企業が、自社の直販オンラインストアをオンプレミスのデータセンターからAWSへ移行しようとしています。現在は1台のデータベースサーバーに、商品カタログの構造化データと、買い物中の利用者の一時的なセッションデータの両方を格納しています。商品カタログは複数のテーブルを結合するSQLクエリで参照されており、この参照方法は移行後も変えられません。セッションデータはページを開くたびに読み書きされ、一定時間で破棄されます。
企業は移行にあたり、商品カタログのデータとセッションデータを別々のデータストアに分離したいと考えています。あわせて、東京リージョンを主系としつつ、災害対策として大阪リージョンへのレプリケーションを構成する必要があります。これらの要件を満たしたうえで、最も高い性能が得られるソリューションはどれでしょうか。

選択肢：
A. Amazon RDS DBインスタンスに商品カタログを格納し、大阪リージョンにリードレプリカを作成します。セッションデータはAmazon DynamoDBのグローバルテーブルを作成し、大阪リージョンにレプリカを配置して保持します。
B. Amazon RDS DBインスタンスを1つ作成し、商品カタログ用とセッション用にスキーマを分けて同じインスタンスに格納します。災害対策として、大阪リージョンにこのDBインスタンスのリードレプリカを作成します。
C. Amazon DynamoDBのグローバルテーブルを2つ作成し、一方に商品カタログを、もう一方にセッションデータを格納します。読み取り性能を高めるためにDynamoDB Accelerator (DAX) を前段に配置します。
D. Amazon RDS DBインスタンスに商品カタログを格納し、大阪リージョンにリードレプリカを作成します。セッションデータはAmazon ElastiCache for Memcachedのグローバルデータストアを構成して保持します。

正解：A

A. Amazon RDS DBインスタンスに商品カタログを格納し、大阪リージョンにリードレプリカを作成します。セッションデータはAmazon DynamoDBのグローバルテーブルを作成し、大阪リージョンにレプリカを配置して保持します。

正解結合を伴うSQLをそのまま実行できるRDSに商品カタログを残し、クロスリージョンリードレプリカで大阪リージョンへ複製します。セッションデータは主キーで1件を引く単純なアクセスに適したDynamoDBのグローバルテーブルへ分離するため、いずれのリージョンでも自リージョンのレプリカに対して低レイテンシーで読み書きできます。負荷の性質が異なる2種類のデータが互いに干渉しません。

B. Amazon RDS DBインスタンスを1つ作成し、商品カタログ用とセッション用にスキーマを分けて同じインスタンスに格納します。災害対策として、大阪リージョンにこのDBインスタンスのリードレプリカを作成します。

不正解スキーマは名前空間を区切るだけの仕組みで、CPUやメモリ、ストレージのI/Oは1つのDBインスタンスで共有されたままです。ページを開くたびに発生するセッションの読み書きが商品カタログのSQLクエリと同じリソースを奪い合うため、参照の応答時間が伸びます。2種類のデータを別々のデータストアに分離するという要件も満たしていません。

C. Amazon DynamoDBのグローバルテーブルを2つ作成し、一方に商品カタログを、もう一方にセッションデータを格納します。読み取り性能を高めるためにDynamoDB Accelerator (DAX) を前段に配置します。

不正解商品カタログは複数テーブルの結合を伴うSQLで参照する前提が置かれており、キーバリュー型のDynamoDBへ移すとデータモデルとクエリを作り直すことになります。またDAXはリージョン単位で動作するサービスで、グローバルテーブルのレプリケーションはキャッシュを迂回して書き込まれるため、複製先では古い値が読み取られます。

D. Amazon RDS DBインスタンスに商品カタログを格納し、大阪リージョンにリードレプリカを作成します。セッションデータはAmazon ElastiCache for Memcachedのグローバルデータストアを構成して保持します。

不正解 ElastiCacheのグローバルデータストアが対象とするのはValkeyとRedis OSSのクラスターであり、Memcachedのクラスターでは構成できません。Memcachedにはレプリケーションの仕組み自体が備わっておらず、セッションデータを別のリージョンへ複製する手段がないため、災害対策のレプリケーションという要件をこの構成では実現できません。

全体的な説明

問われている要件

商品カタログのデータとセッションデータを別々のデータストアに分離する
商品カタログは複数テーブルを結合するSQLクエリで参照し続ける
セッションデータは高頻度の読み書きに耐え、一定時間で破棄できるようにする
主系のリージョンから別のリージョンへレプリケーションして災害対策に備える
上記を満たしたうえで最も高い性能を得る

前提知識

構造化データを扱うデータベースについて

Amazon RDS リレーショナルデータベースエンジンをマネージドで提供します。テーブル間の結合やトランザクションをそのまま利用できるため、既存のリレーショナルスキーマを持つアプリケーションの移行先になります。
クロスリージョンリードレプリカプライマリから別のリージョンへ非同期でレプリケートし、読み取り専用のインスタンスを保持します。災害時にはスタンドアロンのDBインスタンスへ昇格させて書き込みを受け付けられます。

セッションデータの性質と保管先について

セッションデータの特徴主キーであるセッションIDで1件を引く単純なアクセスが大半で、結合や集計を必要としません。参照と更新の頻度が高く、一定時間が過ぎれば不要になります。
Amazon DynamoDB キーバリュー型のフルマネージドデータベースで、規模にかかわらず1桁ミリ秒台の応答を維持します。有効期限（TTL）属性を設定すると期限切れの項目が自動的に削除されます。

リージョン間レプリケーションの手段について

DynamoDBグローバルテーブル複数のリージョンにレプリカを配置し、どのレプリカに対しても読み書きできるマルチアクティブ構成です。アプリケーションは自リージョンのレプリカへアクセスするため、リージョンをまたぐ往復が発生しません。
ElastiCacheのグローバルデータストア ValkeyまたはRedis OSSのクラスターをリージョン間で複製する機能です。Memcachedはレプリケーション自体を持たないため、この機能の対象になりません。

キャッシュサービスの適用範囲について

DynamoDB Accelerator (DAX) DynamoDBの前段に置くインメモリキャッシュで、読み取りをマイクロ秒単位まで短縮します。クラスターはリージョン単位で動作し、グローバルテーブルによる複製はキャッシュを迂回して書き込まれるため、複製先では古い値が残り続けます。

解くための考え方

判断の軸は2つあります。1つはデータの性質にデータストアを合わせられているか、もう1つはリージョン間のレプリケーションが実際に構成できるかです。

商品カタログは複数テーブルの結合を伴うSQLで参照されており、この参照方法を維持する前提が置かれています。リレーショナルなクエリをそのまま実行できるのはRDSであり、災害対策のレプリケーションはクロスリージョンリードレプリカで実現できます。ここをキーバリュー型のデータベースへ移すと、テーブル設計とアプリケーションのクエリを作り直す作業が発生し、移行の目的から外れます。

セッションデータはセッションIDで1件を取り出すだけの単純なアクセスであり、負荷の山が読み書きの回数として現れます。これをリレーショナルデータベースに同居させると、商品カタログの参照と同じCPUとI/Oを奪い合い、性能の足を引っ張ります。キーバリュー型のデータベースへ分離すれば、この負荷は商品カタログから完全に切り離されます。

レプリケーションの実現可能性も見落とせません。キャッシュサービスでリージョン間の複製を行う機能はエンジンによって対応が分かれており、選んだエンジンが対応していなければ災害対策の要件はそもそも成立しません。また、キャッシュを前段に置く構成はリージョン単位で閉じるため、複製されたデータとの整合が崩れます。

これらを踏まえると、商品カタログをRDSに置いてリードレプリカで複製し、セッションデータをマルチアクティブに複製できるキーバリュー型のデータベースへ分離する構成が、要件を満たしながら最も高い性能を得られます。

アーキテクチャ図

アーキテクチャ図の解説

主系リージョンでのデータの流れ

オンラインストアの利用者からのリクエストはApplication Load Balancerを経由してアプリケーションサーバーに届きます。アプリケーションサーバーは、商品の一覧や詳細を組み立てる際に結合を含むSQLをAmazon RDSへ発行し、ログイン状態やカートの内容といったセッションはAmazon DynamoDBのテーブルに対して読み書きします。参照先が2つに分かれているため、セッションの高頻度アクセスが商品カタログの検索性能に影響しません。

災害対策リージョンへの複製

Amazon RDSは大阪リージョンのクロスリージョンリードレプリカへ非同期でレプリケートします。Amazon DynamoDBはグローバルテーブルとして構成され、東京と大阪のレプリカ間で双方向にデータが複製されます。前者は読み取り専用の待機系として保持し、災害時に昇格させて書き込みを受け付けます。

切り替え後の動作

大阪リージョンには待機状態のアプリケーションサーバーを用意しておきます。切り替えの際は昇格させたデータベースと大阪側のセッションテーブルのレプリカを参照先とし、利用者のセッションを引き継いだままサービスを継続できます。グローバルテーブルの複製は通常1秒未満で伝播するため、切り替え時点の直近の状態を引き継げます。

他のソリューションとの比較

同じデータベースインスタンスの中でスキーマだけを分ける案との違いは、リソースの分離ができているかどうかです。スキーマは名前空間の区切りにすぎず、計算資源とストレージのI/Oは共有されます。セッションのアクセス頻度がそのまま商品カタログの参照に跳ね返るため、性能の観点では最も不利になります。

キャッシュサービスでセッションを保持する案との違いは、リージョン間の複製が構成できるかどうかです。エンジンによっては複製の機能そのものが提供されておらず、災害対策の要件が満たせません。

すべてをキーバリュー型のデータベースに寄せる案との違いは、既存のリレーショナルなクエリを維持できるかどうかです。結合を含むSQLは移行先で表現し直す必要があり、さらにリージョン単位で動くキャッシュを前段に置くと、複製されたデータとキャッシュの内容がずれます。

実装の考慮事項

DynamoDBのセッションテーブルでは、セッションIDをパーティションキーにし、有効期限を保持する属性にTTLを設定して期限切れの項目を自動削除させます。グローバルテーブルは書き込みが競合した場合に最後の書き込みが優先されるため、同一セッションを複数リージョンから同時に更新しない設計にします。通常時は利用者を主系のリージョンへ寄せ、切り替え時にまとめて移す運用が扱いやすくなります。

RDS側では、クロスリージョンリードレプリカの遅延を監視し、災害時に許容できる範囲に収まっているかを継続的に確認します。昇格後は書き込み先が変わるため、アプリケーションが参照する接続先をパラメータストアなどから取得する形にしておくと切り替えが短時間で済みます。移行時は既存のセッション管理コードをDynamoDBのAPIを使う実装に置き換える作業が発生するため、商品カタログの移行とは別の工程として計画します。

参考資料

問題文：
小売企業がAWS上でeコマースアプリケーションを運用しています。アプリケーションはApplication Load Balancer（ALB）の背後にあるAmazon EC2インスタンス上で実行されています。同社はデータベースバックエンドとしてAmazon RDS DBインスタンスを使用しています。Amazon CloudFrontはALBを指す1つのオリジンで設定されています。静的コンテンツはキャッシュされています。Amazon Route 53はすべてのパブリックゾーンをホストするために使用されています。
アプリケーションのアップデート後、ALBが時々502ステータスコード（Bad Gateway）エラーを返すようになりました。根本原因は、ALBに返される不正な形式のHTTPヘッダーです。エラー発生直後にソリューションアーキテクトがウェブページをリロードすると、ページは正常に返されます。
同社が問題に取り組んでいる間、ソリューションアーキテクトは標準のALBエラーページの代わりに、訪問者にカスタムエラーページを提供する必要があります。
最小の運用オーバーヘッドでこの要件を満たす手順の組み合わせはどれですか。（2つ選択）

選択肢：
A. Amazon S3バケットを作成する。S3バケットを静的ウェブページをホストするように設定する。カスタムエラーページをAmazon S3にアップロードする。

B. ALBヘルスチェック応答Target.FailedHealthChecksが0より大きい場合にAWS Lambda関数を呼び出すAmazon CloudWatchアラームを作成する。公開アクセス可能なWebサーバーを指すようにALBでの転送ルールを変更するようにLambda関数を設定する。

C. ヘルスチェックを追加して既存のAmazon Route 53レコードを変更する。ヘルスチェックが失敗した場合のフォールバックターゲットを設定する。公開アクセス可能なウェブページを指すようにDNSレコードを変更する。

D. ALBヘルスチェック応答Elb.InternalErrorが0より大きい場合にAWS Lambda関数を呼び出すAmazon CloudWatchアラームを作成する。公開アクセス可能なWebサーバーを指すようにALBでの転送ルールを変更するようにLambda関数を設定する。

E. CloudFrontカスタムエラーページを設定してカスタムエラー応答を追加する。公開アクセス可能なウェブページを指すようにDNSレコードを変更する。

正解：A, E

解説：

A. Amazon S3バケットを作成する。S3バケットを静的ウェブページをホストするように設定する。カスタムエラーページをAmazon S3にアップロードする。

正解 Amazon S3は静的コンテンツのホスティングに最適化されたサービスで、高可用性、低コスト、簡単な設定が特徴です。カスタムエラーページのような静的HTMLファイルを配置するのに理想的で、設定も簡単で運用オーバーヘッドが最小限です。S3の静的ウェブサイトホスティング機能により、パブリックにアクセス可能なエンドポイントが提供され、CloudFrontからの参照が可能となります。

B. ALBヘルスチェック応答Target.FailedHealthChecksが0より大きい場合にAWS Lambda関数を呼び出すAmazon CloudWatchアラームを作成する。公開アクセス可能なWebサーバーを指すようにALBでの転送ルールを変更するようにLambda関数を設定する。

不正解 CloudWatchアラームとLambda関数を使用してALBの転送ルールを動的に変更するアプローチは、運用の複雑性を大幅に増加させます。Lambda関数の開発、デプロイ、監視が必要となり、さらにALBルールの動的変更は全ユーザーに影響を与えるため、502エラーが発生した特定のリクエストのみを対象とする要件に適していません。

C. ヘルスチェックを追加して既存のAmazon Route 53レコードを変更する。ヘルスチェックが失敗した場合のフォールバックターゲットを設定する。公開アクセス可能なウェブページを指すようにDNSレコードを変更する。

不正解 Route 53のヘルスチェックとフォールバック機能は、サービス全体の可用性制御に使用される仕組みです。502エラーが発生した個別のリクエストに対してカスタムエラーページを表示するのではなく、DNSレベルで全トラフィックを別のエンドポイントにリダイレクトしてしまうため、この問題の要件に適していません。

D. ALBヘルスチェック応答Elb.InternalErrorが0より大きい場合にAWS Lambda関数を呼び出すAmazon CloudWatchアラームを作成する。公開アクセス可能なWebサーバーを指すようにALBでの転送ルールを変更するようにLambda関数を設定する。

不正解 Lambda関数を使用したALBルールの動的変更は運用複雑性が高く、全ユーザーへの影響があるため不適切です。また、Elb.InternalErrorメトリクスの監視による自動化は、一時的な問題に対する過剰な自動化となり、予期しない動作を引き起こす可能性があります。

E. CloudFrontカスタムエラーページを設定してカスタムエラー応答を追加する。公開アクセス可能なウェブページを指すようにDNSレコードを変更する。

正解 CloudFrontのカスタムエラーページ機能は、オリジン（ALB）からの特定のHTTPエラーコード（502など）を検知した際に、自動的に事前定義されたカスタムエラーページを表示する標準機能です。設定は簡単で運用オーバーヘッドが最小限であり、502エラーが発生した個別のリクエストにのみ影響するため、この問題の要件に最適です。

全体的な説明

問われている要件

ALBからの502エラー発生時のカスタムエラーページ表示
最小限の運用オーバーヘッドでの実装
既存のCloudFront構成を活用した効率的な解決策
一時的な問題に対する迅速で簡潔な対応
エラーが発生した特定のリクエストのみを対象とした制御

前提知識

CloudFrontカスタムエラーページ機能について

CloudFrontは、オリジンサーバーからの4xx、5xx系のHTTPエラーレスポンスを検知すると、設定されたカスタムエラーページを自動的に表示する機能を提供します。
カスタムエラーページの設定では、特定のエラーコード（例：502）に対して、代替のHTTPステータスコード（例：200）とカスタムエラーページのパスを指定できます。
この機能により、エンドユーザーはオリジンサーバーのエラーを直接見ることなく、適切にデザインされたエラーページを表示されます。
エラーページのキャッシュ設定も可能で、頻繁なエラー発生時の負荷軽減にも効果があります。

Amazon S3静的ウェブサイトホスティングについて

S3の静的ウェブサイトホスティング機能は、HTMLファイル、CSS、JavaScript、画像などの静的コンテンツを高可用性で配信するマネージドサービスです。
設定は簡単で、バケットポリシーでパブリックアクセスを許可し、インデックスドキュメントとエラードキュメントを指定するだけで運用開始できます。
99.999999999%（11 9’s）の耐久性と高い可用性を提供し、自動的に複数のアベイラビリティーゾーンにデータが複製されます。
コスト効率が高く、使用した分のみの課金で、静的コンテンツの配信に最適化されています。

CloudWatchアラームとLambda連携の複雑性について

CloudWatchアラーム、Lambda関数、ALB設定変更を連携させるソリューションは、複数のサービス間の統合が必要で運用複雑性が高くなります。
Lambda関数の開発、デプロイ、バージョン管理、エラーハンドリング、ログ監視などの運用タスクが追加されます。
ALBの転送ルールを動的に変更することは、全ユーザーのトラフィックフローに影響を与えるため、慎重な設計と十分なテストが必要です。

解くための考え方

この問題の核心は「最小の運用オーバーヘッド」という要件です。ALBが時々502エラーを返し、すぐにリロードすると成功するという状況から、これは一時的で局所的な問題であることが分かります。

このような場合、全体のアーキテクチャを大幅に変更したり、複雑な自動化システムを構築したりする必要はありません。むしろ、既存のCloudFront構成を活用して、エラーが発生した個別のリクエストに対してのみカスタムエラーページを表示する方が適切です。

CloudFrontのカスタムエラーページ機能は、まさにこのような用途のために設計された標準機能です。オリジンからの502エラーを検知すると、自動的に事前に準備されたカスタムエラーページを表示し、エンドユーザーエクスペリエンスを向上させます。

カスタムエラーページの配置先としては、高可用性、低コスト、簡単な設定というすべての要件を満たすAmazon S3が最適です。S3の静的ウェブサイトホスティング機能により、HTMLファイルをアップロードするだけで即座に運用開始できます。

Lambda関数やDNS設定変更を伴う選択肢は、いずれも運用オーバーヘッドが大きく、問題の規模に対して過剰なソリューションとなります。

アーキテクチャ図

アーキテクチャ図の解説

通常時のトラフィックフローと502エラー発生メカニズム

通常時、エンドユーザーのリクエストはRoute 53でドメイン名解決され、CloudFrontを経由してALBに転送されます。ALBは複数のEC2インスタンスに負荷を分散し、EC2インスタンスがRDSからデータを取得してレスポンスを生成します。しかし、アプリケーションアップデート後に不正な形式のHTTPヘッダーが原因で502 Bad Gatewayエラーが時々発生するようになりました。このエラーは一時的で、リロードすると成功する性質があります。

CloudFrontカスタムエラーページ機能による自動エラー処理

CloudFrontにカスタムエラー設定を追加することで、ALBからの502エラーを自動的に検知し、事前に準備されたカスタムエラーページで置き換えることができます。502エラーが発生すると、CloudFrontは設定に従ってS3にホストされたerror.htmlファイルを取得し、HTTPステータスコード200でエンドユーザーに返却します。これにより、エンドユーザーは技術的なエラーメッセージではなく、分かりやすいカスタムエラーページを見ることができます。

運用オーバーヘッドを最小化する設計思想

この構成では、既存のCloudFront配信インフラを活用し、新たに追加するのはS3バケットとHTMLファイルのみです。Lambda関数や複雑なヘルスチェック機能は不要で、CloudFrontの標準機能だけでエラーハンドリングが完結します。S3は高可用性でコスト効率が良く、静的ファイルのホスティングに最適です。この方式により、メインアプリケーションの修正を並行して進めながら、エンドユーザーエクスペリエンスを即座に改善できます。

他のソリューションとの比較

Route 53のヘルスチェックとDNSフェイルオーバーを使用するアプローチでは、サービス全体を別のエンドポイントに切り替えてしまうため、502エラーが発生した個別のリクエストのみを対象とするという要件に適していません。DNSの変更は伝播に時間がかかる場合があり、キャッシュされたDNSレコードの影響で即座に反映されない可能性もあります。

CloudWatchアラームとLambda関数を使用してALBの転送ルールを動的に変更するアプローチは、技術的には可能ですが運用複雑性が大幅に増加します。Lambda関数の開発、テスト、デプロイ、監視が必要となり、ALBルールの変更は全ユーザーに影響するため、一時的な問題に対する解決策としては過剰です。

CloudFrontのカスタムエラーページ機能は、エラーが発生したリクエストのみを対象とし、他のリクエストには影響を与えません。設定も簡単で、運用開始までの時間も短く、問題の性質と要件に最も適したソリューションです。

実装の考慮事項

実装時には、S3バケットのパブリックアクセス設定とバケットポリシーの適切な構成が重要です。カスタムエラーページはパブリックに読み取り可能である必要がありますが、書き込み権限は適切に制限する必要があります。

CloudFrontのカスタムエラー設定では、エラーページのキャッシュTTLも設定できます。頻繁に502エラーが発生する場合は、エラーページをある程度キャッシュすることでS3への負荷を軽減できます。しかし、エラー解決後に古いエラーページが表示され続けることを避けるため、適切なTTL値を設定する必要があります。

また、カスタムエラーページのデザインでは、ユーザーに適切な情報を提供し、可能であれば代替アクション（リロードボタン、サポート連絡先など）を含めることが推奨されます。アクセシビリティとユーザビリティを考慮したデザインにより、エラー発生時のユーザーエクスペリエンスを最大限に改善できます。

参考資料

問題文：
不動産仲介事業を全国展開する企業は、AWS Organizations の配下で数十のAWSアカウントを運用しています。そのうちの1つをネットワークハブアカウントと位置付け、ここに作成したTransit Gatewayを組織内の全アカウントへ共有しています。国内の各支社とネットワークハブアカウントの間はAWS Site-to-Site VPNで接続されており、全アカウントでAWS Configが有効化されています。
ネットワークチームは、支社に割り当てた社内IPアドレス範囲の一覧を1か所で保守し、範囲が変わったときも一度の作業で全アカウントへ反映したいと考えています。各アカウントの開発者は、この一覧を参照して自分のアプリケーションへの接続元を絞り込みます。
運用オーバーヘッドが最も小さいソリューションはどれでしょうか。

選択肢：
A. 支社ごとのIPアドレス範囲をAmazon DynamoDBのグローバルテーブルに登録する。テーブルの変更をDynamoDB Streamsで検知し、各アカウントに配置したAWS Lambda関数をAmazon EventBridge経由で呼び出す。Lambda関数が対象のセキュリティグループのインバウンドルールを書き換える。
B. ネットワークハブアカウントで、支社のIPアドレス範囲をまとめたVPCマネージドプレフィックスリストを作成する。AWS Resource Access Managerで組織内の全アカウントに共有する。各アカウントでは共有されたプレフィックスリストをセキュリティグループルールの送信元に指定する。
C. ネットワークハブアカウントのAmazon VPC IP Address Manager（IPAM）に、支社のIPアドレス範囲を登録したプールを作成する。そのIPAMプールを組織内の全アカウントと共有する。各アカウントではセキュリティグループルールの送信元にIPAMプールを指定する。
D. 支社のIPアドレス範囲を許可リストとして埋め込んだAWS Configのカスタムルールを組織全体に配布する。各アカウントのセキュリティグループがその許可リストに沿っているかを継続的に評価する。逸脱したセキュリティグループを自動修復するように設定する。

正解：B

A. 支社ごとのIPアドレス範囲をAmazon DynamoDBのグローバルテーブルに登録する。テーブルの変更をDynamoDB Streamsで検知し、各アカウントに配置したAWS Lambda関数をAmazon EventBridge経由で呼び出す。Lambda関数が対象のセキュリティグループのインバウンドルールを書き換える。

不正解テーブルの保守に加えて、全アカウントへのLambda関数の配置、イベント連携の設定、セキュリティグループを書き換えるコードの保守が必要になります。アカウントが増えるほど管理対象も増え、更新の失敗や反映漏れを検知する仕組みまで自前で用意することになります。IPアドレス範囲を配布するという目的に対して、継続的に発生する運用作業が大きすぎます。

B. ネットワークハブアカウントで、支社のIPアドレス範囲をまとめたVPCマネージドプレフィックスリストを作成する。AWS Resource Access Managerで組織内の全アカウントに共有する。各アカウントでは共有されたプレフィックスリストをセキュリティグループルールの送信元に指定する。

正解マネージドプレフィックスリストは複数のCIDRを1つの名前付きリソースにまとめる機能で、セキュリティグループルールの送信元として直接指定できます。AWS Resource Access Managerで組織または組織単位に共有すれば、各アカウントは自分のリソースと同じようにリストを参照できます。支社の追加や範囲の変更はリスト側を書き換えるだけで済み、参照している全てのセキュリティグループへ反映されます。

C. ネットワークハブアカウントのAmazon VPC IP Address Manager（IPAM）に、支社のIPアドレス範囲を登録したプールを作成する。そのIPAMプールを組織内の全アカウントと共有する。各アカウントではセキュリティグループルールの送信元にIPAMプールを指定する。

不正解セキュリティグループルールの送信元として指定できるのはCIDR、別のセキュリティグループ、マネージドプレフィックスリストのいずれかであり、IPAMプールを送信元に指定することはできません。IPAMのプレフィックスリストリゾルバーによってプールの内容からプレフィックスリストを自動生成することはできますが、その場合もセキュリティグループが参照するのは生成されたプレフィックスリストです。

D. 支社のIPアドレス範囲を許可リストとして埋め込んだAWS Configのカスタムルールを組織全体に配布する。各アカウントのセキュリティグループがその許可リストに沿っているかを継続的に評価する。逸脱したセキュリティグループを自動修復するように設定する。

不正解 AWS Configはリソースの構成が定めた条件に合致しているかを評価し記録するサービスであり、開発者がセキュリティグループから参照できるIPアドレス範囲の集合体を提供するものではありません。評価と修復の仕組みを整えても、開発者はルールごとにCIDRを直接書き並べることになり、一覧を一元管理して参照させるという要件そのものが満たされません。

全体的な説明

問われている要件

多数のAWSアカウントにまたがる支社IPアドレス範囲の一元的な保守
範囲の変更を一度の作業で全アカウントへ反映する仕組み
開発者がセキュリティグループから直接参照できる形での提供
Transit Gatewayで相互接続された組織環境での共有手段
継続的な運用作業が最も少ないソリューションの選択

前提知識

VPCマネージドプレフィックスリストの特徴と用途について

マネージドプレフィックスリストは、複数のCIDRを1つの名前付きリソースとしてまとめる仕組みです。セキュリティグループ、ルートテーブル、ネットワークACLから参照でき、IPアドレス範囲の一元管理を実現します。
AWSサービスの範囲を表す事前定義のリストと、利用者が定義するカスタムリストがあります。支社の社内IPアドレス範囲のような独自の要件にはカスタムリストが適しています。

AWS Resource Access Manager（RAM）の共有機能について

RAMを使うと、マネージドプレフィックスリストを組織や組織単位の単位で他アカウントへ共有できます。共有されたリストは各アカウントでローカルのリソースと同じように参照できます。
AWS Organizationsとの統合を有効にしておけば、組織単位に対する共有はその配下に追加された新しいアカウントにも及びます。

セキュリティグループでのプレフィックスリスト参照について

セキュリティグループルールでは、個々のCIDRを列挙する代わりにプレフィックスリストを送信元や送信先として指定できます。リストの内容を更新すると、参照している全てのセキュリティグループに反映されます。
プレフィックスリストを参照するルールは、現在登録されているエントリ数ではなく、リストに設定した最大エントリ数の分だけルール数を消費します。セキュリティグループあたりのルール数の上限を踏まえた設計が必要です。

IPAMとプレフィックスリストの役割の違いについて

IPAMはIPアドレス空間の計画、割り当て、使用状況の可視化を担当します。プールから払い出されるのはVPCやサブネットに割り当てるCIDRです。IPAMのプレフィックスリストリゾルバーを使えばプールの割り当て状況からプレフィックスリストを自動更新できますが、その場合も通信制御が参照するのは生成されたプレフィックスリストです。
セキュリティグループルールの送信元として指定できるのはプレフィックスリストであり、IPAMプールそのものではありません。両者は扱う対象と参照できる場所が異なります。

解くための考え方

この問題の核心は、多数のAWSアカウントにまたがってIPアドレス範囲の集合をどう配布するかです。支社から到達する社内IPアドレス範囲を、各アカウントの開発者が自分のセキュリティグループで安全に指定できる状態にする必要があります。

「運用オーバーヘッドが最も小さい」という条件から、独自の同期処理や手作業での書き換えを前提とする案は外れます。マネージドサービスの標準機能だけで完結する構成が求められます。

次に、提示された機能が実際にセキュリティグループから参照できるものかを確認します。評価用のルールやアドレス管理用のプールは、セキュリティグループの送信元として指定できません。

マネージドプレフィックスリストはまさにこの用途のための機能であり、範囲の一元管理、RAMによる共有、セキュリティグループからの直接参照をそのまま満たします。

アーキテクチャ図

アーキテクチャ図の解説

中央集約型のIP範囲管理による運用効率化

この構成では、ネットワークハブアカウントに置いたマネージドプレフィックスリストが、各支社の社内IPアドレス範囲を一元的に保持しています。ネットワークチームは1か所だけを見ればよく、支社の追加や範囲の変更もリストの更新だけで完了します。

AWS Resource Access Managerによる組織単位での共有により、業務アカウントは自動的にリストを参照できます。組織単位に新しいアカウントが追加された場合も同じ共有が適用されます。開発者は自分のセキュリティグループでプレフィックスリスト（pl-9f8e7d6c）を送信元に指定するだけで、全支社の範囲を許可できます。

更新の即時反映

リストの内容が更新されると、それを参照している全アカウントのセキュリティグループの評価結果に反映されます。各アカウントでルールを個別に書き換える作業が不要になり、更新漏れや書き間違いによる不整合が起きません。

支社ごとのCIDRを手作業で配って回る運用と比べると、対象アカウントとセキュリティグループが増えても作業量が増えない点が決定的な違いです。Transit Gatewayで相互接続された環境でも、リストの共有と参照はそのまま機能します。

他のソリューションとの比較

テーブルとイベント連携で配布する案との比較では、構成要素の数と保守対象が大きく異なります。データストアの保守、各アカウントへの関数の配置、書き換えロジックの実装と例外処理まで自前で抱えることになります。プレフィックスリストはこれらをマネージド機能に置き換え、保守対象をリスト1つに集約します。

構成評価と自動修復による案との比較では、目的そのものが異なります。評価の仕組みは既存の設定が条件に合っているかを判定するもので、開発者が参照する範囲の一覧を提供しません。プレフィックスリストは参照されることを前提に設計されており、開発者の作業手順にそのまま組み込めます。

アドレス管理プールを共有する案との比較では、参照できる場所が決定的な違いです。プールはVPCやサブネットへCIDRを払い出すためのもので、セキュリティグループの送信元には指定できません。範囲の集合を通信制御から参照させる用途では、プレフィックスリストを経由する必要があります。

実装の考慮事項

プレフィックスリストの設計では、将来の拡張を見込んだ最大エントリ数の指定が重要です。参照するルールは最大エントリ数の分だけルール数を消費するため、大きすぎる値はセキュリティグループのルール数の上限を圧迫します。支社の増加を見込みつつ過大にしない値を選び、用途別や地域別にリストを分割して参照側で必要なものだけを指定する設計も検討してください。

AWS Resource Access Managerの設定では、AWS Organizationsとの統合を有効にしたうえで組織単位に対して共有し、アカウント追加のたびに手作業が発生しない状態にします。共有先を必要な組織単位に絞ることで、参照範囲を限定しながら利便性を確保できます。

セキュリティグループでの参照にあたっては、リストの用途と含まれる範囲を開発チームへ明示する文書と命名規則の整備が有効です。エントリを追加や削除するとリストのバージョンが上がり、参照側は最新バージョンを自動的に使う点も押さえておいてください。AWS CloudTrailでリストの変更操作を記録し、いつ誰が範囲を変更したかを追跡できるようにしておくことも重要です。

参考資料

【無料】AWS SAP-C02練習問題10問｜図解解説付き｜Udemy講師作成

スポンサーリンク