Amazon Redshift / 公式ブログ / 2026/05/27 / 通常
Amazon Redshift公式ブログ解説: Zyngaのmulti-warehouse governance事例
公式ブログ原文
AWS Big Data Blog は 2026年5月27日、Zynga が Amazon Redshift federated 権限 と AWS IAM Identity Center を使い、複数の Redshift ウェアハウス にまたがるデータアクセス制御をどう整理したかを紹介しました。
要点
- Zynga は中央の Redshift 環境とスタジオ別の compute 環境をまたぐ ガバナンス を課題にしていた
- Redshift federated 権限 と IAM Identity Center を組み合わせ、producer 側の権限を consumer 側にも即時反映する構成を採った
- ユーザー向けの IAM Identity Center group と サービス account 向けの federated IAM 役割 に同じ read 権限 を付与する dual-grant pattern が中心
- 手動 grant 同期や外部ジョブを減らし、multi-ウェアハウス 構成でも一貫した tiered access control を保つ狙いがある
今回のブログ記事で語られていること
この記事は、新機能の単純な発表というより、Amazon Redshift を複数 ウェアハウス / workgroup で使う組織が、権限管理をどう破綻させないかを示す実装事例です。Zynga は複数のモバイルゲームスタジオを持ち、中央の analytics platform に telemetry や revenue data を集約しています。一方で、スタジオごとに独立した query capacity や移行段階の compute が必要になると、データは共有したいが権限は中央で一貫して管理したい、という難しい構図になります。
従来の方法では、producer cluster で定義した権限を consumer 側へ手動同期したり、外部の Lambda / Airflow のような仕組みで grant を反映したりする必要が出ます。これは小規模なら動いても、ウェアハウス が増えるほど遅延、漏れ、運用負荷が増えます。記事では、この問題に対して Redshift federated 権限 を使い、producer 側の権限を consumer workgroup に伝播させる構成が説明されています。
実務上のポイントは、IAM Identity Center の ユーザー/group と サービス account の扱いを分けていることです。人間の利用者は Okta などから IAM Identity Center に同期される group membership を通じて Redshift 役割 に対応します。一方、ETL やアプリケーションの サービス account は IAM 役割 を前提に federated ユーザー として扱われます。Zynga は、同じ read 権限 を IAM Identity Center group と federated IAM 役割 の両方へ grant する dual-grant approach を採り、人とシステムの両方で同じ access tier を保てるようにしています。
また、移行期間中の互換性にも注意が払われています。既存の producer cluster にはローカル 役割 や既存 grant が残っているため、急に全てを新方式へ切り替えると既存ユーザーに影響します。そこで記事では、legacy local 役割、IAM Identity Center group、federated IAM 役割 の三つへ grant する tri-grant approach も紹介されています。これは、既存運用を壊さずに段階移行するための現実的なパターンです。
この内容は、単に Redshift の セキュリティ機能 を知る話ではありません。複数 ウェアハウス、複数事業部、複数 リージョン、あるいは買収後の統合などで、データ共有と権限統制を両立させるための設計論です。BI や分析チームが consumer 側で自由に compute を使えるようにしつつ、データ owner は producer 側で ポリシー を一元管理したい、という組織には読みどころがあります。
実務で確認したいポイント
- producer / consumer ウェアハウス 間で、権限がどこを正とするか決める
- 人間ユーザーと サービス account の認証経路を分け、それぞれの 役割 mapping を明確にする
- 既存 local grant から IAM Identity Center / federated 役割 へ移行する期間の互換性を設計する
- 手動 grant 同期や外部ジョブが残っている場合、Redshift federated 権限 で置き換えられるか検証する
どう読むべきか
Zynga の事例は、Redshift を単一 ウェアハウス としてではなく、複数 compute 環境を持つ governed data platform として使うときの設計例です。アクセス制御を後付けの同期処理に任せず、認証・権限・compute 分離をまとめて設計する必要があることを示しています。