AWS開発・ステージング・本番の環境分離設計｜アカウント分割 vs VPC分割のコスト・セキュリティ・運用比較と現場の判断基準

オンプレのインフラ設計をやってきたエンジニアなら、開発・ステージング・本番の環境分離は当たり前の概念だ。物理サーバーなら別ラック、VMwareなら別クラスターかVLANで分離するのが普通だった。

AWSへ移行したとき、多くのエンジニアがここで立ち止まる。「VPCを3つ作ればいいのか」「アカウントを分割すべきか」「Terraformのworkspaceで分けられると聞いたが本番でも安全か」——設計判断の軸が見えないのだ。

この記事では、AWSで開発・ステージング・本番を分離する代表的な2つのアプローチであるアカウント分割とVPC分割を、コスト・セキュリティ・運用の観点で比較し、組織規模別の選択基準と移行手順を整理する。

なぜAWSで環境分離が重要なのか

オンプレではネットワーク機器のVLAN設定や物理分離が明確な「壁」になっていた。AWSではその壁が目に見えないため、設計者が意識して作り込まないと環境間の分離は崩れやすい。

環境分離の目的は主に3つある。

・コスト配分の明確化: 開発チームがスピンアップしたインスタンスの費用が本番のコストと混ざると、部門別請求も予算管理も成立しない
・セキュリティの爆発半径（Blast Radius）の制限: 開発環境のIAMキー漏洩が本番S3バケットへのアクセスにつながるような事態を構造的に防ぐ
・本番の安定稼働保護: 開発者の実験的な設定変更が本番のセキュリティグループやルートテーブルを誤って書き換えるリスクを排除する

特に「爆発半径の制限」はAWSのベストプラクティスでも繰り返し強調されるポイントだ。IAMのポリシー設計だけでこれを完全にコントロールするのは難しく、アカウントの境界が最強の隔離壁になる。

主要な分離方式3パターン

1. アカウント分割（AWS推奨・最も強固）

AWS Organizations傘下に複数のメンバーアカウントを作り、環境ごとにアカウントを分ける方式だ。

管理コンソールのログイン自体がアカウント境界で分離されるため、IAM設定の複雑さに依存せず、構造的に環境間の干渉を防げる。

主なメリット
・SCPでアカウント単位のポリシー（例：本番アカウントではEC2の削除を禁止）を強制できる
・CloudTrailのログが環境ごとに独立し、監査対応がしやすい
・コスト可視化がAWS Cost Explorerでアカウント単位に自然に分かれる
・AWSサービスクォータがアカウントごとに独立するため、開発環境での上限到達が本番に波及しない

主なデメリット
・アカウントをまたいだリソース参照（クロスアカウントIAMロール）の設定が必要
・VPCをアカウントごとに作るとNAT Gatewayなどのコストが分散する
・CI/CDパイプラインにクロスアカウントのAssumeRole設計が必要になる

2. VPC分割（低コスト・シンプル）

単一のAWSアカウント内にVPCを3つ（dev-vpc、staging-vpc、prod-vpc）作る方式だ。

スタートアップや少人数チームが「まずAWSに慣れる」フェーズで選ぶことが多い。

主なメリット
・設定がシンプルで、クロスアカウントの複雑さがない
・NAT GatewayなどのVPCコンポーネントを共有または集約できる
・小規模チームではコスト・運用の負荷が低い

主なデメリット
・IAM管理者が誤って本番リソースに権限を付与するリスクがある
・コスト配分はリソースタグに依存するため、タグ付け漏れがあると不正確になる
・SCPによる強制ポリシーが使えない（AWS Organizationsの機能のため）

3. サブネット分割（最小構成・非推奨）

単一VPC内でサブネットのCIDRと命名規則、セキュリティグループで環境を論理的に分ける方式だ。セキュリティグループの「壁」は設定次第でいくらでも穴が開くため、本番環境の分離手段としては原則推奨しない。小規模の開発専用環境や学習目的に限定すべきだ。

コスト比較：3環境を想定した試算

小規模チームで3つの環境（dev・staging・prod）を東京リージョン（ap-northeast-1）に作る場合の代表的なコスト差を見てみよう（2026年7月時点）。

VPCに関連する代表的なコスト要素としてNAT Gatewayが挙げられる。東京リージョンの料金は$0.062/時間（月額約$45/基）+ $0.062/GBのデータ処理料だ（2026年7月時点）。

ただし、NAT Gatewayのコストだけでアカウント分割を避けるのは短絡的だ。本番のインシデントで1日の稼働が止まった場合の機会損失と比べれば、月$90の追加費用など問題にならないケースが多い。

また、アカウント分割を採用しつつAWS Resource Access Manager（RAM）でVPCサブネットを共有する構成を使えば、NAT Gatewayを集約してコストを抑えることも可能だ。

セキュリティとガバナンスの比較

IAMの爆発半径

VPC分割では、同一アカウント内に全環境のリソースが存在する。IAMポリシーの設計ミス（例：Resource: "*" を含むポリシーの誤付与）があれば、本番リソースへのアクセスが可能になる。

アカウント分割では、本番アカウントのクレデンシャルはそもそも別の認証情報だ。開発アカウントのアクセスキーが漏洩しても、そのキーで本番アカウントのリソースを操作することはできない。この「構造的な壁」がアカウント分割の最大の価値だ。

AWS Organizations + SCPの活用

AWS Organizationsを使ったアカウント分割では、SCP（Service Control Policy）で本番アカウントに対して以下のような制限を強制できる。

# SCP例: 本番アカウントでap-northeast-1以外のリージョンへのリソース作成を禁止
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideAllowedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "cloudfront:*",
        "route53:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "ap-northeast-1"
        }
      }
    }
  ]
}

このようなポリシーはIAMだけでは実現できない。SCPはアカウント内のルートユーザーを含むすべてのプリンシパルに適用されるため、どのユーザーが作業しても強制力がある。

CloudTrailとログ管理

アカウント分割であれば、本番アカウントのCloudTrailログが開発・ステージングの操作と混在しない。コンプライアンス要件（PCI DSS、SOC2など）では監査ログの分離が求められることが多く、アカウント分割の方が対応しやすい。

運用設計の比較

CI/CDパイプラインの設計

アカウント分割を採用した場合、CI/CDパイプラインはクロスアカウントのAssumeRoleを使って各環境にデプロイする設計になる。

# GitHub Actionsでのクロスアカウントデプロイ設定例（概念）
# パイプラインが各環境アカウントのデプロイロールをAssumeRoleして操作する

jobs:
  deploy-dev:
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::111111111111:role/github-deploy-role
          aws-region: ap-northeast-1
  deploy-prod:
    needs: [deploy-dev, run-tests]
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::333333333333:role/github-deploy-role
          aws-region: ap-northeast-1

初期設定はやや複雑だが、一度確立すれば「本番へのデプロイは必ずこのロール経由」という統制が自動的に守られる。開発者が直接本番アカウントのコンソールを操作してデプロイする、という事態が構造的に起きにくくなる。

TerraformのState管理

Terraformで複数環境を管理する場合、「workspaceで分けるか、別ディレクトリ・別stateで分けるか」がよく議論になる。

アカウント分割構成では、TerraformのStateファイルも環境別のS3バケット（アカウント内）に分けて保存するのが基本だ。Stateが混在すると、planコマンド実行時に別環境のリソースを誤って破壊するリスクが生まれる。

組織規模別の判断基準

「本番で事故が起きた場合の損失規模」を基準に考えると判断しやすい。月商が数百万円を超えるシステムであれば、アカウント分割の初期設定コスト・複雑さは十分に見合う。

アカウント分割の実装パターン

AWS Control TowerでLanding Zoneを作る

AWS Control Towerを使うと、アカウント構造と基本的なガードレール（SCPセット、CloudTrail設定、AWS Config有効化）を自動で整備できる。ゼロから手動でOrganizationsを構築するより安全で速い。

典型的なLanding Zoneの構成例は次のとおりだ。

・管理アカウント（Management）: 請求集約・SCP管理のみ。リソースは作らない
・ログアーカイブアカウント（Log Archive）: 全アカウントのCloudTrailログを集約
・セキュリティ監査アカウント（Audit）: セキュリティチームが全アカウントをRead-Onlyで閲覧
・共有サービスアカウント（Shared Services）: Active Directory、Route 53 Resolverなどを集約
・開発アカウント（dev）: 開発環境
・ステージングアカウント（staging）: テスト・受け入れ環境
・本番アカウント（prod）: 本番環境

最初から全部揃える必要はない。まずは管理アカウント＋dev・staging・prodの4アカウント構成で始め、チームが大きくなったらLog ArchiveやAuditアカウントを追加するという進め方が現実的だ。

AWS IAM Identity CenterでSSO設計

アカウントが増えると、エンジニアが各アカウントの認証情報を個別に管理するのは現実的でなくなる。AWS IAM Identity Centerを使えば、1か所のログインで複数アカウントへのアクセスをコントロールできる。

「開発チームはdev・stagingアカウントのみ」「本番はシニアエンジニアとCI/CDのみ」といったアクセス制御をPermission Set（権限セット）で管理できる。個人ごとのIAMユーザーをアカウントごとに作る必要がなくなり、オフボーディング時の権限削除漏れも起きにくくなる。

Transit GatewayでVPC間通信を統制

アカウント分割後、環境間でネットワーク通信が必要な場面（例：本番DBのデータをステージングに同期するバッチ）では、AWS Transit Gatewayを使ったハブ&スポーク構成が現実的な選択肢だ。

各アカウントのVPCをTransit Gatewayに接続し、ルートテーブルで「dev→prod方向の通信は禁止」「staging→prodのRDSリードレプリカのみ許可」といった細かな制御を実装できる。

アカウント間でVPCのCIDRが重複するとTransit Gatewayでルーティングできなくなるため、VPC CIDRブロック設計は事前に整理しておく必要がある。

VPC分割からアカウント分割への移行パス

「最初はVPC分割で始めたが、組織が大きくなってアカウント分割に移行したい」という相談は現場でも多い。以下の順序で段階的に移行できる。

Step 1: AWS Organizations + 管理アカウントを作成
既存の単一アカウントをOrganizationsのメンバーアカウントとして取り込む。請求はOrganizations管理アカウントに集約される。

Step 2: Control Towerを有効化してLog Archive・Auditアカウントを作成
必須ではないが、このタイミングで整備しておくと後の運用が楽になる。

Step 3: 新しい本番アカウントを作成し、本番リソースを移行
RDSスナップショットのクロスアカウントコピー、AMIの共有、S3バケットポリシーの変更など。EC2の移行は同期期間を設けてDNS切り替えで本番切替を行う。

Step 4: CI/CDパイプラインをクロスアカウント構成に移行
GitHub ActionsやAWS CodePipelineにクロスアカウントのAssumeRole設定を追加する。

Step 5: 旧VPC内の本番リソースを削除
旧アカウントのprod-vpc内のリソースを整理し、VPC単独の構成（dev/staging用）に整理する。

一度に全部移すのではなく、本番環境を先に新アカウントへ移すのが安全な進め方だ。開発・ステージングは後から移行しても本番への影響がない。

よくある判断ミスと注意点

・「Terraformワークスペースで環境を分ければOK」という誤解: workspaceはコードの環境切り替えに使えるが、IAMの分離やSCPの適用ができない。本番の構造的な保護にはならない
・タグだけに頼るコスト管理: タグ付け漏れは必ず発生する。コスト配分の確実性ではアカウント分割の方が圧倒的に高い
・「完璧な構成」を最初から目指す: 最初はdev・staging・prod＋管理アカウントの4構成で十分。共有サービスアカウントは必要になってから追加する
・スモールスタート期にアカウント分割を導入して運用が回らなくなる: 1人または少人数チームではクロスアカウント管理のコストが本番リスクを上回る場合がある
・dev環境とprod環境で同じCIDRブロックを使う: 後からTransit Gatewayで接続しようとしたときにIPが重複して詰む。最初のCIDR設計が重要だ

本記事のまとめ

AWSにおける環境分離の選択基準を整理すると次のとおりだ。

AWSはアカウント分割を推奨しており、Control TowerやOrganizationsを使えば以前より遥かに簡単に実装できる。ただし「アカウントを分ければ安心」ではなく、クロスアカウントのIAMロール設計・CI/CD設計・VPCのIPアドレス計画がセットで必要になることを理解した上で導入してほしい。

スタートアップ期はVPC分割でシンプルに始め、本番の売上が立って開発チームが拡大するタイミングでアカウント分割へ移行するという進め方が現実的だ。最初から「完璧な構成」を目指すより、現在の体制と規模に合った設計を選ぶ方が、長期的な運用コストは低くなる。