SAA-4.2コストを最適化したコンピューティングソリューションを設計する。

ヒントボタン

平日日中に必ず動く20台は年間を通じてほぼ変動しないベースロードです。ここにはインスタンスタイプ変更やAZ移動にも柔軟な1年Compute Savings Planを当てると、運用を縛らず割引が得られます。夜間ライブ配信で一時的に膨らむ最大100台分は短時間ピークなので、予約で全量を縛るより、Auto Scalingグループでスポットとオンデマンドを動的に増減させた方が、月間平均使用率40%という前提でも費用効率が高くなります。

スポットインスタンスは最大2分前通知で回収される特性があります。全台スポット構成では停止許容時間10分でも同時回収のリスクが残るため、混合キャパシティのAuto Scalingグループでスポット70%＋オンデマンド30%など比率を設定し、キャパシティリバランシングを有効にするのが堅実です。これにより回収シグナル受信時に別プールへ自動置換が始まり、可用性99.9%を維持しながらスポットの大幅割引を享受できます。

ピークが時間帯で読めるワークロードではスケジュールアクションやターゲット追跡ポリシーを組み合わせ、通知から2分でもバーストに追従できるAuto Scaling設計が有効です。2つのAZへ均等にスプレッドし、オンデマンドがバックフィルすることで10分以内の復旧要件も満たせます。Compute Savings Planでベースを押さえ、スポット＋キャパシティリバランシングで変動分を補う構成が、可用性・コスト・運用負荷を総合的に俯瞰した最適解となります。

ヒントボタン

日次推移と半年先までのコスト予測を一枚の画面で確認したい場合、AWS Cost Explorer には「Daily」粒度と「Forecast」パネルが初期状態で備わっています。組織で有効化した Project=WebProd タグをフィルタに入れ、さらに Purchase option・Instance type・Region の三段階グループ化を設定すれば、オンデマンドと Savings Plans の比率やリージョン差を時系列で瞬時に把握でき、S3 や Athena を介すパイプラインは不要です。これが即時性と低運用負荷の鍵になります。

AWS Cost and Usage Report＋Athena＋QuickSight を組み合わせる方法も確かに強力ですが、S3 バケットの容量管理や Glue カタログ更新、SPICE インジェストの定期実行など継続運用が不可欠です。AWS Budgets は閾値通知が中心、AWS Compute Optimizer はリソース推奨が主目的で、多軸グラフや共有ダッシュボードを即座に提供できません。「追加インフラやデータパイプラインを構築しない」という前提を満たせるサービスがどれかを見比べてください。

マルチアカウント全体のコストを素早く可視化し共有する最短経路は、組織の管理アカウントで AWS Cost Explorer を有効化し、FinOps 用 IAM ユーザーへ ce:Get* だけを付与して URL を渡す方法です。タグフィルタ、日次グラフ、12 か月先までの予測、GUI でのレポート保存と閲覧権限委譲という複数要件を単一サービスでまかなえるかを総合的に判断しましょう。

ヒントボタン

Auto Scaling の MixedInstancesPolicy を使って二つの AZ に Spot80％・オンデマンド20％で EC2 を配置すると、インスタンス不足時も余裕あるキャパシティを拾いながら平均 70％超のコスト削減が狙えます。ヘルスチェックを ELB と EC2 の両方で行えば、Spot 回収や AZ 障害が起きても Application Load Balancer が即座に正常ターゲットへ振り分け、ゼロダウンタイムを保てる点が重要です。

急激な 8,000 rps に 1 分以内で追従するには、スケジュール型ではなくターゲット追跡型スケーリングを選び、CloudWatch メトリクスとして ALB の RequestCountPerTarget を採用します。デフォルト 300 秒のクールダウンは短縮して 60 秒程度に調整し、起動テンプレートにはヘルスチェック猶予も設定しておくことで、平常時の 800 rps からプロモ直後のピークへ滑らかに拡張しつつ過剰増築を避けられます。

サブセカンドでの DB フェイルオーバーを実現したい場合は Aurora MySQL Multi-AZ DB クラスター（専用スタンバイ）を採用し、同一リージョン別 AZ に同期レプリカを常駐させます。書き込みエンドポイントが固定されつつメモリまで同期されるため切り替えは 1 秒未満で完了し、Classic RDS のスタンバイや Aurora Serverless v1 の段階型スケールより高い可用性とレスポンスを得られます。

以上を総合すると、MixedInstancesPolicy と Spot80/OD20 の ASG、ALB 指標のターゲット追跡 60 秒設定、Aurora MySQL Multi-AZ の組み合わせがコスト最適化・スケール速度・可用性すべての要件を最もバランス良く満たします。

ヒントボタン

平常時に常時稼働する20 vCPUについては1年間の利用を確約できるため、インスタンスタイプやサイズを問わずc6gを含むさまざまなGravitonインスタンスへ自動で割引が適用されるCompute Savings Planが最適です。Savings Planはドル/時間コミットで柔軟性が高く、Auto Scalingでサイズ変更しても適用範囲が外れず、Standard RIより遊休コストを抑えながら経営陣が求める50％超の削減効果を土台として提供します。

突発イベント時に追加で200 vCPUを3分以内に確保するには、EC2 スポットインスタンスを優先しつつキャパシティ不足時にはオンデマンドへ即座にフェイルオーバーするAuto Scalingのミックスインスタンスポリシーが有効です。SQSキューによるステートレス処理はスポット中断でも再投入が容易なため、ピーク時スループットとコスト効率を両立しながらSLAを満たすことができます。

年間コスト最適化を俯瞰すると、最低負荷をSavings Planなど確約系でディスカウントし、変動分をスポット→オンデマンドの順に段階利用する三層構成が要件・価格・柔軟性を総合的に満たします。逆に全量を長期コミットする案やスポット単独案は遊休コストやキャパシティ不足リスクが大きく、複数購入モデルを組み合わせるハイブリッド戦略こそ最終判断の鍵となります。

ヒントボタン

週3回各2時間だけ需要が急増するパターンでは、Auto Scalingで平常運転のベースキャパシティと突発増分を分離して考えるのが鍵です。m5.largeを常時10台使う部分は割引率約40％のStandard RIやCompute Savings Plansが最適候補ですが、月に数十時間しか走らない増分90台はSpotを併用した方が費用対効果が高く、99.9％稼働を保つには混在構成が向いています。

Auto Scaling GroupにMixedInstancesPolicyを適用すると、On-DemandとSpotを同一グループ内で柔軟に割合制御でき、capacity-optimized戦略により3つのAvailability Zoneへ余裕のあるキャパシティから順に起動されます。ベース10台分だけをOn-Demand固定にしてそこをStandard RIで1年前払いすれば価格変動やSpot中断に左右されずRTO10分内で復旧可能となり、追加分は上限価格付きSpotで自動取得することで運用負荷を増やさず40％以上の削減を目指せます。

「1年以内のコミット」「運用負荷を増やさない」「40％以上削減」という三要件を並べると、3年Convertible RIは期間要件で外れ、全台SpotはSLAを守りにくく、Compute Savings Plans単独では割引率が不足します。Standard RIで確実に使う部分を押さえ、残りをSpotで吸収する構成がコスト・可用性・運用のバランスを最も高いレベルで両立できる総合判断となります。

ヒントボタン

処理がステートレスで途中中断しても再試行できるワークロードは Spot の深い割引と再起動機構を最大限に活かせます。AWS Batch のマネージドスポット環境で c6a や m6a など複数インスタンスタイプを Capacity-Optimized 取得し、スポットキャパシティリバランシングを有効化すれば、中断リスクを抑えつつ夜間のピークでも素早く 70％超のコスト削減を狙えます。

オンデマンドのみや 1 年期 Standard Reserved Instance の割引率は 40％前後にとどまり、短時間に 10,000 件を処理するバースト型ジョブでは前払い分やアイドル時間が無駄になりやすいです。ECS の AWS Fargate オンデマンドも vCPU・メモリ単価が高く、Spot インスタンスの 70〜90％割引幅との差が大きいこと、そして Batch が提供するキュー管理や自動再試行を自前で組む運用コストも比較してみてください。

1 件 5 分・2 vCPU のジョブを 3 時間で 10,000 件完了させるには同時に約 280 台相当を確保する必要があります。AWS Batch を用い、複数 Availability Zone で多様な Spot プールを横断しリバランシングで継続稼働を図る構成は、スループット、可用性、月間費用削減という複数要件を俯瞰して最もバランスよく満たす選択肢と言えるでしょう。

ヒントボタン

p95レイテンシ200msとPod再配置60秒という厳しいSLOを守るには、Amazon EKSのスケジューラだけでなくCluster AutoscalerとHorizontal Pod Autoscaler(HPA)を併用し、需要急増やスポットインスタンス中断シグナルに即応して数十秒でm5.large相当の代替ノードを別AZへ起動させる流れを整えておくことが肝要です。
月間コストを70%以上削減し運用負荷も増やさないためには、Savings PlansやFargate Spotよりも、マネージドノードグループに容量最適化ポリシーのEC2 Spotを複数インスタンスタイプで混在させつつ、最低限のオンデマンドをベースラインとして各AZに1台残す方法が、回収リスクを抑えながら割引率70〜80%を享受しやすいです。
可用性は3AZ分散、性能はAutoscaler連携、コストはSpot＋少量オンデマンドのハイブリッド、運用はEKSマネージドノードグループに委任──これらの要件を同時に満たす構成を選ぶことで、RTO2分と70%超の費用削減を無理なく両立できると総合的に判断できます。

ヒントボタン

24時間必須となる20台は2つのAZに分散して常時稼働しないとSLAを満たせません。このベースラインはオンデマンドではなく、インスタンスタイプやサイズ変更に縛られないCompute Savings PlansやConvertible Reserved Instancesで先に割引枠を確保すると、1年間の固定コストを抑えながら将来のt3→t4gなどのリプレースにも柔軟に対応できます。

18時以降に短時間発生する最大180台分のスパイクは、Auto ScalingのMixedInstancesPolicyで複数ファミリーを束ね、容量最適化ストラテジーでEC2 Spotを優先取得すると効果的です。スポットは中断リスクを分散させれば割引率が最大90％に達し、ピークが2時間と短いため回収されても再取得しやすく、全体のコストを大幅に削減できます。

Reserved Instancesは長期固定割引、Spotは可変割引、Savings Plansは使用量コミットによる柔軟割引という違いを整理しましょう。平均稼働率が低い可変部分までStandard RIを買うと遊休コストが膨らみ、逆にスポットだけに依存すると中断で20台の下限を下回る懸念が残ります。基盤をSavings Plansで固め、変動分をSpotで吸収する構成が、30％超のコスト削減と可用性要件の両立を総合的に満たせる判断となります。

ヒントボタン

書き込みスループットを増やさずに一定期間後にレコードを自動削除したい場合、DynamoDB の Time to Live を思い出してください。有効期限を示すエポック秒を属性に追加するだけで、バックグラウンドで無料削除されるため追加の PutItem や Scan は不要です。TTL 処理はシステム側で動くので運用タスクも極小化でき、削除後はストレージ課金も即座に減少します。削除は非同期なものの数分〜数時間で完了し、ダッシュボードの Query 結果にも自然に反映される点がオンラインゲームの可視化ニーズと相性が良いです。

EventBridge でスケジュールした Lambda から PartiQL DELETE を流したり、DynamoDB Streams をトリガーにフルスキャンして BatchWriteItem で消す方法もありますが、30 日分の数億アイテムを毎日走査すれば On-Demand の RCU/WCU や Lambda 同時実行が急増しコストが跳ね上がります。加えて IAM、リトライ、障害対応の運用設計が必要になり「追加の書込やスキャンを増やさず」「運用負荷を最小に」という要件とかみ合いにくい点を踏まえて比較すると、ネイティブ機能活用の利点が際立ちます。

要件は①毎秒 5,000 件の高頻度書き込みを阻害しないこと、②30 日経過後に自動でストレージ課金を削減すること、③キャパシティ消費と運用作業を最小に抑えることの三点です。DynamoDB TTL は値を設定するだけでこれらを一括で満たし、ダッシュボードは単純な Query で最新 30 日を取得できます。保存期間が変わった場合は TTL のフィールド値を変更するだけで済む拡張性も備えており、複数要件を俯瞰しても最もシンプルで経済的な設計になります。