記事を読んでいただきありがとうございます。
モブエンジニア（@mob-engineer)です。
TLを見ていたらセキュリティ対策における三層分離モデルの有効性云々の情報が流れていたので、頭の整理のために三層分離モデルをAWSアカウントで実現しようとした場合の構成を整理してみました。
前提知識
三層分離モデルについては総務省から公開されている自治体情報セキュリティ対策の経緯についてをお読みいただければ概要については理解できると思います。
次のようなイメージを持っていただければわかりやすいと思います。
AWSアカウントについて
そもそもAWSアカウント自体分離できるのか考えてみましょう。
AWSアカウント管理 リファレンスガイドを読んでみると分かりやすいかと思います。
分離単位 – AWS アカウント は、 AWS リソースの自律性と分離の実現に役立つリソースのセキュリティ、アクセス、請求の境界を提供します。設計上、アカウント内にプロビジョニングされたすべてのリソースは、独自の AWS 環境内であっても、他のアカウントでプロビジョニングされたリソースから論理的に分離されます。この分離境界により、アプリケーション関連の問題、設定ミス、または悪意のあるアクションのリスクを制限する方法が提供されます。1 つのアカウント内で問題が発生した場合に、他のアカウントに含まれるワークロードへの影響を軽減または排除することができます。
結論として分離可能と理解できました。
そのうえで三層分離を実現するための参考材料としてAWS Well-Architected フレームワーク SEC01-BP01があります。
組織単位構造の設計: 適切に設計された組織単位構造により、サービスコントロールポリシーやその他のセキュリティコントロールの作成と維持に必要な管理負担が軽減されます。組織単位の構造は、ビジネスニーズ、データ機密性、ワークロード構造と整合させる必要があります。
マルチアカウント環境のランディングゾーンを作成する: ランディングゾーンは、組織がワークロードを迅速に開発、起動、デプロイできる一貫したセキュリティとインフラストラクチャの基盤を提供します。カスタム構築のランディングゾーンまたは AWS Control Tower を使用して、環境をオーケストレーションできます。
ガードレールの確立: ランディングゾーンを通して環境に一貫したセキュリティガードレールを実装します。AWS Control Tower には、デプロイできる一連の必須およびオプションのコントロールが用意されています。必須コントロールは、Control Tower 実装時に自動的にデプロイされます。強く推奨されたコントロールとオプションのコントロールのリストを確認し、ニーズに適したコントロールを実装します。
新しく追加されたリージョンへのアクセスを制限する: 新しい AWS リージョンについて、ユーザーやロールなどの IAM リソースは、有効にしたリージョンのみに伝播されます。このアクションは、Control Tower を使用する場合はコンソールから、または AWS Organizations の IAM アクセス権限ポリシーを調整することで実行できます。
AWS CloudFormation StackSets を検討する: StackSets を使用すると、IAM ポリシー、ロール、グループなどのリソースをさまざまな AWS アカウントとリージョンに承認されたテンプレートからデプロイできます。
SEC01-BP01 アカウントを使用してワークロードを分ける
先ほどの図をAWSアカウントに置き換えれば実現は可能な印象を持っています。（実環境での検証はできていないですが）
検討事項
とは言え、実現しようとしたら高度なネットワークへの理解（少なくともBGPレベル？）とAWSアカウント機能に関する深い理解が必要な印象を持っています。疑似的には実現は可能でしょうが、実務で落とし込んでいくためには設計⇒構築⇒効果測定⇒再設計のサイクルを回していく必要がありそうです。