こんにちは、技術3課の城です。
サーバーワークスに入社して１年半となりましたが、いろいろなお客様の設計や構築業務に携わらせていただきました。
その中で、アカウントやネットワークの設計は土台となるものなので、重要性や難しさについて経験してきました。

最近ではAWSのサービスの拡張により、設計思想を若干変化させる必要がありそうです。
特にネットワークにおいてTransit GatewayやVPC共有等が昨年末発表されたことにより、アカウント設計、ネットワーク設計をより分離して考えることができるようになったと感じています。
そこで、現時点ではどういう観点で設計の検討をしていくかについて、まとめてみたいと思います。

1. 基本的な方針

要件は抑えつつ、できるだけシンプルな構成を心掛けています。
AWSは自由度が高く、要件に合わせやすい反面、複雑にしようとすれば際限なく複雑になってしまう一面があります。
構成が複雑化しすぎることにより、運用場面において、辛いことも多いので気を付けたいところです。

2. マルチアカウント vs シングルアカウント

こちらについては、マルチアカウントにする理由があるかどうかです。
一般的には下記のような要件でマルチアカウントにされるのではないでしょうか。

各アカウントでの請求を分離したい
権限を委譲したい
- IAMの管理をシンプルにしたい
各アカウントで役割を分けたい
- 踏台アカウント
- 監査用アカウント（CloudTrail、Configの集約）
- 本番/ステージング/開発等

このような要件からアカウントを分ける必要があるかどうか、検討したらよいかと思います。
権限委譲については、IAMポリシーを頑張って作れば可能な部分もありますが、アカウントを分ければより明確に権限を分離することができます。
また、ネットワーク的観点でいえばVPC共有がリリースされた現在では、別アカウントであっても同一VPCにリソース（一部除く）を作成できるため、以前ほど同一アカウント内にこだわる理由が薄くなってきていると思われます。

アカウント設計については、2017年の資料ではありますが、下記資料がとても分かりやすいです。
AWS におけるマルチアカウント管理の手法とベストプラクティス

3. マルチVPC vs シングルVPC

VPC共有がリリースされる以前は、アカウントを分けると必然的にVPCをそれぞれで作成する必要がありました。
現在では、VPC共有を利用してマルチアカウントでも同一VPC、細かく言えばサブネットですが、共有して利用することも可能です。
用途や運用ポリシーによるところが多いと思いますが、下記パターンについて考えてみました。

マルチVPC(完全分離型)
マルチVPC + PrivateLink
マルチVPC + VPC Peering or Transit Gateway
シングルVPC（サブネット共有）

3.1 マルチVPC(完全分離型)

VPC間でネットワークを接続させたくない、接続する必要がない場合、マルチVPCで完全に分離した環境とするかと思います。
リソース間のネットワーク的な疎通が不要であれば、VPCを分け、完全に分離されたネットワークとするべきでしょう。
【イメージ図例】

3.2 マルチVPC + PrivateLink

こちらは要件として少し特殊にかもしれませんが、一部のリソースのサービスを提供したい(その他のリソースは共有したくない)場合、マルチVPCでのPrivateLinkがフィットするでしょう。
PrivateLinkを利用することでアクセス範囲をリソースのサービスレベルで限定できます。
例えばSaaSサービスを顧客に対してPrivateLinkで提供するということもあるようです。
PrivateLinkについてはリージョンが同一である必要があるので、それぞれのVPCで、どのリージョンを利用しているかということも加味する必要があります。
【イメージ図例】

3.3 マルチVPC + VPC Peering or Transit Gateway

VPCを分けて作成したいが、ネットワークとして接続したい場合、マルチVPCでのVPC PeeringまたはTransit Gatewayを検討するかと思います。
既存ですでに複数のVPC上にリソースがあり動かせない場合もこのパターンになるでしょう。
【イメージ図例】

VPCを分けて作成したい理由としては、例えば下記のようなことが考えられます。

全てではないが一部だけネットワーク疎通させたいケース
ネットワーク疎通させたいがVPC共有ができないケース
ネットワークリソースについての管理権限が必要なケース

3.3.1 全てではないが一部だけネットワーク疎通させたいケース

一部だけネットワーク疎通といっても、もちろん同一VPCにてセキュリティグループやNetwork ACLによる制限も可能ですが、ネットワーク的な疎通自体を制限することでよりシンプルに、かつ、明確に管理できます。
管理方法としては、接続したいリソースについてサブネットを用意、そのサブネットに紐づけるルートテーブルにのみ、対向のネットワークセグメントを記載するといった方法があります。

3.3.2 ネットワーク疎通させたいがVPC共有ができないケース

VPC共有には前提条件としてAWS Organizationsで同じ組織に属している必要があるため、別組織に属する場合はVPC共有ができません。
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-sharing.html

また、VPC共有で共有先のアカウントでは下記利用できないサービスがあり、こちらが必要な場合も該当しそうです。

Amazon Aurora サーバーレス
AWS CloudHSM
AWS Glue
Amazon EMR
Network Load Balancer

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-sharing.html#vpc-share-unsupported-services

3.3.3 ネットワークリソースについての管理権限が必要なケース

厳密には、必要な管理者にクロスアカウントのIAMロールやIAMユーザーを払い出すことで対応可能ですが、どのように運用するか次第でしょう。

3.4 シングルVPC（VPC共有）

特にVPCを分けて作成する理由がない場合はシングルVPCとなるでしょう。
なにかしら理由があったとしても、VPCは少ない方が管理リソース数が少なく、シンプルになることによる利点もあります。
VPCを分けるべき理由が許容できる範囲であったり、別の方法で回避することが可能であれば、シングルVPCでの設計とするのもアリでしょう。
【イメージ図例】

ただし、前の項でも述べていますが、VPC共有を利用する場合、共有先のアカウントではいろいろと制限があります。
作成できないリソースがあったり、ネットワークリソースは共有元の管理となるため、変更、追加等の操作は出来ません。
運用の仕方に依る部分かと思いますので、柔軟に検討しましょう。

※注) VPC共有を利用するには共有元アカウント、共有先アカウントがAWS Organizationsの同一組織に属している必要がありますので、ご注意ください。

4. VPC Peering vs Transit Gateway

VPC間の接続方法について比較します。

4.1 コスト

VPC Peering自体に対する課金はないのに対し、Transit Gatewayは処理データ量についての課金、また、各VPCとのアタッチメント毎にも課金されます。
Transit Gateway 料金

4.2 接続方法

VPC Peeringは接続するVPCをそれぞれ1対1で接続します。
Transit GatewayはひとつのTransit Gatewayから接続するVPCに対してアタッチメントを作成することで接続します。
下図は5つのVPCをすべて疎通させたいケースの例となりますが、VPC Peering（図左）はフルメッシュで作成するのに対し、Transit Gateway（図右）はハブ&スポークで接続できるイメージです。

4.3 サブネットのルートテーブル

VPC Peeringは送信先ネットワークレンジのターゲットとして、そのVPCとのVPC Peeringをそれぞれ指定する必要があります。
Transit GatewayはTransit Gatewayを指定できます。
Transit Gatewayはターゲットが同じなので、場合によっては経路集約するなどでシンプルなルートテーブルにできそうです。
対して、VPC Peeringは各送信先ネットワークレンジに対し別々のターゲットを指定する必要があり、接続するVPCが5,10と多くなればなるほど、複雑化します。
実際に経験としてありますが、中々に大変です。

4.4 VPN接続

VPC Peeringで接続しているVPCについては、同一拠点に対するVPN接続であっても、それぞれのVPCでVPN接続を行う必要があります。
Transit GatewayについてはVPN接続をアタッチできるため、一つのVPN接続を一つのアタッチメントとして取り扱うことができます。
https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-vpn-attachments.html

4.5 Direct Connect

東京リージョンにおいては現状、どちらもDirect Connect(Direct Connect Gateway)からVirtual Interface作成し、各VPCのVirtual Private Gatewayに紐づけする必要があります。
ただし、Transit GatewayはDirect Connectに対応する予定とされており、一部リージョンではDirect Connect GatewayをTransit Gatewayと関連づける機能がリリースされています。
※2019/5/27時点の情報となります。

https://aws.amazon.com/jp/blogs/aws/use-aws-transit-gateway-direct-connect-to-centralize-and-streamline-your-network-connectivity/
https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/direct-connect-transit-gateways.html

4.6 その他

Transit Gatewayには各アタッチメント毎にルートテーブルを設定する必要があります。
デフォルトのルートテーブル（Any to Any）を利用することもできますが、内容を詳細に設定することもできます。
また、ブラックホール(ドロップ)を設定することもできます。
例えば、VPC間はすべて疎通させるが、VPN接続先の拠点ネットワークとの疎通はVPCにより制限するなど、詳細に設定することが可能です。
https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-route-tables.html

4.7 比較まとめ

	VPC Peering	Transit Gateway
コスト	VPC Peering自体に対する課金はなし	処理データ量、及び、アタッチメント数に応じて課金
接続方法	各VPC対各VPCでピアリングを作成	1つのTransit Gatewayから各VPCにアタッチメントを作成
サブネットのルートテーブル	ターゲットに各ピアリングを指定する必要があり、複雑化しやすい	ターゲットにトランジットゲートウェイを指定するので単純にしやすい
VPN 接続	別途それぞれのVPCでVPN 接続を作成する必要がある	Transsit GatewayにVPN 接続をアタッチ可能
Direct Connect	それぞれのVPCのVGWにVIFの紐づけ必要	東京リージョンでは現状VPC Peeringと同様だが、対応リリース予定とアナウンスされている ※一部リージョンではリリース済み ※2019/5/27時点の情報となります
その他		アタッチメント毎にルートテーブルを設定するブラックホール機能もある

5. さいごに

改めて考えてみると、現状どのようなことを考えて設計を検討するか見えてきた気がします。
やはり、ほぼほぼアカウント設計とネットワーク設計を分離して考えることができ、それぞれの要件に引きずられることなく、実現しやすいようになっていそうです。

ざっとまとめてみましたが、どなたかの助けになれば幸いです。

AWSへの移行におけるアカウント、及び、ネットワーク設計についての考察