DOP-1.1 CI/CD パイプラインを実装する。

ヒントボタン

Git へのコミットごとに 8 分かかる単体テストを 5 本並列で回し、どれかが落ちた時点で残りも止めたいときは、AWS CodePipeline の Build ステージに置いた AWS CodeBuild で parallelization-factor 5 と buildspec の fail-on-severe-error を有効にします。これにより最大 5 台のビルドコンテナが同時起動し、いずれかが失敗するとフェーズ全体が FAILED になって次の Deploy ステージへ進まないため、追加の制御ロジックを書かなくてもテスト即停止という要件を満たせます。

サービス停止なしで EC2 Auto Scaling グループへリリースしたい場合、Application Load Balancer と連携できる AWS CodeDeploy の Blue/Green デプロイが最も効果的です。置換ターゲットグループをヘルスチェックで監視しながらトラフィックを段階的に切り替えるため、旧インスタンスを DeregisterTargets している間もリクエストを失わずゼロダウンタイムを実現します。さらに /opt/migrate.sh などのフックが失敗した際は CodeDeploy の自動ロールバックが直前の正常版へ戻すため、復旧を手動で行う必要がありません。

chown appuser:appgrp や chmod 750 は AppSpec.yml の AfterInstall、マイグレーションは BeforeAllowTraffic に runas: appuser で記述すると、配布→権限設定→ユーザ権限での処理→本番解放という順序が保証されます。また EC2 インスタンスロールには elasticloadbalancing:RegisterTargets と DeregisterTargets 程度だけを付与すれば IAM 最小権限の原則を守れます。並列テスト、Blue/Green によるゼロダウンタイム、順序付きフック、最小権限、自動ロールバックという複数の要件を俯瞰し、すべてを一つの仕組みで網羅できる構成かどうかを総合判断する視点が大切です。

ヒントボタン

ソースが更新されたら dev と test の 30 個×200 タスクを Blue/Green で一気に切り替える必要があります。その速度を担保するには CodePipeline の同一 Deploy ステージに ECS Fargate 向け CodeDeploy アクションを 2 本置き、両方に runOrder=1 を指定して並列実行させるのが最短経路です。アクションのどちらかが失敗すると同ステージ全体が即座に失敗しパイプラインも停止するため、要件 2 の「失敗時の即時停止」を追加のロジックなしで満たせます。結果を CloudWatch Events で拾えば監視も容易です。

dev と test がそろって成功した場合だけセキュリティ部門のチェックを入れるには、同じ Deploy ステージ内に ManualApproval アクションを runOrder=2 で続けて配置するのが効果的です。2 つの CodeDeploy が完了しない限り承認待ちには遷移しないため判定が明確で、承認ボタンが押されると直後に runOrder=3 の CodeDeploy が prod 環境へ Can​ary や Linear のトラフィックシフトを利用した段階的リリースを実施できます。Approval の結果は EventBridge で記録しておくと監査対応も万全です。

ステージやパイプラインの数が増えるほど設定とトラブルシュートの手間が跳ね上がりますが、CodePipeline では複数アクションを 1 つのステージにまとめ runOrder で順序を制御すれば構成を大幅に圧縮できます。Blue/Green 2 環境→ManualApproval→本番デプロイを単一 Deploy ステージに納めれば「ステージ数最小化」を守りつつ失敗時のロールバック確認もワンビューで完了し、CodeBuild や SNS、別パイプラインを増やす必要もないため、可観測性・ガバナンス・運用工数のバランスを総合的に最適化できます。

ヒントボタン

マルチアカウントでリージョン障害を一括監視したい場合、AWS Organizations で委任管理アカウントを設定し、AWS Health API の DescribeEventsForOrganization を1回呼び出すだけで全アカウントの REGIONAL スコープの issue を数秒で取得できます。Lambda 関数にこの API 呼び出しを実装すれば、コード量もレスポンス時間も最小で済み、1,000 回以上の高頻度チェックでも待ち時間をほぼ生まないため、15 分以内デプロイという高速要件を圧迫しません。

CodePipeline でデプロイ途中に安全弁を挟むとき、Manual approval は人のクリックが前提なので SLA は人速でしかなく、「2 分以内に自動停止」と「手動操作排除」という条件に整合しませんが、Custom approval なら Lambda の put-job-success / put-job-failure によって自動判定でき、AssumeRole を使えばパイプライン実行アカウントからでも委任管理アカウントの Lambda を直接利用でき、運用者ゼロでアカウント横断の統一ゲートを実現できます。

EventBridge から CodeDeploy stop-deployment を呼ぶ方法や CodeBuild 内で curl する方法は、一度デプロイが始まってから中断するか、ビルド環境起動で数十秒以上かかるため、障害検出までの遅延と実行コストが大きくなります。パイプライン開始直後に Custom approval でヘルスを確認して通さない設計なら無駄なリソース消費を防ぎ、マルチアカウント構成でも IAM ロールを用いた安全な権限委譲でシンプルな保守が可能です。

以上を俯瞰すると、Organizations と AWS Health API を組み合わせた Lambda による CodePipeline の Custom approval ゲートが、速度・自動化・多アカウント対応の全要件を最もバランスよく満たす選択と判断できます。

ヒントボタン

GitHub の main へのマージを即座に検知して dev ステージから自動でビルドを走らせたい場合、Amazon CodePipeline の Source を GitHub ウェブフックで駆動し、パイプライン定義を CloudFormation にコード化しておき、同じテンプレートを CloudFormation StackSets で各アカウントへ展開すれば、Jenkins のような常時稼働サーバーやポーリング処理を置かずに済み、待機時間と保守工数を同時に削減できます。
EC2 Auto Scaling、Amazon ECS Fargate、AWS Lambda にそれぞれ Blue/Green、10% Canary、alias 切り替えという異なる戦略を単一ワークフローで扱うには、CodeDeploy が提供する DeploymentGroup と DeploymentConfig を併用するのが最も自然で、同じ CodePipeline 内で順次呼び出せば 15 分以内の自動ロールバックやメトリクス連動停止も一貫して管理でき、ダッシュボードや CloudWatch Logs で失敗原因の追跡も統合されるため運用者の負荷が大幅に減ります。
dev→stg→prod のクロスアカウント展開でセキュリティ部門による承認を挟みつつシークレットを安全に扱いたいなら、CodePipeline が AssumeRole で各環境の IAM ロールを引き受けてデプロイし、その途中に ManualApproval アクションを配置し、ビルド時のパラメータは KMS で暗号化した Secrets Manager を CodeBuild 環境変数で参照する構成がベストプラクティスと合致し、要件のスピード・安全性・管理容易性を横串で満たす案が運用負荷の観点で最適だと総合判断できます。

ヒントボタン

CodePipeline の Manual approval アクションは同一ステージに複数を直列配置でき、それぞれに異なる IAM ロールを割り当てることで「個別に承認」を強制できます。承認操作は PutApprovalResult として CloudTrail に自動記録され、SNS を併用すれば承認依頼や結果を Slack へ即通知できます。すべてマネージド機能のため追加スクリプトが不要で運用は軽量です。

内部統制が求める改ざん不能な 7 年保管は、CloudTrail ログをバージョニング有効かつオブジェクトロック設定済みの S3 バケットに送信し、ライフサイクルで S3 Glacier Deep Archive へ移行するのが定番です。S3 側で削除防止を有効にすれば上書きや誤削除を防げ、監査対応の信頼性が向上します。90 日のみの既定保持に頼ると長期調査に耐えられません。

通知・承認・長期保存をすべて自動化し、日次 400 回のデプロイでも速度を落とさない構成を考えると、CodePipeline に 2 段の Manual approval を直列で置き各 SNS トピックから AWS Chatbot へ通知、CloudTrail をイミュータブルな S3 から Glacier Deep Archive に流す案が、運用負荷とガバナンスを同時に最適化できる総合的な解となります。

ヒントボタン

検証フェーズ終了時に ServiceNow の承認フラグを即時チェックできる同期方式が鍵です。AWS CodePipeline の Invoke タイプで AWS Lambda を呼び出せば、関数が REST API を照会し Result=Failed を返すだけでステージを即座に失敗させられます。CodeBuild や EventBridge 経由の非同期処理と違いビルド時間課金が増えず、要件「未承認なら停止」を最小コストで実現できます。

本番デプロイ前には人手による確認を義務づける必要がありますが、AWS CodePipeline には Manual Approval アクションが用意されています。コンソールや CLI でワンクリック承認ができ、SNS 通知で監査証跡も残せます。CodeBuild を待機用に流用したり CodeDeploy のブルー／グリーン切替承認を利用する方法もありますが、構成が複雑化し追加料金が発生するため「標準機能でシンプルに」という要件に沿いません。

追加ビルドを避ける、外部チケットを同期判定でゲートにする、人による承認も挟む――この三点を経済的かつ簡潔に満たすには、CodePipeline ネイティブの Lambda Invoke と Manual Approval の直列配置が最適です。Step Functions をステージ代替にしたり EventBridge で通知だけ飛ばす案は制御が甘く、CodeBuild 代用はコスト増となるため、複数要件を俯瞰すれば標準アクションを素直に使う設計が最も合理的といえます。

ヒントボタン

1行目
CodeBuild のサービスロールはビルドコンテナが S3、ECR、CloudWatch Logs、KMS に直接 API コールするときに使われます。SOC2 で求められる最小権限を満たすには AdministratorAccess を外して必要な操作だけ許可する IAM ポリシーに置き換えるのが基本です。AWSCodeBuildDeveloperAccess などの管理ポリシーはプロジェクト作成や削除も許しリソースも ＊ 指定なので監査では過剰になりやすい点を意識してください。

2行目
ビルド処理を分解すると「S3 へ成果物保存・取得」「ECR へ Docker イメージ push・pull」「CloudWatch Logs へログ送信」「KMS で Parameter Store の暗号化値を復号」の四つだけが必要です。従って s3:GetObject/PutObject、ecr:BatchGetImage/PutImage、logs:CreateLogStream/PutLogEvents、kms:Decrypt だけを action に列挙し、tools-artifact-bkt や各環境の ECR リポジトリ、特定 CMK など対象 ARN を resource に設定することで余計なバケットやキーへの経路を閉じることができます。

3行目
クロスアカウント実行・1 日 200 回の高頻度・単一ポリシーという制約を俯瞰すると、CodeBuild のサービスロールに S3、ECR、CloudWatch Logs、KMS で本当に利用する API とリソースだけを許可するカスタムポリシーを付与し AdministratorAccess を削除する案が、可用性を犠牲にせず SOC2 が求める最小権限を同時に満たす総合的に最も整合的な判断になります。

ヒントボタン

99.9%以上の可用性と最大50並列ビルドという数値要件は、Amazon EC2やJenkinsを自前でスケールさせるより、CodePipelineとCodeBuildというフルマネージドサービスに任せた方が、リージョン単位で自動スケールする公開SLA基盤と同時ビルド上限100以上を活かしてキャパシティ計算やパッチ適用の手間なく目標を達成しやすいと考えられます。
AWS KMSによる自動暗号化と鍵のAWS管理ローテーションという条件は、SSE-S3や手動ローテートのCMKでは満たせませんが、CodePipelineやCodeBuildでデフォルト指定できるaws/codebuildなどのAWS管理型キーを使えばアーティファクトとビルドログがSSE-KMSで保護され年1回自動更新されるため追加運用が不要になります。
ビルド時間短縮とコスト削減を両立させるにはCodeBuildのローカルキャッシュやAmazon S3キャッシュモードで依存ライブラリやDockerレイヤの再取得を抑えるのが効果的で、セルフホストJenkinsではEBS/EFS容量確保やプラグイン管理が増える点と比較すると、可用性・暗号化・性能・運用負荷を総合的に満たすフルマネージド構成が最も適切だと判断できます。

ヒントボタン

dev 環境へはコミットから 30 秒以内に自動反映しつつ prod では手動承認を挟みたい場合、CodeCommit プッシュをフックに CodePipeline を即時開始し、ステージを dev と prod に分けて Approval アクションを配置する形が最小構成で実現しやすいです。EventBridge や外部 CI だけでは秒単位のトリガと承認フローを両立するのが難しく、さらにマルチアカウントでもクロスアカウントロールを設定すれば同じパイプラインから安全に両方へ配布できます。

本番を無停止で 1 分以内に切り替え、障害時には 30 秒で元に戻したいなら、ECS Fargate とネイティブ連携している CodeDeploy の Blue/Green デプロイが最適です。ターゲットグループの切替やヘルスチェック、オートロールバックまで制御してくれるため、単なる ECS rolling update や Elastic Beanstalk の切替よりも迅速かつ信頼性の高いリリースが可能で、デプロイ中に新旧タスクを並行稼働させるためダウンタイムも発生しません。

イメージのセキュリティ担保が必須なら Amazon Inspector V2 の ECR 継続スキャンをパイプラインに組み込み、失敗時に CodePipeline がステージを停止させることで自動ゲートとして機能します。機密情報は AWS Secrets Manager で暗号化保存しタスク定義に ARN 参照を記載することで実行時に安全注入でき、運用は完全マネージドです。これら複数の要件を包括的に満たせるサーバレス CI/CD の組み合わせを選ぶ視点が総合判断の決め手となります。

ヒントボタン

ヒント1
金融系で複数アカウント間の連携を自動化する場合、CodePipeline から別アカウントの AWS Service Catalog を操作するにはクロスアカウント権限委譲が欠かせません。AWS STS の AssumeRole を使えば、一時的なセキュリティトークンで共有サービスアカウントの IAM ロールを引き受けられるため、恒久的なアクセスキーを保有しなくて済みます。さらにパイプラインの各ステージは「アーティファクトを渡すだけ」にしておくとシンプルで運用しやすく、失敗時に即座に止められるよう例外を拾えるアクションを間に挟むのが定石です。

ヒント2
ユニットテストを担当する CodeBuild はビルドとテストの専用サービスなので、テストが成功したあとのカタログ更新処理まで任せるとビルドスペックが肥大化しがちです。CodePipeline では Lambda カスタムアクションを追加すれば、Python や Node.js など短いコードで AWS SDK を自由に呼び出せます。Lambda 関数内で servicecatalog create-provisioning-artifact と update-product を順に呼び出し、エラー時に例外を投げればアクションが Failed 判定となり、後続ステージへ進まないため「テスト失敗なら停止」の要件も自然に充足できます。

ヒント3
CloudFormation アクションはテンプレートのデプロイ、CodeDeploy はアプリケーションの配布を目的としており、既存 Service Catalog 製品へ新しいバージョンだけを登録する API 呼び出しを直接ラップしてはいません。一方、Lambda は管理がサーバレスで追加運用負荷が極小、クロスアカウント STS の使用も簡単、パイプラインで必要なロジックを柔軟に実装できるため、本要件（短命認証・自動登録・失敗時停止・最小運用）の全てを同時に満たしやすいという総合判断が鍵となります。

ヒントボタン

CodePipeline はステージやアクションの状態変化を EventBridge に自動送信できます。ポーリングやカスタムメトリクスを使わずともイベントドリブンで即時処理でき、1 時間に 50 回の実行でもスケーラブルです。さらに SNS にルーティングすればリトライポリシーや DLQ を簡単に設定でき、外部監査システムが一時停止しても疎結合のまま 99.9% 可用性を維持しつつ運用負荷を抑えられます。

監査レスポンスを 15 分以内に待つ要件には最大実行時間が 900 秒の AWS Lambda が最適です。非同期呼び出しでパイプライン本体と独立して待機でき、タイムアウトを 15 分に設定すれば自動的に失敗判定が可能です。Lambda から PutJobFailureResult など CodePipeline API を呼び出せば追加作業なしにステータスを FAILED に変更でき、マネージド運用を貫けます。

要求は「イベントを無駄なく検知する仕組み」「15 分以内の双方向待機」「失敗時の自動ハンドリング」「マネージドサービスのみ」「毎時 50 回でも安定稼働」の五点です。EventBridge＋SNS＋Lambda なら各 SLA が 99.9% 以上で構成もシンプルになり、DLQ で障害時の耐性も確保できます。すべての要件を俯瞰し最も運用負荷が小さくスケーラブルな選択肢を見極めましょう。