[レポート] Netflixの大規模なマルチアカウントの旅：2年目 #AWSReInvent #NFX402

AWS re:Invent 2024
#AWS
#マルチアカウント戦略
#ABAC
丸毛篤史
2024.12.06
AWS re:Invent 2024、今回はNFX402「Netflix's massive multi-account journey: Year two」のレポートをお送りします
 セッション概要2年前、NetflixはAWS Identity and Access Managementのロールをアプリケーションの基礎となるコンピュートインフラストラクチャから切り離し、ワークロード固有のAWSアカウントにIDを格納するというアイデアを紹介しました。本セッションでは、アプリケーションの所有者が関与することなく、ワークロードのAWS IAM IDを透過的に置き換えるためのアプローチと、必要なデータとツールについて説明します。このビジョンを実現するための過去2年間の実装と移行作業からのNetflixの学習に基づいて、このセッションでは、マルチアカウントへの取り組みで成功を見つけるために他のAWS顧客が優先すべき機能と定量化されたリスク削減について議論します。
 スピーカーJoseph Kjar, Cloud Security Engineer, Netflix
Patrick Sanders, Senior Security Software Engineer, Netflix
Prateek Sharma, Principal Solutions Architect, AWS
 セッションの内容 はじめにNetflixはAWSを2008年から採用し、当初は少数のAWSアカウントで運用を行っていました。しかし、この構成では以下の課題に直面していました。
すべてのアプリケーションが同一アカウント内で動作するため、不必要なアクセス権限が発生
アプリケーション間の分離が困難で、セキュリティリスクが高い
AWS APIのレート制限を共有することによる「ノイジーネイバー」問題
IAMポリシーの管理が複雑化し、運用負荷が増大
 従来のアプローチとその課題これまで、マルチアカウント化を試みる際の一般的なアプローチは以下の通りでした。
アプリケーションごとに新しいアカウントを作成
コンピュートリソースを新アカウントに移行
ネットワーク構成を更新
IAMロールと権限を移行
しかし、このアプローチには重大な問題がありました。
ネットワーク構成の変更が複雑で危険
データの移行に伴うリスク
サービス停止のリスク
移行に膨大な時間とリソースが必要
 革新的なアプローチこれらの課題に対し、Netflixは従来の常識を覆す発想で解決策を見出しました。
 コアアイデア：IAMロールとコンピュートリソースの分離コンピュートリソースは既存アカウントに残したまま
IAMロールのみを新しいアカウントに移行
クロスアカウントアクセスを活用
このアプローチを選択した理由：
ネットワーク構成の変更が不要
データ移行のリスクを回避
サービス停止のリスクを最小化
段階的な移行が可能
 技術的な実装 1. 認証情報配信の仕組み課題：
EC2インスタンスは同一アカウント内のIAMロールしか使用できない
アプリケーションコードの変更は避けたい
Netflixの実装：
軽量なOIDCプロバイダーの構築
S3バケットとCloudFrontを使用
JSONウェブキーセットとOpenID Connect設定をホスト

カスタムIMDSプロキシの実装
内部発行トークンをIAMロール認証情報に交換
AWS SDKの標準的な認証情報検出フローを維持

このあたりの内容については、re:Invent 2022のセッション動画をご参照ください
https://www.youtube.com/watch?v=MKc9r6xOTpk
代替アプローチ：
IAM Roles Anywhere
AWSの比較的新しいサービス
IMDSプロキシまたは外部認証情報プロセスと組み合わせて使用可能
同様の透過的な認証情報配信を実現可能

Kubernetes用のIAM roles for service accounts
OIDCベースの認証
コンテナ環境での代替手段として有効

これらの代替アプローチは、組織の要件や既存インフラに応じて選択できます。
 2. Cloud Application Migration Platform (CAMP)課題：
大規模な移行の自動化が必要
安全な移行の保証が必要
移行状態の追跡が必要
機能：
移行の自動オーケストレーション
アプリケーションの健全性監視
安全性検証
アプリケーションの適格性チェック
環境の依存関係チェック
インフラの健全性チェック

CAMPは移行オーケストレーションのための内部ツールとして開発されました：

主な機能：
移行状態の管理
アプリケーションの移行状態（未開始/進行中/完了）の追跡
環境ごとの進捗管理
実行されたタスクの記録

移行の検証
アプリケーションが適切なカテゴリーに属しているか
環境の依存関係（テスト環境が本番環境より先に移行されているか）
インフラの健全性（不健全なEC2インスタンスがないか）

外部システムとの統合
継続的デプロイメントプラットフォーム（Spinnaker）との連携
アカウントインベントリシステムとの連携

 移行戦略と優先順位付け データ収集アプローチNetflixでは、アプリケーションの移行適格性と優先順位付けのために、2つの異なる観点からデータを収集しています：
適格性判断とプライオリタイゼーション
アプリケーションはどのAWSサービスにアクセスしているか？
データソース：IAM last accessed info
目的：移行の複雑さの評価と優先順位付け


実際の移行計画
アプリケーションはどのリソースにアクセスしているか？
データソース：
AWS CloudTrail
S3アクセスログ
CloudTrailデータイベントは使用しない（S3とSQSのデータイベントを無効にすることでAWS請求額を約15%削減）

目的：必要なリソースポリシーの特定と更新計画の策定


このように2段階のデータ収集アプローチを取ることで、効率的な移行計画の立案と実行が可能になります。とくにIAM last accessed infoを活用することで、初期の適格性判断を低コストで実施できます。
 リスク評価の枠組み以下の3つの指標を用いて各アプリケーションを評価します：
移行の複雑さ
AWS APIの使用パターン
クロスアカウントアクセス対応の有無
コード変更の必要性

セキュリティリスク
インターネット公開の有無
取り扱うデータの機密性
他サービスとの依存関係

運用リスク
ビジネスクリティカリティ
トラフィック量
可用性要件

 移行の優先順位付けセキュリティリスクは高いが、移行の複雑さが低いアプリケーションを優先
リスク削減効果と作業工数の比率（leverage）を重視
例：複雑な1つのアプリケーションの移行に1ヶ月かけるより、同じ期間でより単純な50のアプリケーションを移行する方が効果的

 データ収集と分析CloudTrailログの分析
S3アクセスログの活用
AWS APIの使用状況モニタリング
CloudTrailデータイベントの代替として、カスタムAWS SDKインストルメンテーションを開発
コスト効率の高いAPI使用状況の収集を実現

このあたりの内容については、re:Invent 2022のセッション動画をご参照ください
https://www.youtube.com/watch?v=L3af70WANPg
 移行グループの分類アプリケーションを以下の3グループに分類：
簡易移行グループ
AWS APIを使用していないアプリケーション
即時移行可能

中程度の複雑さ
クロスアカウントアクセス対応のAWSサービスのみ使用
リソースポリシーの更新のみで移行可能

高複雑度
Route 53やCloudFrontなど、クロスアカウント非対応サービスを使用
コード変更が必要

 セキュリティ設計 アクセス制御の階層化組織レベルの制御
サービスコントロールポリシー（SCP）
リソースコントロールポリシー
セキュリティサービスの保護
特権昇格の防止

アカウントレベルの制御
パーミッションバウンダリー
VPC関連操作の制限
リソース作成の制限

アプリケーションレベルの制御
IAMパターン：直接指定 vs ABAC
従来の直接指定方式（左側）の問題点
特定のIAMロールARNを直接指定
アカウント移行時に更新が必要
メンテナンス性が低い


ABACを活用した新しいアプローチ（右側）
ワイルドカードプリンシパルと条件を使用
組織のOUパスとタグの組み合わせで制御
複数アプリケーションへの権限付与が容易

ABACアプローチの利点
アカウント移行時にポリシー更新が不要
タグベースの管理による柔軟性の向上
スケーラブルな権限管理が可能
保護されたタグ名前空間によるセキュリティ確保


このアプローチにより、アプリケーションの移行をより安全かつ効率的に実施できます
 リスク削減の効果アクセスエクスポージャーの大幅な削減
例：1000アプリケーション×10リソースの場合
当初：1000万のアクセスパス
半数移行時：75%のアクセスパス削減


 成果と効果 定量的な成果405アプリケーションの移行完了
1,100以上のIAMロールを移行
最大277アプリケーションの並行移行を実現
サービス停止影響：内部サービス1件のみ（ユーザー影響なし）
 定性的な効果セキュリティの向上
最小権限の原則に近づいた権限管理
アプリケーション間の分離強化
セキュリティインシデントの影響範囲限定

開発者体験の向上
インフラストラクチャアズコードの利用が可能に
自律的なリソース管理
デプロイメントの柔軟性向上

 学んだ教訓 成功要因組織的サポート
セキュリティチームとエンジニアリング組織からの強力な支持
長期的なコミットメント
トップマネジメントの理解

技術的アプローチ
既存インフラへの影響を最小化
アプリケーションオーナーの負担を軽減
自動化の徹底

段階的な実装
簡単なアプリケーションから開始
フィードバックループの早期確立
リスクベースの優先順位付け

 改善点と反省プロジェクト管理
完璧を求めすぎて初期の移行が遅延
外部依存関係の管理に苦慮
リソース配分の最適化が必要

技術的課題
アカウントインベントリの規模対応
クロスアカウントアクセスの複雑さ
モニタリングとオブザーバビリティの確保

 まとめNetflixの取り組みは、大規模クラウド環境におけるセキュリティと開発者体験の両立が可能であることを実証しました。とくに従来の常識を覆すアプローチにより、リスクを最小化しながら段階的な移行を実現した点は、多くの組織にとって参考になるでしょう。
今後の展開として：
新規アプリケーションへのデフォルト適用を計画
アカウントインベントリシステムのスケーラビリティ改善
さらなる自動化と効率化の追求

他組織への示唆：
組織の規模やリスク許容度に応じたアプローチの調整が必要
既存インフラへの影響を最小化する戦略の重要性
段階的な実装と継続的な改善の有効性
このアプローチは、とくに大規模なレガシー環境を抱える組織にとって、現実的な移行戦略のモデルケースとなるのではないでしょうか。
 質疑応答 アプリケーションオーナーの説得についてQ: 人々をどのように説得したのでしょうか？CAMPに移行すれば新機能が使えるといった利点を提示したのでしょうか？

A: 多くの場合、アプリケーションオーナーに代わって私たちが透過的に移行を実施しました。自発的に来てくれたチームは、専用アカウントでの制限緩和やTerraform利用への期待が大きかったですね。とくに機密性の高いアプリケーションを扱うチームからの関心が高かったです。
 環境分離の方針についてQ: 本番環境とその他の環境は、どのようにアカウントを構成しているのでしょうか？

A: アプリケーションごと、環境ごとに1つのアカウントを使用しています。たとえば、1つのアプリケーションが開発、テスト、本番環境を持つ場合、3つの別々のアカウントを使用します。
 アーキテクチャの設計判断についてQ: なぜコンピュートを別のアプリケーションアカウントに分離しなかったのでしょうか？

A: コンピュートとネットワークリソースの移行は、S3バケットへのリソースポリシーの更新と比べて桁違いに複雑だからです。IAMロールの分離だけでも、セキュリティの観点から大きな改善が得られます。たとえばSSRF脆弱性が悪用された場合でも、攻撃者が引き起こせる被害を大幅に制限できます。
 状態の移行に関する課題についてQ: インフラストラクチャの状態移行において、どのような課題に直面しましたか？

A: 最大の学びは、可能であれば避けるということです。多くの場合、リソースは元の場所に残したまま、クロスアカウントアクセスを活用しています。たとえば、複数のプロデューサーとコンシューマーを持つS3バケットは、そのままの場所に残して汎用的なABACポリシーを適用する方が賢明です。
 アカウントインベントリについてQ: アカウントインベントリについて何度か言及されていましたが、どのように実装していますか？

A: 私たちはNetflixが作成したオープンソースツール「swag」を使用しています。現在、アカウント数の急増に伴いスケールの課題に直面していますが、シンプルなCRUD APIでも十分かもしれません。
 サービスの健全性チェックについてQ: すべてのサービスの健全性チェックが複雑に聞こえますが、実際には何を構築したのですか？

A: 私たちはSpinnakerのヘルスチェック機能に大きく依存しています。Netflixが長年かけて構築してきた基盤を活用することで、この課題を解決しています。