あまり重要ではない概念の気もするが、
実際の現場でAWSアカウントやVPC構成をどう使い分けしているのか？
具体的に知らないのだが聞いた話をまとめてみる。
大きく分けて２つの構成がある。
それが、マルチVPC構成とマルチアカウント構成である。
マルチVPC構成
中規模な組織で使用されるVPC構成で、１アカウント内でサービスを切り分ける時に使用する。
サービスごとにネットワークやアカウントの管理を分けない構成で使用する。
なぜなら、１アカウント内でVPC内のサービスやアカウント内の様々なリソースには（IAMで権限わけを細かくできるかもしれないが）基本的にアクセスができてしまう。
サービス毎に運用するチームが全く違うのならば、他の資源は見えない方が望ましいのでAWS Organizationを使用してマルチアカウント構成を用いるべきだろう。
マルチアカウント構成
先にも説明した通り大規模な組織向けのVPC構成。
１アカウントごとに１VPC（ないしは複数のVPCを作成してもいいわけですが、）サービスを構成するようにして権限を分けてあげる構成。
個人的には中規模な組織であっても異なるサービスであれば何かトラブルがあっても問題の切り分け（たとえば誰が何の操作をしたとかのログを追うにしたって）権限分けは比較的細かくできる方がいいし、中規模な組織が大組織になったりまたは大組織に組み込まれる（M&Aされる等）可能性があるなら、アカウントを切り分けて柔軟な対応が可能なようにしておくのがお作法かなと思います。
つい１人で学習しているとAWSアカウント１つに何でもかんでも詰め込みたくなるが、１アカウント単位で作成するVPCは５つまでである（正確には１リージョンに対してVPCが５つまでだから、リージョンごとにVPCを複数つくることはできる。）
余談
１VPCあたり１サービスだとすれば、１人でマイクロサービス開発プロジェクトを実施するにしても簡単に使い尽くしてしまうので、１人プロジェクトでもAWS Organizationを使うのはありなのではないか？と思っているところ。
（余談１）ま、１VPC内にいくつもEC2のWebサーバを立てていけばいいんだけど、開発環境として仕事に使うものとかはアカウントをふつうに分けたくシーンがいっぱいあるよね。私でも個人用VPC、学習用VPC、人へ指導する用VPC、開発用VPCと分けているくらいです。タグで分けるだけだと他のEC2インスタンスなどのリソースが見えてしまって都合が悪いし、他人にいざアカウントを共有しようとしても、気軽に渡せなくなってしまいます。
（余談２）（アカウントを別にすると課金が発生するのなら安易なやり方を行わない方がいいかもしれないが、もう少し調べてみてからアカウントごとにサービス開発をやってみようと思う）
コメント