20241015 Toranomon Tech Hub#1 Service Catalog使ってみた

Transcript

1. 2024/10/15 Toranomon Tech Hub#1 クラスメソッド株式会社 芦沢広昭 AWS Control Tower歴2年で初めて Service Catalogと向き合ってみた
2. ⾃⼰紹介 2 芦沢広昭 (ASHIZAWA Hiroaki) / @ashi_ssan • 所属 ◦ クラスメソッド株式会社 AWS事業本部コンサルティング部 • ロール ◦ ソリューションアーキテクト • コミュニティ活動 ◦ Hibiya Tech 運営 ◦ Toranomon Tech Hub 運営 • その他 ◦ 2024 Japan AWS Top Engineers (Security) ◦ 2024 Japan AWS All Certifications Engineers
3. AWS re:Invent 2024に⾏く⼈！ 現地で仲良くしてください！！！！！！ 今⽇参加‧運営しているモチベーション 3
4. アジェンダ 4 • ⾃⼰紹介 • このLTの⽬的 • AWS Control TowerとAWS Service Catalogの概要 • Control Tower周りのこれまでの経験 • 向き合うことになったきっかけ • 使い始めてわかったこと (Good / Bad) • まとめ
5. このLTの⽬的 5 • 伝えたいこと ◦ AWS Service CatalogやAWS Control Towerの概要 ◦ AWS Service Catalogによるマルチアカウントへのデプロイの選択肢 ◦ 現在検討中のアーキテクチャの設計、ここまでに⾄るまでの考え‧背景 • 私が持ち帰りたいこと ◦ 現在検討中のアーキテクチャに対するフィードバック、ご意⾒
6. AWS Control Towerとは 6 簡単に⾔うと... 複数のAWSアカウント（マルチアカウント）をベストプラクティスに基づいて 設定および管理してくれるサービス 参考:https://dev.classmethod.jp/articles/introduction-2024-aws-control-tower/
7. 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/
8. 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/
9. AWS Service Catalogとは 9 簡単に⾔うと... AWS で承認された IT サービスのカタログを作成および管理できるサービス 参考: https://dev.classmethod.jp/articles/introduction-2024-aws-service-catalog/
10. 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
11. Control Tower と Service Catalogの関係性 11 Account Factory (アカウントの払い出し + 初期設定) • AWSアカウントを払い出す際にService Catalogの製品が起動される → 内部的にService Catalog が利⽤されている
12. これまでの私の経験 (Control Tower関連) 12 • やっていたこと：約2年半程度 ◦ Control Towerの初期セットアップまでの要件調整‧プリセールス ◦ Control Tower/Organizationsを使ったガバナンスの設計‧実装（SCPなどコントロール） ◦ その他セキュリティサービスとの連携(Security Hub、GuardDuty、Detective、 CoudTrail) ◦ ランディングゾーンアップデートのキャッチアップ • やっていなかったこと ◦ アカウント払い出しの⾃動化 (Account Factory) ◦ 複数アカウントへのリソースのプロビジョニング (Service Catalog / StackSets) ◦ など → これまで Service Catalog と向き合ったことがない (と思っていた)
13. ここ以降、説明する事項は すべて検討‧検証中のもので どうあるべきかは結論が出ていません (まだ) 直近の出来事につき 考慮不⾜な点が含まれます ちょっとした注意 13 ‧こうしたらいいんじゃね？ ‧こうやったらうまく⾏ったよ！ のようなフィードバック⼤歓迎です
14. 向き合うことになったきっかけ 14 社内ツールの開発において、以下のアーキテクチャを構成していた（検証中）
15. 向き合うことになったきっかけ 15 今後のスケールに伴い、アカウント構成‧リソース配置⽅針が変更に
16. 向き合うことになったきっかけ 16 既存のデプロイ戦略を背景に「リポジトリ:中央:⼦ = 1:1:N」の構成を検討
17. (参考) 「リポジトリ:中央:メンバー = 1:1:N」構成にした理由 → 本番/開発環境のGitHubブランチ戦略が背景 向き合うことになったきっかけ 17
18. 向き合うことになったきっかけ 18 「何か」の箇所を埋められるソリューションを探すことになった
19. アカウント構成‧リソース配置⽅針が達成できれば特にない 個⼈的には「コスト低 + 管理リソース少」だといいな Q. 要件はあるの？ 19
20. 「何か」を埋めるソリューションの候補 20 • AFT (Account Factory for Terraform) の利⽤ • CloudFormation StackSetsの利⽤ • Service Catalog (Terraform) の利⽤
21. 「何か」を埋めるソリューションの候補 21 • AFT (Account Factory for Terraform) の利⽤ • CloudFormation StackSetsの利⽤ • Service Catalog (Terraform) の利⽤ → ⼀旦、この⽅法で検討していく⽅針に決まった
22. 検討中の構成案 22
23. 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. 検討した他の選択肢 と 採⽤しなかった理由 24 • AFT (Account Factory for Terraform)の利⽤ ◦ 要件的にアカウント払い出し機能が不要なため、過剰に感じた ◦ 機能を利⽤するために必要なAWSリソースの維持コストが気になった 参考: https://dev.classmethod.jp/articles/arc hitecture-diagram-for-aft/
25. 検討した他の選択肢 と 採⽤しなかった理由 25 • CloudFormation StackSetsの利⽤ ◦ Gitリポジトリ:中央アカウント:⼦アカウント= 1:1:n の構成が取れそう ▪ 中央アカウントに⼦アカウントにリソース展開 するための設定を構成できそう ◦ 必要な準備は各アカウントへのIAMロールの作成く らいで簡単そう ◦ しかし、IaCコードをすべてTerraformで管理してお り、デプロイのために擬似的にCFnテンプレートに 変換するのはいけていないと思った jsonencodeで CFnテンプレートを定義
26. ここまでやったこと 26 • Terraform Reference Engineのプロビジョニング • 製品の⼦アカウントへのデプロイ (⼿動) ◦ アプデ時のブログの内容と同等 ▪ https://dev.classmethod.jp/articles/provisioning-pr oduct-defined-by-terraform/
27. 使ってみてわかったこと (Good) 27 • Terraform Reference Engineの プロビジョニングは簡単 ◦ 基本はブログの⼿順に従って設定するだけ ▪ 事前定義されたSAMを実⾏してリソースを デプロイしている ◦ 製品登録時に製品タイプを「外部」に変える必要あり ▪ 「Terraform のオープンソース」は廃⽌になった
28. 使ってみてわかったこと (Bad) 28 • Terraform Reference Engineのためのリソースの維持‧管理が必要 ◦ VPC, EC2(x1), NAT Gateway(x2), Lambda, S3など ◦ ⼀度きりの設定なのか...？と思いきや、削除したら動かなくなった（想像はできたが） ▪ 製品起動時にAPIエラーとなる
29. 今後検討‧検証したいこと 29 • Service Catalog(Terraform)を使った追加の検証 ◦ 製品の作成‧⼦アカウント展開まで含めた⾃動化 ◦ コスト削減策の検討 • 他の選択肢の検討 ◦ CloudFormation StackSetsの利⽤：本当にいけてなかったのか...??? ◦ そのほかの選択肢の模索
30. まとめ 30 • AWS Service CatalogはAWS で承認された IT サービスのカタログを作成お よび管理できるサービス • Service CatalogでTerraformを利⽤する場合Terraform Reference Engine のプロビジョニングが必要 • 要件を満たす最⾼のアーキテクチャを模索していくぞ！