Amazon SAA-C03: コンピューティング、Auto Scaling、インスタンス管理 — 学習ガイド

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

こちらの一部です： AWS SAA-C03 — 完全学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

EC2インスタンスタイプとAMI

適切なEC2インスタンスファミリーを選択することは、適切に設計されたコンピューティング層の基盤です。なぜなら、ファミリー、世代、サイズが一体となって、CPUアーキテクチャ、vCPUあたりのメモリ比率、ネットワーク帯域幅、利用可能なアクセラレータを決定するためです。汎用 (M6i, M7g, Tシリーズ) は、バランスの取れたウェブ層や混合ワークロードに適しています。コンピューティング最適化 (C7i, C7gn) は、CPUバウンドなシミュレーション、エンコーディング、バッチ処理、ウェブフロントエンドに適合します。メモリ最適化 (R7i, X2idn) は、インメモリデータベースやキャッシュを対象としています。ストレージ最適化 (I4i, D3) は、NoSQL、HDFS、データウェアハウジングを対象としています。高速コンピューティング (P5, G5, Trn1, Inf) は、GPUやMLシリコンを提供します。Graviton (g サフィックス) インスタンスは、ARM64にクリーンにコンパイルできるスケールアウトワークロードに対して、通常20〜40%優れたコストパフォーマンスを提供します。

Tファミリーはバースト可能で、デフォルトでは標準モードです。このモードでは、アイドル中にCPUクレジットが蓄積され、バースト中に消費されます。クレジットが枯渇すると、パフォーマンスはベースラインにスロットリングされます。予測不能なスパイクがあるワークロード（小規模なウェブ層、開発/テスト環境、またはスパイク的なフロントエンドを支えるElastic Beanstalk環境など）の場合、無制限モードのTインスタンスを使用すると、インスタンスはクレジットを借用でき、超過分に対してvCPU時間あたり少額の追加料金が請求され、ユーザーに可視なスロットリングを回避できます。これが、短いCPU飽和状態が発生するBeanstalk環境が、より高価なコンピューティング最適化ファミリーにアップグレードするのではなく、通常は無制限モードを有効にすることで修正される理由です。Tシリーズを真にスパイク的で平均負荷が低いワークロードに限定することが重要です。標準モードでCPUを持続的に使用すると、数分でクレジットを使い果たしてしまいます。

垂直スケーリング（ファミリー内でより大きなサイズに移行すること）は、利用可能な最大のインスタンスによって制限され、変更にはダウンタイムを伴い、単一障害点を生み出し、アベイラビリティーゾーンをまたいでワークロードを分散させることはできません。負荷が大幅に変動する場合は常に、Auto Scalingグループによる水平スケーリングが正しい答えです。

ゴールデンAMIは、アプリケーションコード、ランタイム、依存関係をルートスナップショットに焼き込むことで、高速で決定論的な起動を実現します。これは、Auto Scalingがスパイクに反応する際に非常に重要です。起動のたびにユーザーデータを通じてブートストラップを行うと、まさに最悪のタイミングで数分間のレイテンシーが追加されます。

ストレージの選択: インスタンスストア vs EBS、スナップショット、高速スナップショット復元

インスタンスは2つのストレージ基盤を提供します。インスタンスストア（物理ホストに接続されたエフェメラルなNVMe）とAmazon EBS（ネットワーク接続型ブロックストレージ）です。インスタンスストアは可能な限り低いレイテンシーを提供しますが、そのデータは停止、休止、終了、またはハードウェア障害時に破棄されます。これを永続ストレージとして扱うことは、一般的で危険な間違いです。これは、スクラッチ領域、バッファ、キャッシュ、または他のノードにレプリカが存在するHDFSデータノードのような複製データにのみ適しています。永続的なデータは、S3に保存されたスナップショットによってバックアップされるEBSに配置すべきです。

スナップショットは一度作成されると増分形式であり、独立しているため、新しいボリュームに復元してもソースには一切影響しません。大規模な本番データセットをテスト環境に複製する標準的な方法は、ソースボリュームのスナップショットを取得し、そのスナップショットから新しいボリュームを作成することです。しかし、スナップショットから復元されたボリュームは、最初の読み取り時に**S3からブロックを遅延ロード（lazy-load）**するため、各ブロックがハイドレートされるまで重大なI/Oレイテンシーが発生します。同じ遅延ロードは、ルートスナップショットが大きいAMIから起動された新しいインスタンスにも影響し、起動後数分間は動作が遅く感じられます。

**EBS高速スナップショット復元（FSR）**は、そのペナルティを解消します。ASGがインスタンスを起動するAZに対してスナップショットでFSRを有効にすると、そこから作成されたボリュームはすぐにプロビジョニングされた完全なパフォーマンスを提供します。

aws ec2 enable-fast-snapshot-restores \
  --availability-zones us-east-1a us-east-1b \
  --source-snapshot-ids snap-0123456789abcdef0

これは、スケールアウトイベントで数分ではなく数秒でキャパシティを追加する必要がある場合に不可欠です。

ENAとEFAによる拡張ネットワーキング

公称ネットワークスループットはインスタンスサイズに応じてスケールしますが、Elastic Network Adapter (ENA) ドライバが存在する場合にのみ達成可能です。ENAはSR-IOVベースの拡張ネットワーキングを提供し、新しいインスタンスでは最大200 Gbpsをサポートします。最新のAMI（Amazon Linux 2、最近のUbuntu、Windows）にはENAが有効化された状態で出荷されています。次のようにして確認してください。

aws ec2 describe-instances --instance-ids i-0abc \
  --query 'Reservations[].Instances[].EnaSupport'

modinfo ena | grep version
ethtool -i eth0

ENAがない場合、インスタンスはサイレントに低スループットと高ジッターにフォールバックし、プレイスメントグループの選択に関わらず、あらゆる低レイテンシー設計を損ないます。

マイクロ秒スケールの集団通信（CFD、気象モデリング、分子動力学、大規模モデルのトレーニングなど）には、Elastic Fabric Adapter (EFA) を追加します。EFAは、OSバイパス転送（Libfabric）をMPIおよびNCCLに公開し、カーネルのネットワークスタックを完全に回避します。EFAは、サポートされているインスタンスタイプ（c7gn、hpc7a、p5）上のクラスタープレイスメントグループ内でのみその利点を発揮し、EFAドライバに加えて互換性のあるMPI（Open MPI、Intel MPI）またはNCCLビルドが必要です。

aws ec2 create-placement-group --group-name hpc-cg --strategy cluster
aws ec2 run-instances --instance-type hpc7a.96xlarge \
  --placement GroupName=hpc-cg \
  --network-interfaces InterfaceType=efa,DeviceIndex=0,SubnetId=subnet-abc

プレイスメントグループ

プレイスメントグループは、インスタンスの物理的なトポロジーを制御します。

選択を誤ると、この機能の利点を活かせません。クラスターグループはAZをまたぐことはできません。設計上、単一AZ内（intra-AZ）に限定されます。スプレッドは、AZあたり7つという上限があるため、100台のWebサーバーをホストすることはできません。40ノードのKafkaクラスターには、スプレッドではなくパーティションプレイスメントが適切なツールです。なぜなら、レプリカの配置をフォルトドメインと整合させることができるからです。一般的な高可用性を実現するためには、ASGを単一AZの単一プレイスメントグループに限定せず、複数のAZにまたがってASGを分散させるべきです。

ストリーミング分析やMPIワークロードのように、ノード間のレイテンシーを最小限に抑える必要がある場合、クラスタープレイスメントグループとENA対応インスタンスの組み合わせが正解です。クラスターはホップ数を削減し、ENAはそのレイテンシーの利点を実現するために必要なパケット/秒のキャパシティを提供します。

Auto Scalingグループと起動テンプレート

Auto Scalingグループ（ASG）は、MinSize、DesiredCapacity、MaxSizeという3つの整数とサブネットのリストによって定義され、1つ以上のAZにわたってEC2インスタンスの希望する数を維持するランタイムユニットです。ASG自体は何を起動するかを記述しません。それは、起動設定（launch configuration）に代わる現代的な後継である起動テンプレートの役割です。起動テンプレートは、バージョニング、混合インスタンスポリシー、スポット/オンデマンドの混在、IMDSv2の強制、キャパシティ予約、およびTインスタンスの無制限モードをサポートします。起動テンプレートは、AMI、インスタンスタイプ、セキュリティグループ、IAMインスタンスプロファイル、ユーザーデータ、およびブロックデバイスマッピングを参照します。

ステートレスなWebアプリケーションの典型的なパターンは、AMI + 起動テンプレート + ASG + ALBです。AMIは高速な起動を提供し、ALB（TCP/UDPの場合はNLB）はトラフィックを分散させ、ヘルスチェックを実行します。ASGは新しいインスタンスを自動的にターゲットグループに登録し、異常なインスタンスを終了させます。マルチAZでのデプロイ（最低2つのAZ、クォーラムシステムでは3つ）は必須です。単一のサブネットに紐づけられたASGは、AZ障害を乗り切ることができません。なぜなら、AZが機能不全に陥っている間、ASG自体が代替インスタンスを起動できないからです。

MyASG:
  Type: AWS::AutoScaling::AutoScalingGroup
  Properties:
    MinSize: 2
    MaxSize: 20
    DesiredCapacity: 4
    VPCZoneIdentifier: [subnet-a, subnet-b]
    TargetGroupARNs: [!Ref AppTargetGroup]
    LaunchTemplate:
      LaunchTemplateId: !Ref AppLT
      Version: !GetAtt AppLT.LatestVersionNumber
    HealthCheckType: ELB
    HealthCheckGracePeriod: 120

スケーリングポリシー: ターゲット追跡、ステップ、スケジュール、予測

ASGのスケーリングには4つのモードがあり、それぞれが異なる問題を解決します。

• ターゲット追跡は、メトリクスを選択し、設定値（例: ASGAverageCPUUtilization = 50%、ALBRequestCountPerTarget = 1000）の近くに維持します。これは自己調整型であり、AWSがアラームを管理し、メトリクスの逸脱に応じて速度を調整します。これがデフォルトの選択肢となるべきです。
• ステップスケーリングは、メトリクスが範囲からどれだけ外れているかに基づいて、段階的にキャパシティを追加または削除します。アラームの深刻度に応じて対応の規模をスケーリングする必要がある場合に便利です。
• シンプルスケーリングはレガシーです。アラームごとに単一の調整しか行わず、クールダウン中はブロックされるため、新しい設計で選択すべきではありません。
• スケジュールされたスケーリングは、cronのように指定した時間にMinSize/DesiredCapacity/MaxSizeを変更します。
• 予測スケーリングは、最大14日間の履歴データに対して機械学習を使用し、次の48時間を予測して、需要が急増する前にキャパシティを事前プロビジョニングします。

動的スケーリングは本質的に遅延を伴います。メトリクスがしきい値を超えた後に初めて反応し、新しいインスタンスは起動、登録、ウォームアップに数分を要します。全ユーザーが09:00にアクセスを開始し、ASGが追いつくまでの2〜3時間、動作が遅くなるような業務アプリケーションでは、動的スケーリングだけでは不適切な解決策です。需要が発生する前にスケジュールされたアクションを重ねて、ピークに備えてMinSizeとDesiredCapacityを引き上げておきます。

ScheduledAction:
  AutoScalingGroupName: web-asg
  ScheduledActionName: pre-sale-warmup
  Recurrence: "0 8 * * *"
  MinSize: 20
  DesiredCapacity: 30
  MaxSize: 200

その後、ターゲット追跡に残りの変動を吸収させます。予測スケーリングは、ピークの形状は安定しているものの、その正確なタイミングが日によって変動する場合に適切な選択です。予測可能な非本番環境のシャットダウン（開発環境の夜間や週末の停止など）には、金曜の夜にdesired=0, min=0にし、月曜の朝に戻すスケジュールされたアクションが、最もオーバーヘッドの少ない解決策です。ASG自体がスケジュールエンジンとなるため、LambdaやEventBridgeによる連携は不要です。

メトリクスの選択は、ポリシーの選択と同じくらい重要です。CPUはCPUバウンドなWebワークロードには有効ですが、SQSからプルするバックログ駆動のワーカーの場合は、CPUではなくキューの深さでスケーリングする必要があります。I/Oでブロックされたワーカーは、何百万ものメッセージが蓄積されている間もCPU使用率が10%程度しか示さないことがあります。インスタンスあたりのApproximateNumberOfMessagesVisibleを、カスタムメトリクスとして公開するか、組み込みのSQSQueueBacklogPerInstanceターゲットを介して使用します。

backlog_per_instance = messages_visible / running_instances
target = acceptable_latency_seconds / avg_processing_seconds_per_msg

TargetTrackingConfiguration:
  CustomizedMetricSpecification:
    MetricName: BacklogPerInstance
    Namespace: MyApp/Scaling
    Statistic: Average
  TargetValue: 100

同様に、レイテンシーに敏感なHTTP層はTargetResponseTimeやRequestCountPerTargetを追跡すべきです。メモリ、ディスク、またはダウンストリームのレイテンシーに制約されるアプリケーションは、実際のボトルネックを反映するカスタムメトリクスを公開すべきです。CPUが制約でないにもかかわらずCPUでスケーリングすると、インスタンスがスケールアウトせず、キューが無限に増大し、ALBが5xxエラーを返すという、まさに典型的な障害モードを引き起こします。

ヘルスチェックとライフサイクルフック

ASGはデフォルトでEC2ステータスチェックを使用しますが、これはハイパーバイザーの障害は検知できますが、アプリケーションの障害は検知できません。ASGでELBヘルスチェックを有効にすると、インスタンスを置き換えるかどうかの判断が、ロードバランサーのアプリケーションレベルのプローブに委任されます。これは、OSは正常でもプロセスが応答不能になっている場合に不可欠です。HealthCheckGracePeriodは、ユーザーデータが完了するのに十分な長さに設定してください。さもないと、新しいインスタンスがブートストラップの途中で終了させられ、ループに陥ります。

ロードバランサーの選択によって、「正常」の意味が変わってきます。

TCPヘルスチェックのみを行うNLBの背後にあるHTTPアプリケーションは、接続は受け付けるが500エラーを返すインスタンスにもトラフィックを送り続けてしまいます。意味のあるシグナリングを回復するには、ALBに切り替えるか、NLBでHTTPヘルスチェックを設定してください。

ライフサイクルフックは、インスタンスをPending:WaitまたはTerminating:Waitの状態で一時停止させ、外部の自動化処理を実行できるようにします。起動時、フックによって、ALBがトラフィックを送信する前に、設定管理システムへの登録、キャッシュのウォームアップ、シークレットの取得などが可能になります。終了時、フックによって、セッションのドレイニング、ログのフラッシュ、サービスメッシュからの登録解除などが可能になります。フックはEventBridgeイベントを発行します。ハンドラーはCompleteLifecycleActionを呼び出す必要があります。さもないと、フックはタイムアウトし、デフォルトのアクション（CONTINUEまたはABANDON）が実行されます。

ウォームプールとハイバネーション

大規模なモデルのロード、キャッシュのウォームアップ、JITコンパイルなどを実行してからサービスを開始するアプリケーションにとって、コールドローンチ（起動）時間は深刻な問題です。ウォームプールは、ASGにアタッチされた、事前初期化済みのインスタンスの予備プールです。インスタンスは起動してブートストラップを実行した後、停止、実行中、またはハイバネート状態でプールに保持され、ASGがスケールアウトするまで待機します。プールからインスタンスを取得することで、数分かかる起動時間をスキップできます。

ハイバネーションは、OSを暗号化されたEBSルートボリュームにサスペンド（待避）するため、JVMヒープ、MLの重み、OSのページキャッシュなどが再開時に復元されます。要件は、RAMを保持するのに十分な大きさの暗号化されたルートボリューム、サポートされているファミリーでインスタンスRAMが150GB以下であること、そして起動時にHibernationOptions.Configured = trueが設定されていることです。PoolState: Hibernatedを指定したウォームプールは両方を組み合わせたものです。インスタンスは停止中はコンピューティングコストがかからず、メモリにデータがロードされた状態で数秒で再開します。これは、「生産的になる前にメモリのロードに時間がかかる」アプリケーションにとって正しいパターンです。

スケール不可能なワークロードの自動復旧

すべてのワークロードが水平方向にスケールできるわけではありません。MACアドレスに紐づいたライセンス、ファイルベースのロック、共有ストアのないインメモリセッション状態を持つレガシーアプリケーションは、複数のインスタンスで実行できません。追加のノードを起動すると、データ破損やライセンス違反を引き起こします。これらの場合、耐障害性はスケールアウトではなく自動復旧によってもたらされます。

2つのパターンが有効です。StatusCheckFailed_Systemに対するCloudWatchアラームとEC2の復旧アクションを組み合わせることで、基盤となるホストに障害が発生しても、インスタンスID、プライベートIP、Elastic IP、EBSアタッチメントを維持できます。さらにシンプルなのは、複数のAZにまたがる**MinSize=MaxSize=1に設定したASG**です。これにより、障害が発生したインスタンスが置き換えられ、復旧アクションとは異なり、AZ障害を乗り切ることができます。ただし、そのためには状態がルートボリュームの外部に保存されているか、AMIが再構築可能であることが条件です。

ロードバランサーとサブネットの配置

ALBはL7で動作し、HTTP/HTTPSを終端し、ホスト/パス/ヘッダーベースのルーティング、HTTP/2、WebSockets、WAF/Cognito/OIDC統合を提供します。NLBはL4で動作し、クライアントIPを維持し、静的IPとTLSパススルー、PrivateLinkをサポートし、毎秒数百万の接続を維持できます。Gateway Load Balancerは、サードパーティ製のアプライアンス（ファイアウォール、IDSなど）をトラフィックパスに挿入します。

サブネットの配置は、アーキテクチャが最も破綻しやすいポイントです。インターネット向けのALBは、パブリックサブネットにアタッチする必要があります。パブリックサブネットとは、インターネットゲートウェイへの0.0.0.0/0ルートを持つサブネットのことで、ターゲットが存在する各AZに1つずつ必要です。ターゲット自体はプライベートサブネットに配置します。ALBがプライベートサブネットに配置されたり、「パブリック」サブネットにIGWへのデフォルトルートがない場合、クライアント側で接続タイムアウトが発生します。ターゲットへの到達性を確保するには、ターゲットのセキュリティグループで、ターゲットポートに対してALBのセキュリティグループからのインバウンドを許可する必要があります。同じVPC内のALBとターゲット間ではNATは不要です。

Client → IGW → ALB (public subnets, SG: allow 443 from 0.0.0.0/0)
              → Targets (private subnets, SG: allow 8080 from ALB-SG)

ASGでELBヘルスチェックを有効にして、異常なターゲットが単に登録解除されるだけでなく、置き換えられるようにします。クロスゾーン負荷分散（ALBではデフォルト、NLBではオプトイン）は、AZごとのインスタンス数に関係なく、リクエストの分散を均等にします。Route 53は、エイリアスレコード（または複数のALB間での加重/レイテンシーポリシー）を介してALBを解決するように設定する必要があります。個々のEC2のIPにRoute 53を直接向けてはいけません。なぜなら、障害が発生したインスタンスはTTLが切れるまでトラフィックを受け取り続け、ASGによって置き換えられたインスタンスは異なるIPを持つためです。

購入モデルと混合インスタンスフリート

購入モデルの選択は、アーキテクチャパターンとは無関係に、EC2の費用を削減するための最も大きな手段です。

合理的な戦略は、ベースラインの負荷をリザーブドインスタンスまたはSavings Planで、バーストをオンデマンドで、フォールトトレラントな作業をスポットで賄うことです。ASGでは、これは混合インスタンスポリシーとして表現されます。

MixedInstancesPolicy:
  LaunchTemplate:
    LaunchTemplateSpecification:
      LaunchTemplateId: lt-0abc123
      Version: $Latest
    Overrides:
      - InstanceType: m5.large
      - InstanceType: m5a.large
      - InstanceType: m6i.large
      - InstanceType: m6a.large
  InstancesDistribution:
    OnDemandBaseCapacity: 4          # covered by Savings Plan
    OnDemandPercentageAboveBaseCapacity: 20
    SpotAllocationStrategy: price-capacity-optimized

インスタンスタイプを多様化することで、スポットプールが深まり、相関のある中断が減少します。price-capacity-optimized（またはcapacity-optimized）は、価格とプール深度のバランスを取り、インスタンスが回収される可能性を低くします。

スポットは、ステートレス、チェックポイント可能、再試行可能、または水平方向に冗長なワークロードに適しています。例えば、ALBの背後にあるウェブワーカー、自動再試行機能を持つBatchジョブ、Sparkエグゼキュータ、CIランナーなどです。常時稼働が必須の重要なサービス、ステートフルなプライマリデータベース、または回復パスのないリーダーノードの唯一のキャパシティとしては不適切です。2分前の中断通知では安全なシャットダウンを保証できず、特定のインスタンスタイプがフリート全体で相関して回収されることは、現実の障害モードです。要件が「中断されてはならない」である場合、スポットは選択肢から外れます。

逆の落とし穴は、真に変動するワークロードにRIやSavings Planを適用することです。使用したかどうかに関わらず時間単位のコミットメント料金を支払うため、168時間のコミットメント下で週に40時間稼働するワークロードは、予約の76%を無駄にします。価格ではなくキャパシティ自体が懸念事項である場合（イベント駆動の急増、災害復旧など）、オンデマンドキャパシティ予約を使用します。これは、オンデマンド料金でAZスコープの純粋な保証を提供するもので、割引のためにSavings Planと組み合わせることができます。

サーバーレスコンピューティング: LambdaとFargate

サーバーレスは、キャパシティ管理をプラットフォームに移譲します。Lambdaは、イベント駆動で短時間の処理に適しています。例えば、S3のObjectCreatedトリガー、DynamoDB Streams、低ボリュームのSQSコンシューマー、API Gatewayのバックエンド、グルーロジックなどです。メモリ（128 MB～10,240 MB）はCPUを比例的にプロビジョニングするため、メモリを増やすチューニングは実行時間を短縮し、結果としてコストを削減することがよくあります。ハードリミットがその適用範囲を定義します。最大実行時間15分、メモリ10GB、/tmp 10GB、非圧縮デプロイパッケージ250MB（コンテナイメージ経由では10GB）、同期ペイロード6MBです。30分のビデオトランスコード、数時間にわたるETL、またはGPUトレーニングにLambdaを使用するのはアーキテクチャ的に誤りです。関数は処理の途中でタイムアウトし、再試行ロジックは無駄を増やすだけです。レイテンシーに敏感なパスでは、プロビジョンドコンカレンシーを使用して、コールドスタートとVPCにアタッチされたENIの初期化時間を軽減します。

Fargateは、EC2ホストを管理することなくコンテナを実行します。タスクが15分を超えたり、カスタムランタイムが必要だったり、ECS/EKSオーケストレーションには適合するがチームがキャパシティ管理をしたくない場合に、適切な選択肢となります。FargateはvCPU時間あたりのコストがEC2スポットよりも高いため、定常状態の利用率が高く予測可能な場合は、ECS上でスポットインスタンスを使用した混合インスタンスASGの方が安価です。バースト性のある、または予測不能なトラフィックに対しては、Fargateの秒単位の課金が有利です。

多数のLambdaをオーケストレーションする場合、SNS/SQSで連鎖させるよりもStep Functionsが望ましいです。なぜなら、視覚的な実行履歴、再試行セマンティクス、集中エラーハンドリング、永続的な状態管理を提供するからです。標準ワークフローはステート遷移ごとに課金され、最大1年間実行できます。Expressワークフローは、高ボリュームで短時間のイベント処理に最適化されています。

ゲノミクス、モンテカルロ、ETLなど、何千ものパラメータ化されたコンテナジョブのファンアウトには、AWS Batchが、管理されたEC2、スポット、またはFargate全体で、キューイング、依存関係の解決、再試行、プロビジョニングを処理します。ジョブはジョブ定義（コンテナ + vCPU/メモリ + IAMロール）を参照し、Batchはそれらを適切なサイズのインスタンスにビンパッキングします。Step Functionsは、1つのステートマシン内でBatch、Lambda、ECSをオーケストレーションするためによく使用されます。

Elastic Beanstalk

Beanstalkは、アプリケーションバンドルからALB、ASG、EC2インスタンス、そしてオプションでRDSをプロビジョニングするマネージドPaaSです。CloudWatchとの統合により、ローリング、ローリング（追加バッチあり）、イミュータブル、ブルー/グリーンデプロイメントをサポートします。スケーリングポリシーは、環境オプション（メトリクス、しきい値、最小/最大）として公開されています。Beanstalkはデフォルトでバースト可能なインスタンスタイプを使用するため、T-unlimitedモードを有効にすることは、一時的なCPU飽和に対する手軽な修正策です。スケジュールされたスケーリングアクションは、他のASGと同様に、Beanstalkが管理するASGにアタッチされます。チームがCloudFormationを手動で作成することなく標準的なウェブアプリのトポロジーを望み、かつローリングアップデートとバージョン管理されたバンドルがリリースサイクルに合致する場合に、Beanstalkを選択します。

Systems Managerによるフリート管理

SSHと踏み台サーバーのパターンは脆弱で、セキュリティ確保のコストが高くなります。AWS Systems Managerはこれらを置き換えます。SSMエージェント（Amazon Linux 2、Ubuntu、Windowsにプリインストール済み）と、AmazonSSMManagedInstanceCoreを許可するインスタンスプロファイルがあれば十分です。

• Run Commandは、タグ付けされたフリート全体でシェルやPowerShellを実行し、出力を統合します。
• Session Managerは、AWS APIを通じてインタラクティブシェルを開きます。インバウンドのポート22も踏み台サーバーも不要で、完全なIAM認証に対応し、セッションはS3またはCloudWatch Logsに記録されます。
• Patch Managerは、メンテナンスウィンドウを使用して、スケジュールに基づいてOSパッチを適用します。

aws ssm send-command \
  --targets Key=tag:Env,Values=prod \
  --document-name AWS-RunShellScript \
  --parameters 'commands=["yum -y update"]'

スケジュールに基づく起動/停止の自動化

営業時間外に停止する必要がある非本番環境のEC2やRDSには、EventBridge Scheduler → Lambdaというメンテナンスの手間が少ないパターンがあります。cronルール（cron(0 19 ? * MON-FRI *)）が、タグ付けされたリソースを停止するLambdaを呼び出します。もう一つのルールが07:00にそれらを起動します。

import boto3
ec2 = boto3.client('ec2'); rds = boto3.client('rds')

def handler(event, _):
    action = event['action']  # 'start' or 'stop'
    ids = [i['InstanceId'] for r in ec2.describe_instances(
        Filters=[{'Name':'tag:AutoStop','Values':['true']}]
    )['Reservations'] for i in r['Instances']]
    getattr(ec2, f'{action}_instances')(InstanceIds=ids)
    for db in rds.describe_db_instances()['DBInstances']:
        if any(t['Key']=='AutoStop' and t['Value']=='true' for t in db['TagList']):
            getattr(rds, f'{action}_db_instance')(DBInstanceIdentifier=db['DBInstanceIdentifier'])

これはサーバーレスであり、パッチを適用するフリートがなく、タグによってスケールします。AWS Instance Schedulerソリューションも同様に機能します。注意点として、停止したRDSインスタンスは7日後に自動的に起動するため、停止スケジュールを定期的に実行して再停止させる必要があります。週末にスケジュールされたアクションでキャパシティをゼロにするASGと組み合わせることで、アイドル時間中のコストはほぼゼロに近づきます。

スケールしたコンピュート環境におけるネットワーキングの落とし穴

NATゲートウェイの配置。 NATゲートウェイは1つのAZに配置されます。3つのAZにまたがるフリートが、us-east-1aにある単一のNATゲートウェイ経由ですべてのEgressトラフィックをルーティングすると、us-east-1bやus-east-1cからのすべてのパケットにAZ間データ転送コストが発生し、us-east-1aで障害が発生した際にはEgress通信が完全に失われます。正しいパターンは、AZごとに1つのNATゲートウェイを配置し、各プライベートサブネットのルートテーブルが自身のAZ内のNATを指すようにすることです。これにより、トラフィックがAZ内に留まり、単一AZの障害モードが排除されます。

NATインスタンス。 単一のEC2ベースのNATは、フリートが成長するにつれて帯域幅とPPSのボトルネックとなり、SPOF（単一障害点）にもなります。マネージド型のNAT Gatewayは、ゲートウェイあたり100 Gbpsまでスケールします。AWSサービストラフィックには、VPCエンドポイント（S3/DynamoDBにはゲートウェイ型、その他にはインターフェイス型）を使用することでNATを完全にバイパスし、コストを削減し、スケールイベント中の飽和リスクを排除します。

繰り返し見られる設計の罠

• 単一AZのASGはAZ障害を乗り切れません。常に少なくとも2つ（クォーラムシステムの場合は3つ）のAZのサブネットをアタッチし、MinSize ≥ 2を維持してください。
• すべてのワークロードが水平スケールすると仮定すること。 ステートを持つ、単一ライター、またはクラスター化不可能なライセンスのアプリは、ASGの下では状況が悪化します。まず自動復旧を使用するか、リファクタリングしてください。
• 予測可能なピークに対するリアクティブスケーリングは、「最初の2〜3時間、動作が鈍くなる」という症状を引き起こします。スケジュールスケーリングや予測スケーリングを使って事前にウォームアップしてください。
• CPUが制約でないのにCPUでスケーリングすること。 真のボトルネック（キューの深さ、レスポンスタイム、接続数など）を反映するメトリクスを発行してください。
• シンプルスケーリングと起動設定はレガシーです。 ターゲット追跡と起動テンプレートを推奨します。
• HTTPアプリに対するTCPのみのヘルスチェックは、故障したインスタンスをローテーションに残してしまいます。HTTPヘルスチェック（ALB経由、またはHTTPモードのNLBヘルスチェック）を使用してください。
• ステートフルまたは中断不可なワークロードにスポットインスタンスを使用すること。 スポットインスタンスは、チェックポイント可能で、置き換え可能なワーカーを要求します。
• 真に変動するワークロードに対するリザーブドインスタンスやSavings Plans。 未使用のコミットメントは純粋な無駄です。代わりにライトサイジングとスポットインスタンスでコストを削減してください。
• Route 53を個々のEC2のIPアドレスに向けること。 フリートの変動をDNSに反映させるため、ALBのエイリアスにルーティングしてください。
• インスタンスストアを永続的であるかのように扱うこと。 データは停止、終了、またはホスト障害で消失します。
• スナップショットの復元やAMIからの起動後のレイジーロードによるレイテンシーを無視すること。 ターゲットAZで高速スナップショット復元を有効にしてください。

すべてのドメイン · コンテナとオーケストレーション →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Amazonを閲覧 →