アクセス集中対策をAWSで設計する｜詰まる層の切り分け・事前準備と発生時の対処手順

セールの開始時刻やテレビ放映の直後にサイトが503を返すとき、足りないのはサーバー台数だけとは限りません。データベースの接続数、AWSアカウントのクォータ、ロードバランサーの拡張速度のどれか1つが先に上限へ達すると、そこで止まります。この記事では、落ちる原因を層ごとに切り分け、AWSでの対策をCloudFront・ALB・EC2 Auto Scaling・データベースの順に整理します。そのうえで、予告されたピーク前の準備をAWS CLIの手順で示し、検知に使うCloudWatchの指標と、落ちている最中に打つ手を順に並べます。数値は2026年10月時点のAWS公式ドキュメントに基づきます。

まとめ：AWSでアクセス集中に備える要点

• オリジンに届くリクエストを先に減らす：静的ファイルとログイン不要のページはCloudFrontで返す。増台より先に効き、突発的な集中にも間に合う。
• EC2 Auto Scalingは「数分遅れて効く」前提で使う：開始時刻が分かっているピークはスケジュールスケーリングで事前に台数を積む。デフォルトのインスタンスウォームアップは既定で無効なので有効にする。
• クォータを先に確認する：EC2オンデマンド（標準ファミリー）の既定は5vCPU、Lambdaの同時実行は1,000、API Gatewayは10,000RPS。最大台数を40にしても上限で止まる。
• データベースは接続数で詰まる：アプリのサーバーを増やすほど接続が増える。RDS Proxyで接続をプールし、読み取りはAuroraレプリカ（最大15台）へ逃がす。
• 予告イベントはALBのLCU予約とDynamoDBの事前ウォームを併用：LCU予約は最小100LCUから。予約分は使わなくても課金されるので、終わったら解除する。
• 検知は層ごとの指標で行う：ALBのHTTPCode_ELB_5XX_CountとHTTPCode_Target_5XX_Countを分けて見れば、詰まっているのが入口か背後かが分かる。
• 落ちている最中は「特定→増台→流入削減→遮断」の順：手動で台数を足すときは最大台数とクォータを先に上げ、オリジンを守るためにCloudFrontのエラー応答を静的ページへ差し替える。

アクセス集中でサイトが落ちる仕組みと詰まる層

アクセス集中で起きるのは、処理待ちの要求が積み上がって応答が遅れ、やがてタイムアウトやエラーに変わる現象です。ALBでは、ターゲットが未登録または全台unusedの場合などに503、接続や応答がタイムアウトすると504が返ります。全台がunhealthyの場合は、そのターゲットへ転送するフェイルオープン動作になるため、正常なターゲットがないだけで503になるとは限りません。エラーコードごとの切り分けは503エラーの原因と復旧手順で扱っています。

詰まる場所は上流から順に連鎖します。Webサーバーを増やしても、データベースの最大接続数に達した時点でアプリは接続待ちになり、全台が遅くなります。対策は「どの層が最初に上限へ達するか」を見積もることから始めます。

スケーラビリティという言葉の定義はスケーラブル（スケーラビリティ）の意味と拡張性の解説にまとめています。

予測できる集中と突発的な集中で分かれる対策

打てる手は、開始時刻が分かっているかどうかで変わります。予告されたピークには事前に容量を積めますが、SNSでの拡散や報道のような突発的な集中には、自動拡張とキャッシュに加えて、待機室やレート制限による流入制御が要ります。

悪意のある集中は、正規の利用者を受け入れる対策とは逆向きです。台数を増やすと攻撃の分だけ費用が膨らむので、入口で遮断します。攻撃の種類と企業側の備えはDDoS攻撃の仕組みと企業が取るべき対策を参照してください。

AWSで組むアクセス集中対策の構成

基本形は、CloudFrontを入口に置き、その背後でALBがEC2（またはFargate）へ振り分け、データベースの前にRDS Proxyを置く構成です。上流で吸収できる要求ほど下流の負担が減るので、設計も上流から固めます。

CloudFrontによるオリジン負荷の削減

CloudFrontがキャッシュから返した要求はオリジンに届きません。画像・CSS・JavaScriptに加え、ログイン不要の商品一覧やキャンペーンページを短いTTLでキャッシュできれば、オリジンが受ける要求は大きく減ります。Origin Shieldは、リージョナルエッジキャッシュとオリジンの間にもう1層キャッシュを挟む機能で、キャッシュに無いオブジェクトへの要求をまとめてオリジンへの要求を減らします。追加料金がかかるため、画像変換のようにオリジンの処理が重い場合に検討します。

ディストリビューションあたりのリクエスト数には既定で毎秒250,000のクォータがあります（定額プランのディストリビューションには適用されません）。CloudFrontの全体像はAmazon CloudFrontの仕組みと料金プラン、費用の見積もりはCloudFrontの料金を実額で計算する方法で扱っています。

ALBとEC2 Auto Scalingによる計算資源の拡張

ALBはトラフィックに応じて自動で拡張しますが、急激なスパイクが拡張の速度を上回ると、CloudWatchのCapacityUtilizationが短時間100%に達することがあると公式ドキュメントに記載があります。ELBの種類と使い分けはElastic Load BalancingとALBの違いを参照してください。背後のEC2はAuto Scalingグループで台数を増減させます。方式は、動的スケーリングの3種類（ターゲット追跡・ステップ・シンプル）に予測とスケジュールを加えた5つです。

AWSは動的スケーリングのドキュメントでターゲット追跡を使うよう強く推奨しており、ステップと併用すると両者が衝突して増減を繰り返すことがあると注意しています。指標はCPU使用率よりもALBRequestCountPerTarget（ターゲットあたりのリクエスト数）が合う場合があります。ただし検知の速さは指標の発行間隔やアラーム設定にも依存するので、リクエスト当たりの処理負荷が大きく変わるアプリでは、CPU使用率も含めて負荷試験で選びます。複数のターゲット追跡ポリシーを併用した場合は、どれか1つがスケールアウトを求めれば増やし、スケールインを有効にしたすべてのポリシーがスケールインを求めたときだけ減らします。

見落としやすいのがデフォルトのインスタンスウォームアップです。起動直後のインスタンスはCPU使用率が一時的に高く、そのまま指標に含めると過剰に台数を増やします。AWSはこの設定の有効化を強く推奨していますが、既定では無効です。必要な秒数が分からなければ300秒から始め、実測で調整します。起動に時間がかかるアプリケーションなら、初期化済みのインスタンスを停止状態で待機させるウォームプールも選べます（停止中はEBSボリュームとElastic IPの料金だけがかかる）。コンテナで動かす場合の選択肢はAWS FargateとEC2の違いとECS・EKS・Fargate・Lambdaの選び方で比較しています。

データベース接続のプールと読み取り負荷の分散

計算資源を増やせる構成ほど、先に限界へ達するのはデータベースになりがちです。各サーバーのコネクションプールの上限が同じなら、アプリのサーバーを10台から40台に増やすと、データベースが受ける可能性のある接続数の上限も4倍になります。RDS Proxyはデータベース接続をプールして使い回し、すぐに捌けない接続はキューに入れるか制限するので、接続の急増でデータベースが倒れる事態を防げます。ただしクエリそのものの処理負荷やロック競合は減らず、セッション状態を使う処理ではピン留めで接続の使い回しが効かなくなるため、遅いクエリの見直しは別に必要です。

読み取りが多いサイトなら、参照系のクエリをリードレプリカへ振り分けます。Auroraは最大15台のレプリカを持てて、Aurora Auto Scalingの最小・最大キャパシティには0〜15を指定できます。ただし自動スケーリングの動作には少なくとも1台のリーダーが必要で、リーダーが0台かつ最小キャパシティが0の場合は動作しません。リーダーエンドポイントの振り分けは接続単位なので、コネクションプールを使う場合は新しいレプリカに接続が分散するよう接続の再作成方針も確認します。作成手順はリードレプリカの作成手順と読み書き分離、Aurora自体の特徴はAmazon Auroraの仕組みとRDSとの違いで解説しています。同じ結果を返すクエリが多いなら、Amazon ElastiCacheでデータベースの手前にキャッシュを置くほうが効きます。

DynamoDBのオンデマンドモードは、直前のピークの2倍までは即座に対応します。2倍を超える増加が30分以内に起きるとスロットリングが発生しうるため、セールのように10倍・100倍の跳ね上がりが見込まれる場合は、後述の事前ウォームで備えます。

Amazon SQSによる書き込み負荷の平準化

メール送信や、受付と確定を分けられる注文処理のように、受け付けた瞬間に処理を終える必要がない書き込みは、Amazon SQSのキューに積んでワーカーが処理する形に変えられます。ピーク時は受け付けだけを高速に返し、データベースへの書き込みは処理できる速度に均せます。標準キューは順序と一回だけの配信を保証しないため、注文IDなどで冪等性を確保し、処理順序が必要ならFIFOキューを選びます。設計の要点はAmazon SQSの標準キューとFIFOの違いを参照してください。

スケールしても止まるAWSのクォータ

Auto Scalingの最大台数とアカウントのクォータは別の制約です。最大台数を40にしていても、クォータが足りなければ台数は増えません。最大台数に必要なvCPU数を計算し、アカウントに適用されているクォータと照合します。主なクォータの既定値は次のとおりです（出典：EC2オンデマンドインスタンスのクォータ、API Gatewayのクォータ、CloudFrontのクォータ）。API Gatewayの値は東京などのリージョンに適用され、一部リージョンでは2,500RPS・バースト1,250です。

EC2の5vCPUはドキュメント上の既定値です。オンデマンドの上限はインスタンスタイプごとではなくvCPUの合計で管理され、m5.2xlarge（8vCPU）なら1台も起動できない計算になります。アカウントによっては既に引き上げられているため、必ず自分のアカウントの値を確認します。Lambdaも新規アカウントでは同時実行数が1,000より低く設定され、利用状況に応じて自動で引き上げられます。

API GatewayとLambdaを組み合わせる構成では、上限の不一致にも注意します。API Gatewayが10,000RPSを受け付けても、Lambda側の同時実行上限に達すると呼び出しが拒否され、API Gatewayは利用者に500を返します。必要な同時実行数は毎秒のリクエスト数に平均実行時間（秒）を掛けた値が目安で、平均0.2秒なら10,000RPSで約2,000です。Lambdaのクォータのページもこの不一致を例に挙げ、Lambda側の引き上げを勧めています。429を返す側の設計はAPIレート制限の5方式と429設計が参考になります。

クォータはService Quotasから確認できます。東京リージョンの値を確認する例です。

# EC2 オンデマンド標準ファミリーのvCPU上限
aws service-quotas get-service-quota \
  --service-code ec2 --quota-code L-1216C47A \
  --region ap-northeast-1 --query 'Quota.Value'

# Lambda の同時実行数
aws service-quotas get-service-quota \
  --service-code lambda --quota-code L-B99A9384 \
  --region ap-northeast-1 --query 'Quota.Value'

# API Gateway のアカウント単位スロットリング（RPS）
aws service-quotas get-service-quota \
  --service-code apigateway --quota-code L-8A5B8E43 \
  --region ap-northeast-1 --query 'Quota.Value'

引き上げの承認には日数がかかることもあります。イベント直前ではなく、構成を決めた段階で確認と申請を済ませます。

予告されたピークの前にやる事前準備の手順

ここでは、2026年11月21日9時（日本時間）にセールが始まる想定で、30分前に容量を積み、終了後に戻す手順を示します。各コマンドのパラメーター名と型はbotocore 1.42.97のAPI定義と照合済みですが、AWSアカウント上での実行結果ではありません。リージョンは東京（ap-northeast-1）を既定に設定したプロファイルを前提とし、台数は容量の重み付けをしていないグループを想定しています。リソース名・ARN・日時は環境に合わせて置き換え、通知先のSNSトピックは購読まで済ませたうえで、検証環境で動作を確かめてから本番に適用してください。必要台数と余裕率の見積もり方はキャパシティプランニングの手順にまとめています。

手順1：インスタンスウォームアップとターゲット追跡の設定

# デフォルトのインスタンスウォームアップを300秒に（既定は無効）
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --default-instance-warmup 300

# ターゲット1台あたり・1分間のリクエスト数を1,000に保つターゲット追跡ポリシー
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg \
  --policy-name alb-req-per-target \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ALBRequestCountPerTarget",
      "ResourceLabel": "app/web-alb/50dc6c495c0c9188/targetgroup/web-tg/943f017f100becff"
    },
    "TargetValue": 1000.0
  }'

TargetValueの1,000は、ターゲット1台あたり1分間に1,000リクエストという設定例です。負荷試験で応答時間の目標を守れる1台あたりの処理量を測り、毎分の値に換算したうえで余裕を持たせます。

手順2：スケジュールスケーリングによる開始前の増台

開始時刻はUTCで指定します。日本時間8時30分はUTCの前日23時30分です。終了側の設定は最小台数と最大台数を戻すもので、実台数を直ちに2台へ戻すものではなく、その後の縮小はターゲット追跡に任せます。

# 開始30分前（JST 8:30）に最小12台へ
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name web-asg \
  --scheduled-action-name sale-prewarm \
  --start-time 2026-11-20T23:30:00Z \
  --min-size 12 --max-size 40 --desired-capacity 12

# 終了後（JST 14:00）に最小台数を戻す
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name web-asg \
  --scheduled-action-name sale-end \
  --start-time 2026-11-21T05:00:00Z \
  --min-size 2 --max-size 20

最小台数を上げておけば、ターゲット追跡が働く前から12台で受けられます。開始後に負荷がさらに上がれば、ターゲット追跡が最大40台まで増やします。毎週同じ時刻に集中する場合は、--recurrenceにcron式と--time-zone Asia/Tokyoを指定すると日本時間で繰り返し設定できます。

手順3：ALBのLCU予約による容量下限の確保

2024年11月20日に提供が発表されたLCU予約は、ALBの容量に下限を設ける機能です。予約しても通常どおり自動で拡張し、予約値を下回らないように保たれます。予約は最小100LCUから指定できます。

aws elbv2 modify-capacity-reservation \
  --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/web-alb/50dc6c495c0c9188 \
  --minimum-load-balancer-capacity CapacityUnits=300

# 状態の確認
aws elbv2 describe-capacity-reservation \
  --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/web-alb/50dc6c495c0c9188

# イベント後に解除
aws elbv2 modify-capacity-reservation \
  --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/web-alb/50dc6c495c0c9188 \
  --reset-capacity-reservation

予約量は、過去の同規模イベントでのCloudWatchメトリクスPeakLCUsの1分ごとの合計から見積もるのがLCU予約のドキュメントの推奨です。課金は予約したLCUに対して発生し、実際の使用量が予約を下回っても減りません。料金ページの例（us-east-1）では、200LCUを予約して1時間に240LCU使った場合、予約分1.60ドルと超過40LCU分0.32ドルに時間料金が加わります。

手順4：DynamoDBテーブルの事前ウォーム

aws dynamodb update-table \
  --table-name orders \
  --warm-throughput ReadUnitsPerSecond=30000,WriteUnitsPerSecond=10000

# 反映の確認（WarmThroughput の Status が UPDATING から ACTIVE になれば完了）
aws dynamodb describe-table --table-name orders \
  --query 'Table.WarmThroughput'

ウォームスループットは、テーブルが即座に処理できる読み書きの量です。引き上げたい値を指定すると、課金モードを変えずに事前ウォームを申請できます。更新は非同期で進むため、describe-tableで状態がACTIVEになるのを待ちます。指定できるのはアカウントのテーブル単位クォータ（既定は読み取り・書き込みそれぞれ毎秒40,000単位）までです。プロビジョンドモードのテーブルでは、プロビジョンド容量もこの値まで上げておかないと、その容量を超えた要求はスロットリングされます。引き上げ差分には1回限りの料金がかかり、一度上げた値は下げられません。必要量を負荷試験で確かめてから指定します。

負荷試験による最初に飽和する層の特定

事前準備の数値は、負荷試験で確かめるまでは仮説です。本番と同じ構成（CloudFront・ALB・Auto Scaling・RDS Proxy）を検証環境に組み、想定ピークを超える水準（例えば1.5〜2倍。倍率は需要予測の幅と試験費用から決める）まで段階的に負荷を上げて、どの層が最初に飽和するかを見ます。セール開始の瞬間を再現するなら、徐々に上げる試験とは別に、短時間で一気に負荷をかける試験も行います。シナリオ設計と合否指標は負荷試験のシナリオ設計と合否指標、一気に負荷をかける試験の種類はラッシュテストとスパイクテストの違い、Pythonで書く場合はLocustによる負荷試験で扱っています。

AWS上で負荷試験をするときは、AWSのテストポリシーに沿います。EC2から大量のトラフィックを送るネットワークストレステストはStress Test policyの対象で、送信先がAWS内なら同じリージョンに置くよう求められ、経路やリージョンによって25Gbpsまたは100Gbpsを超えるとAWS側でトラフィックシェーピングをかける場合があります。意図的にパケットや接続の洪水で対象を圧倒する試験はDDoS試験として扱われ、EC2上での実施は禁止です。DDoS Simulation Testing policyでは、DDoSシミュレーションはAWSが事前承認したパートナーが、Shield Advancedで保護した自社リソースなどに対して実施するものとされ、技術的制限を超える試験は予定日の14日前までに例外承認を申請します。

アクセス集中を検知するCloudWatchの指標とアラーム

落ちてから気づくのでは増台が間に合いません。層ごとに上限へ近づいたことを示す指標を選び、アラームを置きます。ALBの指標の定義はALBのCloudWatchメトリクス、Auto Scalingグループの指標はAuto Scalingのメトリクスに一覧があります。

TargetResponseTimeは、要求がロードバランサーを出てからターゲットが応答ヘッダーを返し始めるまでの秒数です。平均ではなく百分位（p99など）で見ると、一部の利用者だけが待たされ始めた段階で気づけます。5xxは発生元で2つに分かれ、HTTPCode_ELB_5XX_Countにはターゲットが返した応答は含まれません。前者が増えていれば入口とターゲットの間、後者が増えていればアプリかデータベースを疑います。

Auto Scalingグループの指標は、有効にしないと送られません。有効にすれば1分粒度で、追加料金はかかりません。次の例は、グループの指標を有効にし、ALBの応答時間のp99が1秒を超える状態が3分のうち2回続いたらSNSへ通知するアラームを作ります。閾値は平常時の値と応答時間の目標から決めてください。

# Auto Scaling グループの指標を有効化（1分粒度・追加料金なし）
aws autoscaling enable-metrics-collection \
  --auto-scaling-group-name web-asg \
  --granularity 1Minute

# ALB の応答時間 p99 が 1 秒を超えたら通知
aws cloudwatch put-metric-alarm \
  --alarm-name web-alb-p99-latency \
  --namespace AWS/ApplicationELB \
  --metric-name TargetResponseTime \
  --dimensions Name=LoadBalancer,Value=app/web-alb/50dc6c495c0c9188 \
  --extended-statistic p99 \
  --period 60 --evaluation-periods 3 --datapoints-to-alarm 2 \
  --threshold 1 --comparison-operator GreaterThanThreshold \
  --treat-missing-data notBreaching \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:ops-alert

アクセス集中が起きている最中の対処手順

サイトが遅い、または5xxが出始めたら、次の順に進めます。先に詰まっている層を特定しないと、データベースが原因なのにアプリを増やして接続数をさらに増やす、という逆効果の手を打ちかねません。

手順1：メトリクスによる詰まっている層の特定

• HTTPCode_ELB_5XX_CountやRejectedConnectionCountが増えている：ALBとターゲットの間か、ALB自身の容量を疑う。
• HTTPCode_Target_5XX_CountとTargetResponseTimeが増え、DatabaseConnectionsが上限付近：データベースが先に詰まっている。アプリの増台は後回しにする。
• GroupDesiredCapacityがGroupInServiceInstancesを上回ったまま縮まらない：インスタンスが起動しない。Auto Scalingの活動履歴でクォータ超過などの失敗を確認する。
• LambdaのThrottlesが出ている：アカウントの同時実行上限か、関数ごとの拡張速度（10秒ごとに1,000実行環境）のどちらに当たっているかを、同時実行数の推移と合わせて見る。
• どの層にも余裕があるのに要求数だけが異常に多い：特定のIPやパスへの偏りを見て、悪意のある集中かを判断する。

手順2：最大台数・クォータの確認と増台

計算資源が足りないと分かったら、手動で台数を増やします。Auto Scalingグループの希望容量は最小台数以上・最大台数以下の範囲でしか指定できないため、最大台数に達しているなら先に最大台数を上げます。手動で増やした後も、Auto Scalingは設定済みのスケーリングポリシーとスケジュールに沿った動作を再開します。そこで希望容量ではなく最小台数を引き上げます。希望容量を指定せずに現在の台数より大きい最小台数を設定すると、希望容量はその最小台数まで上がり、すでにそれ以上で動いているなら台数は減りません（希望容量を直接20に指定すると、30台で動いている最中なら縮小が始まります）。最小台数で防げるのは動的スケーリングによる縮小だけで、事前準備の手順2で登録した終了側のスケジュールが来れば最小台数は2に戻るため、障害が長引く場合は予定済みのアクションも確認します。

# 現在の希望容量と最大台数を確認
aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names web-asg \
  --query 'AutoScalingGroups[0].[DesiredCapacity,MaxSize]'

# 現在の値より大きいことを確かめたうえで、最小20台・最大60台に設定
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --min-size 20 --max-size 60

# 起動の進み具合と失敗理由を確認
aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name web-asg --max-items 5

vCPUのクォータに当たっていれば、この操作でも台数は増えません。クォータの引き上げは障害対応中に頼れる手段ではないので、事前の確認が前提です。

手順3：CloudFrontによるオリジンへの流入削減

増台が効くまでの数分を稼ぐには、オリジンへ届く要求を減らします。CloudFrontは、オリジンが応答しないか500〜599のエラーを返したときに、キャッシュ済みの古いコンテンツを返すStale-If-Errorに対応しています。例えばCache-Control: max-age=3600, stale-if-error=86400なら、1時間キャッシュしたうえで、オリジンが落ちている間は最大24時間古い版を返します（CloudFrontの最大TTLが短ければその時間で打ち切られます）。効くのはキャッシュ済みのオブジェクトだけなので、ヘッダーは平常時から付けておきます。

古い版を持たないページには、カスタムエラーレスポンスで、オリジンが返した5xxをS3に置いた静的な「ただいま混雑しています」ページへ差し替えます。CloudFrontはエラー応答を既定で10秒キャッシュし、その間は同じオブジェクトへの要求をオリジンへ送りません。ただしCloudFrontのエラー処理の説明のとおり、マネージドのCachingDisabledポリシーを使う動作ではエラーもエラーページもキャッシュされないため、購入処理のようにキャッシュを無効にしたパスでは流入は減りません。あわせて、レコメンドやサイト内検索のように重いが止めても購入には響かない機能を一時的に止めれば、残った処理能力を購入や予約に回せます。

手順4：AWS WAFによる悪意のあるアクセスの遮断

特定のIPやパスへの偏りは調査の手掛かりにすぎず、人気商品のページや社内の共有IPからでも起きます。送信元・User-Agent・リクエストの中身から正規の利用者でないと判断できたら、AWS WAFのレートベースルールで制限します。評価ウィンドウは60・120・300・600秒から選べ（既定は300秒）、レート上限は最小10から設定できます。ログイン画面のように正規の利用者でも短時間に何度も送る場所は誤遮断が起きやすいので、まずCountアクションで件数を見てからBlockへ切り替えます。ルールの書き方と誤検知の切り分けはWAFルールの書き方にまとめています。

待機室と販売方法の変更で入場を絞る判断

チケット発売のように、どれだけ容量を積んでも需要が上回るケースでは、入場者数を制御する待機室が現実的な選択肢になります。オリジンが捌ける人数だけを通し、残りには順番待ちの画面を表示します。

注意したいのは、AWSが提供していたVirtual Waiting Room on AWSは提供が終了した点です。ソリューションのページには「This AWS Solution is no longer available.」と表示され、GitHubのリポジトリもアーカイブ済みです（最後のリリースはv1.1.15・2025年9月17日）。READMEは代替として、AWS Marketplaceの製品か、CloudFront FunctionsとCloudFrontで来訪者を優先制御する構成をAWSブログの手順に沿って自前で組むことを勧めています。これから待機室を入れるなら、このソリューションは選ばず、CDN事業者の待機室機能か専用製品を比較します。

待機室よりも先に検討したいのが、ピークそのものを崩す販売側の手です。先着順の一斉販売を抽選販売に変える、会員ランクや地域ごとに販売開始時刻をずらす、事前登録者にだけ購入用URLを送る、といった変更は、インフラの容量を1台も増やさずに瞬間の要求数を下げます。先着順で売る理由が無いなら、システムで受け止める前に販売方法を変えるほうが安く確実です。

アクセス集中対策が裏目に出るケース

• Auto Scalingだけで突発的な集中を受けようとする：インスタンスの起動とウォームアップには分単位の時間がかかる。数十秒で10倍になる集中には間に合わないので、キャッシュで吸収できる割合を先に増やす。
• ログイン後のページをキャッシュする：キャッシュキーにCookieや認証ヘッダーを含めずに個人ページをキャッシュすると、他人の情報を返す事故になる。ログインしていなくても、カートの中身や閲覧履歴のようにCookieで表示が変わるページは同じ扱いになる。キャッシュするのは、同じキャッシュキーに対して誰にでも同じ内容を返せるページに限る。
• LCU予約やスケジュールを戻し忘れる：イベント後も予約や最小台数が残ると、使わない容量に課金され続ける。終了側のスケジュールもイベント前に登録しておく。

単一リージョンの障害まで含めて止まらない構成を考えるなら、サーバーのBCP対策とRTO・RPOの決め方が次の検討範囲です。構成の設計から負荷試験・本番切り替えまでを外部に任せる場合は、AWSなどのインフラ構築支援で相談を受けています。

よくある質問

アクセス集中対策は何から始めればよいですか？

まずキャッシュです。静的ファイルとログイン不要のページをCloudFrontで返せるようにすると、オリジンが受ける要求を減らせます。そのうえで、データベースの接続数とアカウントのクォータを確認します。台数を増やす設定はその後で構いません。

Auto Scalingはアクセスが急増してから何分で効きますか？

負荷の検知から追加容量がリクエストを処理するまでの時間は、CloudWatchでの検知、インスタンスの起動・初期化、ALBのヘルスチェックに依存します。デフォルトのインスタンスウォームアップは主にスケーリング指標の扱いを制御する設定で、満了までリクエストを受け付けない設定ではありません。開始時刻が分かっている集中は、スケジュールスケーリングで事前に最小台数を上げておきます。

ECサイトのセールに備えて最低限やることは？

スケジュールスケーリングで開始前に台数を積むこと、利用するAWSサービスのクォータを確認すること、データベースの接続数と処理性能を負荷試験で確かめることの3つです。注文処理をSQSで非同期にできれば、決済などの外部APIが遅くなっても受け付けを止めずに済みます。先着順でなくてよい商品なら、抽選販売への変更も検討します。

サイトが落ちたとき最初に何を確認しますか？

ALBのHTTPCode_ELB_5XX_CountとHTTPCode_Target_5XX_Countのどちらが増えているか、データベースのDatabaseConnectionsが上限付近か、Auto Scalingの希望台数に稼働台数が追いついているかの3点です。詰まっている層が分かってから、増台・流入削減・遮断のどれを打つかを決めます。

スケーラビリティを高めると費用はどれだけ増えますか？

台数を常時増やす方式は費用が比例して増えますが、Auto Scalingとキャッシュを組み合わせれば、ピークの時間帯だけ費用が増える形にできます。継続的な費用として確認したいのは、解除し忘れたLCU予約やOrigin Shieldの追加料金です。DynamoDBの事前ウォームは引き上げ分に対する一回限りの課金です。

関連記事

• スケーラブル（スケーラビリティ）とは？意味・言い換えと弾力性との違い、拡張性の測り方
• 負荷試験とは？シナリオ設計と合否指標、本番相当環境の揃え方をk6の実例で解説
• Amazon CloudFrontとは？仕組み・料金プランとエッジ機能・採用判断を実装者目線で解説
• Elastic Load Balancingとは？ELBとALBの違い・4種類の使い分けと料金・設定を解説
• 503エラーとは？原因の切り分けと復旧・再発防止をサーバー実装目線で解説【2026年版】