Amazon SAP-C02: デプロイ、自動化、DevOps — 学習ガイド

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

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

Infrastructure as Codeと環境管理

コードとしてのインフラストラクチャ (IaC) を環境の信頼できる唯一の情報源 (Single Source of Truth) として扱い、ネットワーク、IAM、アプリケーションのトポロジーを再利用可能でバージョン管理されたアーティファクトに埋め込みます。厳密な宣言的管理とAWSとの緊密な統合が必要な場合はCloudFormationを選択し、より高レベルの構成要素や言語ネイティブな抽象化によって開発者の生産性が向上する場合はAWS Cloud Development Kit (CDK) を使用します。CIでは常にCDKをテンプレートに合成 (synthesize) させ、アーティファクトを暗号化され、バージョニングが有効なS3バケットに保存してください。アカウント間、リージョン間にわたる一貫したスタックのインスタンス化にはCloudFormation StackSetsを使用し、ドリフトが設定のエントロピーを示した場合には、ドリフト検出を有効にし、Systems Managerによる自動修復と組み合わせます。EC2 Image BuilderやPackerでゴールデンイメージをベイクし、自動化されたパイプライン経由でAMIをアカウントやリージョンに発行します。これにより、イミュータブルデプロイメントがサポートされ、起動後の設定ドリフトが削減されます。データ損失を引き起こす可能性のある意図しないリソースの置換を避けるため、CloudFormationの変更セット、終了保護、更新ポリシーは慎重に扱ってください。よくある落とし穴として、テンプレートへのシークレットの埋め込み、ドリフト検出を妨げる安易な手動変更への依存、過度に広範なCloudFormation実行ロールの付与などが挙げられます。実行ロールは最小権限に制限し、監査可能性のためにCloudTrailとConfigの履歴を保持してください。トレードオフは明確です。CDKは開発を加速させますが、ランタイムスタックの非同期を避けるために規律あるCI/CDが必要です。一方、純粋なCloudFormationはより厳格ですが、即座に監査可能です。

CI/CDパイプラインとデプロイ戦略

ビルド、テスト、デプロイのステージを分離し、ロールバックの決定を自動化するパイプラインを設計します。AWS CodePipeline、CodeBuild、CodeDeployは、ソースから本番環境へのフローのためのフルマネージドなパスを提供します。一方、サードパーティシステム (GitHub Actions、Jenkins、GitLab) は、アーティファクトストレージ (S3)、コンテナレジストリ (ECR)、デプロイメントフックなどのAWSサービスと統合できます。ランタイム戦略として、ステートフルまたはセッションを持つサービスには、インプレースでの設定ドリフトを排除するためにイミュータブルデプロイメントまたはブルー/グリーンデプロイメントを優先します。段階的なリスク低減のためには、トラフィックシフトを伴うカナリアデプロイメントを使用します。Lambdaでは、エイリアスと加重トラフィックシフトをCloudWatchアラームまたはCodeDeployと組み合わせて使用し、自動ロールバックを実現します。ECS/EKSでは、デプロイメントコントローラー (CodeDeploy、AWS App Mesh、またはネイティブのKubernetes戦略) をALBターゲットグループのドレイニングやライフサイクルフックと組み合わせ、グレースフルシャットダウンを保証します。データベースのスキーマ変更には注意が必要です。後方互換性のあるマイグレーションを設計し、機能フラグ (AWS AppConfig) やダークローンチを使用して、コードのロールアウトをスキーマの進化から切り離します。コストとスピードの考慮事項は重要です。カナリアはロールアウトを遅くしますが、影響範囲 (ブラスト半径) を最小限に抑える一方、並行するブルー/グリーンは切り替え期間中のインフラコストを2倍にします。インシデント発生時の手動介入を避けるため、デプロイポリシー、ヘルスチェック、自動ロールバックを常にパイプラインに組み込んでください。

自動化、設定コンプライアンス、可観測性

オペレーショナルエクセレンスは、自動修復、一貫した設定、そして包括的な可観測性に依存します。AWS Systems Managerは、設定のためのParameter Store、ランブックのためのAutomationドキュメント、ベースライン維持のためのPatch Manager、そして踏み台サーバー不要のトラブルシューティングのためのSession Managerを提供します。疎結合な自動化のための中央イベントバスとしてEventBridgeを使用し、CloudTrail、Config、またはアプリケーションのイベントをLambdaやStep Functionsにルーティングして、オーケストレーションされた修復を行います。AWS Configルールと、複数アカウントを監査するためのConfig Aggregatorでガードレールを適用し、非準拠リソースに対してはSystems ManagerやEventBridge経由で自動修復プレイブックを実装します。可観測性のためには、CloudWatchメトリクスとLogsでサービスを計装し、分散トレーシングのためにX-RayまたはAWS Distro for OpenTelemetryを有効にし、CloudWatch LogsサブスクリプションまたはKinesis Firehoseでログを中央のS3データレイクと分析スタックに集約します。よくある落とし穴には、コストを膨張させる無制限のログ保持期間、メトリクス費用を急増させる高カーディナリティのカスタムメトリクス、トレースを役に立たなくする相関IDの欠落、非本番環境で修復ランブックをテストしないことなどがあります。トレードオフは、テレメトリの粒度と、取り込みおよびストレージコストの間で発生します。トレースのサンプリングと短い保持期間はコストを削減しますが、まれで重大な障害を不明瞭にする可能性があります。アクションにつながるシグナルに的を絞ったアラートとダッシュボードを設計し、運用オーバーヘッドを管理可能な範囲に保ちます。

パフォーマンス、ステートフルサービス、セキュリティ、およびクロスリージョンに関する考慮事項

アクセスパターン、レイテンシー要件、一貫性の要件に基づいて、ステートフルサービスとストレージサービスを選択します。インメモリキャッシュはサブミリ秒の読み取りを提供します。ElastiCache (Redis) は、リーダーボードに最適なソート済みセットをサポートし、レプリケーション、永続性、およびクロスリージョンでの読み取り局所性のためのGlobal Datastoreを提供します。DynamoDBは、高スケールで耐久性のあるストレージとして優れており、読み取りを高速化するためにDAXと組み合わせることができますが、DAXはキャッシュ可能な項目レベルのアクセスに最適であり、結果整合性のトレードオフがあります。ファイルベースのレガシーアプリには、リフトアンドシフトの互換性のためにAmazon FSx for NetApp ONTAPまたはAmazon EFSとDataSyncの組み合わせを検討してください。SMB/NFSセマンティクスには、FSxが最もリスクの低い選択肢となることが多いです。暗号化とレプリケーションには微妙な落とし穴があります。AWS KMSキーはリージョナルであり、クロスリージョンのS3レプリケーションのためにはリージョンごとに管理するか、マルチリージョンキーを使用してアクセスパターンを簡素化する必要があります。キーポリシーとクロスアカウントの権限付与には注意が必要です。VPC内のLambdaは、ENI作成によるコールドスタートの問題を抱えています。これは、VPCエンドポイント、より小さなパッケージサイズ、プロビジョンドコンカレンシー、またはVPC外のLambdaをRDS Proxyと共に使用することで緩和できます。コストと回復力を比較検討してください。グローバルテーブルとクロスリージョンレプリケーションは、コスト増と引き換えにRTO/RPOを改善します。プロビジョンドコンカレンシーはレイテンシーを削減しますが、ベースラインの支出を増加させます。アーキテクチャを選択する際には、データの耐久性要件、DRのタイムライン、およびアカウントごとのリソース制限を考慮してください。

実践的な問題：ユースケースシナリオ

シナリオ：SkyForge Gamesは、2つのリージョンにまたがる本番アカウントとステージングアカウントで既存のAWS環境を運用しています。現在のリーダーボードはDynamoDBで実装され、CodePipelineを通じてデプロイされたLambda APIによって提供されています。プレイヤーは、頻繁な機能リリース中もマイクロ秒の読み取りレイテンシーとほぼゼロのダウンタイムを期待しています。

課題：耐久性を維持しつつ、マイクロ秒のリーダーボード読み取りを実現し、アカウントやリージョンをまたいで、迅速でロールバック可能なデプロイをサポートする、安全で自動化されたCI/CDパイプラインを構築すること。

推奨アプローチ：

リーダーボードのホットパス用に、プライマリリージョンにElastiCache for Redis（クラスターモード有効）をプロビジョニングし、AZをまたいだレプリカとRedisの永続化（AOF）を有効にします。セカンダリリージョンでの読み取り局所性のためにGlobal Datastoreを設定します。
DynamoDBを信頼できる唯一の情報源（source of truth）として維持します。DynamoDB Streams + Lambda（またはKinesis Data Streams）を使用してRedisを非同期に更新し、結果整合性を確保し、リカバリのためのリプレイ可能性を保証します。
CDKベースのパイプライン（CDK PipelinesまたはGitによってトリガーされるCodePipeline）を実装します。このパイプラインは、テンプレートを合成し、アーティファクトを暗号化されたS3/ECRにビルドし、CloudFormation StackSetsを介してターゲットのアカウント/リージョンにインフラをデプロイします。自動化されたスモークテストと承認ゲートを含めます。
カナリア/ブルーグリーン戦略を使用してアプリケーションの変更をデプロイします。重み付けされたLambdaエイリアスまたはALBのターゲットグループの切り替えを、CloudWatchアラームと自動ロールバックと共に使用します。CloudWatch、X-Ray、および合成カナリアチェックで計装します。

論理的根拠：DynamoDBの耐久性とリプレイ可能性を維持しつつ、真のサブミリ秒読み取りのためにRedisを使用します。CDKとStackSetsによるCI/CDは、一貫性があり監査可能なマルチアカウントデプロイを提供します。また、トラフィックシフトと可観測性により、迅速なロールバックが可能な安全な反復リリースが実現します。

← コスト最適化とガバナンス · すべてのドメイン

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