NAT ゲートウェイのデータ処理料金の削減
製造業の IoT 分析基盤では、プライベートサブネットで稼働する 600 個の Amazon ECS on AWS Fargate タスクが、毎月およそ 400 TB のセンサーデータを Amazon S3 へ書き込み、加工結果を Amazon DynamoDB に保存しています。各タスクは起動時に Amazon ECR からコンテナイメージを取得し、標準出力を Amazon CloudWatch Logs へ送信しています。請求内訳を確認したところ、NAT ゲートウェイのデータ処理料金が月額コストの最大項目になっていました。アーキテクチャを大きく変更せずにこの費用を削減する対策を 2 つ選択してください。
複数選択問題です (正解 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 ゲートウェイを通ること自体を回避するものではありません。
高負荷時のアプリケーション可観測性の確保
スポーツ観戦チケットを販売する企業が、AWS 上で 3 層構成のウェブアプリケーションを運用しています。フロントには Amazon CloudFront があり、Java で実装された予約エンジンは Apache ウェブサーバーを載せた Amazon EC2 インスタンス群 (Auto Scaling グループ) 上で動作し、バックエンドは Amazon Aurora MySQL DB クラスターです。先週のテレビ CM 放映直後にアクセスが急増し、利用者から座席をカートに入れる操作がタイムアウトするという報告が相次ぎました。運用チームが原因を調べようとしたところ、スケールインによって一部の EC2 インスタンスがログ回収前に終了しており、Aurora 側もどのクエリが遅延の原因かを判断できるだけの情報が残っていませんでした。次回以降のトラフィック急増時にアプリケーションの挙動を詳細に把握できるようにするために実施すべき対策はどれですか。3 つ選択してください。
複数選択問題です (正解 3 つ)。選んでから判定してください。
解説を読む（正解: A、B、D）
可観測性の課題は「揮発するインスタンス上にデータを残さない」ことと「層をまたいだ処理の内訳を可視化する」ことの 2 点に整理できます。まず A は、Aurora MySQL がスロークエリログとエラーログを CloudWatch Logs へ直接発行できる機能を利用するもので、どのクエリが閾値を超えたかを永続的に保持し、Logs Insights で集計できるようになります。次に B の AWS X-Ray SDK for Java は、受信 HTTP リクエストにトレース ID を付与し、JDBC 呼び出しなどのダウンストリーム処理をサブセグメントとして記録するため、遅延がウェブ層で発生しているのか SQL 実行で発生しているのかをサービスマップ上で切り分けられます。D は CloudWatch Logs エージェントで Apache のログをほぼリアルタイムに転送する対策で、Auto Scaling によってインスタンスが終了してもログが失われないという、本問の中心的な課題を直接解決します。誤りの選択肢を見ると、C は Aurora の DB クラスターログの発行先として Kinesis を直接指定する機能が存在しないため実装できません。E の CloudTrail は AWS API 呼び出しの監査記録を残すサービスであり、アプリケーション内部のリクエスト処理時間や SQL の遅延は記録対象外です。F は Aurora に「パフォーマンスベンチマークを有効化して X-Ray へ発行する」という機能自体が存在せず、DB 側の詳細分析には Performance Insights など別の仕組みを使う必要があります。
共有 DynamoDB テーブルのテナント別コスト按分
勤怠管理 SaaS を提供する企業が、マルチテナント環境を運用しています。ストレージ層ではすべてのテナントが共通の Amazon DynamoDB テーブルを共有しており、アプリケーションのビジネスロジックは AWS Lambda 関数で実装されています。各テナントは、Lambda 関数へのすべてのリクエストに含まれる一意のテナント ID で識別されます。同社は、テナントごとのリソース消費量に応じた段階的なサブスクリプション料金体系を新たに提供しようとしており、その前提として DynamoDB の利用料金をテナントごとの消費量に比例して配賦したいと考えています。AWS アカウントでは AWS コストと使用状況レポート (AWS CUR) がすでに有効化されています。最も少ない運用工数でテナント別の DynamoDB コストの内訳を得られるソリューションはどれですか。
解説を読む（正解: B）
AWS の請求データは基本的にリソース単位で集計されるため、複数テナントが 1 つの DynamoDB テーブルを共有するプール型のマルチテナント構成では、請求情報だけからテナント別のコストを割り出すことはできません。この場合の定石は、アプリケーション側でテナントごとの実消費量を計測し、その比率で実際の請求額を按分する方式です。DynamoDB の API レスポンスには ReturnConsumedCapacity を指定することで各操作が消費した RCU / WCU が返されるため、B のように Lambda 関数がテナント ID と消費キャパシティユニットを CloudWatch Logs へ記録すれば、テナントごとの正確な使用量を継続的に取得できます。あとは別の Lambda 関数が定期的に、ログから集計した使用量と AWS Cost Explorer API から取得した実際の DynamoDB 合計コストを掛け合わせて按分し、EventBridge のスケジュールルールで自動実行すれば、既存のデータモデルを変更することなく詳細な内訳が得られます。A は誤りで、コスト配分タグはリソース (テーブル) 単位でしか集計できないため、1 つのテーブルを共有するテナント間のコストを分割できません。C はテナントを識別するためにパーティションキーを設計し直す必要があり、既存データの移行とアプリケーション改修を伴う大規模な作業となるうえ、項目数はキャパシティ消費量と比例しないため按分の精度も低くなります。D はレスポンスサイズや実行時間からキャパシティ消費を推定する間接的な方法で精度が劣るほか、AWS Pricing Calculator は将来の見積もりを算出するツールであり、実際に発生した請求額を取得する用途には使えません。