こんにちは!
みなさま、AWS でマルチアカウントをうまく活用できておりますでしょうか?今回はマルチアカウントな運用方法にどのぐらいのメリットがあるのか、ベストプラクティスをご紹介しながら語っていきます!
読み応えたっぷりですのでぜひ最後までお付き合いください!
マルチアカウントで AWS を運用するのって何がお得なの?と思われる方もいらっしゃるのではないでしょうか?
そのためマルチアカウントを語る前に、いくつかのメリットを確認しておきましょう。
管理が楽になったり、セキュリティが向上したりすることが、マルチアカウントを運用する主なメリットになります。
では次にデメリットにも触れてみましょう。
複数の AWS アカウントを運用するので、当然のデメリットとなります。これらを事前に理解したうえで、マルチアカウントの運用を考えていきましょう。
ベストプラクティスを語る前に、マルチアカウントの運用で利用する3つの AWS サービスをご紹介させてください!
この3つをうまく活用することがある種のベストプラクティスにもなりますので、ぜひひとつずつお読み頂ければと思います。
AWS Organizations はマルチアカウントの管理に必須の AWS サービスです。これを利用することにより、一括請求の管理、AWS アカウントの組織化、アカウント単位のポリシー設定を行うことができます。
また、AWS Single Sign-On や CloudFormation StackSets を利用するには、AWS Organizations を有効にしていることが前提条件となりますので、マルチアカウントの管理において必要不可欠の存在となります。
AWS Single Sign-On、以下略して AWS SSO は、その名の通り複数の AWS アカウントなどに対してシングルサインオンを行うことができます。もちろん AWS 以外のサービスにも利用することができます。
マルチアカウントで運用する場合のユーザー管理に必須のサービスとなります。具体的なベストプラクティスは後述いたします。
各アカウントごとに必要なリソースを手動で作成するのは少々面倒です。そんなときに CloudFormation StackSets を利用します。これを用いることで、各アカウントに必要な共通のリソースを簡単にデプロイできます。
それではマルチアカウントの運用におけるベストプラクティスをご紹介いたします。ぜひ参考にしてください。
AWS Organizations は組織( OU )を作成して、その配下に AWS アカウントを置くような形で組織ディレクトリを作成していきます。組織ディレクトリは最大 5階層まで作成することが可能です。
この組織ディレクトリを設計するうえで大切なのが、AWS アカウントを目的ごとに作成するということです。例えば、本番・開発などの環境別に作成したり、組織の部門別に作成したりします。
リソースが増えて誤ってほかのリソースを操作しそうだからもうひとつ作ろう、コストを節約するためにチーム内で3つぐらい持っておこう、こういった考えは望ましくありません。
SSO ユーザー管理のタスクが余計に増えたり、AWS アカウントごとの目的がよくわからないまま運用してしまったりするため、AWS アカウントは必ず目的に応じて作成しましょう。
マルチアカウントでは、AWS SSO ユーザーを利用することがベターです。これには主に2つの理由があります。
1つ目は、ユーザー管理を複雑にしないためです。AWS SSO を有効にした状態では IAM ユーザーを作成しなくても、AWS SSO ユーザーでユーザー作成やアクセス管理ができるので各アカウントでの IAM ユーザーは不必要となります。
権限セットと呼ばれるロールやグループにユーザーを分けることで、アクセスできる AWS アカウントに制限を加えたり、必要な権限を制限できたりするので、マルチアカウントの運用では AWS SSO を主に利用しましょう。
2つ目は、個人にアクセスキーを持たせないためです。通常 AWS アカウントでIAM ユーザーを作成すると、個人の操作でアクセスキーを作成できます。ですがこの運用方法では、アクセスキーを不正利用されてしまう可能性を残してしまうことになります。例えば、社員が退職したあとに管理者が IAM ユーザーを削除し忘れていた場合、作成したアクセスキーは有効のままですので危険です。
この問題を解決するのが AWS SSO でのユーザー管理となります。AWS SSO では以下のようにユーザーに対して一時的なアクセスキーを発行します。
このアクセスキーは最大で12時間の有効期限を設定できます。運用上、毎回 AWS で作業するたびに認証情報のセットが必要となりますが、セキュリティ向上のメリットもあります。
例えば CloudFront で HTTPS を利用する場合、ACMが us-east-1 リージョンに1つ必要です。すべてのアカウントで CloudFront を利用する場合、すべてのアカウントにひとつずつ ACM が必要ということになります。
こういった各アカウントで共通しているリソースなどは積極的に Cloud Formation StackSets を利用して、手動での作成を回避しましょう。なおデプロイ先の AWS アカウントは選択できますので、その点はご安心ください。
また serverless framework や Terraform などを利用している方は、各環境ごとに必要なものはすべてデプロイしているので必要がないという場合もあります。
そのため何を CloudFormation StackSets で作成するのかは、マルチアカウントの運用ルールを決めてから利用したほうがよいかと思います。作成前に AWS リソースのコード管理について整理しておきましょう。
AWS Organizations にはサービスコントロールポリシー(以下、SCP )と呼ばれるアカウント単位でのポリシーがあります。これを活用することでヒューマンエラーを防ぐことが可能です。
例えば、東京リージョン以外でリソースを作成させたくない場合などには、以下のように制限をします。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllOutsideEU",
"Effect": "Deny",
"NotAction": [
"cloudfront:*",
"iam:*",
"route53:*",
"support:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"ap-northeast-1"
]
}
}
}
]
}
このようにして作成した SCP を、アカウントや組織( OU )ごとにアタッチすることで AWS アカウント内での操作を制限することが可能となります。なお、組織( OU )にアタッチした場合は、配下の AWS アカウントすべてに適用されるので注意してください。
また例え Administrator のアクセス権限が割り当てられているユーザーであっても、SCP の内容が優先されますので、その点も踏まえて制限を設けるようにしましょう。
利用されている環境にもよりますが、Route53 を利用している場合に複数のAWS アカウントで同じ Route53 のホストゾーンが必要な場合などがあると思います。そんなときはメインの Route53 のみにホストゾーンを作成し、各アカウントで作成したリソースのレコードを登録することで運用していきましょう。
以下の図をご覧ください。
上記のようにメインの AWS アカウントの Route53 にレコード登録を集中させることで、各アカウントで Route53 を利用することができます。
設定方法は簡単です。特別なことは何もせずに、別アカウントで作成した AWS リソースのレコードを、Route53 に登録するだけです。
上記の図で言うと、dev1 環境に作成した CloudFront と ACM のレコード情報を控えたあと、prd 環境の Route53 でレコードを作成します。これにより設定したドメイン名にトラフィックが通るようになります。
Route53 は外部のレコードも登録できるので、アカウント内に登録する AWS リソースがなくてもレコード情報が間違っていなければ問題ありません。
記事の執筆時点では、東京リージョンで利用できませんが、マルチアカウント運用のベストプラクティスを知らなくても簡単に作成できる AWS サービスがあります。それが AWS ControlTower です。
簡単にまとめると以下のような特徴があります。
自動でマルチアカウント環境を作成してくれる!といえば聞こえはよいのですが、作成されるリソースやマルチアカウントの設計をある程度理解していないと、知らぬ間に不要なリソースを持ってしまい余分にコストがかかってしまう可能性がありますので、その点はご注意ください。
ここで述べている不要なものというのは、ログアーカイブ用と監査用の AWS アカウントを作成したり、いつくかのルール( AWS ControlTower ではガードレールを指す)を作成したりすることを指しています。
東京リージョンにまだ対応していないことと、マルチアカウント運用への理解および AWS ControlTower への理解が必要なことから、現時点においては慎重に検討されたほうがよいかと思われます。こちらは今後のアップデートや東京リージョンの対応に期待ですね。
今回はマルチアカウント運用についてのナレッジを出し惜しみせず執筆いたしました。ぜひ参考にしていただければ幸いです。
このブログでは、マルチアカウント運用以外にも、AWS のサーバーレスサービスについての記事をどんどん公開しておりますので、ご興味のある方はほかの記事もご覧いただければと思います。
マルチアカウントの運用に関する設計は、お気軽にお問い合わせください。
スモールスタート開発支援、サーバーレス・NoSQLのことなら
ラーゲイトまでご相談ください
低コスト、サーバーレスの
モダナイズ開発をご検討なら
下請け対応可能
Sler企業様からの依頼も歓迎