AWS What's New Digest

Appearance

2026年03月20日 ​

[Datasync] AWS DataSync now supports AWS Secrets Manager for all location types ​

概要 ​

AWS DataSyncが全てのロケーションタイプ（例：HDFS、Amazon FSx for Windows File Server、Amazon FSx for NetApp ONTAP）でAWS Secrets Managerを使った資格情報管理をサポートしました。これにより資格情報をSecrets Managerに集約し、KMSカスタマーキーでの暗号化やローテーション・監査ポリシーの統一が可能になります。

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

今回の更新で、従来は一部ロケーションのみ対応していたSecrets Managerとの統合がDataSyncの全ロケーションタイプに拡張されました。主な技術要点は以下の通りです。

  • 対応対象: HDFS、Amazon FSx for Windows File Server、Amazon FSx for NetApp ONTAP を含む全ロケーションタイプ。
  • 資格情報管理方式: (1) ユーザーが管理するSecrets ManagerのシークレットARNを指定して利用（シークレットのローテーション、アクセス制御、監査をユーザーで管理）(2) DataSyncがアカウント内にシークレットを自動作成・管理する方式の二通りをサポート。
  • 暗号化: デフォルトのAWS管理キーではなく、顧客管理のAWS KMSキー（カスタマー管理キー：CMK）でシークレットを暗号化可能。これにより組織のセキュリティ要件やガバナンスに対応。
  • 運用性: シークレットはお客様アカウント内に保存され、必要に応じてシークレット値を更新可能。DataSyncサービス側に直接資格情報を保持する必要がなくなるため、資格情報の管理・更新が独立して行えます。
  • 利用可能リージョン: DataSyncが提供されている主要リージョンの大半で利用可能。完全な対応リージョンはAWS Capabilitiesツールで確認する必要あり。
  • 利用方法: コンソールおよびAPIでシークレットARNを指定するか、DataSyncに自動作成を許可して開始します。ドキュメントに従ってIAMポリシーやKMSポリシーを適切に設定してください。

影響範囲・利用シーン ​

  • 対象ユーザー: DataSyncを利用してファイルシステム間／オンプレ⇄クラウドのデータ転送を行うクラウドエンジニア、SRE、セキュリティチーム
  • 利用シーンまたは効果: 資格情報をSecrets Managerで一元管理することで、複数ロケーションに跨る転送設定の資格情報管理を統一できる（例: HDFS→S3、FSx→S3の移行など）
  • 運用効果: シークレットのローテーション・監査・アクセス制御をSecrets Manager側で統制でき、資格情報漏洩リスク低減およびコンプライアンス対応が容易になる
  • 自動化への影響: シークレットARNを参照する方式は既存CI/CDやインフラ自動化と相性が良く、ローテーション時のサービス停止を最小化できる
  • セキュリティガバナンス: KMS CMKの利用により鍵管理ポリシー（キーの管理/アクセス制御）を適用でき、社内のセキュリティ基準に適合させやすくなる

技術的な注意点 ​

  • IAM権限: DataSyncがSecrets Managerのシークレットを参照・作成するために、secretsmanager:GetSecretValue、secretsmanager:CreateSecret（自動作成を使用する場合）などの権限が必要です。KMSを利用する場合はkms:Decryptなどの権限付与も必要です。DataSyncサービスプリンシパルや実行ロールへの明示的なアクセス許可を検討してください。
  • リージョン制限: ほとんどのDataSync提供リージョンで利用可能ですが、完全対応リージョンはAWS Capabilitiesツールで確認してください。リージョン間でのSecrets Managerの挙動（リージョン固有のシークレット）に注意してください。
  • コスト: Secrets Managerはシークレット毎の利用料金（保存・APIリクエスト）と、KMS（CMK）を使用する場合はKMSリクエスト料金が発生します。大量のシークレット作成や頻繁な回転はコスト増加要因になります。
  • 既存設定の切替: 既にDataSyncで資格情報を直接設定しているロケーションをSecrets Managerに移行する場合、ロケーション設定の更新が必要です。移行手順とダウンタイムを事前に確認してください。
  • ローテーション/監査: シークレットを自分で管理する場合はローテーション設定（Secrets Managerの自動ローテーション）やCloudTrailでのアクセスログを活用してください。DataSyncが自動管理するシークレットの詳細なローテーションポリシーはドキュメントで確認してください。
  • ネットワーク/アクセス: Secrets ManagerやKMSへアクセスするためのネットワーク経路（VPCエンドポイントやアウトバウンドアクセス）が必要な場合があります。オフライン環境や制限されたVPCでは構成を確認してください。
  • コンプライアンス/監査: シークレット操作はCloudTrailにより記録されるため、監査要件に合わせたログ管理を検討してください。

参考情報 ​

[Firewall Manager] AWS Firewall Manager launches in AWS Asia Pacific (New Zealand) Region ​

概要 ​

AWS Firewall ManagerがAWSアジアパシフィック（ニュージーランド）リージョン (ap-nz) で利用可能になりました。これにより同リージョンでホストされるワークロードに対して中央集中的なセキュリティポリシーの作成・適用が行えます。

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

AWS Firewall Managerは、AWS Organizationsと連携して複数アカウント／OUに対してAWS WAF、AWS Shield Advanced、AWS Network Firewall、VPC セキュリティグループポリシー、Route 53 Resolver DNS Firewallなどのセキュリティ機能を中央管理できるサービスです。今回のリリースにより、これらの管理機能が ap-nz リージョンで利用可能になり、ローカルリージョン内のリソースに対してポリシーを作成・適用・監査できるようになります。Firewall Managerを使うと、WAFルールやNetwork Firewallルール、セキュリティグループの標準化・自動適用、攻撃緩和のためのShield Advancedの監視設定などを運用作業の自動化により一貫して実施できます。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドセキュリティ管理者、SRE/運用チーム、コンプライアンス担当者
  • 利用シーン: ap-nzリージョンでホストするウェブアプリケーションやVPCリソースに対してWAFポリシー、Network Firewallやセキュリティグループの標準化と自動適用を行う場面
  • 運用効果: マルチアカウント環境でのルール適用・監査を中央化することで設定ミスや漏れを削減し、運用負荷を低減する
  • 地域的効果: データレジデンシー要件やレイテンシ要件のあるニュージーランド内ワークロードに対して、リージョン内で管理できることによる運用・法令面での利便性向上

技術的な注意点 ​

  • IAM権限: Firewall Managerの操作にはOrganizations関連の権限とFirewall Manager固有の権限が必要です（例: Organizations:EnableAWSServiceAccess, fms:* / または必要最低限の権限を含むカスタムポリシー）。
  • リージョン制限: 本発表は ap-nz（Asia Pacific (New Zealand)）への対応追加を示します。Firewall Managerのポリシーにはリージョン性（リージョナルポリシーとグローバルポリシー）があるため、CloudFrontなどグローバルサービス向けの設定は別扱いになります。
  • コスト: Firewall Manager自体は管理機能ですが、適用する各サービス（AWS WAF、AWS Network Firewall、Shield Advanced、Resolver DNS Firewall 等）は別途課金されます。Shield Advancedはサブスクリプション費用が発生します。
  • AWS Organizations: Firewall Managerを有効にするにはAWS Organizationsの管理アカウント（現Management account）からサービスアクセスを設定する必要があります。組織単位でのポリシー展開を行うため、組織構成を事前に設計してください。
  • 互換性と動作: 一部の機能（例: Shield Advancedの保護）はグローバルな側面を持つため、ポリシーの適用範囲と対象サービスが地域により異なります。ポリシー作成時に“グローバル”か“リージョン”かを意識してください。
  • 注意表記: 元記事内に "Taipei" に関する記述がありましたが、今回の発表はニュージーランド（ap-nz）リージョンへの展開を指しています。記事中の表記の不一致に注意してください。

参考情報 ​

[General] Amazon EC2 Fleet now supports interruptible Capacity Reservations ​

概要 ​

Amazon EC2 Fleetが「interruptible Capacity Reservations」をサポートしました。Launch Templateで指定した割り当て可能なCapacity Reservation IDを単一のEC2 Fleet呼び出しで利用できるようになり、組織内の未使用オンデマンド予約を効率的に消費できます。

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

EC2 Fleetは複数のインスタンスタイプやアベイラビリティゾーンにまたがってインスタンスを起動する機能ですが、本リリースによりLaunch Template内でinterruptible（中断可能）として共有されたCapacity Reservation IDを指定して、それらの予約をEC2 Fleetで直接消費できるようになりました。既存のCapacity Reservation（オンデマンド予約）は所有アカウントが使用していない期間に組織内で“interruptible”として一時的に利用可能にでき、他アカウントはその予約を参照してインスタンスを起動できます。実装上はLaunch TemplateやFleetのオーバーライドでCapacityReservationSpecification / CapacityReservationTarget（CapacityReservationIdを指定）を設定することで利用します。予約はオーナーにより回収される可能性があるため「interruptible」の扱いとなり、利用中に予約が取り下げられた場合はインスタンスに影響（中断や終了など）が発生し得ます。本機能はすべてのAWS商用リージョンで利用可能です。詳細はEC2 FleetドキュメントおよびCapacity Reservationsユーザーガイドを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド運用者、SRE、インフラ／コスト最適化担当者
  • 利用シーン: 組織内で未使用のオンデマンド予約資源を他アカウントで消費して短期的な需要を満たす／EC2 Fleetで複数予約をまとめて利用するバースト展開
  • 運用効果: 予約資源の稼働率向上とコスト効率化（所有者側の利用効率改善）、Fleet側は単一の呼び出しで複数予約を活用して配置の柔軟性が向上

技術的な注意点 ​

  • IAM権限: EC2 Fleet作成・RunInstancesおよびCapacity Reservationの参照／利用に関する権限（例: ec2:CreateFleet, ec2:RunInstances, ec2:DescribeCapacityReservations, ec2:DescribeInstances など）を事前に確認・付与してください
  • Launch Template: Launch TemplateまたはFleetのオーバーライドでCapacityReservationSpecification/CapacityReservationTarget（CapacityReservationId）を指定する必要があります
  • 中断時挙動: "interruptible"扱いのため、予約オーナーが回収した場合はインスタンスが中断または終了する可能性があり、重要ワークロードでの利用は設計に注意が必要です
  • リージョン制限: 本機能はすべてのAWS商用リージョンで利用可能と発表されていますが、実運用前に対象リージョンでの可用性を確認してください
  • コスト: 本機能自体の追加料金は想定されませんが、インスタンスの課金は通常のオンデマンド等に準じます。Capacity Reservationの所有者側の請求への影響やコスト効果はケースバイケースです
  • 互換性: Spotとは異なりCapacity Reservationはオンデマンド予約の活用であり、既存のスポット/オンデマンド戦略との組合せ設計が必要です
  • 監視/運用: 予約の利用状況および中断イベントの検知（CloudWatch Events/LogsやAWS Configなど）を組み込み、回復手順を準備してください

参考情報 ​

[General] AWS adds support for NIXL with EFA to accelerate LLM inference at scale ​

概要 ​

AWSは、NVIDIAの推論転送ライブラリNIXLをElastic Fabric Adapter（EFA）と組み合わせてサポート開始しました。これにより、分散（ディスアグリゲーテッド）LLM推論のKVキャッシュ転送が高速化され、低遅延で大規模推論をスケール可能になります。

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

NIXL（NVIDIA Inference Xfer Library）をEFA経由で利用できるようになり、特に分散推論アーキテクチャで使われるKV（key-value）キャッシュの転送が最適化されます。主な技術的改善点は以下の通りです：

  • KV-cacheスループット向上: EFAの低レイテンシ・高帯域のネットワーク（libfabric/OFIを活用したRDMA的通信）とNIXLの効率的な転送パスにより、prefillノードからdecodeノードへのKV転送速度が上がります。
  • インタートークン遅延の削減: トークン生成間の通信往復（prefill→decode→次トークン）にかかる遅延が短縮され、逐次デコードのレイテンシが改善されます。
  • KV-cacheメモリ利用最適化: KVデータの階層（インスタンスのローカルメモリ、共有メモリ、ネットワーク経由のリモートメモリ／ストレージ）間での効率的な移動が可能になり、各ノードのメモリ負荷を軽減してより大きなモデルまたは多数の同時推論を扱えます。 NIXLはEFA対応のすべてのEC2インスタンスタイプで利用可能で、NVIDIA Dynamo、SGLang、vLLMなど主要な推論フレームワークとネイティブに連携します。AWS側の提供条件としては、NIXLバージョン1.0.0以上、EFAインストーラーバージョン1.47.0以上が必要で、全リージョンのEFA対応インスタンスで追加課金なしで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: LLM推論を大規模に運用する機械学習エンジニア、推論プラットフォーム担当者、SRE/運用チーム
  • 利用シーンまたは効果: 分散（prefill/encode と decode ノード分離）アーキテクチャでのKV-cache転送高速化により、スループット増加とトークン生成レイテンシ低減が期待できる。大規模モデルを小さいメモリのインスタンスに分散して運用する際に有効
  • 運用効果: 同一コストでのリクエスト処理数向上、トークン応答時間短縮、KVキャッシュの階層化によるメモリ効率改善でより多くのモデル／バッチを処理可能

技術的な注意点 ​

  • 必要なバージョン: NIXL 1.0.0以上、EFAインストーラー 1.47.0以上が必須
  • 依存関係: 対応するNVIDIAドライバ、CUDAバージョン、libfabric/OFI等のランタイム依存性を満たす必要あり。フレームワーク（vLLM等）のバージョン互換性も確認してください
  • IAM権限: EFAを利用するためのENI作成やインスタンス操作に必要なEC2関連権限（ENI/セキュリティグループ/インスタンス操作等）を事前に確認してください
  • リージョン制限: 記事時点では「全EFA対応リージョンでサポート」と明記されていますが、利用するリージョンでEFA対応インスタンスタイプが利用可能か確認してください
  • コスト: NIXL/EFA自体に追加料金は発生しませんが、EFA対応の高性能インスタンス利用料、ネットワーク転送量、ストレージ費用は発生します。トラフィック増加や保存するKVキャッシュサイズに応じたコスト増を考慮してください
  • 運用上の注意: 性能を出すためにprefill/decodeノードの割合、バッチサイズ、KVシャーディング戦略、MTUやカーネルパラメータ調整などのチューニングが必要です。障害発生時のKV整合性やリカバリ戦略も設計に含めてください

参考情報 ​

[Redshift] Amazon Redshift supports federated permissions with IAM Identity Center in multiple AWS Regions ​

概要 ​

Amazon Redshift のフェデレーテッド権限が AWS IAM Identity Center（IdC）のマルチリージョンサポートに対応しました。IdC のプライマリリージョンから追加リージョンへ拡張することで、ユーザー近接性によるパフォーマンス改善と可用性向上を図れます。

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

今回のアップデートにより、IdC をプライマリリージョンから複数の追加リージョンへ拡張でき、追加リージョン内で Redshift と Lake Formation の Identity Center アプリケーションを作成して既存のワークフォース識別情報を利用した細粒度アクセス制御（テーブル/カラム/行レベル、マスキング）を簡素に管理できます。追加リージョンへのリージョン追加時にプライマリリージョンからユーザーやグループを複製する必要はなく、IdC が付与するフェデレーテッド認証情報（短期資格情報）を介して Redshift や Lake Formation のアクセス判断が行われます。クエリ実行先がどの Redshift ウェアハウスであっても行レベル／列レベルのアクセス制御やマスキングは自動的に適用されます。Amazon QuickSight、Redshift Query Editor、サードパーティの SQL クライアントから新しいリージョンで SSO によるアクセスが可能です。導入前にリージョン対応状況を確認し、IdC／Redshift／Lake Formation のドキュメントに沿ってアプリケーション登録とロールマッピング、必要な権限設定を行ってください。

影響範囲・利用シーン ​

  • 対象ユーザー: データ分析者、データベース管理者（DBA）、セキュリティ/コンプライアンス担当者、SRE/運用チーム
  • 利用シーン: ユーザーが地理的に分散している環境での低遅延クエリ、複数リージョンにまたがるデータウェアハウス運用、QuickSight など BI ツールからのシングルサインオンアクセス
  • 運用効果: IdC の追加リージョンを使うことで認証レイテンシーと依存性を低減し、フェデレーテッド権限の一元管理によりアクセス制御設定の重複を削減
  • セキュリティ/コンプライアンス効果: 行レベル・列レベル・マスキング制御がクエリ時に一貫して適用されるため、データアクセスのコンプライアンス遵守が容易になる

技術的な注意点 ​

  • IAM権限: IdC と Redshift/Lake Formation 間のロールマッピングや一時証明書発行に必要な IAM ポリシー／ロールを事前に設定してください
  • リージョン制限: すべてのリージョンで対応しているとは限りません。利用前にリージョン可用性を確認してください
  • 設定手順: 追加リージョンで IdC アプリケーション（Redshift / Lake Formation）を作成し、ロールマッピングとアクセス許可を設定する必要があります。ユーザー複製は不要です
  • Lake Formation 連携: Lake Formation のデータアクセス制御（LF-tags、データベース/テーブル権限）は引き続き有効です。LF ポリシーと IdC から付与される一時資格情報の整合性を確認してください
  • SSO クライアント互換性: QuickSight、Redshift Query Editor、サードパーティ製 SQL クライアントでの SSO 対応状況やドライバのバージョン要件を確認してください
  • コスト: IdC の複数リージョン展開自体に直接の課金が発生するケースは限定的ですが、クロスリージョンデータ転送や追加のリソース利用により料金が増加する可能性があります

参考情報 ​

[Ec2] Amazon EC2 C8gn instances are now available in additional regions ​

概要 ​

Amazon EC2の新しいC8gnインスタンス（AWS Graviton4搭載）が、ジャカルタ、ハイデラバード、東京、サンパウロ、チューリッヒなど追加リージョンで利用可能になりました。ネットワーク最適化・高帯域向けに設計され、Graviton3世代比で最大30%の計算性能向上を実現します。

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

C8gnは最新世代のAWS Graviton4プロセッサを搭載したネットワーク最適化インスタンスファミリーです。主な仕様・特徴は次の通りです。

  • 計算性能: Graviton3ベースのC7gnと比べ、最大で約30%の計算性能向上を提供。
  • ネットワーク: 第6世代AWS Nitro Cardsを採用し、最大600 Gbpsのネットワーク帯域をサポート。ネットワーク集約型ワークロードにおいて最高クラスの帯域を提供。
  • インスタンス/メモリ: 最大48xlargeサイズまで提供（最大384 GiBメモリ）。
  • EBS帯域: インスタンスあたり最大60 GbpsのAmazon EBS帯域をサポート（EBS最適化）。
  • EFAサポート: 16xlarge、24xlarge、48xlarge、metal-24xl、metal-48xlでElastic Fabric Adapter（EFA）に対応し、低遅延・クラスタ性能向上が可能。
  • 推奨ワークロード: ネットワーク仮想アプライアンス、データ分析、CPUベースのAI/ML推論、高スループットのネットワーク処理など。
  • アーキテクチャ互換性: Graviton4はARM64（aarch64）アーキテクチャのため、既存x86バイナリは再ビルドまたはARM対応イメージの使用が必要。LinuxディストリやAMIs、コンテナイメージの確認が必要です。
  • 利用方法: AWS Management Console、AWS CLI、AWS SDKsから起動可能。既に多数のリージョンで提供され、今回ジャカルタ、ハイデラバード、東京、サンパウロ、チューリッヒなどへの展開が追加されました。

影響範囲・利用シーン ​

  • 対象ユーザー: ネットワーク集約型アプリケーションを運用するクラウドエンジニア、SRE、データ分析者、AI/MLエンジニア
  • 利用シーン: ネットワーク仮想アプライアンス（FW、ロードバランサ）、高スループットデータ処理、CPUベースの推論クラスタ、低遅延クラスタ通信（MPI等）
  • 運用効果: ネットワーク帯域と計算性能の改善によりスループット向上とコスト効率性の改善（Gravitonの価格性能優位を活かしたTCO低減）が期待できる
  • リージョン影響: 追加リージョン（ジャカルタ、ハイデラバード、東京、サンパウロ、チューリッヒ）のユーザーは待ち時間低下とデータレジデンシ要件の改善が可能

技術的な注意点 ​

  • アーキテクチャ: Graviton4はARM64（aarch64）です。アプリケーションやバイナリ、コンテナはARM対応を確認／再ビルドしてください。
  • EFA/ドライバ: EFAを利用する場合はOS側でEFAドライバとMPIライブラリ（libfabric等）の設定が必要です。対応インスタンスサイズは 16xlarge、24xlarge、48xlarge、metal-24xl、metal-48xl です。
  • ENA/Nitro: 高速ネットワーク（ENA）や第6世代Nitroカードの恩恵を受けるため、最新のAMIsやカーネル（ENAドライバ）を推奨します。
  • リージョン制限: 新規追加はジャカルタ、ハイデラバード、東京、サンパウロ、チューリッヒ等。ご利用前に利用希望リージョンでの提供状況を確認してください。
  • クォータ（上限）: 大型インスタンスやmetalインスタンスはデフォルトクォータが低めの可能性があります。必要に応じてService Quotasで上限引き上げを申請してください。
  • コスト: Graviton4は一般に高い価格性能比を提供しますが、インスタンス自体の料金、データ転送、EBS利用料など総コストを検証してください。スポットやSavings Plans/リザーブドインスタンスで更に最適化可能です。
  • 互換性: 一部のサードパーティソフトウェアやドライバはARMを正式サポートしていない場合があります。事前検証を行ってください。
  • セキュリティ/IAM: 通常のEC2起動に必要なIAM権限が必要です。EFAやEBSの操作に関する権限、キーペア、セキュリティグループの設定を事前に確認してください。

参考情報 ​

[Lambda] AWS Lambda now supports Availability Zone metadata ​

概要 ​

AWS Lambda実行環境から実行中の関数が属するアベイラビリティゾーン（AZ）のIDを取得できる新しいメタデータエンドポイントが追加されました。これにより、同一AZ優先のルーティングやAZ単位のフォールトインジェクションなどのAZ-awareな設計が容易になります。

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

Lambda実行環境に新たに提供されたメタデータエンドポイントを通じて、関数実行時のAZ ID（例: use1-az1）をHTTPリクエストで取得できます。これにより、関数からAmazon ElastiCacheやAmazon RDSのAZ固有エンドポイントを同一AZ優先で選択してクロスAZレイテンシを低減したり、AZ別の耐障害性テスト（フォールトインジェクション）を実装したりすることが可能になります。取得方法は、Lambdaが自動的に設定する実行環境の環境変数を使ってメタデータエンドポイントに直接HTTPアクセスするか、Powertools for AWS Lambdaのmetadataユーティリティを利用する方法があります。すべてのLambdaランタイム（カスタムランタイムおよびコンテナイメージを含む）でサポートされ、SnapStartやプロビジョンドコンカレンシーとも連携します。VPC有効/無効に関わらず動作し、追加の設定なしに利用可能です。AZメタデータの提供は追加料金なしで、Lambdaが利用可能なすべての商用リージョンで利用できます。

影響範囲・利用シーン ​

  • 対象ユーザー: サーバーレス開発者、SRE/運用チーム、アプリケーションアーキテクト
  • 利用シーン: 同一AZの下流サービス（RDS/ElastiCache等）を優先するルーティング、AZ別のフォールトインジェクションや耐障害性テスト、AZ-awareなトラフィック最適化
  • 運用効果: クロスAZ通信の遅延削減、AZ単位の障害検証やローカル性を活かしたパフォーマンス改善、カスタムソリューションを構築する手間の削減

技術的な注意点 ​

  • IAM権限: メタデータは実行環境からのローカルHTTP呼び出しで取得するため、追加のIAM権限は不要（ただし取得結果の取り扱いに注意）
  • リージョン制限: 商用AWSリージョンで利用可能。GovCloudや中国リージョンなど商用リージョン外では未対応の可能性があるため公式ドキュメントで要確認
  • コスト: 追加料金は発生しないと明示。ただし大量に呼び出す場合は関数実行時間に影響するため間接的なコスト増加に注意（キャッシュ推奨）
  • 実行環境の安定性: Lambdaは複数AZに実行環境を配置するため、呼び出しごとに異なるAZで実行されることがある。AZ IDは呼び出し時点の実行環境を示すため、セッションの持続性を前提とした設計は避けるか、呼び出しごとに取得／キャッシュ戦略を検討すること
  • 連携機能: SnapStart、プロビジョンドコンカレンシー、カスタムランタイム／コンテナイメージ、VPC有効関数で動作することを確認済み
  • セキュリティ: AZ情報をログや外部に漏らさないように注意。メタデータの出力を誤って外部APIへ送信しない運用ルールを設けること
  • 実装上の推奨: 頻繁に問い合わせる代わりに短期間キャッシュ（実行環境のライフタイムに合わせる）することでレイテンシとコストを抑制。Powertoolsのmetadataユーティリティ利用で実装が簡素化される

参考情報 ​

[Direct Connect] AWS Direct Connect announces new location in Sydney, Australia ​

概要 ​

AWS Direct Connectがオーストラリア・シドニーのEquinix SY5に新しいロケーションを開設しました。専用の10 Gbps/100 Gbps接続とMACsec暗号化が利用可能で、国内ではシドニーの4拠点目、オーストラリア全体では10拠点目となります。

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

新しいDirect Connectロケーション（Equinix SY5, Sydney）が追加され、ここから中国リージョンを除くすべてのパブリックAWSリージョン、AWS GovCloudリージョン、およびAWS Local Zonesへプライベートかつ専用のネットワーク接続を確立できます。提供される物理ポートは専用の10 Gbpsおよび100 Gbpsで、MACsecによるレイヤ2暗号化が利用可能です。Direct Connectはデータセンター／オフィス／コロケーション環境とAWS間の専用回線を提供し、インターネット経由よりも一貫した低遅延・安定した通信を実現します。新ロケーションは既存のシドニー拠点と組み合わせて冗長化や帯域増強に利用でき、Direct Connect Gatewayを併用することで複数リージョンや複数VPCへの接続設計が可能です。導入はAWSマネジメントコンソールからのポート購入／接続申請や、Equinixを介したクロスコネクト手続き、またはDirect Connectパートナー経由のホステッド接続で行います。

影響範囲・利用シーン ​

  • 対象ユーザー: エンタープライズ／SaaS事業者、オンプレミスとAWSを接続するネットワーク／クラウドエンジニア
  • 利用シーン: ハイブリッドクラウド接続（オンプレミス→VPC）、災対/冗長回線構成、低遅延が要求されるアプリケーションのトラフィック移行
  • 運用効果: ネットワーク遅延およびジッターの低減、帯域確保による安定運用、複数ロケーションによる冗長化での可用性向上

技術的な注意点 ​

  • リージョン制限: 中国リージョン（北京/寧夏）はDirect Connect経由での接続対象外です。AWS GovCloudとLocal Zonesへの接続はサポート対象です
  • ポート/帯域: 専用10 Gbpsおよび100 Gbpsを提供。必要に応じて複数ポートでアグリゲーション／冗長化を検討してください
  • MACsec: MACsecが利用可能ですが、顧客側ルーターがMACsecをサポートしている必要があります。キー管理／設定は物理レイヤーでの整合が必要です
  • 接続手続き: Equinix内でのクロスコネクト作業や、ホステッド接続を使う場合はパートナー経由の手続きが必要です。LoA（Letter of Authorization）や物理ポート割当ての作業が発生します
  • Direct Connect Gateway: 複数リージョン／複数VPCへの集約ルーティングに利用可能ですが、中国リージョンは除外されます。リージョン間転送や経路制御の設計に注意してください
  • コスト: ポート時間課金（ポートの時間単位料金）やデータ転送料金、Equinix側のクロスコネクト費用、MACsecや追加サービスの費用が発生する場合があります。導入前に料金を確認してください
  • IAM権限: Direct Connectの操作（接続の作成、仮想インターフェイスの管理等）には適切なIAMポリシーが必要です。運用アカウントの権限設計を事前に確認してください

参考情報 ​

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

Copyright © 2026