記事を読んでいただきありがとうございます。
モブエンジニア（@mob-engineer)です。
AWS環境で開発を行ううえで「アーキテクチャ設計」について思いつく限り整理しました。
前提
今回登場する環境として以下3点があります。
- 開発環境：機能開発・不具合改修などを行うための環境
- ステージング環境：開発環境から展開されたリソースをテストするための環境
- 本番環境：実際にユーザが触る環境
整理
基本的に3パターンに分けられると考えています。
パターン１：同一アカウントで開発・ステージング・本番を管理
- 利点
- 一つのAWSアカウントのみで完結する
- 一番手軽に環境構築できる
- リスク
- コスト管理が難しい
- 誤った環境での操作リスク（本番環境への影響）
- IAMユーザ単位で制御しないといけない
パターン２：開発・ステージングと本番でアカウントを分ける
- 利点
- 本番アカウントでの誤操作防止が出来る
- 開発・リグレと本番でのコスト管理が容易になる
- リスク
- 開発・リグレで負担部署が違う場合パターン１と同じ問題が起きる
- AWSアカウントが増えるため管理が煩雑になる
- リグレ環境での誤操作リスク
パターン３：開発、ステージング、本番それぞれでアカウントを分ける
- 利点
- 環境ごとにアカウントを分けるため権限統制は柔軟に行える
- コスト管理も環境ごとに行える
- リスク
- 構成によってはTransit Gatewayなどを利用するため設計難度が高い
- パイプライン設計を考える必要がある
まとめ
今回整理したアーキテクチャ設計がすべてというわけではないですが、80％程度の開発現場では上記のいずれかのアーキテクチャ設計をとっていると考えています。要件によって使い分けるのがポイントだと考えています。今回のようなラフな構成図でもいいので書いてみることで頭の整理が出来ると思います。