Terraform workspaceとAWSアカウント分離はどこで切り替えるか――環境境界の設計判断

Terraform workspaceで環境を切り替えるだけでよいケースと、AWSアカウントを物理的に分離しなければならないケースは、プロジェクト規模だけでは決まりません。本記事の結論を先に述べると、「本番環境で発生した障害・権限漏えいが他環境に波及するリスクがあるなら、workspaceではなくアカウント分離を選ぶ」という一点に集約されます。設計の判断軸をブラストラジウス（影響爆発半径）に置き、state管理・SCP設計・リポジトリ構成への影響まで含めて、境界線の引き方を解説します。

workspaceで切り替えるだけで十分な環境とアカウント分離が必要になる環境の違い

workspaceが本来解決する問題

Terraform workspaceは、同一のコード構成を維持したまま複数の環境に対してstateを分離する仕組みです。S3 backendであればenv:/workspace名/パスという独立したstateファイルパスが生成され、リソース名の衝突を避けながら並列環境を維持できます。この方式が最も有効なのは、「dev・stg・prdの3環境が同一のAWSアカウント内に存在し、それで許容される」という前提が成立する場面です。社内向けの検証基盤や、EC2インスタンス5台以下で構成される小規模なWebサービスのステージング環境では、workspaceの切り替えで十分な分離が得られます。同一アカウント内での運用はコスト管理もシンプルで、権限設計もIAMポリシーのCondition句でタグやリソースプレフィックスを制御する方法で対応できる場合があります。

アカウント分離が必要になる境界条件

アカウント分離を選ぶべきかの判断は、「本番環境への影響範囲が他環境に及ぶかどうか」で切り分けられます。同一アカウント内にdev・prdが共存する構成では、IAMロールの誤設定やTerraformのapply先の誤指定が直接本番リソースに影響を与えるリスクがゼロになりません。境界条件として実務上よく挙げられるのは次の3点です。第一に、本番環境が外部顧客にサービスを提供していてSLAが設定されている場合。第二に、開発者が本番のIAMポリシーやSecurity Groupを直接参照・変更できる権限が残る構成の場合。第三に、コンプライアンス要件（PCI-DSSやSOC2など）で「本番環境は他環境と物理的に分離されていること」が求められる場合です。この3条件のいずれかに該当するなら、workspace方式では要件を満たせません。

よくある誤判断のパターン

一般的な誤りとして、「dev/stgはworkspaceで管理し、prdだけ別アカウントにする」という中途半端な分離が挙げられます。stgと同一アカウントにprdを置きつつworkspaceを分けるだけでは、AWSのサービスクォータ（例：リージョンごとのVPC上限）をdev・stgと共有するため、stgでの負荷試験がprdのリソース取得を圧迫する可能性があります。もう一つの誤判断は、「Terraform用のIAMロールを環境ごとに分ければworkspaceで十分」という考え方です。ロールを分けてもリソースは同一アカウント内に存在するため、Security Groupの参照やVPCピアリングの誤設定が隣の環境のリソースに作用する可能性は残ります。workspaceはstate分離であり、AWSリソースの物理的な分離ではないという点を、設計の出発点として認識する必要があります。

ブラストラジウスを基準にした環境境界の引き方

ブラストラジウスとは何を測る指標か

ブラストラジウス（blast radius）とは、障害・誤操作・セキュリティインシデントが発生したとき「どの範囲のリソースまで影響が伝播するか」を示す概念です。インフラ設計では「爆発半径を最小化する」という表現で使われ、障害の影響範囲を設計段階でどこまで制限できるかを判断する材料になります。workspaceを使って同一アカウント内で環境を分ける構成では、ブラストラジウスは少なくともAWSアカウント全体に及びます。IAMポリシーの誤設定・S3バケットポリシーの公開設定ミス・Security Groupのインバウンドルール開放など、アカウントレベルの設定ミスはworkspaceの境界を越えてすべての環境に波及します。

環境ごとのブラストラジウス評価

環境境界の設計時には、各環境で「最大何件の顧客データが影響を受けるか」「障害発生から復旧までに許容できる時間（RTO）はどの程度か」を設定します。開発環境であれば影響件数ゼロ・RTOが数時間でも許容できますが、本番環境では顧客データへの影響ゼロ・RTOが15分以内という要件になることも少なくありません。この要件差が10倍以上開く場合（想定例：devのRTOが4時間・prdが15分）、同一アカウントでの共存はブラストラジウス管理の観点から推奨できません。AWSアカウントを分離することで、prdアカウントへのアクセス権を持つIAMエンティティの数を最小化し、影響範囲をそのアカウント内のリソースのみに限定できます。

境界線を引くための判断チェックリスト

環境境界を引く判断として、以下のチェックリストを活用してください。Yesが一つでもあれば、アカウント分離を前提に設計を進めることが推奨されます。

• 本番環境に外部顧客向けのSLAが設定されているか
• 開発者が本番IAMロールをAssumeできる構成になっているか
• コンプライアンス要件で環境分離の物理的証明が必要か
• 同一アカウントのサービスクォータが複数環境で競合するリスクがあるか
• 本番とdev/stgで適用したいSCPポリシーが異なるか

上記5点がすべてNoであれば、workspace方式で十分な分離が得られる可能性が高いです。ただし、要件が将来変わった場合にアカウント分離への移行コストが発生します。リソース数が少ない初期段階でアカウント分離を先行して導入するという設計判断も、移行コストを抑える観点から合理的です。

workspace方式とアカウント分離方式の比較表

比較の前提と観点

両方式を比較する際、「どちらが優れるか」という評価は設計判断の助けになりません。workspace方式はセットアップの速さと構成のシンプルさに優れ、アカウント分離方式はセキュリティ境界の明確さとコンプライアンス対応に優れます。比較の軸は「現在の要件を満たすか」ではなく「将来の要件変化に対してどちらがリスクを抑えられるか」に置くと、設計判断の精度が上がります。以下の表は主要な観点で両方式を整理したものです。

比較観点	workspace方式（同一アカウント）	アカウント分離方式
IAM境界	Condition句で環境を分離。複雑化しやすく誤設定リスクあり	アカウント境界がそのままIAM境界。ポリシーがシンプルになる
ブラストラジウス	障害・誤設定の影響がアカウント全体に及ぶ	障害の影響範囲をアカウント単位で物理的に限定できる
SCP適用	アカウント単位のSCPが全workspace（全環境）に適用される	環境ごとに独立したSCPを設計・適用可能
state管理	backendは共通。パスのプレフィックスで環境を分離	backendがアカウントごとに独立。stateへのアクセス権が分離される
コンプライアンス対応	PCI-DSS・SOC2の「環境物理分離」要件を満たすのが困難	アカウント分離で要件を明確に満たせる
初期構築コスト	低い（既存のbackend設定を変更しない）	高い（アカウント作成・Organizations設定・backend再構成が必要）
CI/CDパイプライン設計	シンプル（workspace切替をパイプラインに組み込む）	複雑（アカウントごとのAssumeRoleをパイプラインで制御）
サービスクォータ管理	全環境で共有。stgの負荷試験がprdに影響する可能性	アカウントごとに独立。クォータ競合が発生しない

比較表から読み取るべき設計判断

比較表で特に注目すべきは「IAM境界」と「SCP適用」の行です。workspace方式でIAMポリシーのCondition句が複数環境分に膨らむと、メンテナンスコストが急増するという傾向があります。一方のアカウント分離では、アカウント境界がそのままIAM境界になるため、ポリシーの複雑性が構造的に抑えられます。ただしアカウント分離方式はCI/CDパイプラインでのIAMロール切り替えを設計する必要があり、GitHub ActionsやCodePipelineでのAssumeRole設計が追加コストになります。どのタイミングでアカウント分離を導入するかは、現在のIAMポリシーの複雑さとCI/CDの整備状況を天秤にかけて判断することになります。

state管理とbackend構成の変化点

workspace方式でのstate管理の特徴と限界

workspace方式でS3 backendを使う場合、stateファイルのパスは自動的に環境ごとに切り分けられます。管理上の利点は、backendブロックの設定を環境ごとに変更しなくてよい点です。しかしデメリットとして、S3バケット自体が全workspace共通になります。バケットへのアクセス権を持つIAMロールは、すべてのworkspaceのstateにアクセスできるため、stateファイルに含まれるシークレット値（データベースのエンドポイントやパスワードなど）が本来アクセスを制限すべき開発者に見える状態になります。対策としてS3 Object-Level LoggingとCloudTrailの組み合わせによる監視は有効ですが、これはアクセス後の検知であり、アクセス自体の防止ではありません。workspaceはstate分離の仕組みであり、stateファイルへの権限境界を保証する仕組みではないという点を設計上の限界として認識する必要があります。

アカウント分離方式でのbackend設計

アカウント分離方式では、backendブロックのbucket・dynamodb_table・role_arnをアカウントごとに切り替える必要があります。実装の選択肢は大きく2つあります。-backend-configフラグで外部設定ファイルを渡す方式と、terragruntなどのラッパーツールを使ってアカウントごとの設定を注入する方式です。どちらを選ぶかはチームの技術スタックと既存構成に依存しますが、新規構築ではterragruntによる管理がbackend設定の重複を減らしやすいです。この設計変更の重要な効果は、「stateファイルが物理的に異なるアカウントのS3バケットに置かれる」という点です。本番アカウントのstateには本番アカウントのIAMロールでしかアクセスできないため、開発者が誤って本番stateを変更することを構造的に防止できます。これはworkspace方式では得られない分離の質です。

backend切替時の落とし穴

既存のworkspace方式からアカウント分離方式に移行する際、stateの移行が最大の難所になります。リソース参照を新しいbackendに移動する作業が必要ですが、200以上のリソースを持つ大規模構成では、この作業に数日から1週間程度の工数を要することがあります（これは想定工数の目安であり、構成によって大きく異なります）。一般的なつまずきとして、stateを新しいbackendにコピーした後も古いbackendのstateファイルが残り続けるという点があります。stateファイルを明示的に削除しなければ、パイプラインが誤って古いstateを参照し続けるリスクが残ります。移行完了の定義に「旧stateの削除確認」を組み込むことが重要です。また、移行中にstateが二重管理になる期間が生じるため、その期間のapplyを禁止する運用ルールを設計段階で定めておく必要があります。

IaCリポジトリ構成への影響と設計の整合性

workspace方式でのリポジトリ構成

workspace方式では、単一のリポジトリ・単一のディレクトリ構成で複数環境を管理できます。dev.tfvars・prd.tfvarsのように変数ファイルを環境ごとに切り替えるか、現在のworkspaceを変数として参照する構成が一般的です。リポジトリ構成がシンプルなため、チームが5名以下でインフラを兼務する体制では初期構築コストを低く抑えられます。一方で、workspaceが3つを超えると変数ファイルの数が増え、「どの環境に何が設定されているか」の見通しが悪くなります。特にlocalsブロックで環境ごとに条件分岐する記述が増えると、コードの可読性が下がり、レビューコストが上昇します。この複雑化を感じ始めた時点が、アカウント分離への移行を検討するシグナルとして機能します。

アカウント分離方式でのリポジトリ設計パターン

アカウント分離方式では、リポジトリ構成に2つの選択肢があります。第一は「モノレポでアカウントごとにディレクトリを分ける」方式（例：envs/dev/・envs/prd/）で、第二は「アカウントごとにリポジトリを分ける」方式です。モノレポ方式はコードの共通化（モジュール参照）がしやすい反面、CIパイプラインでどのディレクトリの変更がどのアカウントに適用されるかのルーティング設計が複雑になります。リポジトリ分離方式は設定の独立性が高まりますが、モジュールのバージョン管理とリポジトリ間の同期が課題になります。10名以上のチームで本番とステージングを別担当が管理する場合、リポジトリ分離方式のほうが権限境界と一致するため整合性を取りやすいです。

構成移行時の整合性維持

workspace方式からアカウント分離方式に移行する際、リポジトリ構成の変更とCI/CDパイプラインの設定変更を同時に行うと、問題発生時の原因特定が困難になります。設計の整合性を維持するには、変更を段階的に分離して実施することが推奨されます。「まずリポジトリ構成を移行（stateはそのまま）→次にCI/CDを切り替え→最後にstateを移行」という順序で進めると、各ステップの影響範囲が明確になります。各ステップの完了基準をあらかじめ定義し、前のステップが安定してから次に進むという原則を守ることで、移行中の本番環境への影響を最小化できます。

AWS Organizations SCPとworkspace方式の相性確認

SCPの役割と適用範囲

AWS OrganizationsのSCP（Service Control Policy）は、組織内のアカウントに対してAPIレベルでの制限を強制する仕組みです。「本番環境ではEC2インスタンスのパブリックIPアサインを禁止する」「特定のリージョン以外でのリソース作成を拒否する」といった制御をIAMポリシーとは独立して適用できます。SCPはIAMポリシーと異なり、アカウントの管理者権限（AdministratorAccess）を持つロールに対しても制限を強制できるため、本番環境の保護手段として有効です。ただしSCPはアカウント単位で適用される仕組みのため、workspace方式（同一アカウント内の複数環境）とは構造的に相性が悪い部分があります。

workspace方式とSCPの限界

同一アカウント内にdev・prdが共存するworkspace構成では、SCPをアカウント単位で適用するため「本番環境だけに厳しいSCPを適用する」という分離ができません。devにも本番と同じSCPが適用されるか、逆に本番にdevと同じ緩いSCPを適用するかのどちらかを選ばざるを得ません。前者はdev環境での作業自由度を下げ、新機能の検証コストを上げます。後者は本番環境への保護が弱まるため、セキュリティ要件を満たせない場合があります。コンプライアンス要件でSCPによる制御が求められる場面では、workspace方式では要件を満たせないため、この時点でアカウント分離を選択する必要があります。SCPを活用した制御が設計要件に含まれているかどうかが、方式選択の早期判断材料になります。

アカウント分離後のSCP設計

アカウントを分離した後は、AWS OrganizationsのOU（Organizational Unit）構造に合わせてSCPを設計します。Production OU配下のアカウントには厳格なSCPを、Development OU配下のアカウントには検証用の緩やかなSCPを適用するという構成が可能になります。これにより、本番環境と開発環境でSCPのポリシーセットを独立して管理でき、コンプライアンス監査でも「本番環境の制御範囲」を明確に提示できます。一般的な注意点として、誤ったSCPを本番OUに適用すると本番APIがすべてDenyされるリスクがあるため、SCP変更はステージング相当のOUで先行検証する運用設計が必要です。Terraformでこの構成を管理する場合も、SCPのポリシー定義とアカウント割り当てをIaCで管理し、変更履歴をGitに残す構成を推奨します。

移行時の段階的アカウント分離手順設計

移行前の前提設計

workspaceからアカウント分離への移行は、「移行中は既存の本番環境を継続稼働させながら進める」という前提で設計する必要があります。移行前に確認すべき前提条件として、まず現在のstateに含まれるリソース数を把握します。リソース数が100件を超える場合は移行コストが大きくなるため、移行期間として最低2〜3スプリント（おおむね4〜6週間）を設計段階で確保することを推奨します。また、CI/CDパイプライン（GitHub ActionsやCodePipelineなど）にアカウント間のIAMロール切り替え機能を追加できるかを事前に確認します。この機能が追加できない場合、パイプラインの再設計が移行の前提条件になります。移行コストを過小評価したまま着手すると、本番稼働中に移行が停滞するリスクが生じるため、工数の見積もりは設計フェーズで完結させる必要があります。

段階的移行のステップ設計

以下は段階的移行のステップを設計判断の観点で整理したものです。操作コマンドの詳細はIaC専門の資料で確認してください。

1. 新アカウント作成とOrganizations登録：本番用の新アカウントをOrganizationsに追加し、OUに割り当てます。この段階ではTerraformリソースはまだ旧アカウントに存在します。
2. backend用リソースの準備：新アカウントにTerraform backend用のS3バケットとDynamoDBテーブルを作成します。この時点でstateはまだ旧アカウント側にあります。
3. リソース再作成か移行かの判断：stateless（EC2インスタンスなどデータを持たない）なリソースは新アカウントで再作成し、stateを新規作成するほうが安全です。stateful（RDS・S3データなど）なリソースは移行コストが高いため、データ移行計画を別途立案します。
4. トラフィック切替：Route53のTTLをあらかじめ短縮（例：300秒から30秒に変更）した上で、ロードバランサの向き先を切り替えます。TTLを短縮しておくことで、問題発生時の切り戻し時間を短縮できます。
5. 旧アカウントリソースの段階的削除：切替完了後、旧アカウントのリソースを即座に削除せず、1〜2週間の監視期間を設けてから削除します。

移行後の検証と切り戻し設計

移行後の検証として、SCPが期待通りに適用されているかのテスト・IAMロールのAssumeRole制限のテスト・Terraform planが新アカウントに対して正しく動作するかの確認を実施します。切り戻し設計として重要なのは、「旧workspace方式のstateを削除する前に移行完了を宣言しない」という原則です。stateが残っていれば、問題発生時に旧構成に戻す選択肢が残ります。切り戻しの有効期限を設計段階で明示（例：「切替後2週間は旧stateを保持し、その後削除」）し、チーム全体で合意することが重要です。移行期間中は本番アカウントとworkspace方式のアカウントが並走する状態が続きますが、この二重管理期間を短くするためにも、移行ステップの各完了基準を事前に定義して手戻りを防ぐ設計が求められます。