2020.09.08 第一回 AWSマルチアカウント事例祭りにて、リクルートのライフスタイル領域クラウド基盤の事例を発表した資料です。 https://zozotech-inc.connpass.com/event/185894/

1. 「進化し続けるインフラ」
のための
マルチアカウント管理
株式会社リクルート
須藤 悠

2. 須藤 悠
好きなAWSのサービス
Fargate
Organizations
好きなHashiCorpのプロダクト
Terraform
Terraform Enterprise
株式会社リクルート
プロダクト統括本部
インフラソリューションユニット
サイトリライアビリティエンジニアリング部
ライフスタイル・SaaS SREグループ
株式会社リクルートライフスタイル
ネットビジネス本部
開発ディレクションユニット
開発ディレクション部
SREグループ

3. の "ライフスタイル領域"

5. "ライフスタイル領域"
のためのAWS基盤チーム

6. Q.どんな基盤なの？

7. チーム
13人
約90アカウント
● 横断的な管理・コスト配賦
● 共通機能の提供・運用・進化
● CCoE活動・リアルタイム監査

8. 発足
5年目
2016年から
● 数アカウントでスタート
● 「進化し続けるインフラ」のチーム
● クラウドの恩恵をプロダクトに届ける

9. 基盤側 プロダクト側
アカウント申請
ヒアリング・アーキテクチャレビュー
標準構成済みアカウント引き渡し
継続的なCCoE活動・リアルタイム監査
問題対処
各AWSサービスの利用
基盤チームの役割

10. 基盤側 プロダクト側
アカウント申請
ヒアリング・アーキテクチャレビュー
標準構成済みアカウント引き渡し
継続的なCCoE活動・リアルタイム監査
問題対処
各AWSサービスの利用
基盤チームの役割

11. Terraformの運用
約90アカウントすべて
● Terraform Enterpriseで管理
● Pull Request作成で自動plan
● applyは管理者がチェックし実行

12. Terraformの運用
に至るまで
最初期：手動構築
その後1年程度：Cloud Formation
その後2年程度：次第にTerraform化
現在：すべてTerraform化
＋ Terraform Enterpriseで運用

13. 最初期：手動構築
その後1年程度：Cloud Formation
その後2年程度：次第にTerraform化
現在：すべてTerraform化
＋ Terraform Enterpriseで運用
Terraformの運用
に至るまで
Infrastructure as Codeしたかった

14. 最初期：手動構築
その後1年程度：Cloud Formation
その後2年程度：次第にTerraform化
現在：すべてTerraform化
＋ Terraform Enterpriseで運用
Terraformの運用
に至るまで
Cloud Formationがつらくなった
importすれば構築済みのリソースもすべて管理できる！

15. 最初期：手動構築
その後1年程度：Cloud Formation
その後2年程度：次第にTerraform化
現在：すべてTerraform化
＋ Terraform Enterpriseで運用
1000plan/月、200apply/月
も実現するようになった
Terraformの運用
に至るまで
自前でのCI/CD維持管理や
強力なCredentialの運用が限界だった

16. Terraform Enterprise
https://engineer.recruit-lifestyle.co.jp/techblog/2019-12-02-terraform-enterprise/
[ Terraform Enterprise ][検索]
Terraform Enterpriseを導入してTerraform v0.10からv0.12に上げた話

17. Q.どのAWSの機能を使ってる？

18. マルチアカウント管理で
利用しているAWSの機能

19. …の前に

20. 基盤の権限構成

21. 基盤の権限構成 4つの権限：何度も調整して今の形に
● 管理者権限 - プロダクト責任者向け
○ SCPやS3バケットポリシーでDenyされていること以外なん
でもできる
● 開発者権限 - 開発者一般向け
○ IAM作成・変更、ビリング、RI・SP購入、Config、
CloudTrail、VPC作成・変更、DX、VPNなどをDenyしてい
る
● 運用者権限 - 運用者向け
○ 開発者に加えてSubnet、SecurityGroup、Spot、
RouteTable、NetworkACLをDenyしている
● コンテンツ権限 - S3バケット更新用

22. 基盤の権限構成 root権限：かなり厳重に制限
● 基盤チームでMFA管理
○ 特定のMFAデバイスでのみ利用
● rootが必須なとき以外使わない
○ サポートプランの変更
○ オプトイン
● プロダクト側の利用は不可
○ 基盤側に作業依頼を出して貰う

23. マルチアカウント管理で
利用しているAWSの機能

24. CloudTrail
● Trailログの出力先S3バケットは、基盤チームで利
用するTerraformとrootを除くあらゆるユーザが変
更・削除できないよう、バケットポリシーで制限
(Get系のActionは制限していないため、Athena等
での調査目的の読み取りは可能)
● 内製のリアルタイム自動監査システムで、
CloudTrailとConfigの出力を利用
Config

25. GuardDuty
● 検知があればSNS Topicを通じてメール・Slackで
通知するよう設定
● 内製のリアルタイム自動監査システムとCCoE活
動が実を結んでか、GuardDutyに検知されるよう
な事象はあまり起きない

26. VPC Peering
● 基盤アカウントと各アカウントを接続する
● 基盤アカウントで、踏み台、LDAPによるID管理、
DirectConnectによる専用線接続などを提供して
いるため
● 多数のSite-to-Site VPN接続を抱える部分につ
いてはTransit Gatewayを利用
Transit Gateway

27. AWS Summit 2020
セッションあります
(別の基盤チームですが)
Transit Gateway

28. Organizations
SCP
● organizations:LeaveOrganization など操作を封じ
たいActionをService Control PolicyでDenyしてい
る
● 基盤管理のTerraformで構成したリソースのうち、
勝手に変更されると困るものもDenyする運用を準
備している

29. Compute
SavingsPlans
● 親アカウントでコミットメントを設定、全アカウント
で割引の恩恵を受けている
● Fargateの利用料が高く、その部分に恩恵を受け
たいアカウントでは個別にSavingsPlansのコミット
メントを設定する
(Fargateの割引率は相対的に低いため、割引が
適用されにくい)
● RIの購入は個別アカウントでのみ
(親アカウントでは購入していない)

30. Consolidated Billing
&
Cost Explorer
● Invoiceの金額とce:GetCostAndUsage APIを利用
して、毎月Pythonスクリプトでどのアカウントにい
くら配賦するか算出
● 親アカウントで購入しているSavingsPlansのコスト
も、各アカウントで適用された割引額にあわせて
配賦
● 各アカウントの管理者に金額をお知らせするメー
ルは、Google App Scriptで一斉送信

31. RDS
● 意図せぬDB再起動によりサービス障害を発生さ
せないため、全アカウントに対して
rds:DescribePendingMaintenanceActionsを発行し
て、見過ごされているメンテナンススケジュールが
ないか定期的にチェックし、Slack通知
● 実装はCloudWatch Events + Lambda + STS
AssumeRole

32. Route53
● 各アカウントの内部HostedZoneレコードを
DynamoDBに集約し基盤アカウントにも登録
● 共用踏み台から各アカウントのインスタンスに
SSHする際に、ホスト名でもアクセスできるように
するため
● 実装はCloudWatch Events + Lambda + STS
AssumeRole
DynamoDB

33. Certificate Manager
● 開発用エンドポイントの証明書とサブドメインの移
管
● 開発用であっても正しくHTTPSを使うことを根付
かせるため
● クロスアカウントでの操作が必要になるため
Terraform化はしていない
Route53

34. Q.Terraform化の範囲は？

35. Terraform化の対象 ● CloudTrail + S3バケット
● Config
● GuardDuty
● VPC/Subnet/RouteTable/NATGW
● いくつかのSecurityGroup
● VPC Flow Logs + CWロググループ
● VPCピアリング
● CLB/ALB/NLBログ用S3バケット
● DB Subnet/ElastiCache Subnet
● 内部HostedZone/DHCPオプション

36. Terraform化の対象
(IAM関連)
● パスワードポリシー
● ServiceLinkedRole(RDS/ELB)
● RDS拡張モニタリングRole
● IDフェデレーション用Role
● SAMLプロバイダー
● デフォルトEC2Role
● 自動監査システムAssumeRole用Role
● プロダクト向けTerraform用Role

37. Q.ほかにも必要なものあるよね？

38. マルチアカウント管理のために
独自に作り込んでいる仕組み

39. LDAPによるID管理と
フェデレーション
● LDAPにアカウントを登録することで、SSHやマネ
ジメントコンソールが使えるように
● IDPとしてはOpenAMを使用
(Keycloak on Fargateへ移行予定)
● アカウント払い出し時に公開鍵を受け取り、自動
でMFAトークンをメール通知
● マネジメントコンソールへのログインはOpenAM経
由のフェデレーションログイン、MFA必須
● SSH時もMFA必須

40. LDAPによるID管理と
フェデレーション
● LDAPの直接操作はさすがにシンドイのでWebア
プリのID管理ツールを作成・提供

41. ID管理と
フェデレーション
今からマルチアカウント基盤を作る人は
● マネージドサービス活用を第一に考えて
○ AWS SSO
○ AWS Directory Service
○ AWS Systems Manager ...etc
● 権限構成は熟慮して、改善を続けて欲しい
○ 弱すぎる権限：生産性が大きく低下する
○ 強すぎる権限：事故の影響範囲が大きい
● 独自ID管理を選択するには相当の覚悟が必要
○ LDAPやめたいけどやめられない状態
○ SSM Session Manager化したい

42. リアルタイム
自動監査システム
Cloud Linebacker
https://pages.awscloud.com/rs/112-TZM-766/images/J3-03.pdf
https://youtu.be/_Y7xGaG3xJU

43. Q.マルチアカウント管理で
大切にしていることは？

44. 進化し続けるインフラ
であること
● 基盤チームがいることでプロダクトを幸せに
○ インフラ運用だけじゃない介在価値を
○ プロダクトに寄り添い伴走し成長させる
● AWSの新機能・新サービスのキャッチアップ
○ この機能はどこに適用できるか？
○ このサービスはどこに活用できるか？
○ 移行する場合のROIはどうか？
○ 各サービスの特性を理解して、冗長性・可用
性・ガバナンスを担保
● 障害を学びにする
○ トラブルシュートは学びの宝庫

45. 一緒に働く仲間を探しています
https://recruit-saiyo.jp/position/

46. ありがとうございました