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 Tables、AWS Glue Data Catalog、Amazon Athena、Amazon EMR、Amazon Redshiftをまたいで、Iceberg tablesとmaterialized viewsをIAMベースで扱う実装ガイドです。

要点

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

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

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

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

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

対象になりそうなチーム

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

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

1. S3 Tables、Glue Data Catalog、Redshift external schemaの責任分界を整理する
2. IAM policyだけで足りる範囲と、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 TablesとGlue Data Catalogを使ってデータの正本と権限を共通化し、RedshiftやAthena、EMRを用途別のcomputeとして使う設計にあります。Redshift利用者にとっては、warehouse外のIceberg dataをどう安全に分析対象へ入れるかを考える材料になります。