アカウント
開発環境、ステージング環境、本番環境でそれぞれアカウントを分けてしまう。
メリット
開発環境やステージング環境上で実施したテストがプロダクション環境に影響を及ぼすリスクを低減できる。VPCによる分離も可能だがより確実に分離できる。
開発環境
開発効率化の観点から別に用意したい。
ステージング環境
影響分離の観点および、インフラレイヤに対する品質保証の観点からプロダクション環境とは別に用意したい。
アプリの品質保証の観点からここでビルドを行う。
Code Buildのビルドおよびテスト内容、Code Deployはプロダクション環境とは分ける。
実際にコンテナイメージをビルド、テストした後、ECRにイメージをプッシュする処理がワークフロー上に記述される。
本番環境（プロダクション環境）
ガバナンス強化の観点からプロダクション環境のCI/CDパイプラインは他の環境から分離したい。
テスト済みのコンテナイメージをここにデプロイする。
Code Buildのビルドおよびテスト内容、Code Deployはステージング環境とは分ける。
ビルドやテストは実施せずにステージング環境のビルド済イメージを取得するようにする。
環境で共有する資産
「共有リソース用アカウント」を用意する。
CodeCommit
ソースコードを配置する。これは共有させておかないと運用が複雑になる可能性があるため。
ECR
ビルド済イメージを格納します。理由は以下です。
情報源を一元化するため。
「マルチアカウント管理」について
アカウントを分けたい理由
本番環境、開発環境、テスト環境など環境を分けたい場合
セキュリティやガバナンス上
メリット
- アカウントによって操作するコンソールを分離できる。
- 構成変更のリスクを局所化できる。
デメリット
- 監査などが厳しい会社の場合は対応が大変
- 同じオペレーションを複数環境でする必要があるので手間が増える。
- もしオンプレとかを使っている場合はネットワーク設定がかなり複雑になる。
課金を明確に分けたい場合
会社ごと、部署ごとなど。
メリット
課金面では非常にシンプルな運用になる。
デメリット
- アカウント別に集計したい場合に面倒。
- ボリュームディスカウントの設定が面倒。
- 共通サービスを持ちたい場合に設定が面倒（ログ管理など）
アクセス手法
IAMロールのクロスアカウントアクセスを使うのが一般的です。いちいちログアウトしてログインし直すとかだと運用が大変ですが、IAMロールのSwitch Roleという機能を使えばそれが非常に容易になります。
また、踏み台用のアカウントを用意しておいてSwitchロールで開発アカウント、本番アカウントなどを切り替えさせる構成の場合もあります。
複数請求管理
Consolidated Billingという機能を使えば一括で請求管理ができます。
複数アカウント統括
AWS Organizationsという機能を使えば楽にできる。複数アカウントのグループポリシーだったり、ログ管理だったりができます。
この記事へのコメントはありません。