Amazon Redshift 2026年5月11日の公式ブログ解説: S3 Tables と Iceberg materialized views の権限管理

AWS は 2026年5月11日、How to use streamlined permissions for Amazon S3 Tables and Iceberg materialized views を AWS Big Data Blog で公開しました。Amazon S3 テーブル、AWS Glue Data カタログ、Amazon Athena、Amazon EMR、Amazon Redshiftをまたいで、Iceberg テーブルとmaterialized viewsをIAMベースで扱う実装ガイドです。

要点

• Amazon S3 テーブル は AWS Glue Data カタログ と統合され、IAMベースのauthorizationでstorage、カタログ、computeの権限をまとめて定義できる
• Iceberg materialized viewsは、集計やjoinの結果をAmazon S3上のIceberg dataとして保持し、繰り返しクエリの再計算を減らす
• 記事ではAthena、EMR、RedshiftからS3 テーブルやIceberg materialized viewsを扱う手順が説明されている
• Amazon RedshiftではGlue Data カタログのリソース linkとexternal スキーマを使い、S3 テーブル カタログ配下のテーブルへアクセスする構成が示されている
• より細かな制御が必要な場合は、AWS Lake Formationを後から重ねられる

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

この記事は、Amazon Redshift単体の新機能紹介というより、AWSの分析スタック全体でIceberg テーブルをどう安全に使うかを説明する実装ガイドです。S3 テーブルは、Apache Iceberg テーブルをAmazon S3上でmanagedに扱う仕組みで、Glue Data カタログと統合することで、Athena、EMR、Redshift、Glueなど複数の分析サービスから同じデータを参照できます。AWSはここで、S3 テーブル、カタログ、computeの権限をIAM ポリシーでまとめて定義できる点を強調しています。既にIAMを中心に運用しているチームにとっては、Lake Formationを必須にせず、まずIAMベースでアクセス制御を始められるのが実務上のポイントです。

もう1つの軸はIceberg materialized viewsです。大規模データに対して同じ集計やjoinを何度も実行する場合、毎回base テーブルを再処理するとコストやレイテンシが大きくなります。Iceberg materialized viewでは、事前計算された結果をS3上のIceberg dataとして保持し、必要に応じて手動またはスケジュールでrefreshできます。記事ではEMRでmaterialized viewを作成し、AthenaやRedshiftからアクセスする流れも示されています。これは、open テーブル formatを軸にしながら、複数engineで同じ事前計算結果を使いたい組織にとって重要です。

Redshift観点で見ると、Glue Data カタログのリソース linkを作り、Redshift側でexternal スキーマを定義してS3 テーブル カタログのデータを参照する手順が紹介されています。つまり、Redshiftはウェアハウス内のデータだけでなく、S3 テーブル上のIceberg dataやmaterialized viewを分析対象として扱う構成に入ります。データレイクとDWHを分けるのではなく、カタログと権限を共通化しながら、Athena、EMR、Redshiftがそれぞれ得意なquery engineとして使われる形です。実務では、IAM ポリシー、Glue リソース link、external スキーマ、refresh設計、Lake Formationを使うかどうかを合わせて検討する必要があります。

対象になりそうなチーム

• Amazon Redshift と S3 テーブル / Iceberg を併用するdata platform team
• Glue Data カタログを中心にAthena、EMR、Redshiftの権限を整理したいAWS analytics管理者
• Iceberg materialized viewsで集計コストやクエリ時間を抑えたいデータ基盤担当者
• Lake Formation導入前にIAMベースで統制を始めたいチーム

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

1. S3 テーブル、Glue Data カタログ、Redshift external スキーマの責任分界を整理する
2. IAM ポリシーだけで足りる範囲と、Lake Formationのfine-grained access controlが必要な範囲を分ける
3. materialized viewのrefresh間隔、手動refresh、増分refreshの運用を決める
4. Redshift、Athena、EMRのどのengineからどのデータを読むか、コストと権限の観点で設計する

結局、今回のブログ記事をどう読むべきか

このAWS Big Data Blogは、Redshiftを含むAWS分析基盤をIceberg中心へ広げるための実装記事です。ポイントは、S3 テーブルとGlue Data カタログを使ってデータの正本と権限を共通化し、RedshiftやAthena、EMRを用途別のcomputeとして使う設計にあります。Redshift利用者にとっては、ウェアハウス外のIceberg dataをどう安全に分析対象へ入れるかを考える材料になります。