AWS What's New Digest

Appearance

2026年05月19日 ​

[Management Console] AWS Management Console now displays AWS Local Zones in the Region Selector ​

概要 ​

AWS Management Consoleのリージョン選択メニューにAWS Local Zonesが表示されるようになりました。コンソール上でLocal Zonesタブからオプトイン済みのLocal Zoneを一覧でき、該当ゾーンをクリックすると親リージョンのコンソールページへ遷移します。

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

今回の変更により、AWS Management Consoleのトップナビゲーションにあるリージョンセレクタで、従来のリージョン一覧と並んでAWS Local Zonesが表示されます。リージョンセレクタ内の「Local Zones」タブを選択すると、そのアカウントでオプトイン済みのLocal Zoneが一箇所に一覧表示され、個々のLocal ZoneをクリックするとそのLocal Zoneを親に持つAWSリージョンのコンソールページに直接遷移してリソースの表示・管理ができます。本機能はパブリックAWSリージョン配下の全てのAWS Local Zonesに対して利用可能で、複数の親リージョンにまたがるLocal Zoneを運用する際のコンソールでのナビゲーションが簡素化されます。なお、本変更はManagement Consoleの表示・ナビゲーション改善が目的であり、新しいAPIやリージョンエンドポイントの追加を伴うものではありません。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドエンジニア、SRE、オンプレ低遅延連携を行うアプリケーション開発者および運用担当者
  • 利用シーン: 複数のLocal Zone（かつ親リージョンが異なる構成）をまたがる運用で、コンソール上で素早く対象ゾーンを選択・リソースを確認したい場合
  • 運用効果: コンソールでのリージョン/Local Zone切替操作が簡素化され、誤ったリージョンでの作業やナビゲーションコストを削減できる

技術的な注意点 ​

  • IAM権限: 表示自体に特別な権限は不要。ただしLocal Zone内リソースの閲覧/操作は該当リソースに対する通常のIAM権限が必要です
  • オプトイン: リージョンセレクタに表示されるのはアカウントでオプトイン済みのLocal Zoneのみです。未オプトインのLocal Zoneは表示されません
  • コンソール限定: この変更はManagement ConsoleのUI表示に関するもので、AWS CLI/SDKのリージョン一覧やAPIの挙動、既存のエンドポイントには影響しません
  • リージョン制限: パブリックAWSリージョン配下のLocal Zonesが対象です。AWS GovCloudや中国リージョンなど特殊リージョンでは挙動が異なる場合があります
  • コスト: 表示変更自体に追加料金は発生しません。Local Zonesを実際に利用する場合は、リソース利用料やデータ転送料金などが発生する可能性があります
  • IaC/自動化への影響: CloudFormation/SDKでのリージョン指定や自動化スクリプトに影響はありません。UIでの利便性向上のみです

参考情報 ​

[Glue] AWS Glue zero-ETL is now available in Asia Pacific (Mumbai) region ​

概要 ​

AWS Glue の zero-ETL 統合がアジアパシフィック（ムンバイ）リージョン (ap-south-1) で利用可能になりました。これにより、データ移動を最小化して分析や機械学習ワークロードのインサイト獲得を高速化できます。

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

zero-ETL は AWS が提供するフルマネージドな統合機能で、一般的なデータ取り込み・レプリケーションユースケースに対して自前の ETL パイプラインを構築・運用する必要を最小化します。対応ソースには Amazon DynamoDB、Oracle Database@AWS、自己運用型データベース（Oracle、SQL Server、MySQL、PostgreSQL）、および Salesforce、SAP、Zendesk、Zoho CRM といったサポートされた SaaS アプリケーションが含まれます。Glue の zero-ETL はスキーママッピング、Change Data Capture（CDC）、増分レプリケーションを自動処理し、ターゲットの分析データストアへほぼリアルタイムでデータを複製します。これによりデータエンジニアはインフラ管理ではなくデータの利活用に注力でき、分析や ML のタイムトゥインサイトが短縮されます。実運用では、ソース側での CDC 有効化や追加のネットワーク設定、資格情報管理（AWS Secrets Manager など）等が必要になる点に注意してください。

影響範囲・利用シーン ​

  • 対象ユーザー: データエンジニア、データ分析者、ML エンジニア、SRE/運用チーム
  • 利用シーン: オンプレ／自己運用 DB や SaaS から分析向けデータストアへほぼリアルタイムでデータを複製するケース（キャンペーン分析、ダッシュボード更新、機械学習の特徴量更新など）
  • 運用効果: ETL パイプラインの開発・保守工数を削減し、データ移動レイテンシを低減してインサイト取得の時間を短縮できる

技術的な注意点 ​

  • IAM権限: Glue、ソース／ターゲットにアクセスするための適切なIAMロール／ポリシー（Secrets Manager、VPC エンドポイント等へのアクセスを含む）が必要です
  • リージョン制限: 本リリースで ap-south-1（Asia Pacific - Mumbai）が利用可能になりました。利用可能リージョンは随時拡張されるため、利用前にリージョン対応状況を確認してください
  • コスト: Glue の利用料金に加え、データ転送費用やソース側（SaaS/API）に伴う課金が発生する可能性があります。料金は使用量やリージョンに依存するため事前に料金ページで確認してください
  • ネットワーク／接続: 自己運用型 DB に対しては VPC 接続、セキュリティグループ、必要に応じて VPN/Direct Connect の設定が必要です。SaaS 接続は API 認証情報が必要になります
  • CDC／ソース設定: CDC を利用する場合、MySQL/PostgreSQL の論理レプリケーションや Oracle の補助ロギング（supplemental logging）などソース側の設定が必要になるケースがあります。DynamoDB はストリームの有効化など要確認
  • 対応ソース／ターゲット: 記載のソース（DynamoDB、Oracle Database@AWS、自己運用 DB、指定 SaaS 等）をサポートしますが、ターゲットの具体的なサポート状況（例：Amazon S3、Redshift 等）や機能制約はドキュメントで確認してください

参考情報 ​

[Lightsail] Amazon Lightsail CDN distributions now support IPv6-only instances as origins ​

概要 ​

Amazon Lightsail の CDN 配信で IPv6 専用インスタンスをオリジンとして利用できるようになりました。これにより IPv6-only インスタンス上のサイト／アプリを、世界中のエンドユーザーに低遅延かつ高速に配信できます。

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

従来は Lightsail CDN のオリジンに対して IPv4 またはデュアルスタック（IPv4+IPv6）のインスタンスしか指定できませんでしたが、本アップデートにより IPv6-only インスタンスをオリジンとして指定可能になりました。CDN はオリジンへの取得（プル）を IPv6 で行い、エンドユーザーへはそのエッジから IPv4/IPv6 のいずれの接続でも配信します（エンドユーザー側が IPv6 非対応でも配信可能）。Lightsail の CDN はインスタンス、コンテナ、バケット、ロードバランサーなど複数のオリジンタイプをサポートしており、今回の拡張で IPv6-only 環境を利用したコスト効率の良い運用や IPv6 移行が容易になります。Lightsail は 16 のリージョン（例：us-east-1, us-west-2, eu-central-1, eu-west-2, ap-northeast-1, ap-southeast-1 など）で利用可能です。利用開始は Lightsail コンソールから行え、料金や詳細は Lightsail の料金ページを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: Lightsail でサービスを運用するウェブ開発者、SRE、インフラ担当者
  • 利用シーン: IPv6-only インフラへの移行、IPv6 ネイティブ環境でのコスト最適化、グローバル配信を行う静的／動的コンテンツ配信
  • 運用効果: IPv6-only インスタンスをそのまま CDN オリジンにできるため NAT64／プロキシ等の中間変換が不要になり、アーキテクチャ簡素化と運用コスト低減が期待できる

技術的な注意点 ​

  • IAM権限: Lightsail と CDN（Distribution）を作成・管理する権限が必要です。組織で IAM を使う場合は Lightsail 管理用のポリシーを付与してください。
  • リージョン制限: Lightsail は 16 リージョンで提供されていますが、IPv6-only オリジンのサポート状況はリージョンによって異なる可能性があるため、コンソールで利用可否を確認してください。
  • コスト: CDN 配信および Lightsail のデータ転送料金が発生します。IPv6 経由のトラフィックであっても料金体系は適用されるため、トラフィック量に応じたコスト評価を行ってください。
  • ネットワーク／ファイアウォール: インスタンス側（OS ファイアウォールや Lightsail のネットワーク設定）で IPv6 の受信を許可する必要があります。CDN エッジからのアクセスを許可するために適切な IPv6 インバウンドルールを設定してください。
  • DNS 設定: オリジン指定にはホスト名または静的 IPv6 アドレス（AAAA レコード）が必要です。オリジンホスト名が AAAA レコードを返すことを確認してください。
  • TLS／証明書: CDN とオリジン間の HTTPS を利用する場合、オリジンが IPv6 上で TLS を受け付け、SNI 等の設定が正しく構成されている必要があります。

参考情報 ​

[General] Amazon EVS enables support for 32 hosts per environment ​

概要 ​

Amazon Elastic VMware Service (Amazon EVS) は、環境あたりの ESXi ホスト上限を従来の16台から32台に倍増しました。これにより、環境数を減らして大規模クラスター運用やドメイン設計の柔軟性を高められます。

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

今回のアップデートで、Amazon EVS 環境あたりの ESXi ホスト上限が16台から32台に引き上げられました。ユーザーは VMware Cloud Foundation (VCF) のドメイン/クラスタ構成を自由に設計でき、単一の大規模クラスタに全ホストを集約することも、複数の小規模クラスタに分散することも可能です。32台まで拡張するにはサービスクォータ（Service Quotas）増加の申請が必要で、申請が承認されると同一環境内で最大32台を運用できるため、複数環境の管理コストや運用オーバーヘッドを低減できます。なお本機能は Amazon EVS を提供する全リージョンで利用可能とされています。詳細な手順や注意点は Amazon EVS の製品ページおよびユーザーガイドを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: VMware をクラウド上で大規模展開・運用するクラウドエンジニア、SRE、プラットフォームチーム
  • 利用シーン: 単一環境での大規模クラスター運用（最大32ホスト）、VCFドメインの集約による環境削減、テナント分離やワークロード特性に合わせたクラスタ設計
  • 運用効果: 環境数を減らすことで管理・監視・パッチ運用のオーバーヘッドを低減。ネットワーク設計やストレージ容量の集約による効率化が見込める

技術的な注意点 ​

  • IAM権限: サービスクォータ増加申請には Service Quotas の利用やサポートケース作成が必要となるため、該当アカウントでの適切な IAM 権限（Service Quotas へのアクセス／サポートケース作成権限）を事前に確認してください
  • リージョン制限: 発表では「Amazon EVS を提供する全リージョン」で利用可能とされていますが、自アカウントのコンソールで当該リージョンの提供状況を確認してください
  • コスト: ホスト数増加はインスタンス料金、ストレージ、ネットワーク使用量、及び VMware ライセンス関連コスト増加を招きます。コスト試算（TCO）を事前に実施してください
  • クォータ申請: デフォルト上限は以前の値のままの場合があるため、32台運用の前にサービスクォータ増加を申請し、承認ステータスを確認してからホスト追加を進めてください
  • VCF/VMware要件: VCF のバージョン、ESXi バージョン、vCenter/NSX-T の設計要件や最大推奨ホスト数に関するベストプラクティスを確認してください。大規模クラスタはメンテナンス時間や再起動時の影響範囲が大きくなるため、運用計画を見直してください
  • ネットワーク/ストレージ: ホスト増加に伴うネットワーク帯域とストレージ IOPS の要件を評価し、必要に応じてネットワーク設計（VLAN/MTU/Overlay）やストレージ構成を調整してください

参考情報 ​

[Serverless Application Model Sam] AWS SAM CLI adds AWS CloudFormation Language Extensions support to accelerate local serverless development ​

概要 ​

AWS SAM CLIがAWS CloudFormation Language Extensionsをローカル処理でサポートするようになり、テンプレートの重複を減らしつつ従来のローカル開発ワークフローを維持できます。これにより、リソースを一度定義してローカルで素早く反復検証できるようになります。

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

SAM CLIはテンプレート内のAWS::LanguageExtensionsトランスフォームをメモリ内で展開（インメモリ処理）し、ローカル操作（sam build、sam local invoke、sam sync、sam local start-api、sam validateなど）でFn::ForEachを使ったループ展開や生成された各リソースを処理できるようになりました。元のテンプレートファイル自体は変更せずに展開を行うため、CloudFormationへのデプロイ時にテンプレートをそのまま利用できます。ローカルでは展開後の各リソース（例: 生成されたLambda関数名）を個別に呼び出せるため、AlphaFunctionのような名前でsam local invokeが可能です。サポートされる追加機能として、Fn::Length、Fn::ToJsonString、Fn::FindInMap（DefaultValue付き）、および条件付きのDeletionPolicy / UpdateReplacePolicyの処理が含まれます。これにより、同一パターンの多数リソースを1つの定義から生成してローカルで早期に構文エラーや依存関係の問題を発見でき、クラウドへの無駄なデプロイを減らしてイテレーションを高速化できます。始めるにはSAM CLIを最新にアップデートし、テンプレートにAWS::LanguageExtensionsトランスフォームを追加してFn::ForEach等を利用してください。

影響範囲・利用シーン ​

  • 対象ユーザー: サーバーレス開発者、SRE/運用チーム、IaCテンプレートを管理するエンジニア
  • 利用シーン: 同一パターンの複数リソース（Lambda、DynamoDB、SNS等）を1つのテンプレート定義から生成してローカルでビルド・実行・検証する場合
  • 運用効果: ローカルでの早期エラー検出によりクラウドへの無駄なデプロイを減らし、デバッグ・反復開発サイクルが短縮される

技術的な注意点 ​

  • SAM CLIバージョン: 最低でも記事公開時点の最新SAM CLIへアップデートが必要です（機能は最新CLIでのみ利用可能）。
  • テンプレート変更: テンプレートにAWS::LanguageExtensionsトランスフォームを追加し、Fn::ForEach等の構文を使用する必要があります。
  • 対応コマンド: sam build、sam local invoke、sam sync、sam local start-api、sam validateでサポートされます。
  • サポートされる関数等: Fn::ForEach、Fn::Length、Fn::ToJsonString、Fn::FindInMap（DefaultValue対応）、条件付きのDeletionPolicy / UpdateReplacePolicyの展開をサポートします。
  • デプロイ時の注意: SAM CLIはローカルで展開を行いテンプレート自体は変更しないため、実際にCloudFormationへデプロイする際は対象リージョンでLanguage Extensionsがサポートされているか確認してください。また、CloudFormationでのデプロイ時に発生する権限・コストは通常通り発生します。
  • IAM権限: ローカル実行では追加のIAM権限は不要ですが、クラウドへデプロイする場合はデプロイ対象リソースに応じたIAM権限が必要です。
  • リージョン制限: 本機能はSAM CLIのローカル機能に関するものでリージョン制限は直接ない一方、CloudFormationのLanguage Extensionsや生成されるリソースのサポート状況はリージョンごとに異なる可能性があるため、実際のデプロイ前に確認してください。
  • コスト: ローカル処理自体に追加料金は発生しません。反復のクラウドデプロイ回数を減らせばコスト削減につながりますが、CloudFormationでの実際のリソース作成・更新は通常の課金対象です。

参考情報 ​

[Redshift] Amazon Redshift adds ALTER TABLE for Iceberg tables and writes via the AWS Glue Data Catalog mount ​

概要 ​

Amazon RedshiftがApache Icebergテーブルへの書き込みをGlue Data Catalog（awsdatacatalog）経由で直接行えるようになり、ALTER TABLE DDLでIcebergテーブルのスキーマ、パーティション、プロパティを変更できるようになりました。これによりデータレイクへRedshiftの変換結果をネイティブに配置し、クロスエンジンでの互換性を維持しつつ運用が簡素化されます。

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

主な変更点は以下の通りです。

  • 書き込み経路: Redshiftは自動マウントされたAWS Glue Data Catalog（awsdatacatalog）を通じてIcebergテーブルに直接書き込めます。外部スキーマを新たに作成する必要がなく、Lake Formationと連携しているIcebergテーブルにもそのまま書き込みが可能です。
  • ALTER TABLEサポート: Icebergテーブルに対して以下のALTER TABLE操作が可能になりました。
    • ADD/DROP/ALTER COLUMN
    • RENAME COLUMN
    • SET TABLE PROPERTIES（例: デフォルト圧縮方式の上書き）
    • ADD/DROP/REPLACE PARTITION FIELD（パーティション戦略の変更） これにより、従来はテーブルとデータを削除して再作成する必要があったスキーマ変更やパーティション戦略の適用が、テーブルを保持したまま行えます。
  • 互換性: Redshiftで変更したIcebergテーブルはAmazon EMR、Amazon Athenaなど他のIceberg対応エンジンと互換性を保ちます（Icebergの仕様に準拠する限り）。
  • セキュリティ: Icebergへの書き込みはAWS Lake Formationの権限モデルをサポートします。必要なアクセス制御をLake Formationで適用できます。
  • 可用性: これらの機能はAmazon Redshiftが提供されているすべてのAWSリージョンで利用可能です。
  • 利用開始: 詳細はAmazon Redshift Database Developer Guideの「Referencing Iceberg tables in Amazon Redshift」と「Altering table definitions」を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: データプラットフォームエンジニア、データエンジニア、SRE、データ分析チーム
  • 利用シーン: RedshiftでETL/ELTしたデータを直接Iceberg形式でデータレイクに配備して、AthenaやEMRなど複数エンジンで共有してクエリするケース
  • 運用効果: テーブルの再作成やデータ移行を伴わずにスキーマ変更やパーティション戦略の変更が可能になり、ダウンタイムとパイプラインの複雑さを低減
  • 互換性効果: Iceberg準拠の他エンジンとのクロスエンジン互換性を維持できるため、分析ワークロードの移行や並列利用が容易になる

技術的な注意点 ​

  • IAM権限: Glue Data CatalogとRedshift間の操作には適切なIAMロール／ポリシーとLake Formationの権限設定が必要です（Write権限とカタログ参照権限を確認してください）
  • リージョン制限: 記事によればAmazon Redshiftが利用可能な全リージョンで利用可能です。ただし、各リージョンでGlue/Lake Formationの設定状況を確認してください
  • コスト: データレイク側でのストレージ料金やGlueカタログ利用に伴う費用は発生します。ALTER操作自体はDDLコストだが、再パーティションやデータ再書き込みが発生するケースはI/Oコストが増える可能性があります
  • 互換性: 変更後のテーブルはIceberg仕様に従っていれば他エンジンと互換性がありますが、Icebergのフォーマットバージョンやパーティション変換の詳細仕様に注意してください
  • 制限/既知の制約: 大きなスキーマ変更やパーティションの全面的な置換は内部でメタデータ更新やファイル操作を伴うため、処理時間や一時的な追加ストレージが必要になることがあります
  • 運用上の注意: ALTERによるパーティション変更は既存データのクエリ挙動に影響するため、変更前にテストし、メタデータキャッシュ（クライアント側）がある場合はキャッシュクリアを検討してください

参考情報 ​

[SageMaker] Amazon SageMaker Studio now supports GPU capacity reservation through SageMaker Flexible Training Plans ​

概要 ​

Amazon SageMaker Studio（JupyterLab／Code Editor）が、SageMaker Flexible Training Plans（FTP）によるGPUキャパシティ予約をサポートしました。高負荷のGPUリソースに対して予測可能なアクセスを確保でき、オンデマンド比で最大65%のコスト削減が見込めます。

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

SageMaker Flexible Training Plans（FTP）を使って、StudioのIDE（JupyterLab・Code Editor）用にGPUインスタンスの予約（インスタンスタイプ、予約期間、開始日を指定）を自己完結型のコンソール操作で購入できます。購入後、Studioでアプリ（Studio app）を作成するときに「Instance」ドロップダウンから購入済みプランを選択すると、SageMaker側でインスタンスを自動プロビジョニングします。インフラ管理は不要で、予約の有効化まで待つだけで利用開始できます。予約期限が近づくとIDEから事前通知があり、作業保存の猶予が与えられます。これにより、ピーク時でも安定して高性能GPUを確保しつつコスト効率を高められます。なお、予約の適用はStudioで新規に作成するアプリ選択時の指定が前提となるため、既存の稼働中セッションへの自動適用は限定的です（必要に応じてアプリの再作成や更新が必要になる可能性があります）。

影響範囲・利用シーン ​

  • 対象ユーザー: 機械学習エンジニア、データサイエンティスト、SRE/プラットフォームチーム
  • 利用シーンまたは効果: ピーク時にGPUが逼迫するトレーニングや大規模推論準備、インタラクティブな実験（JupyterLabやCode Editor）で安定したGPUを事前確保し、コスト効率良くワークロードを実行
  • 運用効果: 予約によりジョブ待ち時間やインスタンス割当失敗を低減し、繰り返し行う学習実験やチームの共用ワークスペースでのスループット向上が期待できる
  • コスト影響: オンデマンド比で最大65%の節約が見込める一方、予約は期間コミット型の支出（未使用時間が発生するとコストが発生）となるため使用率に応じたプラン選定が重要

技術的な注意点 ​

  • IAM権限: FTPの購入・表示・管理およびStudioアプリ作成に必要なSageMakerコンソール操作権限（FTP操作とStudio関連操作が行えるIAMポリシー）を事前に確認してください
  • リージョン制限: 全リージョンで利用可能とは限らないため、利用前に対象リージョンでFTPと希望のGPUインスタンスタイプがサポートされているか確認してください
  • コスト: 予約は期間コミット型の課金が発生します。料金はインスタンスタイプと予約期間で変動し、未使用時間も課金対象となる可能性があります
  • 運用上の注意: 予約終了時にIDEが通知を行いますが、稼働中のセッションやカーネルは影響を受ける可能性があるため、S3への定期的なチェックポイント保存やジョブ再開手順を整備してください
  • 既存アプリへの適用: 記事の説明ではStudioアプリ作成時に購入プランを選択するフローのため、既存で稼働中のアプリに自動的に割り当てられない場合があります。既存環境に適用するにはアプリの再作成や設定変更が必要になることを想定してください
  • インスタンスタイプと可用性: 高需給なGPUインスタンスは地域・AZごとに割当状況が異なります。予約が必ずしも即時アクティブにならない場合があるため、開始日や有効化時間に余裕を持って計画してください

参考情報 ​

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

Copyright © 2026