SRE 統制チームの oracle です。
この記事は freee 基盤チームアドベントカレンダー の12日目になります。
今回は AWS の 組織移行を行った話をさせて頂きます。
AWS の 組織移行というのはどういうこと？と思われる方もいらっしゃるかと思いますので、正しく説明しますと、
既存の複数の AWS アカウントを構成している AWS Organizations を解体し、新規に作成した AWS Organizations にすべてのアカウントを移動させました。
となります。
その動機とアプローチについてご紹介したいと思います。
背景
AWS 組織移行する前から、freee では 数十の AWS アカウントを運用していました。運用の仕方は組織によって様々ですが、一般的にはプロダクトで分けたり、環境で分けたりすることが多いかと思います。
freee でも同様の手法でアカウントを分けていますが、ただし、プロダクトで分けてる場合と環境で分けている場合や全然分けられていないケースが混在しています。
freee に join して数年経ちますが、最初にその状況を見たときに驚いた覚えがあります。
言葉を選ばずにいうと「カオス」だと思いましたが、ただ、これを無計画にやってきた結果と簡単に片付けるものでもないとも思いました。組織とサービスの成長を予測することは当然難しいですし、そして利用している AWS 基盤自体もずっと変化、進化を続けています。規模が小さい昔であれば一つのアカウント上でやりくりすることが効率的だったと思いますし、その後も当時の効率的な選択をしてきたと思います。ただ通して見直す機会がなく続いてしまったという状況と思います。
それでもこの状況でも実際は運用できていることに別の驚きもありました。
後に、freee では IaC の文化が早くそして深く根付いていて、カオスに見える状況でもコントロールができているのではないかと考えています。
運用でカバー はカバーできる限界があります。特にどうにかしたいポイントは AWS Organizations の管理アカウントの特定リージョンに多くのワークロードがあることでした。これはいわゆるアンチパターンとなります。
- SCP の運用がうまくできず、多くのルールの制御を自前でやる必要があります。
- 一つのアカウントでリソースが増えていくと per account のハードリミットにかかるとそれ以上作成できなくなります。
- 一つのリージョンにほとんどのリソースに集中しているので、 per region のハードリミットにかかるとそれ以上作成できなくなります。
上記のペインを伴っている状態での運用でしたが、ある時ついにハードリミットの制限がかかる状況となってしまいました。リソースを整理することでなんとか乗り切りましたが、限界ははっきりと見えたことになります。
そして AWS のアカウント運用を見直すべく新しいチームが発足されました。SRE 統制チームの始まりでもあります。
実はそれより以前に Security Improvement Program を実施する機会がありまして、 Maturity Score は平均より少し高めくらいの結果でした。
より高いスコアを実現するためには統制がとれたマルチアカウント戦略を前提とした構成ではないと難しい項目が多くありました。改善しないといけない機運自体は高まりつつありました。
再設計
アカウントの分離方法は沢山ありますが、今現在の AWS の複数アカウント運用のベストプラクティスはこちらになっているかと思います。 こちらのドキュメントから得られたインサイトを紹介したいと思います。
OU について
アカウントの整理手法のガイダンスとしては基本的にワークロード指向のOU編成が推奨されています。AWS Organizations 横断のサービスはそれぞれ専用の OU (セキュリティ OU や インフラストラクチャ OU ) に所属させ、専門チームだけがアクセスできるように権限を絞る形にするのが良いとされています。基本パターンや拡張パターンをそのまま踏襲しても問題がないと判断し、近い OU 設計をしました。
組織とケイパビリティについて
OU については ワークロードの SDLCs を前提に整理することは違和感がないところかと思います。どうしてきれいに分けられなかったのか、またそもそも分ける理由はなんだったのかを改めて考えたときに、ケイパビリティベースのアプローチがとても良いインサイトを得られたと感じました。
クラウド基盤おいて一般的に必要とされる 29 個のケイパビリティを６つのカテゴリに分けています。
ケイパビリティ間の依存関係を示す図はこちらです。
ID 管理と Workload Isolation は優先して構築するべきと示しております。半年前のドキュメントでは workload isolation はもう少し後となっていましたが、やはり優先事項として変更されました。
クラウド基盤である程度の規模のサービスを構築運用する際に必要とされるこれらの機能について、 freee でも必要としているのか、またその成熟度をどれくらいまで高められているのかを分析しました。
多くの機能は freee でも実現できているものの、成熟度で見たときに足りないものも多くあります。上記の図では特に IdM と Workload Isolation はその後の各ケイパビリティに影響するものなので、高い成熟度が求められると考えられます。
freee では権限管理についてはアカウントと IdP 間の saml によるフェデレーションで制御しています。 また、Workload Isolation は IaC の中でリソースとそのリソースを操作する権限を都度 IAM Role と Policy を作成することによって実現しています。
なのでケイパビリティとしては有しているものの、アカウントが増えていく場合やリソースが増えていく場合はスケールしにくい構造となっています。ベースからの見直しが必要となってきております。
ケイパビリティの構築の順番が変わると機能の実現方法も変わるのが興味深いところです。
ホワイトペーパーの中でケイパビリティにおいての組織との関係性も考えさせられる部分が多くあります。どの機能をどのチームがオーナーシップを持つべきかを示していますが、そのようなチームがない場合や、オーナーシップを持つ自覚がない場合はケイパビリティの成熟度にも関わると考えられます。オーナーシップを持つチームがない場合はチームを発足させるという組織側の変化も必要と思います。
構築方法
設計の方針は上記のホワイトペーパーに沿った内容としています。実際に利用するツールとしてはマルチアカウント環境を構築するためを目的としている AWS Control Tower を採用しました。独立した環境で PoC から行いました。
IaC について
freee では IaC の文化が根付いております。 Control Tower をコードで管理するツールがいくつかありますので、どれを採用するかを検証しました。
結果的には AFT を採用することにしました。 terraform については freee 社内では十分な運用実績がありますし、拡張性の面ではメリットが多いという判断をしました。 CloudFormation をメインの IaC としている場合は AFC が選択となるかもしれません。
freee ではすでにある既存の terraform コードとデプロイシステムがあるので、棲み分けとして、Baseline にあたるリソースを AFT に移して管理を分離していくことを計画しています。
権限について
先述している通り AWS へのアクセスは アカウントと IdP との saml によるフェデレーションで実現していますが、各アカウント毎に設定しているため、AWS Organizations 横断での認証をこれまでは行っていませんでした。 マルチアカウント戦略を実現するために、 AWS Organizations 横断での認証方法として AWS IAM Identity Center (以降 AWS SSOと記述)と IdP との接続を新たに設定をしました。
組織においての ディレクトリサービスと AWS での権限セットを再定義する部分もあるため、既存の権限の設定をすぐに AWS SSO に移行することはまだできておらず、一部のチームの操作権限を優先的に設定を行っています。 将来的には認証認可については AWS SSO に一本化する計画をしております。
移行方法
統制ができるマルチアカウント環境を実現するブロッカーとなっていたのは、管理アカウント上に多くのワークロードがあることでした。統制を行うのに取れる手法としては、
- 各ワークロードをメンバーアカウントに移行する
- 組織 ( AWS Organizations )を閉じて新規の組織にメンバーアカウントとして入る
の二択となります。
各ワークロードをメンバーアカウントに移行するにはそれぞれの開発チームと調整し、本番環境を含む各環境を論理移行していく必要がありますが現実的ではないため後者の方法を取ることにしました。
準備期間
移行期間全体としては約10ヶ月ほどかかりました。
- フィジビリティ検証と設計のドラフト作成 - 1Q
- 旧組織の調査と移行計画策定 - 1Q
- 新旧組織の移行準備と実施 - 1.3 Q
組織移行の準備で行ったことをいくつかピックアップします。
新 AWS 組織で行った準備
- 新しい AWS 組織のための管理アカウントの準備
- サポートプランの契約
- Control tower の有効化
- OUの設定
- AFT のデプロイ
- AWS Organizations 横断サービスの有効化と設定
- セキュリティとコストに関連するサービスの設定
既存 AWS 組織で行った準備
- AWS Organizations 横断サービスの利用状況と影響の調査
- メンバーアカウントがスタンドアロンになるための請求情報の登録と電話認証
- SP や RI の適用アカウントの調査
- 移行時間を最短に行うための計画
統制の準備
AWS の 組織移行をするに当たって行ったことすべてを列挙することはできませんが、社内ではセキュリティチーム、その他の関連チームと共有や説明を行い、社外では AWS の専門の方もお招きして、移行する際の懸念事項や注意事項について打ち合わせを重ねてきました。
以前のマルチアカウント構成は AWS Organizations を有効化しているものの、利用している機能は限定的で、考慮すべきことが複雑に絡んでいるという状況ではないのでAWS の組織移行自体は大きな問題がなく完了できました。 移行直後は多くのアカウントが root 直下に存在しているだけでしたが、今は多くのアカウントを特定の OU 下に移しベースラインとなる統制がある状態になりつつあります。 まだ、やっと統制が取れる基盤を整備したに過ぎません。ガードレールの設定、権限の分離、環境の分離が今後の取り組みとなります。クラウド基盤で必要となる各ケイパビリティの成熟度をあげていくのはまだまだこれからとなります。
AWS でマルチアカウント戦略をこれから行っていきたい方の参考になれば幸いです。
