Zenn
🤹‍♀️

AWSのアカウント戦略を考えてる。

2023/06/25に公開
AWS
idea

はじめに

この 1 年でかなり AWS の勉強をした。その中で AWS のアカウントを適切に設定するだけで、組織の技術力は大きく向上すると考えている。人は失敗するたびに強くなるなら、リソースを素早く作って壊して捨てられるクラウドはそれに最適だと思う。その一方で適切に AWS アカウントを設定しないと、本番で動いているサービスの横で初心者がサーバをぶっ壊しているというヒヤヒヤする状況にも陥る。AWS アカウントで工夫をして、本番環境は安全に、開発環境は柔軟に、初心者には自由な環境を作りたい。

この記事では、私がこれに関して Web 上で探したいくつかのトピックを紹介する。当然、AWS のアカウント戦略のベストな解は業種や組織や時代によって大きく変わってくる。どう構築するかは今のあなたの組織次第だと思う。

多分よくある事例

この paiza の事例[1][2]は結構よくあるパターンだと思う。内容としては 2013 年頃から AWS を使っていて、単一の VPC で複数の EC2 を用いたサービスを運用しており、本番環境とテスト環境も同居している状態で、ネットワークリソースも管理がされてなくて誰が作ったかわからないセキュリティグループやらサブネットやらが大量にあった。これを別の AWS アカウント作って綺麗にしましたって話。

AWS はサービスの性質上、オンプレでの運用経験を前提にスモールスタートで段々とサービスを拡張していった組織が多いと思う。そういう組織だと CloudFormation とか書かずに GUI で構築するので、数年経って人が入れ替わって設定をもういじれない環境に困ってたりする組織も多いと思う。また、AWS に早くから取り入れた組織ほど、当時はその構築が最適解だったとしても今から見返すと古臭くなっていて刷新が求められてたりする。特に AWS Organizations を用いたマルチアカウントを用いて環境を分離する戦略はついていけてない組織も多いのかなと思っている。

こういう状況だと初心者は AWS を触れないから成長できないし、新しいサービス作ろうにも検証環境すら作りづらい。AWS アカウント内のリソースの混沌が組織そのものの成長を妨げてしまっている状態だと思う。こういう状態はなくしたいよね。

私がマルチアカウントで実現したいこと

思いつく限り実現したいことを挙げてみた。多分もっといっぱいある。

  1. 複数の AWS アカウントに対して single sign on できる。
  2. タグ付けポリシーが強制されており、誰が作ったかわからないリソースを極力減らす。
  3. どのチームのどのリソースが最もコストを使っているのかを可視化し、後から分析して改善できるようにする。
  4. 環境はしっかり分離。特に本番と開発は分離されていて欲しい。また全く依存関係がないサービスも AWS アカウントは分離していて欲しい。
  5. 社内のルールは全てのアカウントになるべく自動で適用され、守ってなかったら自動修復もしくは通知が飛ぶ。
  6. 複数の AWS アカウントで運用されているサービスは、ログが一つのアカウントから見れるようになっていて、そこで監視できる。
  7. 分析用のデータは複数の AWS アカウントの S3 に分散させるのではなく、一つの AWS アカウントで見れるようにする。
  8. 初心者がサーバーを壊せる AWS 環境。
  9. 組み込みエンジニアとかデータサイエンティストとか 全く AWS の知識ない人も Linux サーバーだけは作って触れるようにしたい。

上記いくつかは Control Tower を用いて設定すれば簡単に構築できる。

AWS のおすすめ

AWS が出してる以下の記事は非常に興味深い。

https://aws.amazon.com/jp/blogs/startup/multi-accounts-and-control-tower/

内容としては Control Tower を使いましょうって話。大きな企業で数百人が働いてる状態の人たちは AWS アカウントを適切に分離した方がいいのは当然として、小さいベンチャー企業であっても Control Tower を使ってアカウントを分離した方がいいよと書いてある。

前章で挙げた課題のうちいくつかについても Control Tower を用いて設定すれば簡単に解決できる。Control Tower の利用料金はほぼ無料（自動で CloudTrail が有効になるので、 １ AWS アカウントあたり 30 円/月はかかる）なので、AWS アカウント作ったらはじめに Control Tower でマルチアカウントにすると良いと思う。本番で動いているサービスがある状態で Control 　 Tower を有効化したい場合は、別でアカウント作って Control Tower を設定した後で、本番で動いているアカウントを所属させるという手続きが必要になるので、なるべくなら最初から有効化しておいた方がいい。

また、AWS は他にもマルチアカウント戦略を推奨する記事を出している[3][4]。これらも参考にしてほしい。

関連する AWS のサービス

この章では AWS のいくつかのサービスについて、マルチアカウント戦略を考える上で設定してみたい機能を紹介する。思いつく限り挙げてみただけなので、これ以外にも設定すべき項目は沢山あると思う。基本的には組織の成長に合わせて少しづつ設定していく性質のものだと思う。

AWS Control Tower

これを有効化すると AWS Organization や IAM Identity Center などがベストプラクティスに従って自動的に設定される。この管理画面から新しい AWS アカウントの作成やベストプラクティスに従った設定を選択できる。仕組みは CloudFormation StackSets を用いて複数の AWS アカウントに同じリソースを自動で作成している。この StackSets は CloudFormation の画面から確認できる。

Control Tower を有効化することで IAM Identity Center が設定されるので以下が可能になる。

  • 一つの画面から複数の AWS アカウントにログインできるようになる。MFA も設定可能。
  • マネージメントコンソールにログインするための IAM ユーザーや、AWS CLI を使うためだけの IAM ユーザーは不要になる。
  • CodeWhisperer の Professional も使えるようになる。

AWS Organizations

複数の AWS アカウントについてポリシーを適用し請求を一括に出来る。ここで設定したポリシーは組織全体で適用できるので、会社のコンプライアンスで確実に守るべき設定はここでしておくと、同じ設定を何度もする必要がない。主に以下のポリシーを設定できる。

  1. Amazon の AI 系サービスについて、データを Amazon でモデル学習に使われないように制限出来る。[5]
  2. AWS Backup の設定を複数アカウントに適用可能。
  3. 使えるサービスを制限できる。東京と大阪リージョン以外でリソースを作成できないみたいな設定が可能。[6]
  4. タグポリシーを設定して、タグ付けを強制することが可能。タグ付けは AWS のコストを下げる上で重要になるから、複数チームで AWS を使う場合は制度作った方が良い。

以下、Tips。

  • GuardDuty, Security Hub, Firewall Manager, Personal Health Dashboard を中央アカウントで管理
  • リソースベースポリシーの条件に Organization の ID を書く。
  • Resource Access Manager で Organizations にリソースを共有出来る。Transit Gateway を複数の AWS アカウントに共有するにはこれを用いる。

その他

CloudFormation の tips

  1. CloudFormation のスタックのドリフト機能で、定義したファイルと手動で変更してしまったリソースの変化を検知出来る。
  2. CloudFormation StackSets は複数の AWS アカウントに跨ってリソースを共有できる。

S3 の Tips

  1. アクセスコントロールリストで別のアカウントから object のアップロードを許可して実際に別のアカウントからオブジェクトがアップロードされた場合、そのオブジェクトをバケットの所有者が変更できなくなる可能性がある。基本的にはアカウントを跨いだオブジェクトの共有はロールを使うと良い。
  2. S3 Storage Lens で S3 の使用量を簡単に分析できる。S3 の料金が高いなと思ったらこれで分析してゴミを削除すると良い。

おわりに

この記事では AWS のアカウント戦略について考えた。コードを書いた瞬間に技術的負債になるのと同様に、AWS のリソースも作成した瞬間から技術的負債になる。AWS は最初にリソースを作るのはすごく簡単だけど、その先でそのリソースを技術的な負債として抱えてくのはそこまで簡単ではないと思う。サービスの利用初期に楽であることは将来の楽を全く保証してくれない。最初楽だから大量に作るけど、それが未来永劫反映するためにはなるべく初期段階で制度を作って強制しておかないと後々に痛い目に合うと思う。

まあ、AWS のマルチアカウント戦略が楽に構築できるようになってきたのってここ 3,4 年だから、それ以前に作った制度は若干レガシーになってると思う。そういう組織は、混沌とした AWS アカウントと一緒に制度も改修する必要があると思う。

脚注

  1. https://zenn.dev/paiza/articles/yukimura_infra_renewal_1 ↩︎

  2. https://zenn.dev/paiza/articles/yukimura_infra_renewal_2 ↩︎

  3. https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/organizations.html ↩︎

  4. https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/aws-account-management-and-separation.html ↩︎

  5. https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out_syntax.html?icmpid=docs_orgs_console ↩︎

  6. https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_general.html ↩︎

Discussion