CLF-3.3AWS のコンピューティングサービスを特定する。

ヒントボタン

注文APIを毎秒1000件受け付ける規模であっても、AWS Lambda は同時実行数を内部で瞬時に伸ばせるためピークトラフィックに合わせて自動拡張し、実行時間に応じた従量課金のみ発生します。Amazon API Gateway を入口に組み合わせると認証やスロットリング、WAF 連携もマネージドで提供され、サーバープロビジョニングや OS パッチ適用を気にせずビジネスロジックの実装に集中できます。

EC2 Auto Scaling や Amazon EKS などのコンテナ基盤はインスタンス起動や Pod 立ち上げに数十秒～数分を要し、アイドル時でも最小台数の料金が発生します。対して AWS Lambda は常時稼働ホストを持たないイベント駆動型で、深夜など注文が少ない時間帯はほぼ課金が発生しません。コスト効率と運用負荷の軽減を同時に実現できる点が、成長段階にある小売ビジネスにとって大きな魅力となります。

要件は「サーバー管理を排除」「ピーク時に5倍へ自動スケール」「アイドルコスト最小化」の三つです。Elastic Beanstalk や EC2 ベースの構成は基盤運用や常時稼働コストが残り、EKS も最小キャパシティを抱え続けます。リクエスト数に応じて瞬時にスケールし、負荷がゼロに近いときは料金もほぼゼロになる AWS Lambda と Amazon API Gateway の組み合わせが、複数要件を最もシンプルかつ経済的に満たす選択と言えるでしょう。

ヒントボタン

S3 にアップロードされたオブジェクトを契機に処理を走らせるなら、Amazon S3 イベント通知で AWS Step Functions や EventBridge を介しコンテナジョブを呼び出す設計が一般的です。AWS Fargate なら EC2 クラスターのプロビジョニング不要で、タスク数を要求に応じ数百並列まで自動拡張でき、管理工数を最小化できます。

1GB の長尺動画を ffmpeg で変換する場合、メモリ 10GB 以上や実行時間数分を要するケースが多く、AWS Lambda は 10GB/15分という制限と 512MB の /tmp 領域がボトルネックになりがちです。対して Amazon ECS on AWS Fargate は vCPU とメモリを柔軟に割り当てられ、タスクごとに課金されるため大容量メディア処理に適しています。

スポットや常時稼働の EC2 でもコスト低減は可能ですが、Auto Scaling グループ調整や AMI 更新といった運用を残します。Fargate でコンテナを S3 トリガーで起動すればサーバーを持たず秒単位課金、500 並列のピークは Service Auto Scaling が吸収し、可用性・コスト・運用負荷の全要求をバランス良く満たせます。

ヒントボタン

OSパッチ適用やカーネル設定などホストの運用を避けながらDockerイメージだけでデプロイし秒単位課金で実行時間分のみ料金を払いたい場合、インスタンスを意識せずECSタスクを実行できるAWS FargateはAMI作成やSpot Fleet運用の手間を要さず、基盤のパッチ管理をAWSに委ねてコストと運用負荷を大幅に下げられ、さらにApplication Load Balancerのターゲットとしてもネイティブに機能します。
平常時1,000リクエスト毎秒からキャンペーン開始と同時に5分以内で20倍以上へ跳ね上がるような突発的トラフィックには、保有キャパシティを事前に確保しなくてもタスク単位で秒レベルで起動できるAWS Fargateのオートスケーリングが効果的で、ECS Service Auto ScalingとApplication Load Balancerのリクエスト数メトリクスを連携させれば需要に応じたタスク増減が自動化され、ウォームノードの準備やノードグループローリングアップデートの遅延を気にする必要がありません。
SpotやAutoScalingグループはコスト低減や伸縮性に優れるものの起動時にAMI展開とコンテナプルの二段階が必要になり、Kubernetes制御プレーンを持つEKSではノード数増加のリードタイムやクラスタ管理が残るため、秒課金・OS非管理・数分以内の大規模スパイク吸収という複数要件を俯瞰すると、サーバーレスコンテナ実行環境であるECS on FargateにALBを組み合わせる構成が最も要件適合度が高いと整理できます。

ヒントボタン

サーバ運用をなくしたいという要求と4vCPU・16GBコンテナを25分間最大500並列で走らせたいという性能条件を突き合わせると、コンテナごとにCPU／メモリを指定し30分以内であればタスク単位に秒課金されインフラ管理も不要な AWS Fargate が適合し、また対抗として挙がるコンテナイメージ対応 AWS Lambda は実行上限15分・メモリ10GB・CPUメモリ連動で条件を満たせないことが見えてきます。
価格を抑える観点では EC2 スポットフリート で Auto Scaling させる案も検討できますが、インスタンスのプール確保、AMI 更新、パッチ適用、Docker イメージのプリロード、ヘルス監視などの運用作業が利用者側に残るのに対し、Amazon ECS の AWS Fargate と Fargate Spot の組み合わせならタスク起動と終了だけで低価格と運用レスが同時に得られることが大きな差異となります。
Elastic Beanstalk マルチコンテナ Docker を選ぶと環境の初期構築は容易でも常時稼働する EC2 がアイドル時間にも課金されバースト型ジョブには不向きであり、AWS Fargate ならタスク実行中のみ課金されスケールインでリソースがゼロに戻るため500本並列の突発需要でもコストを抑えられ、結果として運用レス・25分実行・4vCPU16GB・従量課金という複合要件を総合的に満たす選択肢が浮かび上がります。

ヒントボタン

秒間5,000件という突発的なトラフィックは数秒内に到達することが多いため、起動まで数分かかるEC2やECSよりも、関数実行数をミリ秒単位で自動増減できる AWS Lambda の同時実行スケーリングと、スロットリング制御や認証を簡単に組み込める Amazon API Gateway の組み合わせがレスポンス確保と瞬時の伸縮に優れ、さらに従量課金で実行時間とリクエスト数にのみ費用が発生するためアイドル時は課金がほぼゼロになります。
Node.js アプリのデプロイを頻繁に行う場合、AWS Lambda では ZIP あるいは Container Image をアップロードするだけでランタイムも OS も自動でパッチ適用されるため、EC2 Auto Scaling グループでの AMI 管理やユーザーデータスクリプト、Amazon ECS での容量プロバイダー設定などに比べて運用負荷が大幅に軽減され、CI/CD との統合も CodePipeline や CodeDeploy を用いて容易に自動化できます。
コスト最小化、秒単位のスケールアウト、パッチ管理不要という三つの要件すべてを一つの選択肢で同時に満たせるのは、サーバーレスである AWS Lambda と Amazon API Gateway の組み合わせだけであり、EC2 Auto Scaling や Amazon Lightsail は特定条件で利点があっても全要件を横断的に満たすには追加構成が必要になるという総合判断になります。

ヒントボタン

リクエストが秒間8,000に達しても平均100 ms以内の応答を保ちたい場合、Amazon API Gateway はリクエスト単位で自動スケールし、AWS Lambda はバースト約3,000同時実行・以降毎秒500ずつ拡張できるため、プロビジョンドコンカレンシーなしでも短時間で許容量が上がり、アイドル時には実行時間とリクエスト数のみ課金となりコストをほぼゼロにできます。さらに VPC 接続が不要ならコールドスタートも小さく抑えられ、HTTP API モードの圧縮転送で待ち時間を削減できます。

Amazon ECS on EC2 や Elastic Beanstalk、Spot Fleet などインスタンス常駐型の選択肢は、Auto Scaling を入れても最少台数を確保する都合上 t3 や c5 の料金が常時発生します。インスタンス起動やウォームアップの遅延、Network Load Balancer や ALB での接続確立時間も挟まるため、ピーク追従はできてもアイドル時ゼロ課金や100 ms 未満のレイテンシを保つにはキャッシュ層や追加チューニングが不可欠となり、運用管理の手間も残ります。

求められているのは高スループット、低レイテンシ、アイドルコストほぼゼロ、そしてサーバー管理不要という複数要件の同時達成です。リクエスト課金型でフルマネージドな Amazon API Gateway と AWS Lambda のサーバーレス構成はスケール特性・料金モデル・運用容易性の全観点で条件を満たしており、インスタンスベース案より総合的に適合性が高いと判断できます。

ヒントボタン

トラフィックが 5 から 1000 リクエスト/秒へ 30 秒で急増する場合、コンテナを常駐させつつ台数を調整する方式では起動時間が追いつかず遅延が出がちです。AWS Lambda は ECR コンテナイメージを直接実行でき、リクエストごとに瞬時にコンカレンシーを拡張できるため、スパイクに対して最も俊敏に追従します。
コンテナのサーバーレス実行先として Fargate も選択肢ですが、Auto Scaling は CPU やメモリの CloudWatch メトリクスを見てからタスクを起動するため、最短でも数十秒から 1 分程度のラグが残ります。また待機タスクを 0 にできないため常時コストが発生します。Lambda はミリ秒単位で立ち上がり、アイドル時課金もありません。
可変幅の大きい API、サーバー管理不要、使用量課金、ECR コンテナ対応という四つの条件をまとめて満たすのは、API Gateway と組み合わせてリクエスト単位で無制限にスケールアウトし、アイドルコストを抑えられるサーバーレスランタイムが最適だと総合的に判断できます。

ヒントボタン

1 秒あたり 500 リクエストと同時 10 万接続という条件は Amazon API Gateway のソフトリミット内であり、AWS Lambda もデフォルト同時実行 1000 に加え申請で数万へ拡張できるためスケール要件を十分満たし、コード以外を運用せず従量課金でアイドルコストを抑えられ、Provisioned Concurrency を 500 に設定すればコールドスタート遅延を最小化できる点を押さえてください。
EC2 を用いた Auto Scaling や Amazon ECS on EC2 は比較的低レイヤ操作が残るため同時 10 万セッションを支えるためのカーネルパラメータ調整・ターゲットグループ分割・Spot 中断ハンドリングなどの運用作業が多く、EKS on Fargate でも HPA や Cluster Autoscaler の設計が必須となるので、最小運用負荷という観点でマネージド抽象度の差を整理してみてください。
ピークとアイドルの差が激しい動画配信 API ではリクエストベース課金かつフルマネージドに自動スケールするサービス選択が低コストと運用軽減の両立につながるため、API Gateway と Lambda の組み合わせが上限緩和手続きだけで性能を伸ばせる一方で他案はいずれも長期のチューニングが不可欠となり、総合的にどこが最重要か俯瞰して判断してみましょう。

ヒントボタン

広告放映直後に秒間リクエストが数百倍へ跳ね上がる場合、待機インスタンスを段階的に増やす方式では追従が難しいです。AWS Lambda はトラフィック到来に合わせて同時実行環境をミリ秒単位で並列起動し、リージョン上限内で 1 万 RPS 規模まで自動拡張します。さらに Amazon API Gateway を前段に置くことでスロットリングや認証もマネージド化され、コード配置だけで高負荷 API を公開できます。

平常時の RPS が 50 程度と低いなら、常時稼働する仮想サーバ群はアイドルコストが重くなります。Lambda は実行時間と呼び出し数に対してのみ従量課金され、API Gateway も転送量と呼び出し回数ベースなので閑散期の費用を極小化できます。どちらのサービスもリージョン内マルチ AZ で自動冗長化されているため、追加構築なしで高可用性が得られる点も広告キャンペーン向けに魅力です。

急激なスパイク吸収、サーバ管理不要、ミリ秒スケール、アイドルコスト最小化、標準マルチ AZ 冗長という複数要件を俯瞰すると、Amazon API Gateway をフロントに据え AWS Lambda を実行基盤とするサーバーレス構成が最も合理的な総合判断となります。

ヒントボタン

Amazon API Gateway と AWS Lambda のサーバーレス構成はリクエスト駆動で瞬時に同時実行数を拡張でき、平均 2,000rps からピーク 10,000rps に跳ねてもコールドスタート対策やインスタンス台数の見積りが不要なため、パッチ適用や容量管理などの日常運用を大幅に削減できます。
EC2 や Amazon ECS では Auto Scaling を組み合わせてもウォームアップに秒〜分オーダーの遅延が生じ、0.5 秒以内応答の前提でバーストを吸収するには予備キャパシティ確保やアラーム調整が欠かせませんので、監視・スケジューリング・ローリングアップデートなどの運用が比較的重くなりがちです。
信頼性・レイテンシ・弾力性・運用工数という複数要件を俯瞰すると、AWS Lambda のミリ秒単位スケールと従量課金、さらに管理レスな特性がピークトラフィックを効率よく処理しつつ運用負荷も抑えられるため、最終的にサーバーレス基盤を選択するのが総合的に妥当と判断できます。

ヒントボタン

月間一千万件・秒間五千リクエストのスパイクを想定するなら、Amazon API Gateway が数万同時接続を標準で受け止め、AWS Lambda が瞬時に同時実行を伸ばし 128 MB 刻みの従量課金だけを発生させるため、深夜帯など完全アイドル時には請求がゼロになるという性質が際立ちます。

仮想サーバやコンテナを使う Auto Scaling グループ、AWS Fargate、Amazon EKS はスケールアウト時に AMI ダウンロードやイメージプルで数十秒かかり、最小キャパシティをゼロにすると ALB やヘルスチェックが成立せず可用性が揺らぐため、結局 EC2 料金や vCPU 分の固定費とクラスタ管理の運用負荷が二名体制には重く残りがちです。

可用性 99.95 以上・アイドルコストゼロ・ピーク耐性・二名運用という複数条件を俯瞰すると、自動マルチ AZ 冗長と明示 SLA を備える Amazon API Gateway とコードだけ管理する AWS Lambda の組み合わせが、信頼性・コスト・運用簡素化の全方位で最も自然に要件を満たすとの総合判断となります。

ヒントボタン

セール時に接続数が1,000から10,000へ跳ね上がる状況では、イベントに応じてミリ秒単位で並列実行数を自動的に伸縮させる AWS Lambda が最も低レイテンシで追従しやすいです。Amazon API Gateway をフロントに置けば HTTP エンドポイントが即座に増減し、プロビジョンやキャパシティ計画の心配を大幅に削減しながら平均応答を 100 ms 以内に収めやすくなります。

インスタンスベースの Amazon EC2 や Amazon EKS ではパッチ適用や OS モニタリングなど運用タスクが残りますが、AWS Lambda はコンテナランタイム以下を完全に隠蔽し、関数コードだけに集中できます。課金は実行時間とリクエスト数に比例する 100 ミリ秒単位の従量課金で、アイドル時間が多い非セール期間のコストを劇的に抑えられます。

要求事項は「OS を触らずに最小運用」「リクエスト単位の従量課金」「瞬時に 10 倍へスケールしつつ 100 ミリ秒以内の応答」、これらを同時に満たすのはマネージドイベント駆動の AWS Lambda と Amazon API Gateway の組み合わせが最も整合します。EC2 Auto Scaling や Amazon Lightsail はサーバーサイズと起動時間の制約、EKS はクラスタ保守が残り、総合判断ではサーバーレス選択が合理的です。

ヒントボタン

コンテナ化済みのアプリをホスト運用なしで走らせたい場合、Amazon ECS と AWS Fargate の組み合わせが最有力です。Fargate は EC2 インスタンスのプロビジョニングやパッチ作業が不要で、タスク単位にだけ集中して管理できるのが特徴です。イメージを ECR に登録しタスク定義を更新するだけで展開が済むため、動画配信チームはメディア変換ロジックの改善に専念できます。

突発的に 1 分あたり一万件のジョブが来ても、Application Auto Scaling を併用した Amazon ECS on Fargate なら DesiredCount を動的に伸ばし短時間で大量タスクを起動できます。AWS Lambda もサーバレスですが同時実行の既定上限や 15 分の制限があり FFmpeg を用いる重いトランスコードでは制約が目立ちます。タスクごとに vCPU とメモリを調整し複数プロファイルを用意すればピークを確実に吸収できます。

課金面では AWS Fargate が秒単位で vCPU・メモリ使用量に応じ課金される完全従量制で、ピーク後にスケールインすれば無駄が残りません。EC2 スポットは安価でもキャパシティ蒸発リスクがあり、Lightsail は月額固定でサーバ管理が付きまといます。コンテナ指向・運用レス・秒課金・爆発的スケールの四要件を俯瞰し、これら全てを同時に満たす選択肢を総合的に見極めることが鍵です。

ヒントボタン

実行時間分のみ課金という条件を考えると、Amazon ECS や Amazon EKS を Amazon EC2 上に構成する方式ではインスタンスが起動している限り料金が発生します。一方、AWS Fargate を利用するとコンテナが動いている秒数に対して CPU とメモリの利用量で課金され、基盤となる EC2 を意識せずに済みます。さらに秒単位課金なので短時間のスパイクでも無駄がありません。

トラフィックが瞬時に 3 倍へ膨らむケースでは、Auto Scaling で Amazon EC2 を追加起動する場合にイメージ展開やブート時間で数分以上かかることがあります。AWS Fargate と Amazon ECS の組み合わせならクラスター容量を事前に確保せずタスクを直接スケジューリングでき、メトリクスベースの Service Auto Scaling が即座に追加タスクを立ち上げるため RTO 5 分以内という厳しい拡張要求に適合しやすいです。

インフラ運用を最小化したい場合、Amazon EC2 のパッチ適用やリザーブドインスタンス購入、Spot 容量の変動対応といった作業が残る構成は選択肢から外れがちです。AWS Fargate はサーバーレスで OS 管理が不要なうえ、必要な vCPU とメモリをタスク単位で宣言するだけで済みます。コスト最適化・高速スケーリング・運用負荷低減という複数要件を俯瞰すると、フルマネージドなコンテナ実行環境が最も理にかなっています。

ヒントボタン

フィンテックの秒間5000件という突発的ピークには、Amazon API Gateway が受けたリクエストを AWS Lambda へイベントとして流す構成が適しています。Lambda は初期キャパシティゼロから短時間で数千同時実行まで伸長し、実行回数と実行時間だけの従量課金でアイドル時コストが発生しません。さらにプロビジョニングやパッチ適用、Auto Scaling の設定をサービス側が担うため、開発者はビジネスロジックに専念できます。

EC2 Auto Scaling や Amazon ECS（EC2 起動タイプ）は水平スケール自体は可能ですが、インスタンス起動に数十秒かかるためピークに備えて余剰キャパシティを置きがちで、稼働時間分は継続課金となります。OS パッチ適用、AMI 更新、Security Group 調整などのインフラ運用も残ります。固定台数で構成する AWS Elastic Beanstalk の t2.micro 環境はさらにスループットが頭打ちとなり、サーバレスのゼロ運用・完全従量課金モデルとは性質が異なります。

要件は「イベント駆動」「サーバ管理ゼロ」「アイドルコストゼロ」「瞬時の大規模スケール」であり、これらを同時に満たせるのは API Gateway とネイティブ連携しミリ秒単位で拡張する Lambda です。VPC 内配置や AWS Key Management Service での暗号化、AWS X-Ray と CloudWatch Logs での可観測性も追加運用なしに実装でき、コスト効率・運用負荷・スケーラビリティを総合的に評価すると最適解となります。

ヒントボタン

課題はサーバを保持せず画像変換のロジックだけを動かし、実行時間分だけ課金されることです。AWS Lambda はコードをアップロードするだけで最大同時並列数を自動拡張し、初期の1000並列を超える場合も申請で増強できます。Amazon API Gateway を組み合わせれば HTTPS エンドポイントもフルマネージドで用意でき、パッチ適用や OS 管理は不要となります。

これに対し Amazon EC2 オンデマンド、Spot、Elastic Beanstalk、Amazon ECS on EC2 はインスタンスを起動している間アイドルでも課金が続き、AMI管理や Auto Scaling のウォームアップなど運用工数が残ります。秒間1000件のバースト時に新規インスタンスを加えても起動遅延が数十秒発生する恐れがあり、1秒以内応答という厳しい SLO を守るには余剰キャパシティを常時確保する必要が生じ、コスト効率が下がります。

サーバ管理不要、実行時間課金、サブ秒スケールアウト、HTTP API 提供という複数要件を俯瞰すると、イベント駆動でミリ秒単位で起動し、CloudWatch と統合されたサーバレスコンピューティングの採用が最適です。API Gateway が入口となり Lambda 関数が瞬時に並列化して画像変換を行う構成が、性能・コスト・運用負荷のバランスを最も高いレベルで満たします。

ヒントボタン

秒間リクエストが 1,000 から 12,000 まで跳ね上がるワークロードでは、Amazon API Gateway と AWS Lambda が採用するリクエスト単位の課金モデルが強みになります。ピーク用に常時キャパシティを確保する必要がなく、呼び出し回数に応じて料金が発生するためコストが実トラフィックに比例し、Lambda の同時実行はバーストにも瞬時に追従してくれるためスパイク対策がシンプルです。

運用負荷を抑えたいという条件では、EC2 や Amazon ECS Fargate のように AMI／コンテナイメージ管理やオートスケーリングポリシー調整が欠かせない環境より、AWS Lambda が提供するフルマネージド基盤が優位です。基盤 OS のパッチ適用やクラスター容量計画が不要で、Amazon CloudWatch に関数単位でメトリクスとログが自動集約されるため、監視・保守工数を大幅に削減できます。

RTO 5 分以内という復旧要件は、AWS Lambda がデフォルトでマルチ AZ 冗長配置され API Gateway もリージョンサービスとして高可用に動作することで自然にクリアできます。関数コードは S3 相当の耐久ストレージに保存されデプロイも数十秒で完了するため、障害時は即時ルーティング継続が可能です。コスト最適化・スケーラビリティ・運用簡素化という複数要件を俯瞰すると、このマネージド型サーバーレスアーキテクチャが総合的に最も適合度の高い選択肢となります。

ヒントボタン

動画エンコードのような20分程度で完結するバッチ処理をコンテナ化して流す場合、Amazon ECS on AWS Fargate が最もフィットします。Fargate はインフラを意識せずタスク単位で従量課金され、停止中は料金ゼロに近く、Application Auto Scaling で同時500本へのスケールアウトも自動化でき、パッチ適用やクラスタ管理の手間も不要です。

Amazon EC2 Auto Scaling や スポットインスタンス運用ではインスタンス起動中に必ず料金が発生し、手動オペレーションや割り込み対応の負荷も残ります。また AWS Lambda は 15 分制限ですぐにタイムアウトし、1 年の Standard RI ではアイドルコストを回避できません。各サービスの制約と課金モデルを一覧化すると要件適合度が比較しやすくなります。

運用負荷を最小化しつつアイドル時コストをほぼゼロに抑え、ピークで 500 並列の動画エンコードを自律的にさばく――この三大要件を同時に満たすのは、コンテナを即時起動・停止し課金も実行時間分だけの AWS Fargate を中核に据えた構成だと総合判断できます。

ヒントボタン

1時間ごとに届く1 TBのレポートを60秒以内でさばくには、ジョブを細分化して一斉にコンテナを起動できる仕組みが必要です。AWS Batch はキューに投入されたタスク数を見て Fargate や Amazon EC2 スポットキャパシティを自動で確保し、ピーク時だけ数百台規模まで水平スケールするため、設備購入を避けつつ従量課金で済ませる運用が可能になります。

関数実行基盤の AWS Lambda はメモリ10 GB・一時ストレージ512 MB・タイムアウト15分といった上限があり、単一ファイル1 TBを1分以内で処理する場合は極端なファンアウトや Step Functions など追加の制御が必要になります。これに対し AWS Batch は S3 からの並列読み込みと vCPU 単位の柔軟な割り当てが行え、スポットインスタンスの割引をそのまま取り込めるのでコスト効率が高いです。

EC2 Auto Scaling だけを直接使うと起動設定やライフサイクルフックの管理が運用負荷となり、Amazon EC2 専有ホストにリザーブドインスタンスを固定すると空き時間も料金が発生します。ジョブキューのマネージド化、スポット連携、コンテナ並列実行、そして60秒以内という処理要件を総合的に俯瞰すると、オンデマンドに伸縮し最安構成を自動選択する AWS Batch が最も合理的な選択肢となります。