2024/10/15 Toranomon Tech Hub#1 クラスメソッド株式会社 芦沢広昭 AWS Control Tower歴2年で初めて Service Catalogと向き合ってみた

⾃⼰紹介 2 芦沢広昭 (ASHIZAWA Hiroaki) / @ashi_ssan ● 所属 ○ クラスメソッド株式会社 AWS事業本部コンサルティング部 ● ロール ○ ソリューションアーキテクト ● コミュニティ活動 ○ Hibiya Tech 運営 ○ Toranomon Tech Hub 運営 ● その他 ○ 2024 Japan AWS Top Engineers (Security) ○ 2024 Japan AWS All Certifications Engineers

AWS re:Invent 2024に⾏く⼈！ 現地で仲良くしてください！！！！！！ 今⽇参加‧運営しているモチベーション 3

アジェンダ 4 ● ⾃⼰紹介 ● このLTの⽬的 ● AWS Control TowerとAWS Service Catalogの概要 ● Control Tower周りのこれまでの経験 ● 向き合うことになったきっかけ ● 使い始めてわかったこと (Good / Bad) ● まとめ

このLTの⽬的 5 ● 伝えたいこと ○ AWS Service CatalogやAWS Control Towerの概要 ○ AWS Service Catalogによるマルチアカウントへのデプロイの選択肢 ○ 現在検討中のアーキテクチャの設計、ここまでに⾄るまでの考え‧背景 ● 私が持ち帰りたいこと ○ 現在検討中のアーキテクチャに対するフィードバック、ご意⾒

AWS Control Towerとは 6 簡単に⾔うと... 複数のAWSアカウント（マルチアカウント）をベストプラクティスに基づいて 設定および管理してくれるサービス 参考:https://dev.classmethod.jp/articles/introduction-2024-aws-control-tower/

AWS Control Towerの主な機能 7 ● AWSのOrganizations、Service Catalog、IAM Identity Centerなど複数サー ビスを使ってランディングゾーンを構築する ● ダッシュボードからランディングゾーンの状態を監視する ● 組織からOUやアカウントのControl Towerへの登録状況を確認でき、OUや アカウントの作成/登録ができる ● 管理‧統制からの逸脱（ドリフト）をさせないためにOUにコントロールを 適⽤する ● Account Factoryで新しいAWSアカウントの作成と初期設定を⾏う 参考:https://dev.classmethod.jp/articles/introduction-2024-aws-control-tower/

AWS Control Towerの主な機能 8 ● AWSのOrganizations、Service Catalog、IAM Identity Centerなど複数サー ビスを使ってランディングゾーンを構築する ● ダッシュボードからランディングゾーンの状態を監視する ● 組織からOUやアカウントのControl Towerへの登録状況を確認でき、OUや アカウントの作成/登録ができる ● 管理‧統制からの逸脱（ドリフト）をさせないためにOUにコントロールを 適⽤する ● Account Factoryで新しいAWSアカウントの作成と初期設定を⾏う 参考:https://dev.classmethod.jp/articles/introduction-2024-aws-control-tower/

AWS Service Catalogとは 9 簡単に⾔うと... AWS で承認された IT サービスのカタログを作成および管理できるサービス 参考: https://dev.classmethod.jp/articles/introduction-2024-aws-service-catalog/

AWS Service Catalogの⽤語 10 ● 製品 ○ AWSリソースをデプロイするテンプレートを登録 ○ 例 ■ CloudFormation ■ Terraform (HCP版, Community版) ● 制約 ○ 設定した製品単位に適⽤されるルール ○ 例 ■ どのIAMロール権限を利⽤するか ■ 対象アカウント制限、リージョン制限 ● ポートフォリオ ○ 製品の集合（制約の設定情報を含む） 参考: https://dev.classmethod.jp/articles/introduction-2024-aws-service-catalog/ https://dev.classmethod.jp/articles/summary-of-the-constraints-available-in-the-service-catalog

Control Tower と Service Catalogの関係性 11 Account Factory (アカウントの払い出し + 初期設定) ● AWSアカウントを払い出す際にService Catalogの製品が起動される → 内部的にService Catalog が利⽤されている

これまでの私の経験 (Control Tower関連) 12 ● やっていたこと：約2年半程度 ○ Control Towerの初期セットアップまでの要件調整‧プリセールス ○ Control Tower/Organizationsを使ったガバナンスの設計‧実装（SCPなどコントロール） ○ その他セキュリティサービスとの連携(Security Hub、GuardDuty、Detective、 CoudTrail) ○ ランディングゾーンアップデートのキャッチアップ ● やっていなかったこと ○ アカウント払い出しの⾃動化 (Account Factory) ○ 複数アカウントへのリソースのプロビジョニング (Service Catalog / StackSets) ○ など → これまで Service Catalog と向き合ったことがない (と思っていた)

ここ以降、説明する事項は すべて検討‧検証中のもので どうあるべきかは結論が出ていません (まだ) 直近の出来事につき 考慮不⾜な点が含まれます ちょっとした注意 13 ‧こうしたらいいんじゃね？ ‧こうやったらうまく⾏ったよ！ のようなフィードバック⼤歓迎です

向き合うことになったきっかけ 14 社内ツールの開発において、以下のアーキテクチャを構成していた（検証中）

向き合うことになったきっかけ 15 今後のスケールに伴い、アカウント構成‧リソース配置⽅針が変更に

向き合うことになったきっかけ 16 既存のデプロイ戦略を背景に「リポジトリ:中央:⼦ = 1:1:N」の構成を検討

(参考) 「リポジトリ:中央:メンバー = 1:1:N」構成にした理由 → 本番/開発環境のGitHubブランチ戦略が背景 向き合うことになったきっかけ 17

向き合うことになったきっかけ 18 「何か」の箇所を埋められるソリューションを探すことになった

アカウント構成‧リソース配置⽅針が達成できれば特にない 個⼈的には「コスト低 + 管理リソース少」だといいな Q. 要件はあるの？ 19

「何か」を埋めるソリューションの候補 20 ● AFT (Account Factory for Terraform) の利⽤ ● CloudFormation StackSetsの利⽤ ● Service Catalog (Terraform) の利⽤

「何か」を埋めるソリューションの候補 21 ● AFT (Account Factory for Terraform) の利⽤ ● CloudFormation StackSetsの利⽤ ● Service Catalog (Terraform) の利⽤ → ⼀旦、この⽅法で検討していく⽅針に決まった

検討中の構成案 22

Service Catalog(Terraform) を 「⼀旦」採⽤した理由 23 ● Service Catalogの利⽤ ○ Gitリポジトリ:中央アカウント:⼦アカウント= 1:1:n の構成が取れそう ■ 中央アカウントに⼦アカウントにリソース展開するための設定を構成できそう ○ Terraform Reference Engine を利⽤することで コミュニティ版Terraformが利⽤可能 ■ どんなものかはあまり理解していないが、いけそうに思った ■ 参考: https://dev.classmethod.jp/articles/provisioning-product-defined-by-terraform/ ○ すべてTerraformで構成している元のコード構成で完結できる ■ これが1番⼤きかった ● 「⼀旦」としているのは、触ってみないとわからないと思ったため ○ 後で変更も可能だし、抜本的なアーキテクチャの⾒直しも相談できる状態

検討した他の選択肢 と 採⽤しなかった理由 24 ● AFT (Account Factory for Terraform)の利⽤ ○ 要件的にアカウント払い出し機能が不要なため、過剰に感じた ○ 機能を利⽤するために必要なAWSリソースの維持コストが気になった 参考: https://dev.classmethod.jp/articles/arc hitecture-diagram-for-aft/

検討した他の選択肢 と 採⽤しなかった理由 25 ● CloudFormation StackSetsの利⽤ ○ Gitリポジトリ:中央アカウント:⼦アカウント= 1:1:n の構成が取れそう ■ 中央アカウントに⼦アカウントにリソース展開 するための設定を構成できそう ○ 必要な準備は各アカウントへのIAMロールの作成く らいで簡単そう ○ しかし、IaCコードをすべてTerraformで管理してお り、デプロイのために擬似的にCFnテンプレートに 変換するのはいけていないと思った jsonencodeで CFnテンプレートを定義

ここまでやったこと 26 ● Terraform Reference Engineのプロビジョニング ● 製品の⼦アカウントへのデプロイ (⼿動) ○ アプデ時のブログの内容と同等 ■ https://dev.classmethod.jp/articles/provisioning-pr oduct-defined-by-terraform/

使ってみてわかったこと (Good) 27 ● Terraform Reference Engineの プロビジョニングは簡単 ○ 基本はブログの⼿順に従って設定するだけ ■ 事前定義されたSAMを実⾏してリソースを デプロイしている ○ 製品登録時に製品タイプを「外部」に変える必要あり ■ 「Terraform のオープンソース」は廃⽌になった

使ってみてわかったこと (Bad) 28 ● Terraform Reference Engineのためのリソースの維持‧管理が必要 ○ VPC, EC2(x1), NAT Gateway(x2), Lambda, S3など ○ ⼀度きりの設定なのか...？と思いきや、削除したら動かなくなった（想像はできたが） ■ 製品起動時にAPIエラーとなる

今後検討‧検証したいこと 29 ● Service Catalog(Terraform)を使った追加の検証 ○ 製品の作成‧⼦アカウント展開まで含めた⾃動化 ○ コスト削減策の検討 ● 他の選択肢の検討 ○ CloudFormation StackSetsの利⽤：本当にいけてなかったのか...??? ○ そのほかの選択肢の模索

まとめ 30 ● AWS Service CatalogはAWS で承認された IT サービスのカタログを作成お よび管理できるサービス ● Service CatalogでTerraformを利⽤する場合Terraform Reference Engine のプロビジョニングが必要 ● 要件を満たす最⾼のアーキテクチャを模索していくぞ！