AWS What's New Digest

Appearance

2026年05月20日 ​

[Local Zones] Announcing the general availability of a new AWS Local Zone in Istanbul, Türkiye ​

概要 ​

AWSはトルコ・イスタンブールに新しいAWS Local Zone（一般提供）を開設しました。これにより、エンドユーザーに近い場所で低遅延処理やデータのローカル保管が可能になります。

変更内容・新機能の詳細 ​

AWS Local ZoneはAWSリージョンを補完する形で都市部にコンピュート、ストレージ、ネットワーキングなどのコアサービスを展開する仕組みです。イスタンブールLocal Zone（識別子: eu-central-1-ist-1a）はGAとなり、以下をサポートします: Amazon EC2（C7i、M7i、R7iインスタンスファミリー）、Amazon S3（One Zone-Infrequent Accessストレージクラス）、Amazon EBS（Local Snapshots、gp3/gp2/io1/sc1/st1ボリュームタイプ）、Amazon ECS、Amazon EKS、Amazon VPC、AWS Direct Connect、Application Load Balancer。利点としてエンドユーザー向けワークロードでの単位ミリ秒（single-digit ms）遅延達成、データのローカル保管によるデータ主権・レジデンシー要件への対応、推論（AI/ML inference）用途やレガシーアプリのクラウド移行・近代化の加速が挙げられます。Local Zoneの有効化は、Amazon EC2コンソールのZonesタブから eu-central-1-ist-1a を有効化するか、ModifyAvailabilityZoneGroup API を使用して行います。料金はLocal Zones専用の価格設定が適用されるため、AWS Local Zonesの料金ページを確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: トルコ（および周辺地域）のエンドユーザーに低遅延を提供したいアプリケーション所有者、SaaS事業者、ゲーム／メディア配信事業者、AI/ML推論をエッジ寄りで行う開発者
  • 利用シーンまたは効果: ユーザー向けレスポンス改善（単位ミリ秒遅延）、データローカル保存によるデータ主権要件の遵守、リアルタイム推論やレガシーアプリの部分的オンプレ移行の代替
  • 運用効果: ユーザー体験の向上とデータバックアップのローカル保持で規制対応が容易に。ネットワーク経路短縮でトランザクション処理やストリーミングのパフォーマンス改善が期待できる
  • 制約・考慮点: Local Zoneはリージョンの完全コピーではないため利用可能サービス・APIが限定される（対応サービスを事前に確認する必要あり）

技術的な注意点 ​

  • IAM権限: Local Zoneの有効化には ec2:ModifyAvailabilityZoneGroup 等のEC2権限が必要です。Local Zone上でインスタンス・ボリューム作成を行うために ec2:RunInstances / ec2:CreateVolume などの権限も確認してください
  • リージョン制限: イスタンブールLocal Zoneはリージョン拡張（eu-central-1-ist-1a）として提供されます。全リージョンで利用できるわけではなく、Region/Zone名を指定して有効化する必要があります
  • コスト: Local Zoneは親リージョンとは別に料金が適用されることが多く（インスタンス、EBS、転送等）、S3 One Zone-IAは可用性/耐久性のトレードオフがあるためコストと耐障害性を評価してください。詳細はLocal Zonesの料金ページを参照
  • サービス対応: 提供サービスは記事記載のものに限定（EC2特定インスタンス、EBS、S3 One Zone-IA、ECS/EKS、ALB、VPC、Direct Connect等）。RDSやLambdaなど一部マネージドサービスはLocal Zoneで非対応の可能性があるため事前確認が必須
  • クォータ/キャパシティ: Local Zoneごとにインスタンス/ボリュームの上限や在庫が異なる場合があります。プロダクション移行前にクォータ確認・引き上げ申請を行ってください
  • ネットワーク: 低遅延を活かすにはVPC設計、ルーティング、Direct ConnectやTransit Gatewayの構成検討が重要です。オンプレ→Local Zoneの接続はネットワーク経路と帯域の確認を行ってください
  • データ保護: S3 One Zone-IAは単一アベイラビリティゾーン内での保存となるため、耐障害性を重視する場合はリージョン多AZストレージやクロスリージョンのバックアップ戦略を検討してください

参考情報 ​

[Transfer Family] AWS Transfer Family web apps now support federated permissions with IAM Identity Center across AWS Regions ​

概要 ​

AWS Transfer FamilyのWebアプリが、IAM Identity Centerのマルチリージョンレプリケーションを利用したフェデレーテッド権限に対応しました。これにより、IAM Identity Centerを有効化した別リージョンでTransfer Family Webアプリを作成し、既存のワークフォースIDで即時サインインできます。

変更内容・新機能の詳細 ​

従来はTransfer FamilyのWebアプリはIAM Identity Centerが有効な同一リージョンでのみ作成できましたが、IAM Identity Centerのマルチリージョンレプリケーション機能により、ID設定（ワークフォースのユーザー・グループ・Permission Setsなど）を別リージョンへ自動複製できるようになりました。手順としては、まずIAM Identity Centerで新しいリージョンを有効化すると、そのリージョンへワークフォース情報が自動で複製されます。複製後、対象リージョンでTransfer FamilyのWebアプリを作成すると、管理者は既存のIAM Identity CenterのワークフォースIDを用いて細粒度のアクセス権（Permission Sets等）を管理でき、ユーザーは既存の認証情報で即時ログイン可能です。これにより、ユーザー側の認証再設定が不要になり、レイテンシ低減や可用性向上が期待できます。なお、具体的な設定手順や制限事項はTransfer FamilyおよびIAM Identity Centerの各ユーザーガイドを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: Transfer Family（Webアプリ）を利用する開発者/運用者、IAM Identity Centerでワークフォースを管理するIAM管理者
  • 利用シーン: グローバルユーザー向けにリージョンを分散してWebベースのファイル転送（ブラウザ経由）のレイテンシを下げたい場合、リージョン単位の冗長化や災害復旧（DR）を構築する場合
  • 運用効果: ワークフォースIDの再設定不要で別リージョンのWebアプリを素早く展開できるため、ユーザーのサインイン即時性が向上し運用負荷を軽減。レイテンシと可用性の改善によりエンドユーザーの操作性が向上します。

技術的な注意点 ​

  • IAM権限: IAM Identity Centerのリージョン追加・レプリケーション設定を行う権限、及びTransfer FamilyでWebアプリを作成・設定する権限が必要です。Permission Setsやアクセス権の割当も適切に設定してください。
  • リージョン制限: 全リージョンで利用可能とは限りません。利用可否はAWSのリージョン対応状況（AWS Capabilities）で確認してください。IAM Identity Centerのマルチリージョンレプリケーションを事前に有効化する必要があります。
  • コスト: IAM Identity Center自体に追加料金はかからない場合が多いですが、Transfer FamilyのWebアプリ／サーバーの利用料金、データ転送（リージョン間のトラフィックやエンドユーザーへの配信）やストレージ（S3/EFS等）に対する通常の課金は発生します。複数リージョンでサービスを展開すると総コストが増加する点に注意してください。
  • その他注意点: 外部IdPを使用している場合は、レプリケーション先リージョンでの認証フローやIdP側の設定（コールバックURL等）が問題ないか確認してください。レプリケーションや設定反映に短時間の遅延が発生する可能性があります。また、Webアプリからアクセスするバックエンド（S3/EFS等）のリージョン設計も性能に影響するため、データの配置とネットワーク経路を見直してください。

参考情報 ​

[General] Amazon MWAA now supports Apache Airflow 3.2 ​

概要 ​

Amazon Managed Workflows for Apache Airflow (MWAA)がApache Airflow 3.2をサポートしました。データパーティション単位でのトリガーなどデータ指向のスケジューリングや、HITLの監査履歴、UIの改善など開発生産性・運用性が向上します。

変更内容・新機能の詳細 ​

主な新機能と改善点:

  • データ指向スケジューリング（asset partitioning）: 日付やS3パスなどのデータパーティション単位で下流のDAGを起動できるようになり、全アセットではなく特定のデータスライスに対する実行制御が可能になります。これにより再処理範囲の限定や効率的なパイプライン実行が実現します。
  • Human-in-the-Loop (HITL) 機能強化: 承認に関するフルオーディット履歴の表示、AgenticOperatorに対するHITLサポート、Deadline Alertsの同期コールバックサポートが追加され、承認フローや相互作用の追跡・管理が容易になります。
  • UIとデバッグの改善: 大規模DAGの描画を高速化するGrid Viewの仮想化表示、Airflow UIからのXComのフル管理（参照・編集等）、PythonOperatorでのasync callableサポートなど、開発者が使いやすい機能が増えています。
  • デプロイ/アップグレード: MWAA上でApache Airflow 3.2の新環境を作成するか、既存環境（Airflow 2.11以降）をAWS Management Consoleの数クリックでアップグレード可能。現在MWAAをサポートしているリージョンで利用可能です。 技術的背景: これらの機能はAirflow 3.2本体の変更に基づくため、プロバイダーパッケージ・カスタムオペレータ・プラグインやXComの取り扱いなど互換性確認が必要です。

影響範囲・利用シーン ​

  • 対象ユーザー: データエンジニア、ワークフロー開発者、プラットフォーム/運用（SRE）チーム
  • 利用シーン: 日付やS3パスで分割されたデータをパーティション単位で処理するETL/ELTパイプライン、承認付きワークフロー（HITL）の可視化と監査、巨大なDAGの設計とデバッグ
  • 運用効果: 不要な再処理の削減とより細粒度な実行制御、承認履歴による監査・トレーサビリティ向上、UI描画の高速化による運用負荷軽減

技術的な注意点 ​

  • アップグレード要件: MWAA上のAirflow 3.2は、MWAAがサポートするリージョンで新規作成または2.11以降からアップグレード可能です。事前にステージ環境での検証を推奨します。
  • 互換性: プロバイダーパッケージ、カスタムオペレータ、プラグイン、requirements.txtに記載のライブラリの互換性を確認してください。Airflow 3系の仕様変更や非推奨事項（changelog参照）によってDAGの挙動が変わる可能性があります。
  • IAM権限: 環境作成/更新にはMWAAのCreateEnvironment/UpdateEnvironment等の権限、S3（DAGs/プラグイン/requirements格納）、CloudWatch LogsやECR（カスタムイメージを使う場合）へのアクセス権が必要です。
  • リージョン制限: 記載のとおり「現在MWAAをサポートしているリージョン」で利用可能です。MWAA自体をサポートしていないリージョンでは利用できません。リージョンごとの対応状況は公式ドキュメントで確認してください。
  • ダウンタイム/運用影響: 環境のアップグレード時にScheduler/Workerの再起動や短時間のジョブ停止が発生する可能性があります。稼働中のプロダクションは事前検証・メンテナンスウィンドウでの実施を推奨します。
  • コスト: MWAAの料金体系自体に自動的な価格上昇はありませんが、検証や再作成による追加リソース利用、ログ保存量増加などでコストが変動する可能性があります。
  • テストとバックアップ: DAGファイル、プラグイン、requirements.txt、接続情報、変数等をバックアップし、ステージングでの総合テスト（特にXComやカスタムオペレータ、AgenticOperatorを使うワークフロー）を行ってください。

参考情報 ​

[General] Amazon Inspector is now available in the AWS Asia Pacific (Taipei) Region ​

概要 ​

Amazon InspectorがAWS Asia Pacific (Taipei) リージョンで利用可能になりました。これにより同リージョン内のEC2、ECRのコンテナイメージ、Lambda関数に対する継続的な脆弱性検出とネットワーク露出検査が可能になります。

変更内容・新機能の詳細 ​

Amazon Inspectorは自動化された脆弱性管理サービスで、AWSワークロード（Amazon EC2インスタンス、Amazon ECRにプッシュされたコンテナイメージ、AWS Lambda関数）を継続的に検査します。今回の拡張により、AWS Asia Pacific (Taipei) リージョンでも以下が可能になります：

  • 新たに起動されたEC2インスタンス、作成されたLambda関数、およびECRにプッシュされた適格なコンテナイメージを自動検出してスキャン
  • ソフトウェア脆弱性（CVE等）や意図しないネットワーク露出に関する検出結果の生成
  • AWS Organizationsと連携して組織単位での検査運用（組織全体の可視化）や、Security Hub / EventBridge等と連携した自動対応ワークフローの構築 新規でAmazon Inspectorを有効化するアカウントは15日間の無料トライアルが適用され、その間は対象リソースの継続スキャンが無償で行われます。トライアル終了後はAmazon Inspectorの公表価格に基づく課金が発生します。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティチーム、SRE、クラウド運用担当者、開発チーム
  • 利用シーンまたは効果: Taipeiリージョン上のインフラ／コンテナ／サーバーレスを自動でスキャンし、脆弱性や意図しないネットワーク露出を早期検出することでリスク低減と対応の自動化が可能
  • 運用効果: 継続的スキャンによる検出速度の向上、Security Hub/EventBridge連携によるインシデント対応の自動化、組織単位での可視化により運用効率が向上
  • リージョン: 新たに AWS Asia Pacific (Taipei) リージョンで利用可能（該当リージョンでの利用を検討する顧客に直結）

技術的な注意点 ​

  • IAM権限: Inspectorの有効化／設定や結果参照には適切なIAM権限が必要です。組織全体で運用する場合はデリゲート管理者の設定や該当IAMロールの付与が必要です。
  • リージョン制限: 本アナウンスは AWS Asia Pacific (Taipei) リージョンでの利用開始の通知です。他リージョンの対応状況はリージョンごとに異なります。利用前に対象リージョンでの有効化を確認してください。
  • 対応リソース: 対象はAmazon EC2インスタンス、ECRにプッシュされた「適格な」コンテナイメージ、AWS Lambda関数です。既存イメージのスキャンはECRでの再プッシュやインベントリ更新によりトリガーされる場合があります。
  • 統合/自動化: 検出結果はAWS Security HubやAmazon EventBridgeと連携可能で、自動化された修復や通知フローに組み込めます。
  • コスト: 新規アカウントは15日間の無料トライアルあり。トライアル終了後はAmazon Inspectorの公表価格に基づき課金されます。スキャン対象の規模や頻度によりコストが変動するため、事前に見積もりを行ってください。
  • 導入手順のポイント: リージョンでInspectorを有効化し、必要に応じてOrganizations連携（デリゲート管理者）を設定、ECR/Lambda/EC2の権限／設定を確認してスキャンを開始します。
  • 注意点: 特定の検査機能やプラットフォーム連携は限定的な場合があるため、利用前に公式ドキュメントで対応範囲を確認してください。

参考情報 ​

[Govcloud Us] Amazon ECS introduces pause and continue controls for service deployments ​

概要 ​

Amazon ECSはサービスデプロイ時に「一時停止（PAUSE）」ポイントを設定できるようになり、手動承認や外部検証を挟んでデプロイを再開またはロールバックできる機能を提供します。EventBridge連携やContinueServiceDeployment APIによる自動化制御が可能です。

変更内容・新機能の詳細 ​

新機能はサービスのデプロイライフサイクルフックとして PAUSE を設定できる点です。デプロイが設定したポーズポイントに到達すると、ECSはデプロイの進行を停止し、Amazon EventBridge イベントを発行します。これにより、承認ワークフロー、運用チェック、統合テスト、外部バリデーション等を挟んで手動または自動で判断できます。デプロイの再開やロールバックは ContinueServiceDeployment API（コンソール/CLI/SDK経由でも利用可）で実行します。ポーズフックは最大14日までのタイムアウトを設定でき、タイムアウト時の自動アクション（自動再開または自動ロールバック）を指定可能です。サポートするデプロイ戦略はローリング、ブルー/グリーン、リニア、カナリーで、ECSコンソール、AWS CLI、AWS SDK、CloudFormation、AWS CDK、Terraformで設定可能です。既存のECS機能（マネージドトラフィックシフト、ベイク時間、迅速なロールバック、CloudWatchアラーム、デプロイ回路ブレーカー）と組み合わせて利用できます。機能は全てのAWS商用リージョンおよびAWS GovCloud (US)で利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: コンテナプラットフォーム運用者、SRE、DevOps、CI/CD設計者
  • 利用シーン: 手動承認ワークフローの挿入、ステージングでの統合テスト実行、運用チェックポイント（健康確認やセキュリティ検証）を挟んだローリング/ブルーグリーンデプロイ
  • 運用効果: 自動デプロイに安全な中間判断を導入でき、誤デプロイやリグレッションの早期検知と人による確認を組み合わせることでリスク低減が可能
  • 自動化連携: EventBridgeイベントをトリガーに承認システムやLambda/Step Functionsで自動判定・通知が容易に可能
  • 適用範囲: ローリング、ブルー/グリーン、リニア、カナリーデプロイすべてで使用可能（既存のトラフィックシフトや回路ブレーカー等と共存）

技術的な注意点 ​

  • IAM権限: ContinueServiceDeployment、UpdateService 等のECS操作権限に加え、EventBridgeやLambdaを用いる場合はそれらの実行権限が必要です
  • EventBridge連携: デプロイ到達時にEventBridgeイベントが発行されるため、承認ワークフローや自動化はEventBridgeルールで受ける形が推奨されます
  • タイムアウト制限: ポーズのタイムアウトは最大14日です。タイムアウト時の自動アクション（継続またはロールバック）を必ず設定してください
  • リージョン制限: 全AWS商用リージョンおよびAWS GovCloud (US)で利用可能と発表されています。ご利用のリージョンで有効か事前に確認してください
  • デプロイ影響とコスト: ポーズ状態自体で追加料金は発生しませんが、停止中に稼働しているタスクや検証用リソース（テスト環境、Lambda、Step Functions、EventBridgeルールなど）の通常コストは継続します
  • インフラ定義ツール: コンソール／CLI／SDKに加え、CloudFormation、AWS CDK、Terraformから設定可能です。既存のサービス定義にフックを追加する形になります
  • API/ツール: デプロイを継続またはロールバックするのは ContinueServiceDeployment API（コンソール/CLI/SDKから呼出し可能）です
  • 注意点: ポーズポイントの配置によってはトラフィックのシフトタイミングやベイク期間の意味合いが変わるため、運用手順とテストを事前に整備してください

参考情報 ​

[Managed Service For Grafana] Amazon Managed Grafana now supports dual-stack connectivity (IPv6 and IPv4) ​

概要 ​

Amazon Managed Grafanaがデュアルスタック（IPv4およびIPv6同時対応）をサポートしました。Grafana 10.4以降のワークスペースで有効化でき、IPv6移行を容易にしつつIPv4互換性を維持できます。

変更内容・新機能の詳細 ​

デュアルスタックモードを有効にすると、Managed GrafanaワークスペースのエンドポイントがIPv4とIPv6の両方で通信可能になります。これによりVPC内での重複アドレス空間管理やNATの依存を低減でき、IPv6対応クライアントはIPv6経路で接続しつつ、従来のIPv4クライアントはそのまま接続を継続できます。要件としてワークスペースはGrafanaバージョン10.4以降である必要があり、コンソール・API・CLIからワークスペース設定を更新して有効化します。本機能はサービスが一般提供（GA）されている全リージョンで利用可能です。IPv6のベストプラクティス（VPCでのIPv6割当て、ルートテーブル、セキュリティグループ／NACLのIPv6ルール、DNSのAAAAレコードなど）に従うことが推奨されます。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドエンジニア、ネットワークアーキテクト、SRE、監視/運用チーム
  • 利用シーン: IPv6へ段階的に移行する環境でのGrafana監視基盤統合、IPv6のみのデバイス（IoT等）からのダイレクト接続、マルチスタック環境でのアドレス管理の簡素化
  • 運用効果: VPC内の重複アドレス空間やNAT依存を削減しネットワーク構成を簡素化。IPv6クライアントの接続性向上によりレイテンシや経路の最適化が可能。既存のIPv4運用は継続可能でダウンタイムを抑えた移行が可能

技術的な注意点 ​

  • IAM権限: ワークスペース設定を更新するために grafana:UpdateWorkspace などの適切なIAM権限が必要です。事前に権限を確認してください。
  • Grafanaバージョン: デュアルスタックはGrafana 10.4以降のワークスペースでのみ有効です。古いバージョンはアップグレードが必要です。
  • ネットワーク設定: VPCにIPv6アドレストを割り当て、ルートテーブル、セキュリティグループ、NACLでIPv6トラフィックを許可する設定が必要です。プロキシ／ロードバランサー経由の構成ではそれらがIPv6を通すか確認してください。
  • DNS／クライアント互換性: クライアント側でIPv6を解決できるようにDNSにAAAAレコードが必要になる場合があります。IPv4専用クライアントは従来通り動作しますが、クライアント環境のIPv6対応状況を確認してください。
  • リージョン制限: 記事では「サービスが一般提供されている全リージョンで利用可能」と明記されています。利用前に対象リージョンでManaged GrafanaがGAか確認してください。
  • コスト: 新たな専用課金は明示されていませんが、IPv6／IPv4いずれのトラフィックでも通常のAWSデータ転送料金が適用されます。データ転送やネットワーク構成変更による間接コストを評価してください。
  • テスト／移行: 本番切替前にステージングでIPv6クライアント、DNS、セキュリティ設定を検証してください。モニタリングやログ収集経路の動作確認も推奨します。

参考情報 ​

AI要約はOpenAI APIによって生成されています。

Copyright © 2026