Amazon Redshift のロゴ

Amazon Redshift / リリースノート / 2025/03/13 / 通常

Amazon Redshift document history: Amazon Redshift service-linked role policy adds lakeformation:GetDataAccess

dataセキュリティ

公式リリースノート

Amazon Redshift の behavior changes ページに、Amazon Redshift service-linked role policy adds lakeformation:GetDataAccess が掲載されています。これは新機能の紹介というより、既存ワークロードの前提が変わる可能性を事前に知らせる運用上の重要な告知です。

要点

  • 変更日または適用開始日: 2025-03-13
  • 内容: AmazonRedshiftServiceLinkedRolePolicy に lakeformation:GetDataAccess permission が追加されました。
  • 対象環境では、接続、権限、クエリ、監査ログ、UDF などの実装前提を確認する必要があります

今回の変更で何が変わるのか

Lake Formation 管理下のデータに Redshift がアクセスする構成では、service-linked role の権限変更がデータレイク連携や Glue Data Catalog 経由のクエリ実行に関わります。権限不足の回避だけでなく、監査上どのAWS管理ポリシーがどの操作を許可しているかを把握する必要があります。

Redshift の behavior change は、patch version のように「新しい機能が増えた」だけではなく、既存の SQL、接続設定、監査ログ、ネットワーク、UDF 運用が同じ前提で動き続けるかを確認するための告知です。該当機能を使っていないチームにとっては影響が小さい一方、使っているチームでは、リリース日を過ぎたあとに突然トラブルとして見えることがあります。

対象になりそうなユーザー・チーム

  • Redshift の本番運用、接続、権限、監査ログ、UDF を管理しているデータ基盤チーム
  • BI / ETL / アプリケーションから Redshift へ接続している開発チーム
  • セキュリティ、ガバナンス、監査ログ、データ共有の運用ルールを持つ組織

実務でまず確認したいこと

  1. 自社環境で該当機能を使っているか棚卸しする
  2. 検証環境で変更後の挙動を確認し、既存ジョブやダッシュボードの失敗有無を見る
  3. ドライバー、IAM権限、監査ログ連携、UDF移行計画など、変更対象に応じた担当者を明確にする
  4. 変更日以降の監視項目と問い合わせ先を運用手順に追記する

どう読むべきか

この種の告知は、華やかなリリースではありませんが、運用リスクを下げるうえでは重要です。Redshift をデータ基盤として使っている場合、behavior changes はリリースノート本体と同じくらい定期的に確認し、変更日、対象機能、移行先、検証方法をチーム内の運用タスクへ落とし込むのがよい読み方です。