Amazon SOA-C02: デプロイ、プロビジョニング、および自動化 — 学習ガイド

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

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

このドメインは、AWSのインフラストラクチャとアプリケーションのデプロイを、信頼性と再現性をもってプロビジョニング、更新、運用するための手法とツールを対象とします。宣言的でべき等なプロビジョニング、リリースのための自動化されたパイプライン、そして監査可能性とセキュリティを維持しつつ手作業を削減する運用自動化に重点を置いています。運用者は、安全性（ロールバック、変更ポリシー）とベロシティ（イミュータブルイメージ、自動パッチ適用）のバランスを取り、コンプライアンスと回復可能性をサポートするパターンを選択する必要があります。

CloudFormationとInfrastructure as Codeパターン

CloudFormation（またはCDK/Terraform）を使用してインフラストラクチャをコードとして宣言し、スタックがべき等になるようにします。つまり、テンプレートが望ましい状態を記述し、エンジンがリソースをその状態に収束させます。命令的なスクリプトよりも、宣言的なリソースとパラメータを優先します。一般的なCLIパターンは以下の通りです。

変更セットの作成と検査:

undefined

レビューと実行:

undefined

便利なデプロイコマンド:

undefined

設計上の決定事項:

再利用と制限のために、ネストされたスタックやモジュールを使用します。可変のシークレットや大きなバイナリはテンプレートから分離し、SSM Parameter StoreやSecrets Managerに移動します。
安全性のために、スタックポリシー、終了保護、ロールバックトリガーを使用します。

undefined

と

undefined

でドリフト検出を有効にします。

CloudFormationサービスロールには、リソースを作成するためのスコープを限定したIAMポリシーを付与します。CloudFormationに広範な管理者権限を与えることは避けてください。

IaCアプローチの比較:

CloudFormation/CDK: AWSネイティブで、変更セットやドリフト検出と統合されています。IAMリソースには

undefined

が必要です。

Terraform: プロバイダーに依存せず、状態ファイルの管理が必要です。混合クラウド環境に適しています。
命令的スクリプト (CLI/SDK): 一度きりの操作には適していますが、べき等ではなく、監査が困難です。

CI/CDとデプロイ自動化プラクティス

再現可能なパイプラインステージ（ソース -> ビルド -> テスト -> デプロイ）を実装します。AWS CodePipelineを使用して、CodeBuild、CodeDeploy、またはサードパーティツール（Jenkins、GitHub Actions）を統合します。主要な設定は以下の通りです。

CodeBuild: フェーズとアーティファクトを定義するためにbuildspec.ymlを定義します。プロジェクトロールには最小権限（入力用のs3:GetObject、アーティファクト用のs3:PutObject）を付与します。
CodeDeploy: デプロイグループとAppSpec.ymlを使用します。デプロイタイプ（インプレースまたはブルー/グリーン）を選択します。EC2/ASGの場合、リスクを低減するためにブルー/グリーンを推奨します。
ECR + ECS/EKS: CIからイメージをプッシュし、イミュータブルに（セマンティックまたはビルドIDで）タグ付けし、タスク定義でそのイメージタグまたはダイジェストを参照します。

デプロイ戦略の決定基準:

ほぼゼロのダウンタイムと安全なロールバックが必要な場合は、トラフィックシフトを伴うブルー/グリーンまたはカナリアデプロイを使用します。CodeDeployまたはApplication Load Balancer (ALB)の加重ルーティングがこれをサポートします。
更新中にキャパシティが減少してもよい、小規模でステートレスなフリートには、ローリングまたはインプレース更新を使用します。
パイプラインの各ロール（パイプライン実行ロール、CodeBuildサービスロール、デプロイロール（インスタンスプロファイル））のスコープが、それぞれ最小限の権限に限定されていることを確認します。

シークレットとパラメータを安全に管理します。パラメータはSSM Parameter Store (SecureString) またはAWS Secrets Managerに保存し、必要に応じてパイプラインロールにkms:Decryptおよびssm:GetParameterまたはsecretsmanager:GetSecretValueの権限を付与します。

AMIのベーキング、イミュータブルイメージ、AMI管理

イミュータブルインフラストラクチャとは、OSとアプリケーションのパッチをすべて組み込んだ新しいAMIを作成し、既存のインスタンスを変更するのではなく置き換えることを意味します。CIでEC2 Image BuilderやPackerを使用してAMIを自動的に生成します。

EC2 Image Builderのパイプラインは、スケジュールに基づいて実行し、パッケージをインストールし、テストを実行し、バージョン管理された命名規則とタグを持つAMIを生成できます。
PackerはCI（CodeBuild/Jenkins）に統合してビルドスクリプトを実行し、AMI IDを出力します。最新のAMIは参照用にSSM Parameter Store（例: /ami/app-prod）に保存します。

AMIのライフサイクル管理:

イメージにビルドメタデータと有効期限をタグ付けします。保持期間が過ぎた後、登録解除とスナップショット削除を自動化します。
新しいAMIを展開するために、バージョンを更新したLaunch Templates/ASGを使用します。イミュータブルなデプロイでは、新しいLaunch Templateバージョンを参照する新しいASGを作成し、ターゲットグループを切り替えます。

ミュータブルとイミュータブルの比較:

イミュータブル (新しいAMI/新しいASG): 以前のASGやAMIに切り替えることで、より安全で簡単なロールバックが可能です。一貫したライフサイクルを実現できます。
ミュータブル (インプレースでのパッチ適用): 小さな修正を適用するのは速いですが、ドリフトが発生しやすく再現が困難です。制約上やむを得ない場合にのみ使用します。

AWS Systems Managerのオートメーション、Run Command、パッチ適用

Systems Manager (SSM) は運用タスクを一元管理します。Run Commandはアドホックなコマンド実行、State Managerは望ましい状態の維持、Patch ManagerはスケジュールされたOSパッチ適用、そしてAutomationは複雑なワークフローの自動化を担います。一般的なCLIパターン：

アドホックなコマンド送信： aws ssm send-command –instance-ids i-0123456789abcdef0 –document-name “AWS-RunShellScript” –parameters commands=’[“yum update -y”]'
定義済みのAutomationを開始： aws ssm start-automation-execution –document-name “AWS-ApplyPatchBaseline” –parameters “InstanceIds=[‘i-…’]”
State Managerのアソシエーションを使用して設定（例：SSM Agentの設定、cronジョブ）を強制し、Patch Managerのベースラインを使用して承認ルールやコンプライアンススキャンを実施します。

設定の詳細と判断のポイント：

予測可能でコンプライアンスに準拠したパッチ適用には、Patch Managerをベースラインとメンテナンスウィンドウと共に使用します。イミュータブル戦略を採用する場合は、自動承認日数を選択し、承認されていないAMIイメージを拒否します。
SSMエージェントがない、またはネットワークが制限されているインスタンスには、SSHポートを開放するのを避けるため、VPCエンドポイントを使用したSession Managerを検討します。
SSMアクセスには、常にAmazonSSMManagedInstanceCoreポリシーを持つインスタンスプロファイルを要求します。必要に応じて追加の権限のスコープを限定します。

変更管理、ドリフト検出、ロールバック

パイプラインの実行、タグ、承認を統合した変更管理を実装します。CloudFormationの変更セットを使用して差分をプレビューし、スタックポリシーを使用して破壊的な更新を拒否します。CLIパターン：

ドリフトの検出： aws cloudformation detect-stack-drift –stack-name my-stack および aws cloudformation describe-stack-resource-drifts –stack-name my-stack
更新中に重要なリソースを保護するためにスタックポリシーを使用し、更新が失敗した際に通知するためのロールバックトリガーを持つRollbackConfigurationを設定します。

ロールバック戦略：

CloudFormationの場合：失敗時の自動ロールバックがデフォルトです。必要に応じてロールバックトリガーを使用し、リソースを保持します。
アプリケーションの場合：ALB/Route53の重み付けを再設定するか、以前のタスクセットを復元することで即時ロールバックを可能にするため、トラフィックシフトを伴うブルー/グリーンまたはカナリアデプロイメントを推奨します。
ロールバックが決定論的になるように、イミュータブルなアーティファクト（AMI ID、コンテナイメージ）を維持し、以前のバージョンをレジストリやSSMに保存します。

判断基準：

ステートフルなデータ移行が伴う場合は、可逆的な移行スクリプトを含めるか、機能フラグを使用してコードのリリースとスキーマの移行を分離します。
デプロイメントのヘルスチェックと自動化されたスモークテストをパイプラインの関門として使用し、早期にロールバックをトリガーします。

よくある落とし穴と判断基準

IaCの状態から乖離する、管理外の手動コンソール変更を行う：ドリフト検出（aws cloudformation detect-stack-drift）を強制し、修正はIaCテンプレート経由で適用することを要求します。IAMコントロールを使用してコンソール編集を制限します。
リリースに対する安全なロールバック計画がない：ブルー/グリーンまたはカナリアデプロイメントを採用し、以前のアーティファクト/AMIを即座に復元できるよう保持します。
パイプラインとロールに対する過度に寛容なIAM：最小権限の原則を適用します。ロール（パイプラインサービスロール、ビルドロール、インスタンスプロファイル）を分割し、必要なssm:GetParameter、secretsmanager:GetSecretValue、kms:Decrypt、s3アクセスのみを許可します。
シークレットをテンプレート内やプレーンテキストで直接保存する：シークレットをSecrets ManagerまたはSSM Parameter StoreのSecureStringに移動し、デプロイ時に適切な復号権限で参照します。
テストなしで本番環境をインプレースでパッチ適用する：CIで更新されたパッケージとスモークテストを含むAMIをベイクし、その後ASGまたはブルー/グリーンパイプライン経由でイミュータブルなイメージをロールアウトします。
ドリフトとステートフルなリソースの保護を無視する：スタックポリシーを使用し、定期的にドリフトを検出します。ステートフルなリソースについては、破壊的な変更の前に手動承認とスナップショットを要求します。

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

Acme Payments社は、PCI準拠のAPIサービスをデプロイし、毎月のOSパッチを適用し、営業時間中にデプロイがエラーを引き起こした場合に迅速にロールバックできる必要があります。

イミュータブルパイプラインを実装する：CodePipeline/CodeBuildを使用してEC2 Image Builder（またはPacker）でAMIをベイクし、AMIにタグを付け、AMI IDをSSM Parameter Storeに発行します。
AMIのSSMパラメータを参照するCloudFormationテンプレートを介してデプロイし、リリースごとに新しいASG + Launch Templateバージョンを作成します。事前レビューには変更セットを使用します。
ヘルスチェックと自動スモークテストを備えたCodeDeployまたはALBターゲットグループのブルー/グリーン方式でトラフィックをシフトします。ヘルスチェック失敗時の自動ロールバックを設定します。
Systems Managerのメンテナンスウィンドウを介してPatch Managerをスケジュールし、ピーク時以外にパッチを適用します。本番環境のインプレースパッチ適用を避けるため、パッチ適用済みイメージをベイクしてデプロイします。
パイプラインロールに最小権限のIAMを適用し、シークレットをSecrets Managerに保存し、重要なリソースに対してCloudFormationのドリフト検出とスタックポリシーを有効にします。

論理的根拠：イメージをベイクしてイミュータブルにデプロイすることで、ビルドと実行の関心事が分離され、再現可能なアーティファクトと安全なロールバックパスが提供されます。SSMによる自動パッチ適用とイミュータブルなデプロイを組み合わせることで、リスクを最小限に抑え、回復性を維持しながらコンプライアンスをサポートします。

← 高可用性、耐障害性、および災害対策 · すべてのドメイン · セキュリティ、アイデンティティ、およびコンプライアンス →

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