ココナラのAWS Organizationsを再構築しよう
こんにちは。
株式会社ココナラのシステムプラットフォーム部インフラ・SREチームのかたぎりと申します。
今回はAWS Organizationsを再構築した話のご紹介です。
経緯
弊社では複数のAWSアカウントを管理・運用しており、メインとなるアカウント（Main Account）をAWS Organizations（Org）の管理アカウント（Payer）、他をメンバーアカウント（Linked）として配下に置く体制で運用しています。ココナラプロダクトはMain Accountに集約されています。
ココナラプロダクト以外にココナラ法律相談、ココナラエージェント、ココナラスキルパートナーズと複数プロダクトがあります。ここ数年で複数事業が立ち上がっていることもあり、このタイミングで事業ごとにAWSアカウントをわけていく方針としました。
AWSアカウントの整理と事前確認
AWSアカウント数増加に伴い、併せてAWS Control Towerを導入します。
導入にあたり、以下の理由からPayerは新たに再作成することとしました。
- Payerはプロダクトリソースを置かず、アカウント管理用途に限定する
- Payerには限られた人のみアクセスを許可する
ただ、Payerを作り直すことで懸念となるのが、既存Payerへの影響でした。
今回は以下2方式を検討しています。
- 既存Payerからプロダクトリソースを他AWSアカウントに移行させる
- メリット：既存Payerを流用できるのでコスト体系は変わらない
- デメリット：リソース移行の難易度が高く、サービスのダウンタイムを考慮しなければならない
- 新規AWSアカウントを作成して、Org再構築後にPayerをスイッチする
- メリット：既存リソースにはほとんど影響を与えなくて済む（厳密には後述する調査が必要）
- デメリット：Payer変更にかかわる契約変更が発生する、Cost Explorerの過去分が閲覧できない
結論2.の方針を取りました。
ココナラではPayerに対して個別割引契約が適用されており、Org全体にディスカウントが効いています。
そのためPayerが変更になると、契約内では以下の変更が必要でした。
- 既存Payer情報の削除
- 新規Payer情報の追加
この変更を進めるにあたり、契約更新手続きや構成変更のタイミング、実施手順を併せて検討して進めています。契約や技術周りなど、AWS社担当営業・ソリューションアーキテクト（SA）とも議論しつつ方針を固めています。
また、2.の方針を取るにあたり以下の内容確認が必要でした。
- AWS CloudFormation StackSets で管理されているものがないこと
- リソースベースのポリシーで aws:PrincipalOrgID 条件キーを使用していないこと
- "AWS リソースの共有"を使っていないこと
- Cost Explorerの過去情報が必要かどうか
幸いにも1-3は対象がなく、4のみ情報として保持したかったので別途CSVにエクスポートして残しておきました。
契約を含めた全体の移行フローは以下のとおりです。新OrgのPayerアカウント（Mgmt Account）作成から個別割引契約更新までの時間を短くするよう、あらかじめ具体的なタイミングを整理して進めています。
移行の流れ
Org再構築とAWSアカウントの移行
Mgmt Accountを作成して、新Orgを作ります。併せてControl Towerを有効にしていきます。
有効に伴い、いくつか新規アカウントが生成されている状態です。
※便宜上OUは割愛しています
新Org作成とControl Tower有効化
次に旧OrgよりLinkedを外して新Orgへ付替していきます。
単純な作業ですが、割と移行時はドキドキしていました。
アカウント付替中
Main Accountを含めた残りのアカウントも同様に移行します。無事に移行が終わり…と思ったら新Orgへ移行できないアカウントがありました。
原因はOrgのクォータ制限に引っかかっていたことです。デフォルトでは上限10アカウントとなっており、Conrtol Towerで生成されたアカウントも相まって超過していました。移行作業中に気がついたため、クォータ引き上げ申請が通るまでは利用金額の少ないアカウントをスタンドアロン状態にして凌ぎました。この点は事前の認識不足でしたが、後日無事に移行できています。
アカウント付替後
Org再構築を終えて
AWS利用者目線では何も変わることがなく、Org再構築およびアカウント付替を終えることができました。コスト観点でも許容範囲内で終えられています。その後はAWS IAM Identity Center（旧AWS SSO）によるユーザー管理方式の検討を進めています。こちらは別途ご紹介したいと思います。
今回はAWSアカウント増加に伴うOrg再構築およびControl Tower導入に関する内容をご紹介しました。AWS社担当営業・SAの協力もあったことで大きな問題なく移行でき、アカウント管理の改善に繋げることができました。同様のユースケースに役立てば幸いです。
ココナラでは一緒に働く方を募集しています。
インフラ・SREだけでなく幅広く募集していますので、ご興味ある方はぜひご応募ください！
ブログの内容への感想、カジュアルにココナラの技術組織の話をしてみたい方はこちら
※ブログ閲覧者の方限定のカジュアル面談の応募フォームとなります！
エンジニアの募集職種一覧はこちら
Discussion
私も最近、旧 Organization から Control Tower を使った 新 Organization の移行作業をしています。
地味にアカウントの移行、プレッシャーですよね...笑
外部AWSアカウントの設定はすんなり行くのですが...笑