##背景
AWSの利用を開始する時にAWSアカウントを作成すると思いますが、その時、このアカウントって誰が使うの？どの環境用？と考えた事はありませんか？何も考えずにAWSアカウントを作成していくと、後々、大変な事になります。そうならないためにも、しっかり整理された複数のAWSアカウントを作成する際に、考えた事をつらつら書いていこうと思います。

##AWSアカウントの特徴を考える
まず、AWSアカウントって何でしょう？AWSアカウントその物の特徴を考えてみました。

セキュリティにおける境界の単位
- 他のアカウントとのセキュリティの境界の役割を果たす（他のAWSアカウントの構成は見えないしアクセスできない）
AWS環境における分割単位
- アカウント単位でAWSのさまざまなリソースを管理する
AWS課金における分割単位
- AWSのサービスの利用における課金はAWSアカウントに対して行われる

##検討観点からメリデメを考える
AWSアカウントを、どのシステム単位、組織単位で利用するか？環境（本番/ステージング/開発）ごとに分けるか？等々を「管理」、「課金」、「組織」、「運用」の観点から考えてみました。

検討観点	AWSアカウントを分割する理由	メリット	デメリット
管理	セキュリティ及び管理上の理由から開発環境、テスト環境、本番環境でアカウントを分割したい	・本番環境の管理コンソールを分離できる・本番環境と非本番環境を管理するメンバーの明確な権限の分離・環境間におけるセキュリティ対策の分離が可能	・複数アカウントにまたがり管理を行う必要がある・複数アカウントにまたがる監査情報取得等の効率化が必要
課金	課金に関する可視性、責任、及びアカウントごとのコントロールを行いたい	・分離したアカウント毎に明確な課金管理を行うことができる・複数の部門やシステム単位に対し、シンプルな課金運用が実現できる	・各アカウントの課金レポートに対するアクセス管理や、レポートを集約する場合にはconsolidationを必要とする・利用料のボリュームディスカウントのためにはconsolidationと配賦の合意が必要になる
組織	リソースの操作権限を特定のシステム（組織単位）に委譲し、その中でより自由にAWSプラットフォームを活用したい	・システム（組織単位）毎に異なる課金管理と共にサポートすることができ、システム（組織単位）での管理を容易に行うことができる・統制や課金が異なる専用アカウントを用いる個々の顧客に対してサービスを提供しやすい	・共通機能のような、アカウントをまたいで利用できる機能を重複して持つことへの考慮・対応が必要となる
運用	構成変更時の影響範囲を小さくし、自身固有の環境を利用したい	・変更による影響範囲を縮小する事ができる。例）開発環境の障害が本番環境に及ばない・AWSアカウントのリソース上限にかかる可能性を緩和できる	・複数アカウントを管理するため重複設定・操作の増加等、運用ボリュームが増加する・監査やセキュリティ対応といった運用にクロスアカウントでのアクセス権限が必要となる・オンプレミスとAWSおよびAWSアカウント間のネットワーク接続の複雑性・コストが増す

##まとめ
AWSアカウントはAWSを利用する際に一番大きな論理区画となるものです。後々の構成変更は容易ではなく、慎重に検討したいものです。