DVA-4.3AWS のサービスと機能を使用したアプリケーションの最適化

ヒントボタン

ヒント1
カタログの更新は15分単位で、利用者が許容する遅延は5分＝300秒です。この数字をそのまま TTL に当てはめ、Amazon API Gateway のステージキャッシュを有効にし productId をキャッシュキーにすると、300秒間は同一リクエストがすべてキャッシュヒットとなり、1秒あたり2,000件の呼び出しの大半を Lambda や DynamoDB へ流さずに済みます。これだけで読み取りキャパシティとレイテンシの両方を大幅に削減できます。

ヒント2
「コード変更を最小に」という条件に注目すると、Lambda で ElastiCache Redis を組み込む、あるいは DynamoDB を DAX に置き換える場合は SDK や接続ロジックを書き換える手間が発生します。CloudFront を前段に挟む手もありますが、オリジン設定や署名付き URL、CORS など調整項目が多めです。それに比べ、API Gateway のステージキャッシュは既存リソースを触らずにコンソールや CLI でオンにするだけで導入でき、運用負荷やデプロイ作業を最小限に抑えられます。

ヒント3
キャッシュ位置の選択は「更新間隔」「許容遅延」「呼び出し経路のどこをバイパスしたいか」「実装コスト」を総合的に比較することが鍵です。CloudFront では TTL が長く、DAX や ElastiCache はコード改修が必要という制約が浮かび上がります。ピークトラフィック2,000 req/s の読み取り集中を軽減し、Lambda と DynamoDB の負荷・コストを同時に下げる解決策としては、API Gateway が提供するネイティブなステージキャッシュに TTL300秒を設定する方法が最もバランス良いと判断できます。

ヒントボタン

Amazon ECS のタスク配置でコストを極小化したい場合、m6i.xlarge（4 vCPU,16 GB）に対し CPU 1024 unit／2 GB のタスクが理論上 4 個収まる点を押さえ、binpack(CPU) を選択すると Scheduler が空き vCPU の少ないインスタンスへ順に詰め込み、ピーク 40 タスク時でも必要台数を最小の 10 台に抑えながら Auto Scaling グループが残余リソースゼロを検知して即座にスケールインできるため追加運用設定が不要となります。
spread 戦略で attribute:ecs.availability-zone や host を指定すると Amazon ECS はタスク数を均等化し高可用性は得られるものの、CPU とメモリが大幅に余るインスタンスが各 AZ に散在して CloudWatch メトリクスの平均使用率が閾値を下回らず EC2 Auto Scaling の停止トリガーが遅れるため、コスト削減を主目的とするワークロードでは均等化よりも binpack でリソースを詰め込む思考が効果的となります。
マルチ AZ にまたがる Amazon ECS クラスターで動画エンコードタスクをピーク 40 個実行しつつアイドルリソースを最小化し、追加の Lambda や運用スクリプトを用意せず即時スケールインしたいという複合要件を俯瞰すると、リソース効率を最大化する binpack(CPU) 戦略が EC2 起動タイプ・Cluster Auto Scaling と最も整合し、性能・可用性・コストのバランスを総合的に満たす選択と判断できます。

ヒントボタン

Amazon RDS Proxy は MySQL 8.0 と統合され、接続プールで Fargate が開く多数のコネクションを束ねつつ、設定でリード / ライト分離を有効にすると SELECT を自動でリードレプリカに、INSERT や UPDATE をプライマリに送ります。書込み性能を落とさず読取りを逃がせ、変更点はアプリケーションの接続先をプロキシエンドポイントに置き換えるだけなので、コード改修は最小限で済みます。

Route 53 の加重レコードや AWS Global Accelerator は TCP レベルで単に接続を振り分けるだけで、クエリ内容を解釈してルーティングを変える機能がありません。そのため INSERT がレプリカに送られてエラーになる恐れがあり、DNS キャッシュの影響で比率も不安定です。さらにこれらの仕組みは接続プールを持たないため 500 の同時接続がそのまま RDS へ届き、max_connections を圧迫してメモリや CPU の枯渇リスクを高めます。

要件を整理すると、①プライマリへの書込みスループット維持、②SELECT の自動的なレプリカ転送、③接続プールで接続数削減、④既存 Amazon RDS for MySQL からの移行コスト最小化、の四つを同時に満たす必要があります。Aurora 移行はデータコピーや検証が大掛かりで、DNS やネットワーク負荷分散はクエリ種別を理解しないため条件不足です。これら複数要件を俯瞰すると、リード / ライト分離オプションをもつ Amazon RDS Proxy が最も適切であることが見えてきます。

ヒントボタン

Amazon SQS で空レスポンスを抑える最も効果的な方法はロングポーリングです。ReceiveMessageWaitTimeSeconds を最大値の 20 秒に設定すると、メッセージが存在しない間は待機し、到着した瞬間に応答するため無駄な API 呼び出しが大幅に減少します。キュー投入後すぐレスポンスが返るので平均遅延は数十ミリ秒に収まり、ECS のワーカー数を増やさずとも現在のスループットを維持できます。

ReceiveMessage API の MaxNumberOfMessages を 10 にしてバッチ受信を組み合わせると、1 回で最大 10 件のメッセージを取得でき、Standard キューを使った 10 タスクが毎秒 50 件処理するケースでも呼び出し回数を 90% 以上削減可能です。バッチ化はメッセージ単価に影響せず、VisibilityTimeout を何秒にしても機能が損なわれないため、コスト効率と性能を両立できます。

追加ワーカーを用意しない、平均取り込み遅延 100ms 以内、空レスポンス 90% 以上削減、コスト最小という複数要件を並立させるには、Standard キューのロングポーリング＋バッチ受信が最も現実的です。SNS への置換はプッシュ配信の運用負荷、FIFO への移行はスループット制限、短ポーリングのままのスケールアウトは API コスト増につながるため、総合判断でロングポーリング構成が最適となります。

ヒントボタン

Amazon SQS では ReceiveMessage API の課金が「メッセージを返した回数」に基づくため、WaitTimeSeconds=0 のショートポーリングを 1 秒間隔で続けると空振りリクエストがそのままコストになります。キュー側に ReceiveMessageWaitTimeSeconds=20 を設定し、ECS Fargate も同じ秒数で最大 10 件をまとめて取得するロングポーリングに切り替えれば、空振り時は接続を保持するだけで追加課金が発生せず API 呼び出し回数を大幅に削減できます。

FIFO キューは順序保証や重複排除が強みですが、1 秒あたりのトランザクション数に上限があり、現状のピーク 3,000 件/分をさばくには制御グループ設計など追加検討が必要です。可用性は Standard と同等でも、ポーリングをショートのまま維持すれば空ポーリング問題は残ります。まずは Amazon SQS Standard のままポーリング方式をロングへ変えるほうが、ワークロードを大規模改修せずにスループットとコスト最適化を両立しやすいです。

Amazon Kinesis Data Streams や DynamoDB Streams へ全面移行すると API インターフェース、再試行、可視性タイムアウトなどの違いを吸収する追加開発が発生します。要件は「5 秒以内にジョブ開始」「高い可用性」「API コスト圧縮」の三点ですから、既存の SQS 標準キューを活かし ReceiveMessageWaitTimeSeconds とバッチ取得数を調整するのみで三つを同時に満たせる選択肢が、複数要件を俯瞰した総合判断として最も合理的です。

ヒントボタン

Regional タイプの Amazon API Gateway にはリージョン内リソースとして AWS WAF v2 Web ACL を直接関連付けられ、IP セットで 10.0.0.0/8 を拒否すると API Gateway に到達する前にレイヤ7で遮断できるため、VPC のネットワーク ACL や Lambda オーソライザーと異なりマネージドでスケーラブルな制御をコードレスで実装でき、ピーク 50,000 rps でも追加設定なしに遅延を抑え、費用削減効果を最大化できます。
さらに AWS WAF v2 のレートベースルールでは「同一 IP 単位で N リクエスト／5 分」という定義がコンソールだけで行え、2,000 を設定すれば Lambda バックエンドへの不要トラフィックを自動的に抑制できるため、API Gateway ステージスロットリングの平均＋バースト方式や CloudFront への迂回より要件に合致し、閾値変更も数クリックで運用が軽くなります。
今回の要望はレイテンシ最小化、CIDR ブロック拒否、IP ごとの 5 分間レート制限、30％コスト削減、運用負荷最小化という多面的条件であり、API Gateway とネイティブ統合する AWS WAF v2 を採用すると全項目を同時に達成できる一方、VPC NACL、WAF Classic、カスタム Lambda などは範囲や保守で妥協が生じるため、複数要件を俯瞰し最も整合性の高いマネージド構成を選ぶ視点が肝要です。

ヒントボタン

Cookie marketing_cookie=beta を持つ約10%のブラウザだけを新バージョンへ送り込むには、HTTP レイヤで Cookie をネイティブに評価できる Application Load Balancer のリスナールールを利用して Blue/Green 両方のターゲットグループを定義し、そのルール一つで振り分け率を宣言的に管理できる構成が最小工数であり、Lambda など追加サービスを介さないため遅延も増えずシステムがシンプルに保てます。
リクエストがインスタンス1台あたり100件に達したら自動的に拡張させたい場合は、Auto Scaling グループで Application Load Balancer 統合メトリクス ALBRequestCountPerTarget をしきい値100に設定すると、CPU 使用率や SQS キュー長のようにワークロードに応じた調整を試行錯誤する必要がなく、HTTP 要求数というビジネスに直結した指標で確実にスケールアウト・インが行われ、運用者の監視負荷が大幅に軽減されます。
Route 53 の加重ルーティングや Classic Load Balancer のスティッキーセッションは Cookie 値を認識できず、Network Load Balancer は L4 製品で HTTP ヘッダーすら扱えない一方、パスベース振り分けでは URL に依存するため今回の要件から外れるため、Cookie 条件判定と ALBRequestCountPerTarget によるスケーリングという二つのゴールを同時に満たしつつ最小の運用負荷で済むのは Application Load Balancer と Auto Scaling の組み合わせであると俯瞰して判断できます。

ヒントボタン

Python 3.11 で 8 MB の画像をリサイズする程度の CPU バウンド処理は、AWS Lambda ではメモリ設定に比例して vCPU とネットワーク帯域も増える特性があります。例えば 512 MB から 1024 MB に引き上げると計算資源がほぼ倍になり、実行時間が半分近くになるケースが多く、GB-秒課金はメモリ増と時間短縮でほぼ相殺できます。アプリケーションコードを変えずに性能を伸ばしたいときはまずコンソールでメモリを段階的に試し、CloudWatch Logs Insight や AWS Lambda Power Tuning の結果を確認すると効果とコストの関係を定量的に把握できます。

コールドスタートを避けるためのプロビジョンド同時実行は AWS Lambda の初期化遅延には効きますが、ウォーム状態でも 9 秒掛かっている処理時間自体には影響しません。また Amazon SQS でバッチサイズを拡大してもコードが直列で走るままなら 10 枚分の合計時間が必要になり、1 枚あたり 5 秒以内という目標に届きにくくなります。プロビジョンド同時実行の固定課金やバッチ化による GB-秒増大が月次コストに直結する点も忘れずに考慮しましょう。

今回の要件は「5 秒以内の処理」と「月間コスト 20% 増以内」を両立し、なおかつ運用変更を最小限に抑えることです。メモリ設定の調整だけで vCPU を増やして処理を短縮し、GB-秒をほぼ横ばいに保てるアプローチなら追加サービス導入や Amazon EC2 への移行よりシンプルかつ要件適合度が高いと総合的に判断できます。

ヒントボタン

30MBのgzip動画を復号してサムネイルを作る処理は明らかにCPUを酷使します。AWS Lambdaではメモリ値を上げると比例してvCPUとネットワーク帯域幅も増えるため、512MBから3000MB級へ引き上げるだけで1インスタンス当たりの所要時間を数分の一に短縮でき、結果としてAmazon SQSのバックログ圧縮に直接効いてきます。また動画チャンクが大きくI/Oも激しいため、ネットワークスループット向上の恩恵も受けられ、S3への書き込みまで含めた総実行時間が短くなる点も忘れないでください。

到着レートが秒間50件なら、関数の同時実行上限を300のままでは単位時間当たりの処理枠が足りず、ピーク時に未処理5万件が溜まるのは自然です。Reserved Concurrencyを拡大すればスロットが確保されオートスケールが頭打ちにならず、Amazon CloudWatchのスロットリングアラームも沈静化します。さらにSQSのReceiveMessageバッチサイズを維持すれば呼び出し回数を増やさずに済むため、料金増加は主にCPU時間の削減で相殺され、可視性も高まります。

Visibility Timeoutの短縮やFIFO化は重複実行やスループット上限に別の問題を持ち込み、メモリを下げてスレッド化してもvCPUが減るため逆効果になりがちです。特にFIFOはメッセージグループ設計変更やDLQ再構築も伴い運用負荷が増すため、本質であるスループット不足を解決するまでの時間も延びかねません。コード変更を避けつつ課金を抑えたいなら、LambdaをスケールアップしつつReserved Concurrencyでスケールアウトを組み合わせる総合策が最も堅実と判断できます。

ヒントボタン

CloudWatch の PutMetricData はリージョン当たり毎秒 150 トランザクションという厳格な TPS 上限があり、Amazon ECS から 800 rps を投げれば ThrottlingException が必ず返ります。AWS SDK for Go v2 には Retryer を拡張して指数バックオフとフルジャitterを組み込み、MaxAttempts を引き上げることでクライアント側で呼び出しを自動平滑化できる仕組みがあります。アプリケーションコードに大きな変更を入れずにデータ欠損を防ぐには、このリトライ戦略とメモリ内キューでの遅延再送を組み合わせ、ピーク時の呼び出しを時間的にスプレッドさせるのが最小工数で効果的です。
VPC エンドポイントを使うと CloudWatch までのネットワーク往復は短縮されますが、サービス側の TPS 制限は変わらないためスロットリング問題は継続しますし、CloudWatch Logs ＋ Subscription Filter へ切り替えると 1 分粒度の遅延が発生しリアルタイム性を失います。Keep-Alive を外して毎回 TCP 接続を張り直すと通信遅延と CPU が増え、観測データの秒単位可視化に悪影響が出ます。根本的には API 上限を超えないようコールを間引くか再送するしかなく、SDK の高度なリトライ機構やフルジャitterが公式に推奨されていることを思い出してください。
つまり、CloudWatch という共有リソースの TPS 制限という制約・リアルタイム可視化の要件・Amazon ECS タスクの運用負荷最小化という複数の観点を俯瞰すると、ネットワーク経路やログ基盤を作り替えるより、既存の AWS SDK for Go v2 の Retryer 拡張とメモリ内バッファによる指数バックオフ＆フルジャitter実装でクライアント側だけでスロットルを吸収するアプローチが最もバランスに優れていると整理できます。

ヒントボタン

DynamoDB は PutItem が届くとハッシュ計算で格納先パーティションを決めますが、1 パーティションが処理できる上限は秒間 1,000 WCU 程度です。ピーク 2,400 書込/秒の 40% が少数の userId に集中すると上限を超え遅延が発生します。userId に 00〜99 のランダムサフィックスを付けキー数を 100 倍に増やすと各パーティションへ平均 24 WPS で散り、オンデマンド課金でも無駄なプロビジョニングなしにレイテンシを抑えられます。

DynamoDB のプロビジョンド WCU を極端に拡大しても内部パーティション構造は変わらず、ホットキーが残ればスロットリングは続きます。Global Table は多リージョン可用性を高める仕組みでパーティション分散には寄与せず、DAX は GetItem や Query をキャッシュする読み取り専用サービスで PutItem の書込み負荷は軽減できません。根本解決には書込みキー自体の偏りをなくすアプローチが有効です。

求められる要件は 99.9% 可用性、コスト効率、運用簡素化、そして書込みスループットの平準化です。DynamoDB のパーティション上限、オンデマンドモードの従量課金、クライアント側での並列 Query 集約といった複数観点を俯瞰し、最小限の変更でホットパーティションを防ぎつつ可用性を維持できる設計を選択するのが総合的に妥当と言えるでしょう。

ヒントボタン

1 インスタンスで安定して 50 RPS を処理できるという前提があるなら、Application Load Balancer の CloudWatch メトリクス RequestCountPerTarget を 50 に狙い撃ちするターゲット追跡スケーリングが最も素直で、Elastic Beanstalk の Managed scaling をオンにして目標値を入力するだけで昼夜のトラフィック変動に合わせて最小 1 台から最大値まで自動で台数を滑らかに変化させられます。
CPUUtilization や平均レスポンスタイムをトリガーにすると、ガベージコレクションや一時的なスパイクの影響で負荷と相関がずれ、Auto Scaling の調整が遅れたり過剰になったりしやすいのに対し、ALB が集計するリクエスト数はトラフィック量そのものを示すため、Node.js コンテナの内部状態に左右されずコスト面と p95 レイテンシ維持の両方に直結した判断材料になります。
昼間 500 RPS、夜間 50 RPS、p95 200 ms 未満、運用負荷低減、コスト最適化という複数要件を俯瞰すると、Elastic Beanstalk 生成の Auto Scaling グループを Managed scaling で制御し、ALB の RequestCountPerTarget を目標値とするターゲット追跡を採用する構成が設定簡素化と性能担保を同時に満たす総合的にバランスの良い選択となります。

ヒントボタン

API の応答時間を 100 ミリ秒未満に保つには、30 秒かかる在庫確定を呼び出し元から切り離し、Amazon SQS などのキューに即時書き込んでからレスポンスを返す非同期化が鍵です。キュー投入はネットワーク往復のみで済むため Web 環境の待機がほぼ消えます。また SQS 標準キューは at-least-once 配信で重複メッセージも許容される設計なので、「一度は必ず届き、重複してもよい」という要件に自然に合致します。

ピークで毎分 2,000 件＝毎秒 33 件を処理するには自動スケールが不可欠です。Elastic Beanstalk ワーカー環境は SQS キューを自動生成し、CloudWatch の ApproximateNumberOfMessagesVisible や AgeOfOldestMessage を使って EC2 インスタンスを水平スケーリングできます。VisibilityTimeout を 45 秒ほどに設定すれば平均 30 秒の処理が終わる前に再配信されるリスクが低く、MinSize を 0 にしておけば無負荷時は台数ゼロまで縮退でき、コスト最適化も実現します。

追加実装を最小限にしたい場合、既存 Elastic Beanstalk Web 環境の横に同一アプリケーションとしてワーカー環境を増設する方法が最も工数を抑えられます。デプロイ手順、ログ取得、IAM ロールなどの運用モデルが共通のまま、キュー送信コードの数行追加で移行できるため学習コストが低いです。他サービスで同等機能を組むと新規設定や制限対応が増えるため、複数要件（応答性能・配信保証・自動スケール・開発負荷）を総合的に見ると、このキュー連携型の Elastic Beanstalk 構成が最もバランスの良い選択になります。

ヒントボタン

HTTP/2 を途切れなく扱いながら WebSocket のハンドシェイクも通し、かつ AWS Certificate Manager の証明書でロードバランサ側に TLS 終端を置き、自動で X-Forwarded-For ヘッダーを付ける機能はレイヤ 7 フルプロキシの Application Load Balancer が標準で備えています。Network Load Balancer や Classic Load Balancer では HTTP/2 未対応やヘッダー付与不可などどこかで要件を取りこぼす点に気付けると選択肢が絞られます。最新の AWS Well-Architected Framework でもこの組み合わせが推奨されています。

ECS Fargate で awsvpc ネットワークモードのタスクを公開する場合、サービス作成ウィザードで Application Load Balancer のターゲットグループを指定すれば IP 単位登録、ヘルスチェック、Auto Scaling がマネージドで連携し、CloudWatch Logs に記録すべきクライアント IPv4 もヘッダー経由で確実に取得できます。Network Load Balancer は IP 登録こそ可能でもヘッダーを扱えず、Classic Load Balancer は HTTP/2 に対応しないため追加ミドルウェアが必要になることを想像すると、最小限の設定変更という条件とずれてきます。

HTTP/2・WebSocket・ACM 統合・X-Forwarded-For 挿入・Fargate 連動・将来のパスベースルーティング拡張という複数要件を俯瞰し、Amazon CloudFront はヘッダー名相違、Network Load Balancer は L4 専用、Classic Load Balancer は旧世代であることを比較すると、単一サービスで全項目を一度にクリアできる Application Load Balancer こそが最小構成という総合判断に行き着くはずです。

ヒントボタン

1行目
Kinesis Data Streams の取り込み量が秒間 20 MB とピーク変動する場合、Spark Structured Streaming を常時実行する Amazon EMR で Managed Scaling を有効化すると YARN メトリクスに応じてワーカ数が数分単位で自動増減し、スループットを確保しつつ Spot インスタンス併用でコストも抑えられます。

2行目
長時間動き続けるストリーミング処理ではノード入替え時のシャッフルデータ損失が致命的です。Enhanced Resilient Shuffle はシャッフルを S3 と DynamoDB にオフロードするので HDFS 消失の影響を最小化でき、Graceful Decommission と組み合わせれば Spot 落選やメンテナンスでもジョブを途切れさせません。

3行目
「1 分以内に応答」「変動負荷で自動調整」「最小運用工数」「費用削減」という複数要件を並立させるには、バッチ起動や CloudWatch ベース手動設定よりも EMR 6 系のマネージド機能をフル活用した構成が総合的にバランス良好だと判断できます。

ヒントボタン

ヒント①
クロスアカウントで 2,000 rps のイベントを安全に運ぶときは EventBridge の custom イベントバスを受信側（分析基盤アカウント）に用意し、送信側 default バスのルールでその ARN を「別アカウント宛てターゲット」として指定するのが推奨パターンです。custom バスにはリソースポリシーで events:PutEvents を発行元アカウントだけに許可すれば、意図しない第三者からの呼び出しをバスの入口で遮断でき、要件の「他の送信元を拒否」をシンプルに満たせます。

ヒント②
EventBridge には「バッチ転送」「最大 24 時間の自動再試行」「デッドレターキュー連携」など運用を助ける機能が組み込まれており、これらは同サービス内でルーティングされた場合にのみフル活用できます。受信側バスに届いた後はルールで SQS FIFO キュー Orders.fifo をターゲットに設定し、キューのリソースポリシーで Service Principal events.amazonaws.com かつ SourceArn＝そのルール ARN の SendMessage を許せば順序保証を保ったまま配信が行われます。

ヒント③
最小権限を徹底するなら「送信権限は PutEvents だけ」「転送権限は EventBridge サービスロールが持つ SendMessage だけ」「キュー側は指定ルールからの SendMessage だけ」という三層分離が鍵です。API Destination は HTTP 専用で AWS エンドポイント向け署名付きリクエスト発行が煩雑、SNS は FIFO 順序保証や EventBridge のリトライ機能を活かせないため運用負荷が上がります。要件①～③を横断的に満たせる構成を俯瞰すると、イベントを EventBridge でクロスアカウント受け渡しし、リソースポリシーで権限を絞り込んだ後に SQS FIFO へ届ける手順が最も整合的です。

ヒントボタン

1行目
Lambda はステートレスで短命なため実行環境ごとに MySQL への TCP セッションを新規確立しやすく、db.t3.medium の max_connections 120 を超えると 502 が出ます。Amazon RDS Proxy を API Gateway 直後で使えば 600 同時実行を 120 のプール接続に集約でき、ハンドラ外で 1 度接続した後は再利用されるのでハンドシェイク 50 ms × 毎回のオーバーヘッドが消え、150 ms 以内のレスポンスに近づきます。

2行目
インスタンスを r6g.2xlarge へ垂直スケールしたり Amazon SQS と Auto Scaling の EC2 ワーカーを組む方法もありますが、前者は Aurora や RDS の料金が数倍になり、後者はキュー待ちやポーリング遅延でリアルタイム要件を逸脱する恐れがあります。RDS Proxy はエンドポイントを差し替える程度でコード変更が小さく、従量課金も接続プール単位で済むため「コスト最小」と「修正最小」の両軸でバランスが良い選択肢です。

3行目
同時実行 600、平均クエリ 50 ms、レイテンシ 150 ms 未満、接続上限 120、運用コストと改修工数抑制という複数要件を俯瞰すると、接続プール機能をマネージド提供し Lambda でも簡単に統合できる Amazon RDS Proxy を導入する設計が最も自然な落とし所と判断できます。

ヒントボタン

まず、東京とバージニア北部に展開した Amazon ECS on Fargate へ世界各地から届くリクエストを常に最小遅延でさばくには、DNS レベルで RTT を測定して応答を返す Route 53 のレイテンシールーティングが王道です。ALB を ALIAS レコードとしてゾーン apex に登録すれば CNAME を分ける手間なく単一ドメインで 1 秒あたり 3 万要求も分散でき、平均 150 ms 未満のレスポンスを維持しやすくなります。

加えて、各リージョンの ALB に紐付けた Route 53 ヘルスチェックを 30 秒周期で実施し、連続 5 回失敗した時点で対象レコードを不健康と判定させれば、DNS 応答から除外されてもう一方の ALIAS へ自動切替が行われます。アプリやスクリプト側に特別な DR 処理を組み込まずともフェイルオーバーが成立し、運用負荷を大幅に抑えられます。

レイテンシポリシーはパフォーマンスと可用性を両立し、マルチバリューのランダム性や地理ルーティングの静的設定、フェイルオーバーポリシーの単一プライマリ固定といった他方式の弱点を避けながら、Route 53 だけで低遅延誘導・自動切替・シンプル運用という三つの要件を同時に叶える総合的な優位性を持っています。

ヒントボタン

DynamoDB はオンデマンドに切り替えても直近実績の約 2 倍からしかキャパシティが立ち上がらず平常時 50 WCU のテーブルでは 10,000 件/秒のスパイクを受けると WriteThrottleEvents が頻発するため、API Gateway と Lambda からの PutItem をそのまま同期で流すのではなく一度バッファに詰めて書き込みレートを平滑化しないとレスポンス遅延が RTO に影響しエラーリトライに伴うコストも膨らみます。
バッファサービス候補のうち Kinesis Data Streams はシャード数拡張や EC2＋KCL ワーカーの運用が発生して最小変更という条件に合いにくいのに対し、SQS 標準キューはスループットがほぼ無制限で API Gateway から HTTP で直接送信でき、可視性タイムアウトや保持期間でデータを安全に保持しつつ Lambda の自動ポーリングと統合できるため運用負荷とコストを最小化できます。
Lambda 側でバッチサイズを 10、予約同時実行数を 50 に限定し BatchWriteItem により DynamoDB へまとめ書きを行えば理論上 500 レコード/秒に抑えられて既存の 500 WCU と整合し、ピークで SQS に溜まったメッセージもスパイク終了後に10 分以内で掃き出せる計算となるので、RPO=0 と RTO 10 分を守りつつコストと開発変更量を抑えられる選択肢だと総合的に判断できます。