Amazon Redshift公式ブログ解説: Zyngaのmulti-warehouse governance事例

AWS Big Data Blog は 2026年5月27日、Zynga が Amazon Redshift federated permissions と AWS IAM Identity Center を使い、複数の Redshift warehouse にまたがるデータアクセス制御をどう整理したかを紹介しました。

要点

• Zynga は中央の Redshift 環境とスタジオ別の compute 環境をまたぐ governance を課題にしていた
• Redshift federated permissions と IAM Identity Center を組み合わせ、producer 側の権限を consumer 側にも即時反映する構成を採った
• ユーザー向けの IAM Identity Center group と service account 向けの federated IAM role に同じ read permission を付与する dual-grant pattern が中心
• 手動 grant 同期や外部ジョブを減らし、multi-warehouse 構成でも一貫した tiered access control を保つ狙いがある

今回のブログ記事で語られていること

この記事は、新機能の単純な発表というより、Amazon Redshift を複数 warehouse / workgroup で使う組織が、権限管理をどう破綻させないかを示す実装事例です。Zynga は複数のモバイルゲームスタジオを持ち、中央の analytics platform に telemetry や revenue data を集約しています。一方で、スタジオごとに独立した query capacity や移行段階の compute が必要になると、データは共有したいが権限は中央で一貫して管理したい、という難しい構図になります。

従来の方法では、producer cluster で定義した権限を consumer 側へ手動同期したり、外部の Lambda / Airflow のような仕組みで grant を反映したりする必要が出ます。これは小規模なら動いても、warehouse が増えるほど遅延、漏れ、運用負荷が増えます。記事では、この問題に対して Redshift federated permissions を使い、producer 側の権限を consumer workgroup に伝播させる構成が説明されています。

実務上のポイントは、IAM Identity Center の user/group と service account の扱いを分けていることです。人間の利用者は Okta などから IAM Identity Center に同期される group membership を通じて Redshift role に対応します。一方、ETL やアプリケーションの service account は IAM role を前提に federated user として扱われます。Zynga は、同じ read permission を IAM Identity Center group と federated IAM role の両方へ grant する dual-grant approach を採り、人とシステムの両方で同じ access tier を保てるようにしています。

また、移行期間中の互換性にも注意が払われています。既存の producer cluster にはローカル role や既存 grant が残っているため、急に全てを新方式へ切り替えると既存ユーザーに影響します。そこで記事では、legacy local role、IAM Identity Center group、federated IAM role の三つへ grant する tri-grant approach も紹介されています。これは、既存運用を壊さずに段階移行するための現実的なパターンです。

この内容は、単に Redshift の security feature を知る話ではありません。複数 warehouse、複数事業部、複数 region、あるいは買収後の統合などで、データ共有と権限統制を両立させるための設計論です。BI や分析チームが consumer 側で自由に compute を使えるようにしつつ、データ owner は producer 側で policy を一元管理したい、という組織には読みどころがあります。

実務で確認したいポイント

1. producer / consumer warehouse 間で、権限がどこを正とするか決める
2. 人間ユーザーと service account の認証経路を分け、それぞれの role mapping を明確にする
3. 既存 local grant から IAM Identity Center / federated role へ移行する期間の互換性を設計する
4. 手動 grant 同期や外部ジョブが残っている場合、Redshift federated permissions で置き換えられるか検証する

どう読むべきか

Zynga の事例は、Redshift を単一 warehouse としてではなく、複数 compute 環境を持つ governed data platform として使うときの設計例です。アクセス制御を後付けの同期処理に任せず、認証・権限・compute 分離をまとめて設計する必要があることを示しています。