AWS 複数アカウントの構成基準を考えてみる

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。

クラウド利用が進んできています。
企業内での複数 AWS アカウント契約も珍しくありません。

新規に AWS をご利用されるお客様においても
複数アカウント前提で話をすることが多くなっているように感じます。

複数アカウントを契約した場合のアカウント構成を
どう考えたらよいかを整理してみました。

複数アカウントの使い分け

アカウントを分割する際の基準を考えてみます。

リソース制限

クラウドの利点は、リソースを使いたい時にすぐ使えることですが、
無制限にリソースを作成できるわけではありません。
例えば、S3 バケットの上限はアカウントあたり 1,000 バケットです。(執筆日時点)

大量のリソースが必要な場合はアカウントを分割します。

リソース制限が本番サービスに影響しないように
本番環境とその他環境は分けたほうが良いと考えます。

環境

環境ごとにアカウントを分割する構成です。
環境というのは、本番・開発・ステージングなどのシステム上の環境です。

なぜ環境ごとに分割するかというと、操作権限 (IAM ポリシー) のメンテナンス性を向上させるためです。

開発者にマネジメントコンソール/CLI で AWS リソースの操作権限を払い出すと思います。
その場合、開発各担当が必要な最低権限を付与することがベストプラクティスです。

IAM ポリシーをカスタマイズして、リソース別やタグベースで各開発担当に操作可能な権限を付与していきますが
それらのメンテナンスは簡単とは言えないのと、設定を誤ると広い権限を与えてしまうことになります。

どこまで細かくアカウントを分割するかは
各プロジェクトの開発チームの体制によると思いますが
本番環境とその他環境は分けたほうが良いと考えます。

請求

システムごと、プロジェクトごとに AWS からの請求を分けたい場合や
コストを明確に把握したい場合はアカウントを分割します。

コスト配分タグを活用すると一つのアカウント内でもある程度のコスト把握は実現出来ます。
しかし、ネットワークトラフィックは明確に分けることが出来ません。
リザーブドインスタンスをコスト配分タグで紐付けることも出来ません。

そうなると ”按分ルール” を社内で策定しないといけなくなります。
按分ルールを決めること自体がかなりの重労働 (肉体的にも精神的にも) ですし
運用が始まったらトラブルになる可能性もあると思います。

そういったことを避けるためにも、請求を分けたい場合はアカウントも分けましょう。

管制塔

管制塔アカウントを作ります。
管制塔アカウントの役割は以下です。

• 一括請求のマスターアカウント
• マネジメントコンソールログイン用
• 統制

個別に説明します。

一括請求のマスターアカウント

請求を特定のアカウントにまとめることが可能です。
ボリュームディスカウントが適用されて請求額が下がる可能性があります。

マネジメントコンソールログイン用

IAM ユーザーを作成するのは管制塔アカウントのみにします。
他のアカウントにはスイッチロールでログインします。

IAM ユーザーを極力作らないようにして
パスワード漏洩のリスクを削減します。

統制

管理している AWS アカウントの CloudTrail や Config を
管制塔アカウントに集約し、アカウント統制に活用します。

他にもアプリケーションのアクセスログを集約する、
EC2 のインベントリ情報を集約するなどして
管理下アカウントの統制を実現するために利用します。

共有 VPC

AWS Organizations でリソース共有を有効化すると
複数アカウントで共有可能な一元管理された VPC を作成できます。
共有 VPC では AWS Organizations で同じ組織に属する他のアカウントと1つまたは複数のサブネットを共有します。

NAT ゲートウェイ、仮想プライベートゲートウェイ、PrivateLink、VPC Peering など
VPC 単位でかかっていた費用を削減することが可能です。

機能面・設計面 (主に自由度) で制限があるので十分に検討してからご利用ください。

同じリソース名を使いたい

2019/07/29 22:00 追記
開発～本番環境まで同じリソース名、例えば Lambda 関数、を使いたい場合があります。
その場合、一つのアカウントに開発～本番環境が混在しているとカオスになるだけではなく
予期せぬ事態が起こる可能性もあります。

同じリソース名を使いたい場合にはアカウントを分割するのが良いでしょう。

AWS Organizations

複数の AWS アカウントをポリシーベースで一元管理します。
企業内の複数アカウント管理に便利です。

主な特徴は以下の通りです。

• AWS アカウントをグループ化してポリシーベースで管理
• AWS アカウント新規作成
• 一括請求

こちらのスライドにある通り、OU というグループを作り
ポリシーを適用して複数アカウントを管理します。

AWS Organizations の詳細は割愛します。
上記スライドを参照ください。

まとめ

請求を分けたい、AWS 利用費を明確に区分したい場合は AWS アカウントを分割します。

ポリシーのメンテナンス性やリソース制限を考えて
本番環境は専用の AWS アカウントにすることも良いと思います。

「これが正解」といったアカウント構成は残念ながらありませんが、
企業内のポリシーや予算管理、部門間の調整をしつつ
上に示した基準で AWS アカウントを管理して頂ければと存じます。

参考

AWS サービスの制限
アカウントの管理
ボリューム割引
共有 VPC の使用
Black Belt AWS Organizations

以上、吉井 亮 がお届けしました。