aws_whats_new_2025-08-28 AWSマネジメントコンソールがAWSアカウントへの色割り当てをサポートし、識別が容易に 他

はじめに

AWSの基礎力をつけるためにAWS What's Newを毎日目を通す事を始めました。
最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。

本情報が役立つ人もいるかなと思い公開します。
個人的な理解なので、実際の情報は原典をあたってください。

---

AWS Transfer Family、SFTPコネクタ展開のためのTerraformサポートを発表

投稿日: 2025年08月27日

何ができるようになったのか

AWS Transfer FamilyのTerraformモジュールが、SFTPコネクタのデプロイをサポートするようになりました。これにより、Terraformを使用して、Amazon S3とリモートSFTPサーバー間でファイルを転送するためのSFTPコネクタをプログラムでプロビジョニングできます。

何が嬉しいのか

Infrastructure as Code (IaC) を用いてファイル転送リソースの一元的なプロビジョニングを自動化・効率化できます。これにより、時間のかかるエラーが発生しやすい手動設定が不要になり、迅速で再現性が高く、安全かつスケーラブルなデプロイが可能になります。

これまでとどう変わるのか

• これまで
  • SFTPコネクタのデプロイには、コンソールなどからの手動設定が必要でした。
• これから
  • Terraformを使い、SFTPコネクタ、関連する依存関係、カスタマイズを単一のデプロイでプログラム的にプロビジョニングできるようになります。

具体的なユースケース

• スケジュールやイベントトリガーに基づいたファイル転送ワークフローの自動化。例えば、特定の時間にS3バケットからパートナーのSFTPサーバーへファイルを自動的にコピーする、といった処理をTerraformでコード化して管理できます。

---

SageMaker HyperPodがEBSボリュームの顧客管理KMSキーをサポート

投稿日: 2025年8月27日

何ができるようになったのか

Amazon SageMaker HyperPodで、EBSボリュームを暗号化するために顧客が管理するAWS KMSキー（CMK）がサポートされるようになりました。これにより、ルートボリュームとセカンダリボリュームの両方を、ユーザー自身のKMSキーを使用して暗号化できます。

何が嬉しいのか

この機能により、企業は組織固有のセキュリティやコンプライアンス要件を満たす機械学習クラスターをデプロイできます。セキュリティ管理の強化、規制コンプライアンスへの対応、そして既存のキー管理ワークフローとの統合が実現します。

これまでとどう変わるのか

• これまで
  • クラスターのストレージ暗号化には、SageMaker HyperPodが所有・管理するキーしか使用できませんでした。
• これから
  • クラスターの作成時または更新時に、顧客が管理するKMSキーを指定してEBSボリュームを暗号化できるようになります。ルートボリュームとセカンダリボリュームで、それぞれ異なるキーを選択することも可能です。

具体的なユースケース

• 金融や医療など、厳格なデータセキュリティとコンプライアンスが求められる業界で、基盤モデル（Foundation Models）をトレーニングする際に、自社の暗号化ポリシーを適用する。
• 既存のキー管理インフラと統合し、暗号化キーの一元的な監査と管理を行う。

---

Amazon SageMaker HyperPodが永続ストレージのためのAmazon EBS CSIドライバをサポート開始

投稿日: 2025年08月27日

何ができるようになったのか

Amazon SageMaker HyperPodが、Amazon Elastic Block Store (EBS) Container Storage Interface (CSI) ドライバをサポートするようになりました。これにより、SageMaker HyperPod EKSクラスタ上の機械学習ワークロードに対して、永続ストレージを動的にプロビジョニングおよび管理できます。ユーザーはKubernetesの永続ボリューム要求（persistent volume claims）を通じて、EBSボリュームの作成、アタッチ、管理が可能です。

何が嬉しいのか

ポッドの再起動やノードの交換があってもストレージが永続化されるため、データの損失を防げます。また、モデルの要件に応じて動的にボリュームをプロビジョニングしたり、サービスを中断することなくボリュームサイズを変更したり、バックアップとリカバリのためにスナップショットを作成したりすることが可能になります。これにより、ストレージコストとパフォーマンスが最適化されます。

これまでとどう変わるのか

• これまで
  • トレーニングや推論ワークロードで柔軟なストレージ割り当てが必要な場合、Kubernetesのワークフローの外で手動でEBSボリュームを管理する必要がありました。
• これから
  • EBS CSIドライバが、Kubernetesの標準的なストレージクラス操作を通じて、EBSボリュームの作成、アタッチ、マウント、クリーンアップといったライフサイクル全体を管理してくれるようになります。

具体的なユースケース

• トレーニングワークロード: データセット、モデルのチェックポイント、共有アーティファクトのための永続ストレージとして利用できます。
• 推論ワークロード: モデルストレージのプロビジョニング、キャッシングボリュームの作成、イベントロギングの維持などに活用できます。

---

Amazon CloudWatch Application Signalsでカスタムメトリクスが利用可能に

投稿日: 2025年8月27日

何ができるようになったのか

Amazon CloudWatch Application Signalsで、カスタムメトリクスのサポートが開始されました。これにより、アプリケーション固有のカスタムメトリクスを定義し、障害率やレイテンシーなどの標準メトリクスと統合されたビューで相関させて表示できるようになります。

何が嬉しいのか

開発者や運用者は、アプリケーションの問題の根本原因をより迅速かつ正確に特定できるようになります。標準メトリクスとカスタムメトリクスを関連付けて分析することで、問題のパターンや依存関係を特定し、原因の絞り込みが容易になります。

これまでとどう変わるのか

• これまで
  • CloudWatch Application Signalsは、障害率、エラー、レイテンシーといった標準的なメトリクスを通じてアプリケーションの健全性を監視していました。アプリケーション固有のビジネスロジックや内部状態を監視するには、別のダッシュボードやツールが必要でした。
• これから
  • アプリケーション固有のカスタムメトリクスを追加し、標準メトリクスと同じコンソール上で相関分析ができるようになります。複数のメトリクスを重ねてグラフ化したり、特定のデータポイントから関連するトレースやログに直接ドリルダウンしたりすることが可能です。

具体的なユースケース

• ビジネスKPIの監視: ショッピングカートに追加された商品数や、特定のAPIエンドポイントの処理件数など、ビジネスに直結する値をカスタムメトリクスとして監視し、システムの健全性メトリクスと関連付けて分析する。
• パフォーマンスボトルネックの特定: 例えば、レイテンシーが増加した際に、特定のデータベースクエリの実行回数や外部API呼び出しの応答時間といったカスタムメトリクスを同時に確認し、どちらが原因であるかを迅速に特定する。
• OpenTelemetryによる詳細な可観測性: OpenTelemetry SDKを利用して、アプリケーションコードから直接メトリクス（例：キャッシュのヒット率、キューの長さなど）をエクスポートし、Application Signalsで他のメトリクスと統合して分析する。

---

AWS App RunnerがIPv6互換性のサポートを拡張

投稿日: 2025年08月27日

何ができるようになったのか

AWS App Runnerが、パブリックおよびプライベートのサービスエンドポイントにおいて、IPv6ベースのインバウンド（受信）およびアウトバウンド（送信）トラフィックをサポートするようになりました。

何が嬉しいのか

これにより、ユーザーはIPv6のコンプライアンス要件を満たすことが容易になり、IPv4とIPv6間のアドレス変換を管理する必要がなくなります。

これまでとどう変わるのか

• これまで
  • IPv6は、パブリックエンドポイントを介したインバウンドトラフィックでのみサポートされていました。アウトバウンドトラフィックやプライベートエンドポイントでは利用できませんでした。
• これから
  • パブリックおよびプライベートの両方のエンドポイントで、インバウンドとアウトバウンドの両方のトラフィックでIPv6が利用可能になります。ネットワーク設定でデュアルスタックオプションを選択することで、この機能を有効にできます。

具体的なユースケース

• IPv6への完全移行が求められる規制や要件を持つ組織（例：政府機関、一部のエンタープライズ）でのアプリケーションデプロイ。
• IPv6のみをサポートするクライアントやIoTデバイスからのアクセスが必要なWebアプリケーションやAPIの構築。
• NAT64/DNS64のようなIPv4/IPv6変換ゲートウェイを排除し、ネットワークアーキテクチャを簡素化したい場合。

---

Amazon Braket、Verbatim回路向けのローカルデバイスエミュレータを発表

投稿日: 2025年8月26日

何ができるようになったのか

Amazon Braketに、ローカルデバイスエミュレータが導入されました。これにより、開発者は実際の量子ハードウェアで実行する前に、デバイス固有の特性を持つVerbatim回路（ハードウェアに忠実な回路）をローカル環境でテストできるようになります。

何が嬉しいのか

• 開発の加速: 回路の互換性や現実的なノイズ条件下での挙動について早期にフィードバックを得られるため、開発サイクルが速くなります。
• コスト削減: 実際の量子ハードウェアを使わずに、量子プログラムの検証やノイズを考慮したアルゴリズムの開発ができるため、ハードウェア利用コストを削減できます。

これまでとどう変わるのか

• これまで
  • 回路の互換性やノイズの影響を正確にテストするには、実際に量子ハードウェア上でプログラムを実行する必要があり、時間とコストがかかっていました。
• これから
  • ローカル環境で、特定の量子デバイスの特性（量子ビットの接続性、ネイティブゲートセット、ノイズモデルなど）を模倣したテストが可能になります。これにより、互換性の問題を早期に発見し、効率的にアルゴリズムを改良できるようになります。

具体的なユースケース

• 開発中の量子プログラムが、ターゲットとする量子ハードウェアで正しく動作するかの事前検証
• ハードウェアのノイズ特性を考慮に入れた、より現実的な量子アルゴリズムの開発とデバッグ
• 実際のハードウェア実行前に行う、効率的なアルゴリズムのイテレーション（繰り返し改善）

---

AWS Client VPNがWindows Arm64 v5.3.0のOSサポートを拡張

投稿日: 2025年8月27日

何ができるようになったのか

AWS Client VPNのデスクトップクライアントが、バージョン5.3.0でWindows Arm64をサポートするようになりました。これにより、最新のWindows Arm64 OSを搭載したデバイスでAWS提供のVPNクライアントを実行できます。

何が嬉しいのか

Windows Arm64ベースのデバイス（例: Surface Pro Xなど）を使用しているユーザーが、エミュレーションなどを介さずネイティブにAWS Client VPNを利用できるようになり、パフォーマンスと互換性が向上します。これにより、リモートワーカーは自身のデバイスからAWSやオンプレミスのネットワークへよりスムーズかつ安全に接続できます。このクライアントは追加費用なしで利用可能です。

これまでとどう変わるのか

• これまで
  • AWS Client VPNは、Windows Arm64をネイティブサポートしていませんでした。サポートされているOSは、MacOS、Windows x64、Ubuntu-Linuxなどに限定されていました。
• これから
  • Windows 10 (x64)およびWindows 11 (x64)に加えて、Windows 11 (Arm64)でもネイティブに動作するクライアントが利用可能になります。

具体的なユースケース

• Windows on Arm搭載のノートPCを利用する企業の従業員が、自宅や外出先から社内のAWS上のリソースや、オンプレミスのファイルサーバーに安全にアクセスする。

---

Amazon EC2 C7i インスタンスがアジアパシフィック (大阪) リージョンで利用可能に

投稿日: 2025年08月27日

何ができるようになったのか

Amazon EC2 C7i インスタンスが、アジアパシフィック (大阪) リージョンで利用可能になりました。 これらのインスタンスは、カスタムの第4世代Intel Xeonスケーラブルプロセッサ（コードネーム：Sapphire Rapids）を搭載しています。

何が嬉しいのか

C7iインスタンスは、C6iインスタンスと比較して最大15%優れた価格性能を提供します。 また、他のクラウドプロバイダーが利用する同等のx86ベースのIn[1]telプロセッサよりも最大15%高いパフォーマンスを発揮します。 これにより、計算集約型のワークロードをよりコスト効率よく実行できます。

さらに、C7iインスタンスはCPUベースの機械学習などで使用される行列乗算演算を高速化するIntel Advanced Matrix Extensions (AMX) をサポートしています。 C6iインスタン[2][3]スの最大28個に対して最大128個のEBSボリュームをアタッチできるため、より大量のデータを処理し、ワークロードを拡張することが可能です。

これまでとどう変わるのか

• これまで
  • 大阪リージョンでは、C7iインスタンスは利用できず、計算集約型のワークロードに[2][3]はC6iのような旧世代のインスタンスを利用する必要がありました。
• これから
  • 大阪リージョンでも、より高いパフォーマンスと価格性能を持つC7iインスタンスを利用できるようになります。 これにより、バッチ処理、分散分析、広告配信、ビデオエンコーディングといった要求の厳しいワークロードを効率的に実行できます。

具体的なユースケース

• バッチ処理
• 分散分析
• 広告配信
• ビデオエンコーディング
• CPUベースの機械学習

---

AWSマネジメントコンソールがAWSアカウントへの色割り当てをサポートし、識別が容易に

投稿日: 2025年8月27日

何ができるようになったのか

AWSマネジメントコンソールで、AWSアカウントに特定の外観色を割り当てることができるようになりました。アカウント管理者は、アカウントごとに色を設定でき、その色はコンソールのナビゲーションバーに表示されます。これにより、すべての認可されたユーザーが、操作中のアカウントを視覚的に素早く識別できます。

アカウントの色を表示するには、ユーザーにAWSManagementConsoleBasicUserAccessというAWS管理ポリシー、またはuxc:getaccountcolorというカスタム権限を割り当てる必要があります。

何が嬉しいのか

複数のAWSアカウントを管理している場合、ナビゲーションバーの色を見るだけで、現在操作しているアカウントが一目でわかるようになります。例えば、本番環境のアカウントと開発環境のアカウントを色で区別することで、誤ったアカウントでの意図しない操作を防ぎ、安全性を向上させることができます。

これまでとどう変わるのか

• これまで
  • ユーザーはアカウントを識別するために、アカウント番号を確認する必要がありました。どのアカウントにサインインしても、ナビゲーションバーの色はデフォルトの灰色のままでした。
• これから
  • アカウントごとに設定された色がナビゲーションバーに表示されるため、現在どの環境で作業しているかを直感的に把握できるようになります。

具体的なユースケース

• 環境ごとの色分け: 本番環境のアカウントを「赤」、開発環境を「黄」のように設定し、オペレーションミスを防止する。
• 事業部門ごとの色分け: 複数の事業部門でAWSアカウントを共有している場合に、部門ごとに色を割り当てて管理を容易にする。

1. マネジメントコンソールにサインインします
2. ナビゲーションバーでアカウント名を選択します
3. Account を選択します
4. Account display settings で色を選択します

Choose Update.

さいごに

AWSマネジメントコンソールの色設定は地味に便利ですね。皆さんクローム拡張とかで色分けしていたのではないでしょうか。マルチアカウントへのスイッチなど開発者向けのアップデートもされてきて嬉しいですね。