NAT ゲートウェイのデータ処理料金の削減 製造業の IoT 分析基盤では、プライベートサブネットで稼働する 600 個の Amazon ECS on AWS Fargate タスクが、毎月およそ 400 TB のセンサーデータを Amazon S3 へ書き込み、加工結果を Amazon DynamoDB に保存しています。各タスクは起動時に Amazon ECR からコンテナイメージを取得し、標準出力を Amazon CloudWatch Logs へ送信しています。請求内訳を確認したところ、NAT ゲートウェイのデータ処理料金が月額コストの最大項目になっていました。アーキテクチャを大きく変更せずにこの費用を削減する対策を 2 つ選択してください。
A VPC に Amazon S3 と Amazon DynamoDB のゲートウェイ VPC エンドポイントを作成し、ルートテーブルを更新して両サービス宛てのトラフィックが NAT ゲートウェイを経由しないようにする B Amazon ECR (api と dkr の両方) および Amazon CloudWatch Logs のインターフェイス VPC エンドポイントを作成し、イメージの取得とログ送信を VPC 内で完結させる C NAT ゲートウェイを削除し、Fargate タスクをパブリックサブネットに移してパブリック IP アドレスを割り当てる D NAT ゲートウェイを各アベイラビリティーゾーンに 1 台ずつ追加して通信の負荷を分散する E Amazon CloudFront ディストリビューションを S3 バケットの前段に配置し、Fargate タスクから CloudFront 経由で S3 へ書き込む
判定する 複数選択問題です (正解 2 つ)。選んでから判定してください。
解説を読む（正解: A、B） NAT ゲートウェイの料金は時間あたりの固定料金と、通過したデータ量に比例するデータ処理料金の 2 つで構成されます。プライベートサブネットから S3、DynamoDB、ECR、CloudWatch Logs といった AWS のパブリックエンドポイントへ出ていく通信もすべて NAT ゲートウェイを通るため、大量データを扱うワークロードではデータ処理料金が支配的になります。S3 と DynamoDB はゲートウェイ型 VPC エンドポイントに対応しており、エンドポイント自体の利用料もデータ処理料金も発生しません。ルートテーブルに宛先プレフィックスリスト向けの経路が追加され、両サービス宛てのトラフィックは NAT ゲートウェイを迂回するため、毎月 400 TB 分のデータ処理料金がそのまま消えます。したがって A が最も効果の大きい対策です。B の ECR と CloudWatch Logs は AWS PrivateLink のインターフェイスエンドポイントに対応しており、エンドポイントの時間料金とデータ処理料金は発生するものの、単価は NAT ゲートウェイのデータ処理料金より低く、イメージのプルとログ送信の帯域を NAT から外せます (ECR のイメージレイヤーは S3 から取得されるため、A の S3 ゲートウェイエンドポイントと併用することが前提です)。C はデータ転送の問題を一部緩和しますが、600 個のタスクをインターネットに直接面する場所へ移すことになり、セキュリティ境界を大きく変えるため「アーキテクチャを大きく変更しない」という条件と最小権限の考え方に反します。D はデータ処理料金が通過データ量に比例する以上、台数を増やしても総額は変わらず、時間料金の分だけむしろ増加します。AZ 間のデータ転送料金の削減にはなりますが、主因の解決にはなりません。E の CloudFront は S3 からの配信 (ダウンロード) を高速化し配信コストを下げるためのサービスであり、VPC 内から S3 へアップロードする経路が NAT ゲートウェイを通ること自体を回避するものではありません。
期間限定キャンペーン基盤のコスト最適化 地方自治体の観光協会が、モバイルアプリを使った期間限定のスタンプラリー抽選キャンペーンを繰り返し実施しています。各キャンペーンの終了時に応募者の中から無作為に当選者を選出し、開催期間はキャンペーンごとに異なります。キャンペーン終了後、応募データを保持しておく必要はありません。現在は Application Load Balancer の背後にある Amazon EC2 インスタンス上の独自コードで応募データを処理して当選者を選び、応募内容は Amazon RDS DB インスタンスに保存しています。協会は運営コストを削減する新しいアーキテクチャを設計する必要があります。この要件を最もコスト効率よく満たすソリューションはどれですか。
A 応募データの保存先を Amazon DynamoDB に移行し、DynamoDB Accelerator (DAX) クラスターを作成する。処理コードは Fargate 起動タイプの Amazon ECS タスクとして動作するよう書き換え、キャンペーン終了時に DynamoDB テーブルを削除する B 応募データの保存先を Amazon DynamoDB に移行し、処理コードを AWS Lambda 関数として書き換える。各項目に DynamoDB の TTL 属性を設定し、キャンペーン終了時に自動的に失効させる C RDS DB インスタンスの前段に Amazon ElastiCache for Redis クラスターを追加して応募データをキャッシュし、処理コードを Fargate 起動タイプの Amazon ECS タスクとして書き換える。各エントリに ElastiCache の TTL 属性を設定し、キャンペーン終了時に失効させる D 応募データの保存先を Amazon Redshift に移行し、処理コードを AWS Lambda 関数として書き換える。キャンペーン終了時に Redshift クラスターを削除する
解説を読む（正解: B） 稼働期間が不定で、実行されていない時間帯が長いワークロードでは、常時起動のリソースを持ち続けること自体がコストの主因になります。EC2 インスタンスと RDS DB インスタンスはアイドル時にも課金されるため、イベント発生時にのみ課金されるサーバーレス構成へ移すことが最も効果的です。Amazon DynamoDB はオンデマンドキャパシティーモードを選べば読み書きした分だけの課金となり、テーブルの維持コストも保存データ量に比例するだけです。さらに DynamoDB の TTL 属性を各項目に設定しておけば、キャンペーン終了時刻を過ぎた項目が追加料金なしで自動的に削除され、不要なデータを保持し続けるコストと削除運用の手間が同時に解消します。処理コードを AWS Lambda に移せば、抽選処理が走る瞬間だけ課金され、ロードバランサーやサーバーの維持費も不要になります。したがって選択肢 B が最もコスト効率に優れます。選択肢 A は方向性は近いものの、DAX クラスターが常時稼働のノード課金となり、要件にない読み取り高速化のために費用が増えます。選択肢 D の Amazon Redshift は大規模分析向けのデータウェアハウスであり、少量のトランザクションデータの保存先としては明らかに過剰で高価です。選択肢 C は RDS を残したまま ElastiCache を追加するため常時稼働のリソースが 2 つに増え、コストは削減どころか増加します。
API キー運用を維持したままの REST API サーバーレス化 施設園芸向けの環境モニタリングサービスを提供する企業が、自社データセンターの複数サーバーでバックエンドを運用しています。センサーデータの収集と分析ロジックは複数の機能を持つ REST API として公開されており、ハウスごとの計測値は中央のストレージに蓄積されています。バックエンドはリクエストのスロットリングと本番トラフィックおよび検証用トラフィックの区別のために異なる API キーを使い分けています。日中と夜間で負荷が大きく変動し、日中のピーク時には容量が不足する一方、夜間は大量のサーバーが遊んでいます。また計測値の参照に遅延が生じ、警報の通知が遅れる事象も起きています。経営層は、負荷変動に自動で追従し、低レイテンシーでデータを参照でき、かつ既存の REST の API モデルを変更せずに移行できるクラウドアーキテクチャを求めています。この要件を満たすソリューションはどれですか。
A Network Load Balancer で REST API を公開し、その背後の Amazon EC2 インスタンスで分析ロジックを実行する。計測値は Amazon Aurora Serverless に保存する。 B Amazon API Gateway で REST API を公開し、分析ロジックを AWS Lambda で実行する。計測値はオンデマンドキャパシティモードの Amazon DynamoDB に保存する。 C Application Load Balancer で REST API を公開し、分析ロジックを AWS Lambda で実行する。計測値はオンデマンドキャパシティモードの Amazon DynamoDB に保存する。 D AWS AppSync で API を公開し、分析ロジックを AWS Lambda で実行する。計測値は Amazon Aurora Serverless に保存する。
解説を読む（正解: B） Amazon API Gateway の REST API は、API キーと使用量プランを組み合わせることでクライアントごとのスロットリングとクォータを設定でき、本番用と検証用でキーを分ける既存の運用をそのまま持ち込めます。バックエンドを AWS Lambda にすれば、リクエスト数に応じて実行環境が自動的にスケールし、夜間のアイドル分に課金されません。Amazon DynamoDB のオンデマンドキャパシティモードは、トラフィックの増減に合わせてスループットを自動調整しつつ 1 桁ミリ秒台の応答を返すため、参照遅延の解消に適しています。選択肢 B はこの 3 つを組み合わせており、API モデルを変えずに伸縮性と低レイテンシーを実現します。選択肢 A は Network Load Balancer が L4 のロードバランサーであるため API キーによる認可やスロットリングを自前で実装する必要があり、EC2 のキャパシティ計画も残ります。選択肢 C の Application Load Balancer は Lambda をターゲットにできますが、API キーと使用量プランに相当する機能をネイティブに備えていないため、レート制限の仕組みを別途構築しなければなりません。選択肢 D の AWS AppSync は GraphQL 向けのマネージドサービスであり、クライアントとスキーマの作り直しが必要になるため「既存の API モデルを変更しない」という要件に反します。