AWS Startup ブログ

スタートアップにおけるマルチアカウントの考え方と AWS Control Tower のすゝめ

こんにちは、スタートアップ ソリューションアーキテクトの松田 (@mats16k) です。

今回のテーマはマルチアカウント(複数の AWS アカウントの利用)です。近年セキュリティやガバナンスの強化を目的にマルチアカウント構成で AWS を利用されているお客様が多くいらっしゃいます。また、AWS もマルチアカウントでの運用を推奨しており、関連する多くのサービスや機能がリリースされています。

一方で、マルチアカウントに関する作業や知見はプロダクトの価値向上に対して直接的な影響を与えることが少なく、結果として対応や検討が後回しになっているスタートアップも多いのではないでしょうか。今回は特にシード・アーリーステージのスタートアップ向けに、マルチアカウントに対する考え方と、簡単に環境をセットアップする方法をお伝えします。

目次

なぜマルチアカウント?

既に多くの場所で議論がなされているため細かくは本記事で触れませんが、主にビジネス・事業上の要件に対応するために多くの企業がマルチアカウントに移行しています。メインの課題や目的は企業によって様々ですが、下記の4つに大別出来るかと思います。

初期のスタートアップにおいてはプロダクト開発や機能追加に比重が置かれるケースが多くありますが、皆さんが真に作り上げているものはビジネスであり事業です。AWS もデベロッパー向けのサービス・機能だけでなく、ビジネス上の課題・要件を満たすために有用なサービスや機能を提供・拡充しています。そういった観点で本記事および関連資料を見ていただくと良いかと思います。

関連資料

 

スタートアップこそマルチアカウント運用に備えるべき理由

これから MVP を作ろうとしているような初期の段階に必要かというと、そうではないかも知れません。ですが多くの場合、マルチアカウントが必要ではないと感じさせる理由は「その瞬間の手間だけ」です。私は、ほぼ全てのスタートアップにとってマルチアカウントは有用である考えています。より正確に言うと、全てのスタートアップが(出来るだけ早く)マルチアカウントでの運用に備えるべきと考えています。これは皆さんが想像しているよりずっと早く必要となるシーンが訪れるからです。ここではスタートアップがマルチアカウント構成に備えるべき理由についてお話します。

 

スタートアップの成長と意思決定の爆発的な速さ

スタートアップの特徴の一つにその成長の速さがあるかと思います。私もスタートアップ入ったばかりの頃はその展開の速さに驚いたのを覚えています。これは特徴であると同時に競争力の源泉であったりもするわけですが、その速さ故に問題が起こることも少なくないかと思います。

突如プロダクトのラインナップが増えたり、検証用の環境が必要になることもあるでしょうし、契約先のエンタープライズ企業の要求や各種認証の取得のために、突如セキュリティの水準を上げなければならないケースもあるかと思います。また、成長に合わせて社員もどんどん増えていくため、誰がどこにアクセスしてよいかなどを適切に管理する必要性も増えてくるでしょう。

つまり、上であげたような「環境の分離」「請求の分離」「権限の移譲」「ワークロードの分離」といったことの必要性が急に出てくるわけです。都度 AWS アカウントを作ることも可能ではありますが、無秩序に増える AWS アカウントの管理が難しいことは容易に想像できるはずです。

参考:スタートアップがAWSを使う時にやりたいこと(アカウントとユーザー管理編) – AWS Startup Tech Meetup #2

逆にこのあたりが整っていると、ビジネスの成長を阻害すること無く開発に集中することが出来ます。後述する Account Factory を利用することで、開発者がセルフサービスで AWS アカウントを作成でき、作成した AWS アカウントを自動的に AWS Organizations や AWS SSO の配下に参加させることも出来ます。

 

全てのスタートアップは将来のエンタープライズ企業

ここまでスタートアップ企業を前提に話を進めてきましたが、多くのスタートアップ企業は短期間に爆発的な成長をした後に、バイアウトや IPO などなんらかの形で Exit を目指します。つまりパブリックカンパニー(もしくはそのグループ企業)になるということです。その様な未来を見据えて、セキュリティやガバナンスの強化がしやすい土壌を作っておくことは重要ではないでしょうか。

一方で、将来のために貴重なリソースを投資すべきかというと、なかなか難しいことも理解しています。そこで今回は表題にもある AWS Control Tower を用いることで最小の工数で、マルチアカウント環境を整備することについて解説します。

 

シングルサインオン前提のサービスが増えている

厳密にはマルチアカウント環境の整備とは直接関係がありませんが、付随してシングルサインオンの環境も整備することになるかと思います。企業によって利用状況が異なるかと思いますが、Amazon SageMaker StudioAmazon ConnectAmazon QuickSight などシングルサインオンの利用を前提にしている or シングルサインオン基盤があるとより便利に使えるサービスが増えています。(AWS SSO-integrated applications をご覧ください。)マネージドサービスを有効活用してビジネスをドライブするために、シングルサインオンの環境が早期に整っていることはプラスに働くかと思います。(また、AWS SSO は AWS 以外のサービスの Identity Provider としても機能します。

 

マルチアカウント構成に必要なもの

複数の AWS アカウントを利用している場合、どこでどのアカウントを利用しているといったことの管理の他に、開発者アカウントの管理やそれぞれの AWS アカウントで運用が適切に行われているかといったことも管理する必要があるかと思います。幸い AWS にはこれらの管理を支援するサービスが多く揃っています。

開発に直結しないセキュリティ・ガバナンス領域でこれだけのサービスが揃っていることは AWS を利用する大きなメリットの一つではあります。一方で、これらのサービスを理解し組み合わせて運用することを考えるとなかなかハードルが高く、リソースの少ないスタートアップにおいて後回しになってしまうことも多いのではないでしょうか。次のセクションでは、これらの設定のハードルを大幅に下げる AWS Control Tower についてお話します。

 

AWS Control Tower のすゝめ

AWS Control Tower は簡単にマルチアカウント環境を整備できるサービスです。AWS Control Tower はお客様に代わって上記の各サービスの設定を行います。お客様は AWS Control Tower を有効化し約60分待つだけで、マルチアカウント環境を整備することが出来ます。お客様がやるべきことは、有効化するリージョンの選択と各 AWS アカウントに割り当てるメールアドレスを設定するだけです。

AWS Control Tower の動作イメージ図

これだけ聞くと、勝手に設定が行われて既存環境に悪影響が出たらどうしよう、、その様に感じる方もおられるかもしれません。原則その様なことはないのですが、なぜ大丈夫であるかを理解するためにも最低限知っておくべきことについて触れておきます。

 

最低限知っておくべきこと

AWS Control Tower が行う設定は、AWS Control Tower の動作に必要なものだけ

原則として現在行うことが出来ている操作を妨げるような設定はされません。一部操作を制限する Service Control Policies (SCPs) が設定されますが、これは AWS Control Tower の動作上必要な Amazon S3 バケットの削除を制限したり、AWS CloudTrail の無効化の制限や監査用の AWS アカウントへのログの集約の設定変更を制限するためのものです。

 

多くのガードレール(設定)は選択制

上記の通り AWS Control Tower が行う設定は最低限動作に必要なもののみです。それ以外のものについては選択制となっています。

内容を確認して選択したもののみ適用でます。また、事前に動作が「予防」「検出」なのか分かるため、影響度も分かりやすいかと思います。(選択した内容を満たすように AWS ConfigSCPs が設定されます。)

 

AWS Control Tower が作成する共有アカウントについて

AWS Control Tower を有効化した AWS アカウントは全体の「管理アカウント」となりますが、AWS Control Tower はそれ以外に「ログアーカイブアカウント」と「監査アカウント」を作成し、専用の OU (デフォルトでは “Security”という名称)の配下に入れます。これらの AWS アカウントは管理用であるため、このアカウント内に皆様のサービス/プロダクトで利用する AWS リソースを作らないように注意してください。

参考:共有アカウントとは何ですか – AWS Control Tower のしくみ

 

ワークロード用の AWS アカウントを作る際は Account Factory を利用する

AWS Control Tower を有効化すると、Account Factory が利用出来るようになります。Account Factory から AWS アカウントを作ることで、AWS Organizations や AWS SSO の設定、上記ガードレールの適用を自動化することが出来ます。また、開発者にアカウント作成の権限を移譲することも可能です。

 

AWS Control Tower を利用する際の Tips

ここでは Must では無いものの、AWS Control Tower を利用する上でやっておくべきことについてお伝えします。

 

アカウントのEメールアドレスにはエイリアスを利用する(利用できる場合)

AWS アカウントを複数管理していると、それぞれに登録されているEメールアドレスも管理する必要がありますが、このEメールアドレスには重要な連絡がいくことがあります。管理を簡素化するために、お使いのメールサービスでエイリアスの機能が使える場合には aws@example.com のような開発者向けの ML を作成した上で、

  • aws+management@example.com
  • aws+log-archive@example.com
  • aws+audit@example.com
  • aws+service-abc@example.com

のようなエイリアスのEメールアドレスを各 AWS アカウントに設定することをおすすめします。

 

現在ワークロードが動いている AWS アカウントで AWS Control Tower を有効化しない

前述の通り、AWS Control Tower を有効化したアカウントは全体の「管理アカウント」となります。管理アカウントではワークロードを動かさないことが推奨されるため、別途 AWS アカウントを取得し AWS Control Tower を有効化することをおすすめします。

 

AWS SSO を自社の ID 基盤と連携する

AWS SSO にはユーザーアカウントを管理する機能が備わっており、これにより誰がどの AWS アカウントにアクセスできるか細かく制御することができます。一方で皆さんの会社には Active Directory や Google Workspace といった ID 基盤があるのではないでしょうか。AWS SSO は Active Directory外部の Identity Provider と連携して認証を行う機能があるため、アカウントの二重管理を避けるためにも設定することをおすすめします。

参考:Connect to your external identity provider – AWS Single Sign-On
参考:How to use G Suite as an external identity provider for AWS SSO – AWS Security Blog

※ AWS SSO は System for Cross-Identity Management (SCIM) を介した ユーザーの自動プロビジョニング をサポートしていますが、Google Workspace では正式にはサポートされていません。サポートされるまでユーザー/グループを手動作成するか awslabs/ssosync を利用する必要があることに注意してください。

 

AWS CLI やその他ツールも AWS SSO を介して利用する

AWS SSO を介してのマネジメントコンソールへのログインは内部的に IAM Role が利用されており非常にセキュアです。この恩恵を AWS CLI でも受けることが出来ます。詳しくは「AWS Single Sign-On を使用するための AWS CLI の設定」をご覧頂ければと思いますが、aws sso login --profile xxx というコマンドを実行することでブラウザにリダイレクトされ、 AWS SSO の認証情報を元に一時的なアクセスキーを取得することが可能です。

AWS Amplify CLI など、一部のツールにおいてネイティブで AWS SSO に対応していない場合は aws-sso-util の利用を検討してみてください。~/.aws/configcredential_process を追記することで同様の利便性を得ることが出来ます。

設定例

[profile xxx]
credential_process = aws-sso-util credential-process --profile xxx
sso_start_url = https://example.awsapps.com/start
sso_region = ap-northeast-1
sso_account_id =123456789012
sso_role_name = AWSAdministratorAccess
region = ap-northeast-1
output = json

aws-sso-util は AWS の公式ツールではありません。確認の上ご利用ください。

 

AWS SSO のログインセッション有効期間を変更する

AWS Control Tower 経由で設定される AWS SSO のログインセッションの有効期間の初期設定は1時間となっています。不必要に長く設定することはおすすめしませんが、開発中にセッションが切れ、不便に感じられることもあるかと思います。ログインセッション有の効期間は変更可能となっているため「Set session duration」を参考に最適な値に変更頂ければと思います。

 

初期は OU を作り込みすぎない

OU 設計については「AWS Organizations における組織単位のベストプラクティス」を参考にして頂ければと思います。一方で、OU は後からも設定を変えることが可能です。変に複雑な構成になるぐらいであれば、運用しながら要件を洗い出し、後ほど OU を再設計するのも一つの手です。まずは「Production starter organization」を参考に下記のようなシンプルな形から初めてはいかがでしょうか。

Example production starter organization

 

よくある質問

AWS Control Tower の有効化、設定は大変ですか?

AWS Control Tower の利用開始は非常に簡単です。有効化にあたって最低限必要な設定は「ホームリージョンの選択」と「ログアーカイブ用、監査用の AWS アカウントで利用するメールアドレスの指定」だけです。有効化後は約60分ほどで設定が完了するのでお待ち下さい

AWS Control Tower 利用の大まかな流れ

  1. AWS Control Tower を有効化する
  2. (約60分待つ)
  3. Account Factory でワークロード用のアカウントを作成・追加する
  4. (自動的に AWS Organizations, AWS SSO 配下に追加され、ガードレールが適用される)
  5. (必要に応じて)任意のガードレールを適用する

 

現在利用している AWS アカウントで AWS Control Tower を有効化すると稼働してるプロダクトに影響出たりしませんか?

前述の通り、多くのガードレールは選択制です。一部操作を制限する Service Control Policies (SCPs) が設定されますが、AWS Control Tower の動作上必要なものであり、原則お客様がプロダクト用に利用しているリソースには影響しませんが、ガードレールにより設定される Service Control Policies (SCPs), AWS Config の内容はコンソールやドキュメントで確認できるため、事前にご確認頂くのがよいでしょう。

 

AWS Control Tower で作ったマルチアカウント環境に、既存の AWS アカウントを参加させることは出来ますか?

可能です。詳しくはドキュメントの「既存の AWS アカウントを登録する」参照してください。

 

AWS Control Tower を有効化する際、ホームリージョンはどの様に選べばいいですか

ホームリージョンは AWS SSO のエンドポイントが配置されたり、ログアーカイブ用のアカウントがログを集約するリージョンとして利用されます。「ランディングゾーンのセットアップに関する管理上のヒント」にも記載がありますが、最も使用する頻度が高い AWS リージョンをホームリージョンに選択して頂ければと思います。

※ ホームリージョンの変更は出来ません。(2021-08-25 時点)

 

AWS Control Tower の料金はどの様になっていますか?

AWS Control Tower の料金」にも記載のとおり AWS Control Tower 自体の利用に費用はかかりませんが、ランディングゾーンやガードレール内で利用されている AWS Service Catalog, AWS CloudTrail, AWS Config, Amazon CloudWatch, Amazon SNS, Amazon S3 などのサービスの料金は使用量に基づいて発生するので留意してください。

 

まとめ

いかがでしょうか。AWS Control Tower を利用することで簡単にマルチアカウント環境を整備できることが伝われば幸いです。AWS Control Tower を有効化しベースとなる環境を作る設定自体は数分で出来るので是非試してみてください。新規に取得した AWS アカウントを利用すれば比較的試しやすいかと思います。

AWS アカウントが増えるということ自体はそう頻繁に発生するものでは無いかと思いますが、増えた AWS アカウントの管理は日々の業務の煩雑さを増長します。AWS Control Tower を利用することで事業成長に伴う管理運用上の負荷を軽減し、事業にフォーカスできるスタートアップが増えることを願っています。

 

このブログの著者

Kazuki matsuda

松田 和樹 (Kazuki Matsuda) @mats16k

コンテナやビッグデータが得意分野なスタートアップソリューションアーキテクト。好きなサービスは AWS AmplifyAWS App Runner