Amazon SAP-C02: コンピューティングとAuto Scaling — 学習ガイド

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

EC2インスタンスの設計、ストレージ、ネットワーキング

EC2インスタンスの設計は、ワークロードの特性をインスタンスファミリーに適合させ、vCPU、メモリ、ネットワーク、ローカルストレージのバランスを取ることから始まります。プロファイリングに基づいて、コンピューティング最適化 (C)、メモリ最適化 (R/X)、ストレージ最適化 (I/D)、またはGPU (P/G) タイプを選択します。高いネットワークスループットと低レイテンシーを実現するために、NitroベースのインスタンスとENA/SR-IOVを活用します。レイテンシーに敏感な、または高いIOPSを必要とする一時データには、I3/I4またはNitro SSD上のインスタンスストア（エフェメラル）を検討します。永続的なブロックストレージには、Provisioned IOPS (io2/io2 Block Express) を備えたEBSを使用し、キー管理のためにKMSでEBS暗号化を有効にします。インスタンスがApplication Load Balancerの背後にあるVPC内に存在する場合、インターネット向けALBがパブリックサブネットに配置され、ターゲットがプライベートサブネットに存在することを確認します。ALBの配置ミスやセキュリティグループの設定ミスは、よくある落とし穴です。プレイスメントグループ（低レイテンシーHPC向けのクラスター、大規模分散ステートフルシステム向けのパーティション、障害分離向けのスプレッド）を使用して配置に影響を与えますが、トレードオフを受け入れる必要があります。クラスターは最高のパフォーマンスを提供しますが、AZレベルの耐障害性は低下します。転送中のデータを暗号化するには、ALBで終端するTLS、またはNLBパススルーによるエンドツーエンドTLSを使用します。決定基準はコストとパフォーマンスを比較検討します。高密度なインスタンスタイプはコストを削減しますが、影響範囲（ブラスト半径）やライセンスコストを増加させる可能性があります。経験則に頼るのではなく、CloudWatch、AWS Compute Optimizer、および負荷テストに基づいた適切なサイジングを優先します。

Auto Scalingグループ、ポリシー、ライフサイクル管理

Auto Scaling Groups (ASG) は、起動テンプレート、混合インスタンスポリシー、ライフサイクルフック、スケーリングポリシーを組み合わせて使用し、伸縮性、回復力、コスト効率を考慮して設計する必要があります。起動テンプレートを使用して、AMI、インスタンスタイプのオーバーライド、EBS設定、およびユーザーデータをバージョニングします。キャパシティー最適化のスポット割り当てまたは多様化戦略を用いた混合インスタンスは、中断リスクを低減し、コストを削減します。スケーリング動作については、予測可能なメトリクス（CPU、ターゲットごとのリクエスト数）にはターゲット追跡ポリシーを、しきい値に基づいた多段階のアクションが必要な場合はステップスケーリングを優先します。予測スケーリングは、既知の日内パターンに対して事前にキャパシティをプロビジョニングできます。ライフサイクルフックを実装して、終了前にカスタムの初期化タスクやドレイニングタスクを実行します。ウォームプールを組み合わせてサービス提供までの時間を短縮し、営業時間中のベースラインにはスケジュールされたスケーリングを使用します。ヘルスチェックは、ELBとEC2のヘルスチェックを統合して、時期尚早なインスタンスの置き換えを避けるべきです。積極的すぎるクールダウンによるスケールインのチャーン、混合ASGでの不適切なインスタンスの重み付け、アプリケーションのウォームアップを考慮しないといった落とし穴に注意してください。ステートフルなサービスでは、インメモリキャッシュを失うような急激なスケールインは避けてください。コスト対回復力の観点では、オンデマンドへのフォールバックを備えたスポットベースのキャパシティは節約になりますが、中断処理が必要です。一方、100%オンデマンドは、より高いコストで予測可能性を最大化します。

コンテナとオーケストレーション: ECS、EKS、Fargateの選択

Amazon ECS、EKS、Fargateの中から選択する際は、運用モデル、制御の必要性、ワークロードのパターンに依存します。Fargateはノード管理を不要にし、運用のシンプルさを優先するチームに最適ですが、vCPUあたりの価格が高く、エフェメラルストレージの制限があります。コスト削減のためにFargate Spotをサポートしています。ECSは、Kubernetesの複雑さなしにコンテナオーケストレーションを望む顧客に対して、緊密なAWS統合とシンプルさを提供します。EKSは、Kubernetesエコシステム、ポータビリティ、または高度なスケジューリングが必要な場合に適しています。動的な適切なサイジングのために、マネージド型ノードグループまたはセルフマネージド + Karpenterを検討してください。ネットワーク制限（ENI/ポッド密度）とCNIの動作は、ポッド密度とノードのサイジングに影響します。EKSでは、IAM Roles for Service Accountsと永続ボリューム用のEBS CSIが、認証情報の拡散を減らし、ポッドごとのストレージを可能にします。共有ファイルシステムには、スループットとレイテンシーのニーズに応じて、EFS (NFS) またはFSx (Lustre) を使用します。メタデータ操作が多い場合はNFSバックのコンテナを避け、ワークロードに合わせてスループットモードを調整したEFSを優先します。ノードスケーリングにはcluster autoscalerまたはKarpenterを、サービスオートスケーリングにはALB/ECSサービスメトリクスを実装します。よくある落とし穴には、Pod Disruption Budgetsの無視、Kubernetesコントロールプレーンのクォータの過小評価、ビンパッキング戦略を使用せずにノードを過剰にプロビジョニングすることなどがあります。制御、コスト、運用オーバーヘッドの間のトレードオフが、選択を決定づけるべきです。

サーバーレスコンピューティングパターン、Lambdaの制約、イベント駆動設計

サーバーレスは運用オーバーヘッドを削減しますが、同時実行性、状態、およびダウンストリームシステムの制限に対処するアーキテクチャパターンが必要です。Lambdaは、短時間のイベント駆動型タスク、API GatewayやALBを介したAPIバックエンド、SQSやSNSによる非同期処理に優れています。長時間実行されるワークフローのオーケストレーションにはStep Functionsを、データベースアクセスにはDynamoDBまたはRDS Proxyを使用して、コネクションストームを緩和します。ENI作成によって引き起こされるLambdaのVPCコールドスタートのオーバーヘッドに注意してください。レイテンシーに敏感なエンドポイントにはプロビジョンドコンカレンシーで緩和するか、VPCエンドポイントとRDS Proxyを使用して接続を制限します。SNS + SQSによるファンアウト/ファンイン、または順序付きストリーム処理にはKinesis/MKSを実装します。再試行と重複を管理するために、SQSのデッドレターキューとべき等なハンドラーを使用します。カスケード障害を避けるために、同時実行数の上限、予約済み同時実行数、スロットリングを計画する必要があります。スロットル、ジッター付きリトライ、サーキットブレーカー（API Gatewayまたはカスタム）を使用して、バックプレッシャーを考慮した設計を行います。コストパフォーマンスのトレードオフは明確です。Lambdaは突発的で短時間のワークロードに対してコスト効率が高く、一方、FargateやEC2は持続的な高CPUタスクや長時間実行タスクに適しています。よくある落とし穴には、ダウンストリームシステムに過負荷をかける同期リトライに依存すること、永続性を期待してローカルの/tmpに状態を保存すること、レイテンシーが重要なフローでコールドスタートに備えてプロビジョニングしないことなどがあります。

実践的な問題: NovaTel Enterpriseのコンタクトセンター移行

シナリオ: NovaTel Enterpriseは、オンプレミスのコールルーティングとAWSへのDirect Connectを備えたハイブリッドコンタクトセンターを運用しています。2つのアベイラビリティーゾーンでEC2上のセッションブローカーを実行しており、オンプレミスのPBXとクラウドサービス間の高可用性と予測可能なレイテンシーを備えたAWSマネージドのコンタクトセンターに移行したいと考えています。

課題: SIPトラフィックのための低レイテンシー接続、スポット中断に耐えられる音声処理用のスケーラブルなコンピュートレイヤー、および運用上の複雑さを増すことなくリージョンをまたいだDR戦略が必要です。

推奨アプローチ:

コンタクトセンター機能のためにAmazon Connectをプロビジョニングし、低レイテンシーのSIPトランキングのためにSite-to-Site VPNまたはDirect ConnectとAWS Transit Gatewayを使用します。これはセッションブローカーの前にあるTLSパススルーを備えたNLBで終端させます。
セッション処理コンポーネントを、キャパシティー最適化されたスポットとオンデマンドのフォールバックを使用する起動テンプレートを持つ混合Auto Scaling Groupとして実行し、重要なブローカーの障害分離のためにプレイスメントグループ（スプレッド）を使用します。
エフェメラルな低レイテンシーストレージを必要とするステートフルな通話メディアには、メディアバッファリングのためにインスタンスストアを備えたインスタンス（Nitro）を使用し、セッションメタデータをmulti-AZレプリケーションでDynamoDBまたはElastiCacheに複製します。永続データにはRDS（Multi-AZ）またはAurora Global DBを使用し、DRのためにクロスリージョンのリードレプリカを配置します。
ブローカーのコールドスタートを最小限に抑えるためにライフサイクルフックとウォームプールを実装し、クロスリージョンDRのためにRoute 53の加重フェイルオーバーを使用し、アラートと自動フェイルオーバーのランブックのためにCloudWatch + SNS/SQSを使用します。

理由: マネージドコンタクトセンターサービスを使用することで運用負荷が軽減され、スポットを含む混合ASGがコストを最適化します。エフェメラルなメディアをインスタンスストアに分離することでパフォーマンスが維持され、DynamoDB/ElastiCacheへの永続的な状態の複製とmulti-AZのRDS/Auroraが、プロフェッショナルなアーキテクチャのベストプラクティスに沿った回復力と迅速なフェイルオーバーを提供します。

← セキュリティ、アイデンティティ、コンプライアンス · すべてのドメイン · ストレージとデータ管理 →

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