先に結論
- AWS を1アカウントで運用し続けると、最初に困るのは作成の手間ではなく、後から必要になる分離がしにくいことです。
- 特につらくなりやすいのは、本番と検証の分離、IAM 権限の境界、請求の切り分け、CloudTrail など監査ログの扱い、クォータ配分、障害時の影響範囲です。
- AWS公式でも、アカウントはリソースの入れ物であり、隔離境界・請求境界・ガバナンス境界として複数アカウントを前提にした運用が勧められています。
- 最初から大規模に分ける必要はありませんが、1アカウントを長く続けるほど、後からの切り出しは重くなります。
小さく始める段階では、AWS を1アカウントで使うのは珍しくありません。
むしろ最初は、その方が分かりやすいことも多いです。
ただ、サービスが増えたり、チームが増えたり、本番運用が始まったりすると、1アカウントのままではじわじわ苦しくなります。
しかもこの苦しさは、今すぐ壊れる というより、運用を続けるほど遅れて効いてくるタイプです。
この記事では、2026年4月28日時点で AWS Organizations と AWS Control Tower の公式ガイドを確認しながら、AWS を1アカウントで運用し続けると何がつらくなるのかを実務目線で整理します。
まず前提: AWSアカウントはただの箱ではない
AWS公式では、アカウントを単なる契約単位ではなく、リソースの入れ物であり、分離境界として扱っています。
AWS Control Tower のマルチアカウント戦略でも、1つのアカウントでは足りず、複数アカウントによって隔離、請求、ガバナンス、クォータ配分を分ける考え方が示されています。
つまり、1アカウント運用がつらくなるのは、整理が下手だから というより、アカウント自体が境界として強い役割を持っているのに、その境界を使わないまま運用しようとするからです。
1. 本番と検証をきれいに切れない
最初に効いてくるのは、本番と検証の分離です。
同じアカウントの中でも、タグ、命名、VPC、IAM ポリシーである程度は分けられます。
ですが、同じアカウントにある限り、
- 誰かが誤って本番資源を触る
- 検証用の設定変更が本番へ波及する
- 本番用と検証用の見分けが運用ルール頼みになる
という状態になりやすいです。
AWS Organizations のベストプラクティスでも、本番と非本番は別アカウントに分ける考え方が強く勧められています。
1アカウントのままだと、分けたつもり を人間の注意力で維持することになり、チーム運用ではかなりしんどくなります。
2. IAM権限が太りやすい
1アカウント運用が長引くと、IAM の権限設計が太りやすくなります。
理由は単純で、同じアカウントの中に
が全部入るからです。
こうなると、運用担当者に必要な権限も広がりやすく、この人は検証だけ触れればよい が守りにくくなります。
結果として、広めの権限を渡し続けたり、逆に細かく制限しようとしてポリシーが複雑化したりします。
アカウントを分けていれば、アカウント単位で到達範囲を切れるので、権限設計はかなり素直になります。
1アカウントでは、その境界を IAM の条件式や命名ルールで再現し続ける必要があり、運用が重くなります。
3. 請求と原価の切り分けが粗くなる
AWS公式でも、アカウントは請求を分ける基本単位として扱われています。
1アカウント運用を続けると、ここがじわじわつらくなります。
たとえば見たいのは、次のような切り口です。
- どのプロダクトがどれだけ使っているか
- 本番と検証でどちらがコストを食っているか
- どのチームの使い方が増えたのか
タグでもかなり頑張れますが、
- タグ漏れが出る
- 共通基盤コストの配賦が難しい
- 一時的な検証資源が混ざる
といった問題は残ります。
請求の話は後回しにされがちですが、1アカウントのままだと どこが増えたのか分からないから止めにくい 状態になりやすいです。
コスト最適化より前に、まず見える単位が粗いことがつらくなります。
4. 監査ログとセキュリティ基盤を独立させにくい
1アカウント運用では、CloudTrail や各種ログの置き場も同じアカウントに寄りがちです。
すると、運用対象と監査基盤が同居します。
この状態のつらさは次です。
- 調査対象の人がログ設定も触れてしまう
- ログの保存先が同じ境界にある
- 監査専用の閲覧権限を分けにくい
AWS Control Tower が最初から Log Archive アカウントと Audit アカウントを持つのは、まさにこの問題を避けるためです。
運用対象と監査対象を同じ箱に置くと、事故後の調査や統制の説明が難しくなります。
5. クォータやAPIレートを食い合う
見落とされやすいですが、AWS の多くのクォータやリクエスト制限はアカウント単位です。
AWS Organizations のベストプラクティスでも、複数アカウントにすることでクォータと API request-rate limits を分配できる点が利点として挙げられています。
1アカウントに全部載せると、
- あるチームの検証が上限を食う
- 別のワークロードの増強余地を圧迫する
- 本番用の余白が読みにくい
といったことが起きます。
普段は問題がなくても、急なリリースや移行、イベント対応のときに 同じアカウントの別用途が上限に近かった という形で効いてきます。
これはサービスの作り込みより、アカウント境界を切っていないことが原因です。
6. 障害や誤操作の影響範囲が広い
1アカウント運用のつらさを一言で言うと、何かあったときの影響範囲が広いことです。
たとえば、
と、同じアカウントに載っている複数のワークロードへ波及しやすくなります。
AWS公式でも、アカウントは blast radius を小さくする単位として説明されています。
1アカウント運用では、この恩恵を使えません。
結果として、障害対応のたびに どこまで影響したか の確認範囲が広がり、運用コストが増えます。
7. 後から分ける移行が重い
最初のうちは 今は1アカウントでよい という判断でも問題ないことがあります。
つらいのは、その状態を長く続けたあとで分けたくなったときです。
後から分けると、次のようなものを見直す必要が出ます。
つまり、分ける作業は リソース移動 だけでは終わりません。
認証、監査、請求、運用手順まで一緒に組み替える必要があります。
よくある誤解
| よくある考え | 起きやすい問題 | 実際に必要な視点 |
|---|---|---|
| VPCを分ければ十分 | 請求、監査、クォータ、IAM境界は同じまま | ネットワーク以外の境界も見る |
| タグで後から整理できる | タグ漏れや共通費の配賦で詰まりやすい | 請求境界としてのアカウントも使う |
| 小さいから1アカウントで問題ない | チームや本番運用が始まった瞬間に苦しくなる | 今ではなく将来の分離コストも見る |
どのタイミングで分離を真面目に考えるべきか
少なくとも次のどれかに当てはまるなら、1アカウント継続を見直した方がよいです。
- 本番と検証を同時に回している
- 複数チームが同じAWS基盤を触っている
- 外部委託や監査対応が入ってきた
- プロダクト別の原価を見たい
- 監査ログやバックアップを独立させたい
- クォータ不足や到達範囲の広さが怖くなってきた
この段階に来ると、1アカウントの分かりやすさより、分離できないことの痛みの方が大きくなりやすいです。
AWS単一アカウント運用のよくある質問
Q. アカウント分離はいつから検討すべき？
A. 本番と検証/開発の混在、複数チームでの利用、月数十万円以上の請求、セキュリティ事案発生、コンプライアンス要件追加、のいずれかに該当した時点から。
Q. AWS Organizations の導入コストは？
A. ツール自体は無料。設計と移行に1-3か月の工数。Master アカウント + 本番 + 検証 + 開発 の4アカウント構成が定石。Service Control Policies で組織全体ガバナンス。
Q. アカウントを分けると料金が増える？
A. ほぼ変わりません。Reserved Instance や Savings Plans は組織内で共有可能。料金分散 するだけで 総額は同じ のことが多い。
Q. IAM 権限が複雑化したらどう対処？
A. IAM Identity Center(SSO) で集中管理、Permission Boundaries で権限上限、Service Control Policies で組織全体禁止、定期的な棚卸し、で複雑化を抑制。
Q. CloudTrail の組織統合とは？
A. Organization Trail で全アカウントのログを Master アカウントの S3 に集約。一元監視可能で、各アカウントへの個別設定不要。セキュリティチームの工数を削減。
Q. アカウント分離後の課題は？
A. アカウント間通信 (VPC Peering、Transit Gateway)、データ共有(S3 cross-account)、認証統合(IAM Identity Center)、課金集約、で運用設計が必要。事前計画が大事。
Q. 1アカウントから移行するベストプラクティスは？
A. 1) Organizations 立ち上げ + Master 作成、2) 本番/検証アカウント新規作成、3) 順次移行(小さなサービスから)、4) IAM Identity Center で SSO 統合、5) 完全移行後に旧アカウントクローズ、です。
まとめ
AWSを1アカウントで運用し続けるとつらいのは、単に構成が大きくなるからではありません。
AWSアカウントが本来持っている隔離境界、請求境界、ガバナンス境界を使わないまま、運用ルールだけで分離を再現し続けることになるからです。
特に効いてくるのは、
このあたりです。
小さなうちは1アカウントでも回ることはありますが、今はまだ平気 と このまま続けても苦しくならない は別の話です。
後で分ける前提を持って命名、タグ、権限、ログを整えるだけでも、将来のしんどさはかなり変わります。
参考情報
- AWS Control Tower: AWS multi-account strategy for your AWS Control Tower landing zone
- AWS Organizations: Best practices for a multi-account environment
- AWS Prescriptive Guidance: What is a landing zone?