CLF-1.4クラウドエコノミクスのコンセプトを理解する。

ヒントボタン

年に2週間だけトラフィックが急増し残りはほぼ無風というパターンでは、EC2やEKSの起動時間課金が発生する構成よりも、API Gateway と AWS Lambda のリクエストベース課金と Amazon S3＋CloudFront へ静的資産を置くサーバーレス構成が、スパイク時は自動で水平スケールして数千万リクエストを処理し平常時は費用0円に抑えられるため初期投資ゼロを実現しやすく、さらにインフラパッチ適用や台数管理の運用負荷も排除できます。
Spot Instance は大幅な割引が魅力ですが世界的セール時など需要集中タイミングで中断されるリスクがあり、リザーブドインスタンスや Compute Savings Plans は長期間コミットしてこそ効果を発揮するためほとんどアイドルの10ヶ月以上にも料金が発生し、結果として年2週間だけ1,000万リクエスト規模の負荷をさばくワークロードでは Lambda や S3 の従量課金に比べコストや調達確実性の面で優位性を持ちにくいと考えられます。
今回の要件である初期費用なし、普段のランニングコスト最小化、大規模リクエストの自動スケール、サーバー保守工数削減を総合的に勘案すると、フルマネージドでイベント駆動の AWS Lambda と API Gateway、安価で耐久性の高い Amazon S3 と高速配信を支える CloudFront を組み合わせたサーバーレスアーキテクチャが複数条件を同時に満たすバランスの良い選択と言えるでしょう。

ヒントボタン

通常 2 000req/s が 50 000req/s に跳ね上がる負荷変動では、EC2 Auto Scaling の MixedInstancesPolicy でオンデマンドをベースキャパシティに、スポットをスケールアウト側に割り当て、SavingsPlans や RI と組み合わせ、InstanceRefresh でパッチも自動化すると、ピーク時 90% 割引を活かしながら運用負荷を抑えつつ 40% 以上のコスト削減と 30 分以内の復旧が狙えます。
既存 SQL Server ライセンスを生かすには BYOL と License Mobility が鍵であり、RDS for SQL Server を Multi-AZ で構成するか EC2 上で SQL Server を運用する方法が適合し、マネージドバックアップや自動フェイルオーバーにより RTO 30 分を余裕でクリアしつつパッチは AWS Systems Manager が担い、Aurora MySQL や DynamoDB はコスト面で魅力があってもライセンス資産を消費せず要件外となります。
ベーストラフィックを 3 年コンバーチブル RI ないしオンデマンドで確保し、急激なスパイクをスポットインスタンスで吸収する EC2 Auto Scaling と、BYOL に対応した SQL Server を RDS Multi-AZ もしくは License Mobility 付き EC2 で高可用化する構成が、スケーラビリティ、コスト最適化、30 分の RTO、運用簡素化という複数要件を総合的に満たします。

ヒントボタン

Microsoft SQL Server のライセンスは vCPU ベースで高額になり、Amazon RDS や Amazon EC2 で BYOL／ライセンス込みを選ぶと 24TB・1 万 QPS の負荷に応じてコストが急増します。対して Amazon Aurora PostgreSQL Serverless v2 は ACU 従量課金でソフトウェアライセンス費用が不要、ピーク時だけ自動でスケールしてアイドル時は最小構成に戻るため、使用量に比例した支払いで初期投資を抑えられます。

24TB のデータを RPO 4 時間以内で保護するには継続的バックアップとマルチ AZ が鍵です。Amazon Aurora は 6 分散コピーのストレージと Amazon S3 への PITR が標準装備され、Serverless v2 でも同じ仕組みをそのまま享受できます。計算資源をゼロに近づけてもバックアップは維持されるので、ストレージ分だけの課金で可用性と復旧要件を同時に満たせる点がコスト効率につながります。

オンデマンドや RI は固定キャパシティ、スポットは中断リスクが課題ですが、製造ライン解析のようにピークとアイドルが交互に来るワークロードでは秒単位でキャパシティが伸縮する Amazon Aurora PostgreSQL Serverless v2 が最も無駄を排除できます。ライセンス費用、前払いの有無、可用性、スケーラビリティという複数要件を俯瞰すると、自動調整と従量課金を同時に満たす選択肢が自然に導かれるはずです。

ヒントボタン

1つ目のヒント
1年契約のCompute Savings Planは、インスタンスファミリーやリージョンを変更しても割引が継続する柔軟性があり、平常時に必ず使うベース負荷を低コストで確保できます。Auto Scaling Groupと組み合わせれば、変動分はオンデマンドやSpotで自動拡張されるため、初期投資を抑えつつ3名体制でも運用が容易になり、RTO4時間内の再展開も問題なく行えます。

2つ目のヒント
アクセスが±60％揺れる場合、Auto Scaling GroupにSpot Instanceを混在させるとピーク時の台数増加を最大90％割安で吸収できます。中断通知は2分前ですが、Elastic Load BalancingとマルチAZ配置で余裕を持たせ、Capacity Rebalanceを有効化すれば置き換えが自動化されます。オンデマンドもフォールバックとして設定できるため、少人数運用でも高可用性とコスト最適化を同時に実現できます。

3つ目のヒント
長期固定のStandard RIは割引率が高い反面、台数を途中で減らしづらく需要変動に強くありません。Fargate Spotは管理いらずですが、タスク数を手動調整する運用は3名では負担が大きくなりがちです。Compute Savings Planでベースを押さえ、Auto Scaling GroupでSpotを組み込む構成なら、初期投資を最小化しながら大幅な負荷変動と厳しいRTOに自動で対応でき、多角的に見て総合評価が最も高い選択となります。

ヒントボタン

クラウドエコノミクスでは初期投資を抑えたい場合、従量課金でオリジンの静的コンテンツを保管できるAmazon S3と世界中のPoPへ自動キャッシュを広げるAmazon CloudFrontを組み合わせると、数分でサーバを追加せずに帯域がスケールし突発的な10倍トラフィックにも対応でき、さらにプロビジョニング不要で平常時は転送量やリクエスト数に応じた課金だけなのでキャッシュヒット率が高いほどコスト効率が高まります。
長期前払いのEC2リザーブドインスタンスやオンプレミスのラック増設、あるいは常時稼働のDedicated Hostに代表されるキャパシティ確保型の手法は、ピークに合わせたCAPEXまたは長期OPEXが固定化され平時の遊休リソースが無駄になりやすく、瞬間的な需要変動に3分以内で追従するには調達・デプロイのリードタイムや再起動時間がネックとなるため、クラウドの弾力性という観点では課金が細粒度で自動スケールする仕組みと比べて柔軟性に劣ります。
求められているのは数分で世界規模に帯域を伸ばす弾性、初期投資を最小化する従量課金、オペレーションレスで自動スケールする仕組みという複数要件であり、CloudFrontとAmazon S3を組み合わせたCDN＋オブジェクトストレージのアプローチが総合的に最もフィットすると判断できます。

ヒントボタン

月末の48時間だけvCPU800を使い残り約672時間は停止できる利用率6％台の分析ワークロードでは、終日固定契約のStandard Reserved InstancesやDedicated Hostではアイドル課金が大きすぎるため、ベースとなる少量を3年契約のCompute Savings Plansで割引確保し、ピーク部分はAuto ScalingがSpot Instanceを優先起動する構成とすることで必要なときだけ大容量を引き出しつつ支出を圧縮できます。

月当たり約720時間のうち実稼働は48時間＝6.7％にすぎないため、3年前払いのReserved Instanceや専有ホストを持つと残り93％は空費になりますが、Compute Savings Plansならインスタンスタイプやリージョン変更の柔軟性を保ったまま最大66％の恒常割引が得られ、追加の需要部分をSpot Instanceでまかなえば最大90％近い割引が重ねられるため、3年間総額で40％以上の節約が見込みやすくなります。

運用負荷を抑えるうえでも、Auto ScalingグループとEC2 FleetでSpot Instanceを自動補充しCompute Savings Plansの支払管理だけに集約すればほぼ手放し運用が可能ですが、常時オンデマンドでt3.largeを動かす案はピーク性能不足と無駄課金が同時発生し、BYOL用の専有ホスト固定運用はキャパシティ監視やライセンス管理の手間が増大するため、可変需要とコスト最適化の両立という複数要件を俯瞰すると動的スケールと割引を組み合わせたアプローチが最も合理的と判断できます。

ヒントボタン

トランスコードのように視聴ピークで処理量が急騰するワークロードは、EC2 Auto Scaling と Spot Fleet を組み合わせると台数を動的に上下させられます。スポットはオンデマンド比で最大9割近い節約が期待でき、複数インスタンスタイプと複数AZを設定しておけば中断リスクも分散され、Elastic Load Balancing 経由で接続を捌くことで 99.9% 可用性を確保しつつ初期投資を抑えられます。

動画ファイルは公開直後は高頻度アクセス、日が経つとロングテール化というパターンが一般的です。S3 Intelligent-Tiering はアクセス状況を自動判定して Standard から IA・Archive レイヤへ移行し続け、手動ライフサイクルより細かな階層化で 500 TB を超えるデータ成長にも無駄なく対応します。さらに CloudFront をオリジンに挟むとエッジキャッシュが転送コストを圧縮し、世界中のエンドユーザーに低遅延で配信できるため、可用性とユーザー体験の両立が図れます。

可変の大きい計算資源は EC2 Spot＋Auto Scaling、容量と配信は S3 Intelligent-Tiering＋CloudFront という棲み分けを取ることで、CAPEX を最小化しながら OPEX も最適化できます。長期契約のリザーブド課金やオンプレ SAN への投資は成長速度が読めないスタートアップには重くなりがちです。マルチAZ構成や Route 53 ヘルスチェックを組み込み、オブジェクトレベルでの冗長化を行えば 99.9% の可用性をクリアしつつ、総合的に最も経済的なアーキテクチャとなります。

ヒントボタン

SA 付き Windows を BYOL すると Dedicated Host や Dedicated Instance が前提となり、CPU10% 稼働でもホスト単位料金を負担し続ける形になります。ライセンスを含んだ Amazon EC2 を選べばホスト縛りがなく、Auto Scaling や Spot を自在に組み合わせて台数を増減できるため、インフラとライセンスを切り離して TCO を抑える余地が大きくなります。

12 か月以内に 200 台がピーク時 600 台へ伸びる可変性を考慮すると、ベース負荷と突発負荷を分ける設計が効果的です。Amazon EC2 Auto Scaling でベースキャパシティを維持しながら、追加分は Spot インスタンスで吸収すれば、需要急増にも即応しつつオンデマンド常時起動に比べて大幅なコスト削減が可能です。マルチ AZ 配置でキャパシティ不足リスクも和らぎます。

ベースの 200 台には 1 年期間の Compute Savings Plans を適用し、月次ピークでのみ出現する 400 台は低単価な Spot を優先し不足分だけオンデマンドにする構成なら、安定稼働部分の割引と突発負荷の柔軟性を両立できます。ライセンス運用の自由度、将来スケール、料金モデルの適用範囲という複数要件を俯瞰し総合的に判断することが最適なコスト戦略の鍵です。

ヒントボタン

RPO15分とRTO1時間を手間なく満たすには、マルチAZ配置・自動バックアップ・ポイントインタイムリカバリを備えたAmazon RDS for SQL Serverを利用するのが効率的で、EC2上のAlways On可用性グループやRedshift移行は高い自由度の代わりにパッチ適用、監視、障害時フェイルオーバー検証など継続的な運用作業が増えることを想像してください。
運用コストを現行比30％下げるには、SQL Server Enterprise版やBYOLの高額ライセンスを避け、ライセンス込みStandard EditionにCompute Savings Plansを組み合わせて割引を確保しつつ、io1 5,000 IOPSを起点にStorage Auto Scalingで年末の増分だけ自動拡張させる構成が有効です。
平常時5,000 IOPSとピーク15,000 IOPS、RPO15分・RTO1時間、運用負荷最小化、コスト30％削減という複数要件を俯瞰すると、マネージドなAmazon RDS for SQL Server Standard Editionにio1とStorage Auto Scaling、そしてCompute Savings Plansを組み合わせたアプローチが全体バランスで最も合理的だと判断できます。

ヒントボタン

毎月の遺伝子解析はピーク時に最大1,000vCPUという大規模並列性を要求する一方で累計500時間ほどと短時間なので、AWS Batch がジョブごとに EC2 スポットインスタンスを自動起動すれば終了後すぐリソースを解放してアイドルコストを限りなく抑えられ、オンデマンド比で最大90%割引の料金だけが秒単位で発生します。
スタンダード Reserved Instances や Compute Savings Plans は3年あるいは1年の利用を前提に一定のキャパシティを前払いで確保する契約体系であり、総使用時間が月500時間に満たないと未使用分にも料金が発生してキャッシュフローが固定費化するため初期投資ゼロと変動費化という要件に整合しません。
オンプレミスでHPCクラスターを購入し Direct Connect で常時接続すればピーク性能は確保できるものの装置代や保守費が前払いの固定費となり長い遊休期間が生じるため、ペイアズユーゴーを実現するには AWS Batch がスポットフリートを動的に割り当てる構成がコスト最適化と運用自動化を総合的に両立させます。

ヒントボタン

平均CPU使用率25％でピーク70％というワークロードは、EC2 Auto Scaling Groupを使ってベースラインの台数を最小限にし、CloudWatchアラームで繁忙時だけインスタンス数を増減させるのが王道です。停止している時間は課金が発生しないオンデマンド料金の長所を活かせるため、常時100台を起動し続ける固定費型の構成より5年TCOを大幅に圧縮できます。また、起動テンプレートでマルチAZを指定しておけば可用性要件にも自然に対応でき、Systems Manager Patch Managerと組み合わせれば運用コストまで削減できます。

Windows ServerをBYOLする場合はDedicated Hostや Dedicated Instanceが必要となりホスト単位のコストとキャパシティ予約が発生しますが、License IncludedのAMIを選択すればAuto Scalingで起動・停止しても時間単位でライセンス料金が計算されるため、低負荷時に台数を落とす今回のシナリオと相性が高いです。一方でホストやインスタンスを丸ごとリザーブ購入すると使わないコアにも前払いが発生し、変動費というクラウドの利点を活かしきれません。

長期的に約25台の稼働が見込めるなら、Reserved Instanceより柔軟なCompute Savings Plansをその分だけ契約しベースラインを割引単価で確保し、ピーク時に必要な追加台数はオンデマンドで自動起動させるのが効率的です。Savings PlansはインスタンスタイプやAZに縛られないため将来のm5からm6への移行でも割引を維持でき、RTO4時間・RPO1時間の要件とコスト最適化を両立できます。複数要件を俯瞰すると、固定的にコミットするリソースを最小限にし、残りを弾力的に課金する構成が総合的に最も経済的と判断できます。

ヒントボタン

保有している Oracle ライセンスを活用してコストを30％削減したい場合、License Included 料金より Bring Your Own License を選ぶ方が月額を大きく圧縮できます。EC2 Dedicated Host でライセンスを縛る方法は初期投資と割当管理の負荷が高く、Auto Scaling による弾力性も制限されるため、RDS for Oracle の BYOL オプションを組み合わせ、Compute Savings Plans でアプリケーション層の変動費を平準化する構成が費用面で優位になります。さらに 1 年リザーブドより Savings Plans の方が実行形態を跨いで適用でき、スポットと併用しても割引を維持できるため、中長期での総支払い額を予測しやすくなります。

RPO 4 時間、RTO 1 時間を実現しつつ運用負荷を最小化するには、マネージドなバックアップとフェイルオーバーを自動化してくれる Amazon RDS Multi-AZ 配置が定番です。EC2 上で Oracle を自前で複製すると RMAN 設定やログ管理の工数が発生し、障害時の切替スクリプトも保守が大変ですが、RDS Multi-AZ なら同期レプリケーションと自動 DNS 切替で 1 時間以内の復旧を標準機能だけで達成できます。また自動バックアップは最短 5 分毎のトランザクションログ永続化により 35 日間保持されるため、4 時間以内の復旧点を手間なく満たします。

ピーク同時 2000 接続を吸収できるよう Web とアプリ層は EC2 Auto Scaling をオンデマンドとスポットの混在で構成し、Compute Savings Plans を重ねることで需要変動とコスト最適化を両立します。データ層は RDS for Oracle BYOL を Multi-AZ で冗長化し、マネージドパッチ適用で運用を簡素化します。自社保有ライセンスを無駄にせずマネージドサービスを積極活用し、可用性・復旧目標・コスト削減・運用負荷という複数要件を総合的にバランスさせた構成が最も合理的です。

ヒントボタン

平日平均10%で週末に100%まで振れるワークロードなら、Amazon EC2 Auto Scaling に起点を置き、平常時は最小台数を維持しつつ CloudWatch メトリクスで閾値を超えたときだけインスタンスを追加する構成が最も無駄な稼働時間を減らし、運用を自動化できます。スケールイン時にはデタッチ前フックで処理中リクエストを捌ききるなど調整も可能で、手動増設に伴う人件費と設備投資の双方を削減できます。

従量課金を最大化するには、長時間稼働が読めない部分をオンデマンドインスタンス、突発的なピークを Amazon EC2 Spot Instances に割り当て、ターゲットキャパシティレベルを柔軟に変更するのが鍵です。スポットはオフプレの遊休リソースの様に短期で確保解除でき、最大90%のコスト削減効果が期待できます。これによりキャパシティープランニングの誤差に備えて過剰に台数を購入する必要もなくなります。

リザーブドインスタンスやDedicated Host、AWS Outposts はいずれも一定の前払いまたは長期コミットメントが発生し、稼働率が低い時間帯に無駄が生じがちです。変動が大きいスタートアップでは、オプション間で固定費と変動費のバランスを比較し、プロビジョニングを自動化できる仕組みを優先すると総合コストを最小化できます。

ヒントボタン

常時必要なのはわずか40ECUで月末3時間だけ400ECUへ跳ね上がるこのバッチ処理では、AWS Batchのマネージド計算環境にスポットインスタンスを割り当て、ジョブ完了後にインスタンスを自動終了させる構成が有効です。スポットは90％以上の割引が得られ、バッチは中断再開を自動化できるため、非ピーク時間帯の固定費を限りなくゼロに抑えつつハードウェア購入を回避できます。

リザーブドインスタンスやCompute Savings Plansは長期的にある程度の使用量が継続する場合に費用効果が高まりますが、ここでは大半の時間が40ECUと小さく、突発的ピークが月に3時間しかないため、全量をコミットすると未使用時間の前払い分が無駄になります。従量課金で瞬時に拡大縮小できるスポット＋AWS Batchの方が課金の変動に追従しやすく、キャッシュフローにも優しい選択になります。

オンプレミス購入、長期前払い、EC2オンデマンド常時起動、そしてAWS Batch＋スポット＋EC2 Auto Scalingという四つの方向を俯瞰すると、スケールの俊敏性、非ピーク固定費の最小化、割引率、運用自動化の観点をすべて同時に満たすのは、マネージドでスポットを活用しジョブ完了後に環境を解放するクラウドネイティブな構成だと総合判断できます。