Help us understand the problem. What is going on with this article?

AWS導入前に知っておきたかった「AWSアカウント設計」

More than 1 year has passed since last update.

1.はじめに

みなさんAWSのアカウント設計はどのようにしていますか?

AWSを使ってシステムをセキュアに開発・運用していくためには、
AWSアカウント(*)の設計が重要になりますよね。

AWSアカウント1つのみで運用されてる方は、誤操作や、
誰にどの権限を与えるかのポリシー設計等で困る方もいらっしゃるのではないでしょうか。
(私もその一人です。)

本内容は、『Amazon Web Services 業務システム設計・移行ガイド』にも載っているので、
悩んでる場合は、購入をおすすめします!(こちらの書籍と実体験を元に書いてます。)
今回はAWSアカウント設計について、パターン別にメリット・デメリットを書いていこうと思います!

(*)AWSアカウントとは、AWSを使用するためのマスターアカウントのことを指しています。
※IAMユーザーとは別物です!

2.AWSアカウント設計パターン紹介

本章では、アカウントの設計パターンを3つに分けてメリット・デメリットを書いていきます。
①アカウントを分割しないパターン
②環境ごとにアカウント分割パターン
③システム、環境ごとにアカウント分割パターン

※.ECサイトと分析基盤のシステムがあり、環境は本番/検証/開発環境があるとして書いていきます。

2-1.アカウントを分割しないパターン

こちらは、以下の図2.1 のように、AWSアカウントを分割せず、
VPCごとに環境を分割するパターンです。

unnamed-2.png
図2.1 アカウントを分割しないパターン

◯メリット

・3パターンのうちコストが一番安価
 →NATゲートウェイや Direcr Connect 、AWSサポートを一つにまとめることができる

△デメリット

・IAMポリシーが複雑になる
 →コードを書くのも、管理するのも手間がかかります。
・3パターンのうち誤操作をする確率が最も高い

2-2.環境ごとにアカウント分割パターン

こちらは、以下の図3.2 のように、環境ごとでAWSアカウントを分けるパターンです。

unnamed.png
図2.2 環境ごとにアカウント分割パターン

◯メリット

・環境ごとのコスト管理が容易になる
・マネジメントコンソール上に別環境のリソースが表示されなくなる
 →同環境のリソースは表示されますが、別環境に対する誤操作のリスクがなくなります。

△デメリット

・リソースの数が増え、アカウントを分割しないパターンよりコストが高くなる
 →NATゲートウェイ等のリソースが3環境分必要となり、コストが高くなります。
  また、ハイブリッド(オンプレ+クラウド)環境の場合、Direct Connectのコストも3環境分必要となります。
・AWSサポート料金がアカウントを分割しないパターンより高い
 →3環境分契約することになるため、価格は上がる可能性があります。
・アカウントを分割しないパターンより管理に手間がかかる
 →環境ごとにロールの変更が必要となるため、少し手間が増えます。

2-3.システム、環境ごとにアカウント分割パターン

こちらは、以下の図2.3 のように、システムと環境ごとでAWSアカウントを分けるパターンです。
書籍でもこちらをおすすめしていました!

pasted image 0.png
図2.3 システム、環境ごとにアカウント分割パターン

◯メリット

・システムごとのコスト管理が容易になる
・マネジメントコンソール上に自分が管理していないリソースが表示されなくなる
 →誤操作の確率がぐ〜んと下がります。これほんとに嬉しいです!
・IAM ポリシーの管理が楽になる
 →複雑なIAMポリシーを作成する必要がなくなる上に管理工数が下がります!

△デメリット

・リソースの数が増え、コストが高くなる
 →NATゲートウェイ等のリソースが複数必要になることがあります。
  また、ハイブリッド環境の場合、Direct Connectも複数必要です。
・AWSサポートの料金が環境ごとにアカウント分割パターンよりも高い
 →各AWSアカウントごとの契約となるため、価格が上がリます。
・管理に手間がかかる
 →ユーザーの切り替えや、AWSアカウントごとにIAMユーザーを作成する必要があるなど。
  (IAMユーザーであれば、CloudFormationで自動化すれば解決できます。)

3.まとめ

AWSアカウントの分割パターンをメリット・デメリットと共にを3つあげました。
「2-3ではコストが高い」や「2-2よりもう少しセキュアにしたい」等、
場合によって、2-1と2-2の間や、2-2と2-3の間というパターンもあるかもしれません。
コストとリスクを考慮した上で決めていくのが良いと思います!

個人的には、システムを一番セキュアに運用できる
"システム、環境ごとにアカウント分割パターン"がおすすめです。

また、AWSアカウントを増やす場合、AWSアカウント自体を管理するための
「AWS Organizations」というサービスがあります。

こちらの活用もおすすめします。
公式ドキュメントのリンクも貼っておきますので、気になる方はチェックしてください。

◯AWS Organizationsとは
https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_introduction.html

今回はこの辺りで!!
お読みくださりありがとうございました!!

4/8 追記

アカウントを分割しても「Shared VPC」を使用すれば NAT Gateway は共有できるようです!
同一の Organization にいる必要がある等の条件がありますので、以下URLをご参照ください!
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-sharing.html

また、Direct Connectもアカウント間で共有できるようになるそうです!
条件等は以下をご参照ください!
https://aws.amazon.com/jp/about-aws/whats-new/2019/03/announcing-multi-account-support-for-direct-connect-gateway/

takuya_tsurumi
インフラエンジニア/AWS/Azure フルスタックエンジニアを目指しています。 機械学習/Node.js/react.js/OAuth 勉強中です。
is-tech
大手優良企業特化型システム内製支援事業。ご連絡は https://www.is-tech.co.jp/ の問い合わせフォームをご利用ください。
https://www.is-tech.co.jp/recruit/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした