こんにちは、博報堂テクノロジーズ・インフラ開発一部の近藤です。
とある内製案件で、AWS環境をゼロから作りPlatform Engineering活動を推進するに至っており、これまでの変遷をまとめます。

伝えたいこと

Platform Engineeringは目的ではなく、あくまで手段であるべきだと考えます。
私個人の考えですが、インフラはそれ自体が価値を生み出すものではなく、アプリケーションあってのものです。このため、必要なタイミングで状況に合った最適な構成を提供すべきだと考えています。
例えば、単に「検証使途でJavaのWebアプリを動かしたい」という場合、ALB+EC2程度を手動構築し素早く提供することが適切だと考えています。これを「Platform Engineeringを意識してIaC化し、CICDで自動化するんだ」という思想は、過剰だと考えています。

つまり、Platform Engineeringは目的ではなく手段として捉えるべきで、状況に応じてQCD（品質・コスト・納期）の最適解を見出していく活動が重要だと考えています。ただ、この「状況に応じて」は、現時点だけでなく少し先の将来を見据えることが肝要と考えます。

以降、それぞれの状況でどのような選択肢を取ったか、理由も含めて紹介していきます。

スモールスタート(N月)

ビジネス側の状況

新規に発足した部門のアプリケーションチームにて、担当者のローカル環境で開発済のWebアプリケーションをAWSで稼働させたい、というニーズがありました。

インフラの対応

新規発足の部門ということもあり、まずは動く環境を素早く提供すべきと判断し、簡素なAWS構成にする方針としました。具体的には、AWSアカウントはスタンドアロンで構成、ワークロードはALB+EC2の構成です。また、この環境は一時的な環境と考えたためIaC化までは実施せず、手組で構成しました。

環境イメージ図

期間

1週間ほどの短期間で提供しています。枯れた技術でもあったため、構築コストも最小限に抑え対応しています。

こうすべきだったコト

ここでは特にありませんでした。

チーム拡大による使途の広がり(N+2か月)

ビジネス側の状況

アプリケーションチームの拡大に伴い、アプリ開発のパイプラインが増加している状況になりました。また、使途もPoCやR&D、開発環境など微妙に使途が異なる状況でした。

インフラの対応

現在の1アカウント構成から発展させ、使途に応じたアカウント構成にすべきと考えました。
ただ、現在はAWSアカウントをスタンドアロンで構成していることから、AWSアカウント数だけIAMリソースを作成する必要がありました。
1,2アカウントのレベルあれば管理コストの観点から問題にならないと考えてましたが、チーム拡大の状況を考慮し今後もアカウント数が増加する可能性を踏まえ、構成変更するタイミングだと考えました。

ネックな点は、IAMログイン方式であり、スイッチロールかIdentity Centerのどちらかで解消できると考えました。当環境では以下理由により、Identity Centerを選択しています。

Identity Centerの方が直感的に操作しやすい
権限設定はそこまで複雑ではない

Identity Centerは制約が少ない組織インスタンス(=Organizationsを利用)で立てました。なお、この時点では、利用者もそこまで多くなかったことから提供スピードを優先し組織レベルでの各種統制は未実施としました。

環境イメージ図

期間

2週間ほどで提供しています。

こうすべきだったコト

ここでは特にありませんでした。

プロダクション利用の開始(N+6か月)

ビジネス側の状況

PoCやR&D、開発使途から一歩踏み出し、プロダクション提供が始まりそうとの状況になりました。

インフラの対応

この状況より、アカウントレベルでの統制から、組織レベルでの統制へ昇格する必要があると考えました。
数アカウント規模で落ち着けば、現在のアカウント毎にオーダーメイドな状況を続ける方がコストパフォーマンスは良いと考えましたが、環境の特性から「アプリ数×提供社数×環境数＝AWSアカウント数」という状況なため、アカウント数が爆増する可能性を考慮し、先を見越してマルチアカウント戦略を検討しました。

期間

1か月少しで設計～実装、運用開始まで実施しました。

補足

組織レベルの統制で悩んだ事とどう対応したかを記載します。

ユーザ管理の見直し

プロダクション利用開始に伴い、Organizations配下に開発環境(PoC,R&D使途含)と本番環境が同居するため、事故防止を目的に、開発用と本番用でアクセスを分離すべきと考えました。具体的には1人の利用者に対し、開発・本番それぞれユーザを払い出す方式としました。
なお、Identity Centerではメールアドレスのユニーク制約があるため、メールアドレスのエイリアスを利用することで対応しました。

柔軟性とセキュリティのバランス

プロダクション利用のため、SCPによる制限を検討しました。
既に環境利用が始まっていたことから、セキュリティリスクと利便性のバランスを考慮したSCPポリシーを検討・設定しました。具体的には以下を設定しています。

利用リージョンの限定
IAMユーザの作成禁止

ここは案件・環境に依存するため、最適解をチーム内で模索するのが良いと考えています。もし、0ベースから検討・実装する場合は、厳しめのポリシーから緩和していく方が、開発者体験を損なわないと考えています。

マネージドとカスタマイズのバランス

マルチアカウントの構成では、Control Towerの利用も一案でしたが、以下理由により素のOrganizationsを利用しています。

Control Towerに合わせた構成とする必要があること
Control Tower自体は無料なものの派生するサービスで一定の利用料がかかること

今の環境は出来て間もないことやAWS有識者が多数在籍していたこともあり、比較的柔軟に環境をコントロールできることに重きを置きました。

こうすべきだったコト

後編ではIaC化の話を記載していますが、プロダクション利用開始後に、IaCでのリソースインポートを行うのは神経を使います。IaCの実装を誤ると予期せず環境破壊を行ってしまう可能性があるためです。
この時点で、多少時間をかけてでも、IaC化しておくべきだったと反省しています。

続きは後半でご紹介します！