Control TowerとAccount Factoryで10アカウント統制したら、手作業が15分から5分になった話
AWSアカウント管理がカオスだったチームがControl Towerを導入。10個のアカウント移行で見つけた実装パターンと、地味だけど痛い落とし穴を正直に解説します。
正直な導入きっかけ｜ぐちゃぐちゃだったアカウント管理から脱出したかった
うちのチームは去年までアカウント管理がカオスだった。新規プロジェクトが立ち上がるたびに「誰かAWSコンソールでアカウント作って」という手作業が始まるし、セキュリティ設定は各チームまかせで統一されてない。CloudTrailもあるアカウントにはあるしないアカウントもあるし、だいたい3ヶ月後には「あ、Config有効化忘れてた」みたいなことになってた。
そこで提案したのがControl Towerの導入。最初は「追加コストが出るんじゃないか」という懸念もあったけど、実装してみたらアカウント作成が手動15分 → 自動5分に短縮されて、セキュリティガバレンスもぐっと上がった。個人的には「これまじで早く導入すればよかった」という後悔しかない。
今日は、実際に10個のアカウントを移行・統制する中で気づいたこと、Account Factoryの使い方のコツ、そして地味だけど痛い落とし穴を赤裸々に話す。
Control Tower の基本構成｜Management Accountと Organizational Units
先日、新入社員の子に「Control Towerって何ですか？」と聞かれて、言葉で説明するより図を見せたほうがわかりやすいと思った。うちが実装した構成図がこれだ。
graph TB
subgraph "Control Tower Landscape"
MA["Management Account<br/>(Control Tower Root)<br/>- Landing Zone Dashboard<br/>- Service Catalog<br/>- Account Factory"]
subgraph "Core OU"
LogOrgUnit["Security OU<br/>- Logging Account<br/>- Audit Account"]
Logging["Logging Account<br/>- CloudTrail集約<br/>- S3 Access Logs<br/>- VPC Flow Logs"]
Audit["Audit Account<br/>- AWS Config<br/>- GuardDuty<br/>- Macie"]
end
subgraph "Workloads OU"
ProdOU["Production OU"]
DevOU["Development OU"]
Prod1["Prod App Account<br/>- ECS/Lambda<br/>- RDS<br/>- ALB"]
Prod2["Prod Data Account<br/>- Redshift<br/>- Glue<br/>- S3 DataLake"]
Dev1["Dev Account 1"]
Dev2["Dev Account 2"]
end
MA -->|"Control Tower Guardrails<br/>+ SCPs"| LogOrgUnit
LogOrgUnit --> Logging
LogOrgUnit --> Audit
MA -->|"Account Factory<br/>Service Catalog"| ProdOU
MA -->|"Account Factory<br/>Service Catalog"| DevOU
ProdOU --> Prod1
ProdOU --> Prod2
DevOU --> Dev1
DevOU --> Dev2
end
style MA fill:#FF9900
style Logging fill:#4B9BFF
style Audit fill:#FF6B6B
style Prod1 fill:#51CF66
style Prod2 fill:#51CF66
style Dev1 fill:#B197FC
style Dev2 fill:#B197FCControl Towerの肝は、Management Accountと呼ばれる親アカウントですべてのガバレンスを一元管理する点だ。ここで以下を自動化する：
- Guardrails：SCPで強制する設定ルール
- Account Factory：Service Catalogでアカウント自動作成
- Logging Account：CloudTrailなど監査ログの集約
- Audit Account：Config・GuardDutyなど検証の一元化
我々のチームは最初ここまで理解するのに2日かかった。とにかく「すべてはManagement Accountから始まる」という脳みそになることが大事なんだ。
実装の流れ｜Landing Zone立ち上げから Account Factory 統制まで
実際に導入した手順を簡単に振り返ろう。
1. Landing Zone 初期化
Control Towerのコンソールからポチッと「Landing Zoneをセットアップ」を押すと、AWS側で自動的に以下を作ってくれる：
- Management Account
- Logging Account（CloudTrail・S3アクセスログ集約用）
- Audit Account（Config・GuardDuty・Macie用）
- Root OU と Core OU
ハマった点①：Landing Zoneセットアップに約1時間かかる。うちは「5分で終わるでしょ」と思ってたら途中で止まって、CloudFormationスタック作成エラーで詰まった。原因は Management Account に古い CloudFormation スタックが残ってて、リソース名がぶつかってたんだ。事前に古いスタックは全部削除しておくこと。これマジで大事。
2. Organizational Unit (OU) 設計
Control Tower立ち上げ後、自分たちの組織構造に合わせてOUを作っていく。うちの場合はこんな感じだ。
Root
├── Security OU
│ ├── Logging Account
│ └── Audit Account
├── Production OU
│ ├── App Account
│ ├── Data Account
│ └── Network Account
└── Development OU
├── Dev Account 1
├── Dev Account 2
└── Sandbox Account個人的にはOU設計が最初の正念場だと思う。アカウントを作った後に「やっぱり別のOUにしたい」となっても、移動には時間がかかるし、SCP再適用されたりして地味に面倒なんだ。
うちは最初「Production」「Development」の2つだけにしてたけど、3ヶ月後に「あ、Network用の専用アカウント作りたい」ってなって、OUを追加して組み直した。今思えば最初からOUをちょっと多めに作っておけばよかったなって後悔してる。
3. Guardrails の有効化
Control Tower は複数の Guardrails を用意してて、ON/OFF で選べる。これが結構強力で、セキュリティを自動的に強制できるんだ。
| Guardrail名 | レベル | 説明 | 僕たちの実装 |
|---|---|---|---|
| CloudTrail enabled on each account | Mandatory | 全アカウントに CloudTrail 強制 | ✅ 有効 |
| AWS Config enabled on each account | Mandatory | Config 有効化を強制 | ✅ 有効 |
| Prohibited Region Restriction | Preventive | 使わないリージョンへのデプロイを禁止 | ✅ 有効（東京以外禁止） |
| Restrict default security group changes | Preventive | デフォルトSGの変更禁止 | ✅ 有効 |
| Disallow root account MFA disable | Preventive | ルートユーザーのMFA無効化を禁止 | ✅ 有効 |
ハマった点②：Guardrails を後から有効化すると、既存アカウントにも遡及適用される。うちは最初 CloudTrail Mandatory じゃなくて、3ヶ月後に有効化したんだけど、古いアカウントで「CloudTrail が存在しない」という SCP 違反が出た。その時点で根っこから CloudTrail を作り直す必要があって、1日仕事になった。Guardrails は立ち上げと同時に有効化すべき。これもマジで重要。
Account Factory 実装｜Service Catalog で自動化
Control Tower の Account Factory は AWS Service Catalog ベースで動く。自分たちのアカウント作成ワークフローをカスタマイズできるのが魅力だ。
flowchart LR
A["エンジニア<br/>Service Catalogから<br/>申請"]
B["Service Catalog<br/>Account Factory<br/>Product"]
C["CloudFormation<br/>StackSet実行"]
D["AWS Organizations<br/>新規アカウント作成"]
E["VPC・CloudTrail<br/>Config自動設定<br/>（Control Tower）"]
F["完了<br/>新規アカウント利用可"]
A -->|"申請フォーム記入<br/>- Account Name<br/>- OU<br/>- Email" | B
B --> C
C --> D
D --> E
E --> F
style A fill:#FFE5B4
style B fill:#FFD700
style C fill:#87CEEB
style D fill:#90EE90
style E fill:#DDA0DD
style F fill:#FF69B4実際の手順を説明すると、こんな感じで進む：
- Management Account の Service Catalog にログイン
- 「AWS Control Tower Account Factory」プロダクト選択
- フォーム入力：
- Account Email: 新規アカウント用のメアド（ユニークである必要あり）
- Account Name: 例「prod-app-001」
- Organizational Unit: 作成先の OU を選択
- SSO User Email: IAM Identity Center でのユーザー登録
- 申請ボタン押下
- 自動化処理が走る（約15分で完了）
完了すると、以下が自動設定されるんだ。これが本当に便利：
- 新規 AWS アカウント作成
- Control Tower Landing Zone ベースラインの適用
- CloudTrail 有効化
- Config 有効化
- Logging Account への ログ転送
- デフォルト VPC 削除
- Guardrails 適用
- IAM Identity Center ユーザー権限設定
従来の「コンソールでアカウント作成 → CloudTrail 設定忘れ → 1週間後に気づく」みたいなことが一切なくなった。地味だけど、これほど気が楽なことはないよ。
実装のコツ｜うちでハマった話
ハマった点③：Account Factory で作成するアカウント名には命名規則を決めておくべき。うちは最初「prod-account-001」「test-env-01」「dev-hokkaido」みたいにバラバラで作ってて、3ヶ月後には「どのアカウントが何用だっけ？」となった。今は「{environment}-{purpose}-{sequential}」でちゃんと統制してる。命名規則ひとつで運用の手間が全然違うんだ。
ハマった点④：Account Factory の申請メールアドレスの管理。新規アカウント作成には専用メアドが必要なんだけど、エンジニア個人のメアドで作るのは本当はダメ。うちは最初「じゃあ個人メアド使おうか」って感じでやってたら、そのエンジニアが退職して、アカウントへのアクセスが誰もできなくなった。本当に困った。ダミーメアドか、共有メアドボックスを用意すべき。学んだ教訓だ。
実際の作成実績はこんな感じだ：
| 日付 | アカウント名 | 用途 | ステータス |
|---|---|---|---|
| 2026-01-10 | prod-app-001 | ECS App | ✅ Active |
| 2026-01-20 | prod-data-001 | Redshift | ✅ Active |
| 2026-02-05 | dev-sandbox-01 | Experiment | ✅ Active |
| 2026-02-15 | prod-network-001 | Transit GW | ✅ Active |
| 2026-03-01 | stg-validation-01 | Staging | ✅ Active |
| その他 | - | - | - |
| 合計 | 10アカウント | 6ヶ月間 | ✅ |
運用で気づいた落とし穴｜Control Tower は「作った後」が大変
CloudTrail 集約の地獄
Control Tower は自動的に全アカウントの CloudTrail を Logging Account に集約する。便利なんだけど、ログが本当に大量。うちはプロダクション環境で CloudTrail を 3ヶ月集め続けたら、S3 に 250GB 溜まってて、月額 $50 の保管費用が発生してた。え、ちょっと待ってよ、みたいな。
今は以下のようにライフサイクルポリシーを実装してる：
{
"S3 Lifecycle Policy": {
"CloudTrail Logs": {
"Standard": "30日",
"Intelligent-Tiering": "90日",
"Glacier": "1年",
"Expiration": "7年"
}
}
}これで月 $50 → $12 くらいまで落ちた。めっちゃ効果あった。
Config Rules の Auto-remediation
Control Tower で Config も自動有効化されるんだけど、デフォルトの Config Rules は報告するだけで修復しない。例えば「Unencrypted S3」を検出しても、自動的に暗号化はされないんだ。
うちは以下の Auto-remediation を追加実装した：
# AWS Systems Manager Automation Document
{
"schemaVersion": "0.3",
"description": "Enable S3 Default Encryption",
"parameters": {
"BucketName": {
"type": "String",
"description": "S3 Bucket Name"
}
},
"mainSteps": [
{
"name": "EnableEncryption",
"action": "aws:executeAwsApi",
"inputs": {
"Service": "s3",
"Api": "PutBucketEncryption",
"Bucket": "{{ BucketName }}",
"ServerSideEncryptionConfiguration": {
"Rules": [
{
"ApplyServerSideEncryptionByDefault": {
"SSEAlgorithm": "AES256"
}
}
]
}
}
}
]
}これで違反検出 → 自動修復まで一気通貫。人間の介入がほぼ不要になった。セキュリティと効率が両立する感じで、これはマジでいい。
2026年時点の Cost と メリット比較
正直なところ、Control Tower のコストはどうなのか。うちが実装して半年のデータを見てみよう。
xychart-beta
title "Control Tower 導入前後のコスト比較（月額）"
x-axis [CloudTrail, Config, CloudWatch Logs, S3保管, Guardrail, 合計]
y-axis "USD" 0 --> 500
line [30, 20, 15, 80, 0, 145] name "導入前（手動運用）"
line [35, 25, 18, 50, 15, 143] name "導入後（Control Tower）"あれ、ほぼ変わらない？ 実はそう。むしろ整理した結果、CloudTrail の S3 保管コストが下がった。Control Tower のプレミアムとしては：
- Guardrails: 1OU月 $1（なので複数OU作ると加算）
- Account Factory: アカウント作成時に若干のオーバーヘッド（CloudFormation実行）
でも見えにくいメリットが本当に大きいんだ。
- セキュリティ人員の工数削減：手動で CloudTrail・Config 設定してた作業がゼロに
- アカウント作成時間：15分 → 5分（年間で最低50時間削減）
- ガバレンス違反の早期発見：SCP で事前に違反できなくする
- 監査対応の容易性：Logging/Audit Account に一元化されてるので、コンプライアンス審査が楽
キャッシュで見えないところで月 20-30 万円レベルの工数削減になってると思う。これが本当の価値だ。
次のステップ｜Customization の落とし穴
最後に、「Control Tower をもっと自分たちの組織に合わせてカスタマイズしたい」という話になるんだけど、ここからが沼だ。マジで。
Control Tower には**Customization（カスタマイズ）**機能があって、CloudFormation テンプレートを追加して自動実行できる。例えば：
- 全アカウントに VPC 作成
- Lambda 関数で特定のタグ付けルール強制
- EventBridge で違反検出 → Slack 通知
# Control Tower Customization例：Lambda関数自動デプロイ
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Custom baseline for all accounts'
Resources:
LambdaExecutionRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service: lambda.amazonaws.com
Action: sts:AssumeRole
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
SecurityBaselineFunction:
Type: AWS::Lambda::Function
Properties:
FunctionName: control-tower-security-baseline
Runtime: python3.11
Handler: index.lambda_handler
Role: !GetAtt LambdaExecutionRole.Arn
Code:
ZipFile: |
import boto3
import json
def lambda_handler(event, context):
client = boto3.client('ec2')
# Check for unencrypted EBS volumes
response = client.describe_volumes(
Filters=[{'Name': 'encrypted', 'Values': ['false']}]
)
if response['Volumes']:
print(f"Found {len(response['Volumes'])} unencrypted volumes")
# Alert or auto-remediate
return {'statusCode': 200}ただし、ここで注意が必要。Customization を追加すると、Account Factory での新規アカウント作成に時間がかかるんだ。うちは「全アカウントに Lambda 関数を自動デプロイしたい」ってことで Customization 追加したら、アカウント作成時間が 5分 → 12分 に増えた。なんで倍以上になるんだよって感じだ。
さらに、Customization が失敗するとアカウント作成そのものが失敗する可能性があるので、テスト環境で何回も検証する必要がある。正直なところ、僕たちはここで 2 週間つぶした。結構な時間損失だった。
推奨は：
- 最初の 3 ヶ月は Customization なしで運用する
- 実際のペインポイント（「あ、これ毎回手動でやってる」）を見つけてから Customization を追加
- Customization は Git で管理して CI/CD で検証
ここを守ると、後々の追加が楽になるよ。
まとめ
Control Tower・Account Factory を半年運用して、本当に変わったと思うことが 3 つ。
-
アカウント周辺の自動化は必須：新規アカウント作成の度に CloudTrail・Config 設定を手動でやるのは 2024 年以前の話。Control Tower で一気通貫にすべき。これまじで。
-
OU 設計と Guardrails は後から変更が面倒：立ち上げ時点で「これでいいだろう」と思う設計を最初にちゃんと握ること。3ヶ月後の修正は工数が跳ね上がる。後悔したくないなら、ここは慎重に。
-
Customization は慎重に：便利だけど、追加するとアカウント作成時間とテスト工数が増える。最初は「できるだけシンプルに」が吉。本当にそう。
次のアクションとしては、もし複数アカウント運用を検討してるなら、今すぐ Control Tower の評価環境を作るべき。ちょっと手間だけど、長期的には確実に投資回収できる。特に 5 アカウント以上になると一気に価値が出る。
皆さんのチームでも「あ、この部分ずっと手動だ」みたいなのがあれば、Control Tower での自動化を検討する価値は高いと思う。マジでおすすめだ。