Skip to content

2026年02月04日

[Redshift] Amazon Redshift now supports autonomics for multi-cluster environments

概要

Amazon Redshiftの自動最適化(Autonomics)がマルチクラスタ環境に対応しました。複数のデータウェアハウス/コンシューマクラスタにまたがるクエリパターンを考慮して、テーブルレイアウトとメンテナンスを自動で最適化します。

変更内容・新機能の詳細

今回の拡張により、Automatic Table Optimization (ATO)、Automatic Table Sorting (ATS)、Auto Vacuum、Auto Analyze といった既存のAutonomics機能が、単一クラスタではなく複数のクラスタ(複数の消費者クラスタ/ウェアハウス)にまたがるクエリパターンを総合的に考慮して動作するようになりました。これにより、共有データに対してビジネスユニットやチームごとに分散したワークロードを一括で分析し、ソートキーやエンコーディング、テーブルの物理レイアウト変更や自動メンテナンスの実行タイミングを決定します。また、特定のエンドポイントやAWSアカウントを最適化判断から除外できるdenylist機能が追加され、クロスオーガニゼーションのデータ共有などで一部のクエリが最適化方針を歪めるのを防げます。これらの拡張Autonomicsは追加料金なしで利用でき、Amazon Redshiftをサポートする全リージョンで提供されます。詳細な有効化手順やdenylistの設定はAmazon Redshift Management Guideを参照してください。

影響範囲・利用シーン

  • 対象ユーザー: Amazon Redshiftを複数クラスタ(複数ワークスペース/ウェアハウス)で運用するデータベース管理者、プラットフォームチーム、SRE/運用チーム
  • 利用シーン: 複数事業部が同一データセットを参照するマルチテナント/分散ワークロード環境におけるテーブル最適化とメンテナンス自動化。クロスアカウント/クロスエンドポイントでのデータ共有がある環境での最適化適用除外(denylist)
  • 運用効果: 手動でのクラスタ間調整や個別チューニング作業を削減し、全体最適化に基づくソート・エンコーディング・VACUUM/ANALYZEの適用でクエリ性能向上と運用負荷低減が期待できる

技術的な注意点

  • IAM権限: Autonomicsおよびdenylist設定の変更には適切なRedshift管理権限(管理者ロールや該当API呼び出し権限)が必要です。詳細はドキュメントで確認してください。
  • リージョン制限: 全リージョンで提供されています(Amazon Redshiftをサポートするリージョンにて利用可能)。
  • コスト: 機能自体に追加課金はありませんが、自動的なテーブル再編成やVACUUM等の実行により一時的なI/Oやクエリ遅延、ストレージ利用量の変動が発生する可能性があります。
  • denylistの挙動: denylistで除外したエンドポイント/アカウントは最適化判断の入力に含まれなくなりますが、該当クエリ自体の実行は引き続き許可されます。除外は最適化モデルへの影響を防ぐためのものである点に注意してください。
  • 監視と検証: マルチクラスタ最適化の適用前後でクエリパフォーマンス(クエリ実行時間、スループット)、WLM設定、テーブルサイズやVACUUM/ANALYZE履歴を監視し、必要に応じて手動調整やdenylistの追加を行ってください。

参考情報


[DynamoDB] Amazon DynamoDB global tables now support replication across multiple AWS accounts

概要

Amazon DynamoDB のグローバルテーブルが複数の AWS アカウント間でのレプリケーションをサポートしました。これにより、アカウント単位の分離を維持しつつマルチリージョン/マルチアクティブ構成での耐障害性と可用性を向上できます。

変更内容・新機能の詳細

新機能により、DynamoDB グローバルテーブルは別アカウントのテーブルをレプリカとして自動的に追加して、アカウントを跨いだマルチリージョン/マルチアクティブなレプリケーションを行えるようになりました。主な特徴は以下のとおりです。

  • 自動レプリケーション: テーブルを複数アカウント・複数リージョンにまたがって自動的に複製し、書き込みは各リージョンで受け付ける多重書き込み(マルチアクティブ)をサポートします。
  • アカウント単位の分離: レプリケーション先を別アカウントにすることで、セキュリティやガバナンス(IAM、KMS、監査ログ等)をアカウント単位で分離・適用できます。
  • 利用可能範囲と課金: 全ての AWS リージョンで利用可能。課金は既存のグローバルテーブルの料金体系に準じます(レプリケートされた書き込み/転送に伴う料金が発生)。
  • 運用面: マルチアカウント戦略を取る組織(AWS Organizations 利用など)で、DR、データ配置ポリシー、ワークロード分離が容易になります。
  • 技術的前提: グローバルテーブルではレプリカ間でのテーブルスキーマ(パーティションキー/ソートキーや GSI 等)整合が必要、DynamoDB Streams を基にレプリケーションを実行するためストリームの有効化等が前提となります。また競合解決はグローバルテーブルの仕様(multi-master の競合解決ポリシー)に従います。
  • セキュリティ考慮: SSE-KMS 等の顧客管理型 KMS キーを使う場合、クロスアカウントでのレプリケーションに向けてキーのポリシーやアクセス許可を適切に設定する必要があります。

影響範囲・利用シーン

  • 対象ユーザー: マルチアカウント運用を行う組織、SaaS プロバイダ、セキュリティ/ガバナンス担当者、SRE/運用チーム
  • 利用シーン: アカウント分離を維持したままリージョン障害やアカウント障害に対する耐障害性を向上させたいシナリオ(DR、リージョン分散、組織単位のデータ配置)
  • 運用効果: アカウント単位でセキュリティポリシーや監査を独立して適用しつつ、アプリケーションの高可用性とフォールトトレランスを強化できる
  • ビジネス効果: 法規制やデータ主権、組織の分離要件に応じたデータ配置とアクセス制御が容易になり、ガバナンス要件を満たしやすくなる

技術的な注意点

  • IAM権限: レプリケーション設定には各アカウントでテーブルの作成/更新権限と、クロスアカウント操作を許可するためのロール/トラストポリシーが必要です。設定時に必要な API/コンソール権限を事前に確認してください。
  • リージョン制限: 記事時点では「すべての AWS リージョンで利用可能」と記載されていますが、利用前に対象リージョンでのドキュメント確認を推奨します。
  • コスト: 既存のグローバルテーブル課金体系に準じます。レプリケートされる書き込み・読み取り、データ転送(クロスリージョン)のコストや、プロビジョニング/オンデマンドキャパシティ、ストレージ、Streams による追加課金を考慮してください。
  • 暗号化(KMS): SSE-KMS(顧客管理キー)を使用する場合は、レプリケーション先アカウントからキーを使用できるように KMS キーポリシーでクロスアカウントアクセスを許可する必要があります。
  • テーブル設計: レプリカ間で主キーや GSI、TTL、タグ等の互換性が必要です。スキーマ変更は各レプリカでの同期を考慮して実施してください。
  • 一貫性と競合解決: グローバル/マルチマスターの性質上最終的整合性や競合(last-writer-wins 等の既定の挙動)を理解し、アプリケーション側で衝突対策やタイムスタンプ設計を行ってください。
  • 運用注意: レプリケーションのモニタリング(CloudWatch メトリクス、Streams、レプリケーション遅延の監視)と障害時の運用手順を整備してください。

参考情報


[Marketplace] AWS Marketplace introduces localized billing for Professional Services from AWS EMEA

概要

AWS Marketplaceは、EMEA(Europe, Middle East, Africa)のお客様向けにProfessional Services(コンサルティング/実装/マネージドサービス等)購入時の課金をローカライズしました。AWS EMEAをMarketplace Operatorとして、SEPA等のローカル決済手段で支払いが可能になり、請求書をAWS EMEA発行に統一できます。

変更内容・新機能の詳細

本機能は、AWS Marketplace上で提供されるProfessional Servicesソリューションの購入において、請求・支払プロセスをEMEA向けにローカライズするものです。具体的には:

  • 支払方法:SEPA(Single Euro Payment Area)などのローカル決済手段をサポートし、SEPAダイレクトデビット等の登録が可能です。
  • 請求主体:AWS EMEAがMarketplace Operatorとして請求書を発行するため、これまで複数のAWS法人体間で発生していた支払振替・送金の複雑さが軽減されます。
  • 適用範囲:AWS EMEAをMarketplace OperatorとするProfessional Servicesの購入が対象。サードパーティ出品者の契約条件や価格設定自体は変わりませんが、請求と支払のエクスペリエンスが統合されます。
  • 運用:顧客はAWSの請求支払画面(Billing and Cost Management)でSEPA用の銀行口座を追加・管理できます。請求書はAWS EMEA名義で発行されるため、会計・税務処理が簡素化する可能性があります。 技術的には、Marketplaceのオペレーター設定と支払方法の組み合わせによる請求エンティティの切替であり、購入フローやMarketplaceのUIは従来通りですが、請求先・支払方法の選択肢がEMEA向けに拡張されています。

影響範囲・利用シーン

  • 対象ユーザー: EMEA地域のクラウド利用企業、購買/調達部門、財務・会計チーム、SRE/クラウド運用チーム
  • 利用シーン: AWS Marketplaceでのコンサルティング、導入支援、マネージドサービスの調達(SEPAでの支払いを希望するケースや請求をAWS EMEAに集約したいケース)
  • 運用効果: 請求・支払の統一により調達手続きが簡素化され、国際送金や複数AWS法人体間の請求リマインダ処理を減らせるため、支払遅延や手続きエラーの低減が期待できる

技術的な注意点

  • IAM権限: Marketplaceで購入・請求情報を管理するには、適切なBilling/IAM権限(請求情報表示・支払方法管理権限など)が必要です
  • リージョン制限: 本機能はEMEA地域向けで、AWS EMEAがMarketplace Operatorとなる購入に限定されます(東京などEMEA外リージョンでは利用不可)
  • 出品者参加: すべてのProfessional Services出品者が自動的に対象になるわけではなく、出品者側のMarketplace設定やオペレーター選択の影響を受ける場合があります。購入前に請求主体がAWS EMEAであることを確認してください
  • 請求・税務処理: 請求書がAWS EMEA発行となるため、VAT処理や会計処理上の扱いが変わる可能性があります。財務・税務担当と事前に確認してください
  • コスト: サービス価格そのものは変わりませんが、銀行手数料・為替処理や支払条件(支払期限など)が影響を受ける場合があります
  • 設定手順: SEPAダイレクトデビットを利用する場合は、AWSのBilling and Cost Managementで銀行口座を追加する必要があります(別途承認フローや口座確認が発生することがあります)
  • 互換性/制限: 本機能はProfessional Services購入向けであり、ソフトウェアサブスクリプションや一部のマーケットプレイス商品には適用されない可能性があります。詳細は購入画面やFAQで確認してください

参考情報


[RDS] Amazon RDS now provides an enhanced console experience to connect to a database

概要

Amazon RDS コンソールに、データベース接続に必要な情報を一箇所に集約した強化された接続画面が追加されました。言語別のコードスニペットやpsql等のツール、統合CloudShellから直接接続できる機能が利用可能です。

変更内容・新機能の詳細

新しいコンソール体験は、接続エンドポイント、ポート、データベース名などの基本情報に加え、Java、Python、Node.js 等のプログラミング言語向けの接続コードスニペットや psql 等のコマンド例を自動生成して表示します。生成されるスニペットはデータベースの認証設定(例えば IAM データベース認証)に応じて自動的に調整され、IAM 認証が有効なクラスタではトークンベースの接続コードが出力されます。さらに、RDS コンソール内から直接 CloudShell を起動し、そのままデータベースに接続できる統合ワークフローを提供します。対応エンジンは Amazon Aurora PostgreSQL、Amazon Aurora MySQL、Amazon RDS for PostgreSQL、Amazon RDS for MySQL、Amazon RDS for MariaDB で、すべての商用 AWS リージョンで利用可能です。開発・運用の初期接続作業を簡素化し、環境固有の設定ミスを減らすことを目的としています。

影響範囲・利用シーン

  • 対象ユーザー: アプリケーション開発者、データベース管理者(DBA)、SRE/運用チーム
  • 利用シーン: ローカル/クラウドアプリケーションからの初期接続設定、サンプルコードの迅速な取得、コンソール内での検証やトラブルシュート(psqlやCloudShellを使った直接接続)
  • 運用効果: 接続情報や認証方式に合わせたコードを自動生成することで接続ミスを削減し、セットアップ時間を短縮。CloudShell 統合によりローカル環境依存を減らして迅速な検証が可能になる

技術的な注意点

  • IAM権限: コンソールで接続情報やコードを表示するには RDS リソースを参照する権限が必要。IAM データベース認証を使う場合は rds-db:connect のリソースポリシー設定や、RDS 側での IAM 認証ユーザー設定(PostgreSQL の rds_iam 等)が必要です
  • ネットワーク接続: CloudShell や生成されたクライアントから DB に接続するには、セキュリティグループやサブネット、パブリック可否(Publicly Accessible)の設定、必要に応じて VPC 内からの接続経路(Bastion/Session Manager 等)が適切に構成されている必要があります
  • トークンの有効期限: IAM データベース認証で生成される認証トークンは短時間(通常約15分)で有効期限切れになるため、長時間の接続確立やバッチ処理では再発行の仕組みが必要です
  • リージョン制限: 記載のとおり「すべての商用 AWS リージョン」で利用可能。AWS 中国リージョンやGovCloudなどは別扱いの可能性があるため、必要なら対象リージョンで確認してください
  • コスト: このコンソール機能自体に追加料金は発生しません。ただし、CloudShell の使用は無料枠があるものの上限超過や、接続先 RDS の利用(インスタンス稼働、データ転送)には通常の料金が発生します

参考情報


[Lake Formation] AWS Lake Formation is now available in Asia Pacific (New Zealand) Region

概要

AWS Lake Formationがアジアパシフィック(ニュージーランド)リージョンで利用可能になりました。これにより、同リージョン内でデータレイクのアクセス制御やセキュアなデータ共有を集中管理できます。

変更内容・新機能の詳細

AWS Lake Formationは、S3に置かれたデータに対してデータ位置の定義、細粒度(列/行レベル、LFタグ等)のアクセス許可、カタログ管理、クロスアカウント共有のための制御を提供するサービスです。ユーザーは集中管理されたAWS Glue Data Catalogを参照してデータセットのメタデータと使用方法を把握でき、Amazon EMR(Apache Spark)、Amazon Redshift、AWS Glue、Amazon QuickSight、Amazon Athenaなどの分析・機械学習サービスでそれらのデータを利用できます。リージョン追加に伴い、ニュージーランドリージョン内のワークロードが低レイテンシでLake Formationのポリシー管理とデータ共有機能を利用可能になります。詳細は公式ドキュメントおよびリージョン対応表を参照してください。

影響範囲・利用シーン

  • 対象ユーザー: データエンジニア、データガバナンス担当、SRE/運用チーム
  • 利用シーン: ニュージーランド域内でのデータレイク構築、細粒度アクセス制御の適用、組織内外へのセキュアなデータ共有
  • 運用効果: カタログと権限を中央管理することで権限設定の一貫性向上、違反リスク低減、分析基盤の運用効率化が期待できる

技術的な注意点

  • IAM権限: Lake Formation用の管理/利用権限(例: AWSLakeFormationFullAccess 相当や細かいLF権限)とGlue/S3への必要なIAMロールやポリシーを事前に設定してください
  • リージョン制限: 本アナウンスはアジアパシフィック(ニュージーランド)リージョンでの提供開始を示します。他リージョンでの対応状況はリージョン対応表を確認してください。クロスリージョン共有は制約があるため設計時に確認が必要です
  • コスト: Lake Formation自体に明確な追加料金が発生しないケースがありますが、Glue(カタログ・ETL)、Athena/Redshift/EMRのクエリ処理、S3ストレージやデータ転送、KMSキー使用料など基盤サービスの費用が発生します
  • データカタログ/統合: Lake FormationはGlue Data Catalogを利用します。既存のカタログと統合する場合はGlueのバージョンやメタデータ整合性に注意してください
  • データ保護/暗号化: S3側の暗号化(SSE-S3/SSE-KMS)やKMSキーのリージョン制限、鍵ポリシーがアクセス制御に影響するため事前確認が必要です
  • 共有/クロスアカウント: クロスアカウント共有機能を利用する際はリソースリンク、プリンシパルへの権限付与、受け手側のアカウント設定(Glueカタログ利用権限など)を適切に構成してください

参考情報


[Connect] Amazon Connect launches an appeals workflow for agent performance evaluations

概要

Amazon Connectにエージェントの評価に対する異議申し立て(appeal)を組み込んだワークフローが追加されました。エージェントはConnectのUI上で評価に対する異議と理由を提出でき、管理者はメール通知で確認・対応し、ステータスを追跡できます。

変更内容・新機能の詳細

新機能はAmazon Connectの評価(エージェントパフォーマンス評価)に対する統合された異議申立てワークフローを提供します。具体的には、エージェントが評価結果に同意しない場合、ConnectのUIから該当評価に対する異議(理由や該当会話の具体例など)を提出できます。申立てが行われると、指定された管理者に自動でメール通知が送信され、管理者は管理画面から異議をレビューして解決(承認・却下・追加コメントなど)できます。管理者向けUIではどの評価が異議申立て済みか、その解決状況(未対応/対応中/解決など)を一覧で監視・追跡可能です。本ワークフローはConnectの評価記録と統合され、監査用のトレイルや運用プロセスに組み込みやすく設計されています。公式発表では、この機能はAmazon Connectが提供されているすべてのリージョンで利用可能とされています。詳細な設定や運用方法は公式ドキュメントを参照してください。

影響範囲・利用シーン

  • 対象ユーザー: コンタクトセンター運営者、QA/品質管理者、スーパーバイザー、チームリーダー
  • 利用シーン: エージェント評価の公正性担保、評価に対するエージェントからの異議申立て処理、評価結果のレビューやトレーニング計画の改善
  • 運用効果: 評価の透明性とエージェントのエンゲージメント向上、異議を追跡することで対応遅延の削減と監査対応の容易化

技術的な注意点

  • IAM権限: 異議をレビュー・解決する管理者アカウントには、Amazon Connectの評価閲覧・編集権限が必要です。導入前に権限ポリシーを確認してください
  • リージョン制限: 発表ではAmazon Connect提供リージョンすべてで利用可能とされています(リージョン差異が出る可能性があるため導入前に自リージョンを確認してください)
  • コスト: この機能自体に別料金の記載はありませんが、Connectの通常利用料、評価データの保存量増加や通知(メール)に関連する料金、ログ保存・エクスポートに伴うストレージ費用は発生する可能性があります
  • ログ/監査: 異議の履歴や解決アクションは運用上重要です。CloudWatch LogsやS3エクスポート等でログ保管ポリシーを検討してください
  • 通知設定: 管理者への自動メール通知は機能の一部ですが、メールの受信先設定や送信制限(SPF/DMARCや社内フィルタ)を確認してください
  • API/統合: 発表は主にUIベースのワークフローを示しています。API連携や外部システムへの通知連携が必要な場合は公式ドキュメントで対応APIやエクスポート機能を確認してください

参考情報


[General] Amazon Aurora DSQL now supports indexes on the NUMERIC data type

概要

Amazon Aurora DSQL が NUMERIC データ型のカラムに対するインデックス作成をサポートしました。これにより、NUMERIC を主キーおよび二次インデックスで利用でき、高精度数値を扱うクエリの性能が向上します。

変更内容・新機能の詳細

今回の変更で、Aurora DSQL 上の NUMERIC 型カラムに対してインデックス(主キーおよび二次インデックス)の作成が可能になりました。NUMERIC は固定小数点(任意精度の十進数)として正確な比較・並び替えを提供するため、通貨や精密測定値、統計データなど高精度を要するワークロードでの等価検索・範囲検索・ORDER BY の性能改善が期待できます。インデックス化により読み取り(SELECT)クエリの応答が速くなる一方で、インデックスの保持・更新により書き込み(INSERT/UPDATE/DELETE)のコストとストレージ使用量は増加します。インデックスのサイズや更新負荷は宣言する精度(精度とスケール)やデータ分布に依存します。

影響範囲・利用シーン

  • 対象ユーザー: データベース設計者、アプリケーション開発者、SRE/運用チーム
  • 利用シーン: 通貨や金額をキーにした検索、測定値や統計値に基づく範囲検索・ソート、精度を要求する結合(JOIN)やグルーピング処理
  • 運用効果: NUMERIC を用いるクエリの検索・ソート性能が改善され、レスポンス向上やクエリプランの効率化が期待できる(ただしインデックス維持による書き込み負荷増加とストレージコスト増に留意)

技術的な注意点

  • IAM権限: DBインスタンスの操作はAWS側のIAM権限が必要。スキーマ変更(インデックス作成/削除)自体はデータベース内のCREATE/ALTER権限が必要です
  • 精度/スケール: NUMERIC の宣言(精度・スケール)によりインデックスの格納サイズと性能が変わります。高精度設定はインデックスサイズ増とI/O増につながる可能性があります
  • パフォーマンス/コスト: 読み取り性能は向上するが、インデックスのメンテナンスで書き込みレイテンシとストレージ使用量が増加します。コスト影響を評価してください
  • インデックス作成の運用: 大規模テーブルでのインデックス作成は時間とI/Oを要します。メンテナンスウィンドウやオンライン/非ブロッキング作成オプション(エンジンがサポートする場合)の利用を検討してください
  • 互換性: NUMERIC は浮動小数点(FLOAT/DOUBLE)とは挙動が異なり、丸め・比較の挙動をアプリ側で確認してください
  • リージョン制限: 公開情報では特定リージョン制限の記載はありません。利用開始前に公式ドキュメントで対応リージョンを確認してください

参考情報


[General] AWS Management Console now displays Account Name on the Navigation bar for easier account identification

概要

AWS Management Consoleのナビゲーションバーにアカウント名を表示する機能が全パブリックリージョンで一般提供(GA)になりました。これにより複数アカウント運用時にアカウントの識別が視覚的に容易になります。

変更内容・新機能の詳細

ナビゲーションバーに「アカウント名」を表示する機能が全てのパブリックAWSリージョンでGAとして利用可能になりました。表示はそのアカウントに対して認可された全ユーザーに適用され、従来の数値によるアカウントIDだけでなく、管理者が設定したアカウント名で一目で識別できます。機能自体は追加料金不要で提供されます。利用開始にはアカウント管理者による有効化が必要で、管理用ポリシーや設定手順はAWSのドキュメントに記載されています。アカウント名は通常、AWS Organizationsの表示名やアカウント設定での名称を基に表示されるため、命名規約を整えておくとより効果的です。

影響範囲・利用シーン

  • 対象ユーザー: マルチアカウントを運用するクラウドエンジニア、SRE、開発チーム、組織の管理者
  • 利用シーン: 開発/ステージング/本番など環境ごとのアカウント識別、複数事業部やプロジェクトでのアカウント切替時の確認
  • 運用効果: アカウントIDのみでの判別ミス低減、誤操作の抑止、運用負荷の軽減(コンソール操作時の確認が短縮される)

技術的な注意点

  • IAM権限: 管理者が機能を有効にする必要があるため、該当するIAM権限(管理ポリシーの適用やOrganizationsの設定変更権限)が必要です。詳細は管理ポリシーのドキュメントを参照してください。
  • リージョン制限: 全てのパブリックAWSリージョンでGA。ただし、AWS GovCloud、Chinaリージョンなどパブリック外のリージョンでは未対応の可能性があるため要確認です。
  • コスト: 追加料金は発生しません(無料機能)。
  • 表示元: 表示される名前はOrganizationsのアカウント表示名やアカウント設定の名称に依存します。名前変更は管理者側で行ってください。
  • 伝播/反映: 管理者による有効化や名称変更後、反映に数分の遅延が発生する場合があります。ブラウザのキャッシュや再ログインで確認してください。
  • 運用上の注意: 類似したアカウント名は混同を招くため、明確な命名規約(環境・リージョン・用途など)を定めて運用することを推奨します。

参考情報


[Iam Identity Center] AWS IAM Identity Center enables account access and application use in multiple AWS Regions

概要

IAM Identity Center(旧AWS SSO)は、プライマリリージョンで有効化した設定を任意の追加リージョンへ自動複製できるようになり、ユーザーのアクセス耐障害性向上やアプリケーションのリージョン配置(データ居住性や低遅延)に対応します。

変更内容・新機能の詳細

新機能により、IAM Identity Centerの組織インスタンス(organization instance)をプライマリAWSリージョンから選択した追加リージョンへ自動で複製できます。複製される情報にはアイデンティティ(ユーザー/グループ)、エンタイトルメント(アカウントやアプリケーションへの割当)、および関連メタデータが含まれます。プライマリリージョンで障害が発生した場合でも、追加リージョンに複製済みのエンタイトルメントを使ってユーザーは既にプロビジョニングされたAWSアカウントやアプリケーションへアクセスし続けられます。AWSアプリケーション管理者は標準のアプリケーション展開ワークフローで追加リージョンにアプリをデプロイでき、そのリージョン上でユーザー割当を行えます。一方、IAM Identity Center自体の管理は引き続きプライマリリージョンで行います。本機能は現在、組織インスタンスかつOktaなどの外部IDプロバイダーに接続された環境で、17の“enabled-by-default”商用リージョンで利用可能です。組織インスタンス側はマルチリージョン対応のカスタマー管理型KMSキー(CMK)を設定する必要があり、CMKの保存・使用には標準のAWS KMS料金が適用されます。IAM Identity Centerサービス自体に追加料金はかかりません。追加で対応可能なAWSアプリケーションの一覧は公式の“AWS applications that you can use with IAM Identity Center”で確認できます。

影響範囲・利用シーン

  • 対象ユーザー: クラウド運用(SRE)/ID管理者、アプリケーション管理者、セキュリティチーム
  • 利用シーン: アカウントアクセスの高可用性(リージョン障害時のフェールオーバー)、アプリケーションのデータ居住要件対応、エンドユーザー遅延低減のためのアプリ配置
  • 運用効果: 単一リージョン依存のリスク低減、ユーザーアクセスの継続性確保、地域要件に合わせたアプリ展開が可能になりコンプライアンスやパフォーマンス要件を満たせる

技術的な注意点

  • インスタンス要件: 組織インスタンス(organization instance)でのみ利用可能です
  • 外部IDプロバイダー: Oktaなどの外部IdPに接続されている環境が対象です
  • KMS: マルチリージョン対応のカスタマー管理型KMSキー(CMK)を設定する必要があります(CMKはマルチリージョンでレプリケートする設計を推奨)
  • IAM権限: 複製設定やCMK管理の権限(Organizations、IAM Identity Center管理、KMSの管理権限など)が必要です。管理者はプライマリリージョンで操作を行います
  • リージョン制限: 現時点では“enabled-by-default”として有効化された商用リージョンの17リージョンで利用可能。すべてのリージョンやローカルリージョンでは未対応の可能性があります。詳細はドキュメントで確認してください
  • レプリケーション遅延: 複製は自動化されますが、設定反映に若干の遅延が発生する場合があります。即時性が必要な運用フローは確認が必要です
  • アプリケーション互換性: すべてのAWSアプリケーションが追加リージョン展開に対応しているわけではありません。対応状況は“AWS applications that you can use with IAM Identity Center”で確認してください
  • コスト: IAM Identity Center自体に追加料金はありませんが、マルチリージョンCMKの保存・使用には標準のAWS KMS料金が発生します。アプリケーションを追加リージョンへ展開する場合はそのリージョンでの通常のリソース料金がかかります
  • 監査/ログ: 複製後のアクセスログや監査設定が期待通りに動作するか、CloudTrailやログ集約の構成を確認してください

参考情報


[General] Amazon Quick Suite Enables Easy Resolution of Ambiguous Map Locations

概要

Amazon Quick Suite の QuickSight で、地名が複数箇所に存在して曖昧になるケース(例:Springfield)がある場合に、マップビジュアル上から直接その場所を解決・更新できる機能が追加されました。これによりジオビジュアライゼーションの精度が向上します。

変更内容・新機能の詳細

QuickSight のマップビジュアルで場所名が複数の地域に存在してマッピングが曖昧になった際、ダッシュボード作者は直接ビジュアル上で該当レコードの地理的コンテキストを明示的に指定できます。解決方法は主に3種類です:

  1. 補助のジオ空間フィールドをデータセットに追加して階層(国/州/市 等)を構築し、より厳密に一致させる方法
  2. Quick Suite 内蔵の地理データベースから特定の場所を検索して紐付ける方法(地名と該当するリージョンを選択)
  3. 緯度・経度(latitude/longitude)を直接入力してピンポイントで配置する方法 UI上では各ロケーションについて Unmatched(未一致)/Matched(一致)/Unused(未使用)といったステータスが表示され、どのレコードが解決済みか、未解決かを把握できます。マップ上から「Resolve now」または「Geo data match」オプションを使ってその場で解決操作ができ、解決結果はマップ表現に反映されます。本機能は QuickSight をサポートするすべての Amazon Quick Suite リージョンで利用可能です。

影響範囲・利用シーン

  • 対象ユーザー: BI/データ分析者、ダッシュボード作成者(QuickSight Authors)、データエンジニア
  • 利用シーンまたは効果: データ内に同名の地名が複数存在する(例:複数州にまたがる市名)ケースで、マップ可視化の地理的誤配置を防ぎ、正確な地域別分析や可視化を実現
  • 運用効果: ダッシュボード作成時の地図修正作業が簡素化され、誤った地域集計による意思決定リスクを低減。ステータス表示により未解決の位置データを効率的に把握・対応できる

技術的な注意点

  • IAM権限: QuickSight の分析(Analysis)編集/ダッシュボード更新権限が必要です。データセットに対する編集権限(列の追加やフィールドタイプ変更)が必要な場合があります。
  • リージョン制限: 記事によれば QuickSight をサポートする全リージョンで利用可能ですが、組織のリージョン設定や将来的なロールアウト差異に注意してください。
  • データ準備: 階層化(国/州/市)に使うフィールドをあらかじめ用意するか、緯度・経度列は数値(小数)で正確に格納しておく必要があります。住所文字列のみの場合は一致率が低くなるため補助フィールドの追加を推奨します。
  • 互換性/永続性: ビジュアル上で解決したマッピングがデータセット単位で永続化されるか(他のビジュアルへ波及するか)は設定やデータセット構成によるため、既存ダッシュボードへの影響を検証してから本番適用してください。
  • コスト: この機能自体による追加課金は明記されていませんが、QuickSight の通常料金体系(ユーザー課金、セッション課金、SPICE ストレージ等)が適用されます。大量にデータを加工・保存する場合はストレージ/クエリコストの影響を確認してください。

参考情報

AI要約はOpenAI GPT-5-miniによって生成されています。