はじめに #
AWSの基礎力をつけるためにAWS What’s Newを毎日目を通す事を始めました。 最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。
本情報が役立つ人もいるかなと思い公開します。 個人的な理解なので、実際の情報は原典をあたってください。
まとめと気付き #
AWS Builder IDがGoogleサインインをサポートしました。これは嬉しいですね。Amazonのアカウントっていっぱいあってややこしい印象です。AWS、お買い物のAmazon、BuildersID、さらにAWSは個人のアカウントも会社のアカウントもありますしね・・・
Amazon Connect が分析データレイクでエージェントの休暇残高データを提供するようになりました。いいことなのかな・・・？と思う一方で、どんどんAIでの代替は進みそうな気がします。人間とAIのスペック及びコスト対効果の対決が激化しますね。逆に言うと同じ土俵で戦ってはいけないし、戦わせてはいけない。幸せな未来につながることを祈ります🙏
AWS Directory Service が API を介したマネージド Microsoft AD のエディションアップグレードを可能に #
投稿日: 2025年10月02日
何ができるようになったのか #
AWS Directory Service のマネージド Microsoft AD において、Standard エディションから Enterprise エディションへのアップグレードを UpdateDirectorySetup API を通じてプログラム的に実行できるようになりました。これにより、セルフサービスでのエディションアップグレードが可能になります。
何が嬉しいのか #
- 運用上の障壁の排除: これまで AWS サポートとの調整が必要だったメンテナンスウィンドウの調整が不要になり、サポートチケットなしでアップグレードが可能になります。
- オンデマンドでのディレクトリ拡張: ユーザーベースの増加やアプリケーション要件の拡大に応じて、ディレクトリインフラストラクチャを迅速かつオンデマンドで拡張できます。
- データ保護と可用性の維持: アップグレード前の自動スナップショット作成によるデータ保護と、シーケンシャルなドメインコントローラーアップグレードによるプロセス中のディレクトリ可用性維持が保証されます。
- 自動化との統合: プログラムによるアプローチにより、既存の自動化フレームワークや Infrastructure-as-Code (IaC) デプロイメントとの統合が容易になります。
これまでとどう変わるのか #
- これまで
- マネージド Microsoft AD のエディションアップグレードには、AWS サポートとの調整やメンテナンスウィンドウの計画が必要で、運用上の手間と時間がかかっていました。
- ディレクトリの拡張が必要な際に、サポート主導のプロセスによる遅延が発生する可能性がありました。
- これから
UpdateDirectorySetupAPI を使用して、プログラムで Standard から Enterprise エディションへアップグレードできるようになります。- サポートチケットなしでセルフサービスでのアップグレードが可能になり、オンデマンドでディレクトリを拡張できます。
- 自動化されたスナップショットとシーケンシャルなアップグレードにより、データ保護と可用性を維持しながら、迅速かつ効率的にアップグレードを実行できます。
具体的なユースケース #
- 動的なインフラストラクチャ拡張: ユーザー数の急増や新しいアプリケーションの導入に伴い、ディレクトリの規模を迅速に拡大する必要がある場合に、API を通じて自動的にエディションをアップグレードし、対応能力を向上させます。
- IaC との統合: AWS CloudFormation や Terraform などの Infrastructure-as-Code ツールを使用して、ディレクトリサービスを含むインフラストラクチャ全体のデプロイメントと管理を自動化する際に、エディションアップグレードもそのワークフローに組み込みます。
- 運用コストの削減: サポートチケットの作成や手動での調整にかかる時間を削減し、運用チームの負担を軽減します。
AWS Parallel Computing Service (PCS) が Slurm を介したノード再起動をサポート #
投稿日: 2025年10月02日
何ができるようになったのか #
AWS Parallel Computing Service (PCS) において、Slurm コマンドを使用してコンピューティングノードを再起動しても、インスタンスの置き換えがトリガーされなくなりました。これにより、scontrol reboot コマンドを使って即時または延期された再起動をスケジュールできるようになりました。
何が嬉しいのか #
トラブルシューティング、リソースのクリーンアップ、劣化状態からの回復といった運用上の理由でノードを再起動する際に、完全なノードの置き換えを必要とせずに対応できるようになります。これにより、クラスターの健全性を効率的かつ低コストで維持できるようになります。
これまでとどう変わるのか #
- これまで
- PCS のコンピューティングノードを再起動すると、インスタンスの置き換えがトリガーされていました。
- これから
- Slurm コマンド（
scontrol reboot）を使用した場合、インスタンスの置き換えをトリガーせずにコンピューティングノードを再起動できるようになりました。
- Slurm コマンド（
具体的なユースケース #
- クラスターの健全性を維持するためのトラブルシューティング。
- 一時的なリソースのクリーンアップ。
- パフォーマンスが低下したノードの劣化状態からの回復。
Amazon GameLift Servers がコンソールでインスタンスの表示と接続機能を追加 #
投稿日: 2025年10月02日
何ができるようになったのか #
Amazon GameLift Servers のコンソールで、個々のフリートインスタンスを表示し、接続できるようになりました。EC2 およびコンテナフリートの詳細ページに新しい「インスタンス」タブが追加され、フリートに関連付けられたインスタンスのリストを確認できます。各インスタンスには、人間が読める形式でメタデータを表示するインスタンス詳細ページがあり、リストビューと詳細ビューから接続ボタンを呼び出し、AWS CloudShell を起動してそのインスタンスに直接 SSM セッションを開始できます。
何が嬉しいのか #
このコンソール機能の改善により、デバッグ、検査、問題解決のための実践的なツールが提供され、より迅速に問題を解決できるようになります。外部ツールや推測に頼ることなく、ホストのパフォーマンスを直接調査したり、最新のゲームサーバーログを取得したり、ネットワーク設定やインスタンスの健全性などの問題を診断したりすることが、すべて Amazon GameLift Servers コンソール内から可能になります。これにより、トラブルシューティングのターンアラウンドタイムが短縮され、ゲームサーバーフリートの「内部」で何が起こっているかについての可視性が向上します。
これまでとどう変わるのか #
- これまで
- ゲームサーバーインスタンスのデバッグや検査には、外部ツールを使用したり、推測に頼ったりする必要がありました。
- インスタンスの内部状態やログへの直接的なアクセスがコンソールから容易ではありませんでした。
- トラブルシューシューティングに時間がかかり、フリートの可視性が限られていました。
- これから
- Amazon GameLift Servers コンソールから直接、個々のフリートインスタンスの表示、詳細の確認、および SSM セッションを介した接続が可能になります。
- ホストのパフォーマンス調査、ゲームサーバーログの取得、ネットワーク設定やインスタンスの健全性の診断がコンソール内で完結します。
- トラブルシューティングの効率が大幅に向上し、ゲームサーバーフリートの運用状況に対する深い洞察が得られます。
具体的なユースケース #
- ゲームサーバーインスタンスで発生している問題をデバッグする。
- ホストのパフォーマンスを検査し、ボトルネックを特定する。
- 最新のゲームサーバーログを直接取得して、ゲームプレイの問題やエラーを診断する。
- ネットワーク設定の問題を診断し、接続性の問題を解決する。
- インスタンスの健全性を確認し、異常な動作を早期に検出する。
AWS Builder IDがGoogleサインインをサポート #
投稿日: 2025年10月02日
何ができるようになったのか #
Googleアカウントを使用してAWS Builder IDを作成し、サインインできるようになりました。これにより、Kiro、AWS Builder Center、AWS Training and Certification、AWS re:Post、AWS StartupsなどのAWSアプリケーションにアクセスできます。
何が嬉しいのか #
Googleアカウントを使ってワンクリックでAWSアプリケーションやウェブサイトにアクセスできるため、利便性が向上します。個別の認証情報を管理する必要がなくなり、登録プロセスがさらに簡素化され、パスワードを忘れる可能性が低減されます。既存のユーザーも、AWSアプリケーションへのサインインがスムーズになります。
これまでとどう変わるのか #
- これまで
- AWS Builder IDを作成する際に、Googleアカウントでの直接サインインはサポートされていませんでした。ユーザーは個別の認証情報を作成・管理する必要がありました。
- これから
- Googleアカウントを使用してAWS Builder IDを簡単に作成し、サインインできるようになります。これにより、複数の認証情報を管理する手間が省け、より迅速かつスムーズにAWSアプリケーションにアクセスできるようになります。
具体的なユースケース #
- AWS Builder IDをサポートするAWSアプリケーション（Kiro、AWS Builder Center、AWS Training and Certification、AWS re:Post、AWS Startupsなど）に、Googleアカウントを使って迅速にサインインしたい場合。
- 新しいAWSアプリケーションを使い始める際に、既存のGoogleアカウントを利用して登録プロセスを簡素化したい場合。
- 複数のAWSサービスやアプリケーションで個別の認証情報を管理する手間を省き、一元化されたサインイン体験を享受したい場合。
AWS Config の高度なクエリとアグリゲーターがアジアパシフィック (ニュージーランド) リージョンで利用可能に #
投稿日: 2025年10月02日
何ができるようになったのか #
AWS Config の高度なクエリとアグリゲーターが、アジアパシフィック (ニュージーランド) リージョンで利用可能になりました。これにより、このリージョンでも以下の機能が利用できます。
- 高度なクエリ: AWS リソースの現在の設定とコンプライアンスの状態をクエリできます。
- アグリゲーター: 複数のアカウントやリージョン、または AWS Organizations 全体から設定およびコンプライアンスデータを集約し、一元的な可視化と分析を可能にします。
- 単一のクエリエンドポイントとクエリ言語を使用して、サービス固有の describe API 呼び出しを実行することなく、リソースの設定とコンプライアンスの状態を取得できます。
- 設定アグリゲーターを使用して、中央のアカウントから複数のアカウントおよび AWS リージョンにわたって同じクエリを実行できます。
- AWS コンソールおよび AWS CLI から高度なクエリを利用できます。
何が嬉しいのか #
- 効率的な設定管理: サービス固有のAPI呼び出しを個別に実行することなく、一元的にリソースの設定やコンプライアンス状態を把握できます。
- コンプライアンスの強化: 複数のアカウントやリージョンにまたがるリソースのコンプライアンス状況を簡単に監視・分析できます。
- 運用の一元化: AWS Organizations を利用している場合、組織全体のリソース設定とコンプライアンスデータを集約し、管理を簡素化できます。
- グローバルな機能均一化: AWS Config の高度なクエリとアグリゲーターがすべてのサポート対象リージョンで利用可能になったため、ニュージーランドリージョンでも他のリージョンと同等の高度な管理機能を利用できるようになりました。
これまでとどう変わるのか #
- これまで
- アジアパシフィック (ニュージーランド) リージョンでは、AWS Config の高度なクエリとアグリゲーターが利用できませんでした。そのため、このリージョン内のリソースの設定やコンプライアンス状態を詳細に分析するには、サービス固有のAPIを個別に呼び出すか、手動での集計作業が必要でした。また、複数のアカウントやリージョンにまたがるデータの集約も、より複雑なプロセスを要しました。
- これから
- アジアパシフィック (ニュージーランド) リージョンでも、高度なクエリとアグリゲーターが利用可能になったことで、単一のクエリ言語とエンドポイントを通じて、リソースの設定とコンプライアンス状態を効率的に照会できるようになります。また、複数のアカウントやリージョンにわたるデータを一元的に集約し、可視化・分析することが容易になり、運用管理の負担が軽減されます。
具体的なユースケース #
- コンプライアンス監査: ニュージーランドリージョンにデプロイされたすべての EC2 インスタンスが特定のセキュリティグループに属しているか、または特定のタグが付与されているかを一括で確認する。
- リソースインベントリの管理: 組織内の複数のアカウントとリージョン（ニュージーランドを含む）に存在するすべての S3 バケットの暗号化設定を一元的に把握し、レポートを作成する。
- 設定変更の追跡: 特定の期間内にニュージーランドリージョン内のデータベースインスタンスの設定がどのように変更されたかを、サービス固有のAPIを呼び出すことなく確認する。
- セキュリティポリシーの適用状況確認: 組織全体の AWS リソース（ニュージーランドリージョンを含む）が、定義されたセキュリティポリシーに準拠しているかを定期的にチェックし、違反しているリソースを特定する。
Amazon Connect が ChromeOS デバイスでのエージェント画面録画をサポート #
投稿日: 2025年10月02日
何ができるようになったのか #
Amazon Connect が ChromeOS デバイスを使用しているエージェントの画面録画をサポートするようになりました。これにより、エージェントが顧客とのコンタクト（音声通話、チャット、タスク）を処理する際のアクションを記録し、確認できるようになります。
何が嬉しいのか #
エージェントのパフォーマンス向上をより効果的に支援できるようになります。顧客との通話を聞いたり、チャットのトランスクリプトを確認するだけでなく、エージェントがコンタクト中にどのような操作を行っているかを視覚的に把握できるため、コーチングが必要な領域（例：コンタクト処理時間の長さ、ビジネスプロセスへの不遵守）を特定しやすくなります。
これまでとどう変わるのか #
- これまで
- ChromeOS デバイスを使用するエージェントの画面録画はサポートされていなかったため、エージェントのパフォーマンス評価やコーチングは、主に通話記録やチャット履歴に限定されていました。エージェントの具体的な操作やデスクトップ上での行動を直接確認することは困難でした。
- これから
- ChromeOS デバイスを使用するエージェントの画面録画が可能になり、エージェントが顧客対応中にどのような操作を行っているかを詳細に把握できるようになりました。これにより、より具体的で効果的なコーチングや品質管理が可能になります。
具体的なユースケース #
- エージェントが顧客対応中に、どのアプリケーションを使用し、どのような情報を参照しているかを記録し、後でレビューすることで、トレーニングの改善点を見つける。
- コンタクト処理時間が長いエージェントの画面録画を確認し、非効率な操作や手順の誤りを特定し、個別のコーチングに活用する。
- コンプライアンス要件がある場合、エージェントが規定のプロセスに従って操作しているか、機密情報を適切に扱っているかを画面録画で確認し、監査証跡として利用する。
- 新しいエージェントのオンボーディング時に、熟練エージェントの画面録画を見せて、ベストプラクティスを学ぶ教材として活用する。
AWS Direct Connect、フィリピンのマカティ市で100Gの拡張を発表 #
投稿日: 2025年10月02日
何ができるようになったのか #
フィリピンのマカティ市にある既存のAWS Direct Connectロケーション（ePLDTデータセンター内）で、MACsec暗号化機能を備えた10 Gbpsおよび100 Gbpsの専用接続が利用可能になりました。これにより、このロケーションからすべてのパブリックAWSリージョン（中国を除く）、AWS GovCloudリージョン、およびAWS Local Zonesへのプライベートで直接的なネットワークアクセスを確立できます。
何が嬉しいのか #
パブリックインターネット経由の接続と比較して、より一貫性のあるネットワークエクスペリエンスが得られます。高帯域幅とMACsec暗号化により、セキュリティとパフォーマンスが向上し、大規模なデータ転送や機密性の高いワークロードをより安全かつ効率的に実行できるようになります。
これまでとどう変わるのか #
- これまで
- マカティ市のDirect Connectロケーションでは、10 Gbpsおよび100 Gbpsの専用接続オプションやMACsec暗号化機能が利用できませんでした。
- これから
- マカティ市のDirect Connectロケーションから、最大100 Gbpsの専用接続とMACsec暗号化を利用して、AWSへのプライベートかつセキュアな高帯域幅接続を確立できるようになります。
具体的なユースケース #
- 大量のデータをAWSに転送する必要がある企業（データ移行、大規模なバックアップ、災害復旧など）。
- オンプレミス環境とAWS間で低レイテンシーかつ高スループットの接続を必要とするアプリケーション（ハイブリッドクラウドアプリケーション、リアルタイムデータ処理、VDIなど）。
- 機密性の高いデータを扱うワークロードで、MACsecによるレイヤー2レベルの暗号化を必要とする場合。
- パブリックインターネットの混雑や不安定さを避け、予測可能で一貫したネットワークパフォーマンスを求める企業。
AWS Secrets Manager が AWS PrivateLink のサポートを FIPS エンドポイントに拡大 #
投稿日: 2025年10月02日
何ができるようになったのか #
AWS Secrets Manager が、商用 AWS リージョンおよび AWS GovCloud (US) リージョンで利用可能なすべての Secrets Manager Federal Information Processing Standard (FIPS) エンドポイントで AWS PrivateLink をサポートするようになりました。これにより、VPC と Secrets Manager FIPS エンドポイント間のプライベート接続を確立できるようになります。
何が嬉しいのか #
パブリックインターネットを介して接続する代わりに、VPC と Secrets Manager FIPS エンドポイント間でプライベート接続を確立できるため、組織のビジネス、コンプライアンス、および規制要件（パブリックインターネット接続の制限など）を満たすのに役立ちます。
これまでとどう変わるのか #
- これまで
- Secrets Manager FIPS エンドポイントへの接続は、パブリックインターネットを介して行われる可能性がありました。
- これから
- AWS PrivateLink を使用して、Secrets Manager FIPS エンドポイントへのプライベート接続を確立できるようになり、セキュリティとコンプライアンスが向上します。
具体的なユースケース #
- パブリックインターネットへの接続を制限するという、組織のビジネス、コンプライアンス、および規制要件を満たす必要がある場合。
- 機密性の高いシークレット管理において、ネットワークトラフィックをAWSネットワーク内に閉じ込めることでセキュリティ体制を強化したい場合。
Amazon Neptune DatabaseがGraphStormと統合し、スケーラブルなグラフ機械学習を可能に #
投稿日: 2025年10月02日
何ができるようになったのか #
Amazon Neptune Databaseが、エンタープライズ規模のアプリケーション向けに構築されたスケーラブルなオープンソースのグラフ機械学習（ML）ライブラリであるGraphStormと統合しました。これにより、NeptuneのOLTP（オンライン・トランザクション処理）グラフ機能とGraphStormのスケーラブルな推論エンジンが連携し、レイテンシーに敏感なトランザクション環境でグラフMLをデプロイすることが容易になりました。開発者はGraphStormでGNNモデルをトレーニングし、Neptuneに直接クエリを実行するリアルタイム推論エンドポイントとしてデプロイできるようになります。
何が嬉しいのか #
グラフのトランザクション更新とML駆動の意思決定の間のギャップが埋まり、ノード分類やリンク予測などの予測をサブ秒単位で返すことが可能になります。これにより、リアルタイムでの意思決定が可能になり、MLフィードバックループをグラフアプリケーション内で直接実現できます。
これまでとどう変わるのか #
- これまで
- グラフデータに対する機械学習モデルの推論をリアルタイムかつ低レイテンシーで実行することが困難でした。
- トランザクション処理とML駆動の意思決定を密接に連携させるには、複雑な統合が必要でした。
- これから
- NeptuneのOLTPグラフ機能とGraphStormのスケーラブルな推論エンジンが統合され、リアルタイムでのグラフML推論が容易になります。
- グラフの更新とMLによる意思決定がシームレスに連携し、サブ秒単位での予測が可能になります。
具体的なユースケース #
- 不正検出と防止: アカウント、デバイス、トランザクション間の複雑な関係に基づいて、リアルタイムで意思決定を行います。
- 動的なレコメンデーション: ライブグラフコンテキストを使用して、ユーザーの行動に即座に適応するシステムを構築します。
- グラフベースのリスクスコアリング: グラフが進化するにつれて、リスク評価が継続的に更新されます。
AWS Parallel Computing Service が Slurm のカスタマイズ機能を拡張 #
投稿日: 2025年10月02日
何ができるようになったのか #
AWS Parallel Computing Service (AWS PCS) が Slurm の設定機能を拡張し、ハイパフォーマンスコンピューティング (HPC) クラスターの運用をきめ細かく制御するための60以上の追加パラメーターを設定できるようになりました。これにより、ジョブスケジューリング、リソース割り当て、アクセス制御、ジョブライフサイクル管理において、より柔軟な対応が可能になります。
何が嬉しいのか #
ジョブスケジューリング、リソース割り当て、アクセス制御、ジョブライフサイクル管理の柔軟性が向上します。複数のチーム、プロジェクト、ワークロードタイプに効率的に対応する本番環境のHPC環境を運用できるようになります。インフラストラクチャの心配をすることなく、研究とイノベーションに集中できます。
これまでとどう変わるのか #
- これまで
- Slurm のカスタマイズ機能が限られており、多様なニーズに対応するHPCクラスターの運用をきめ細かく調整することが困難でした。
- これから
- 60以上の追加 Slurm パラメーターを設定できるようになり、複雑なHPC環境のきめ細かな制御と効率的な管理が可能になります。
具体的なユースケース #
- フェアシェアスケジューリングやサービス品質レベルを含む、様々なリソース管理シナリオをきめ細かく制御する。
- キュー固有の優先度ポリシーを実装する。
- プリエンプション設定を構成する。
- カスタムの時間制限とリソース制限を設定する。
- アカウントレベルでアクセス許可を制御する。
- ジョブごとの実行動作を構成する。
- 複数のチーム、プロジェクト、ワークロードタイプに効率的にサービスを提供する本番HPC環境を運用する。
AWS Parallel Computing Service が動的なクラスター更新をサポート #
投稿日: 2025年10月02日
何ができるようになったのか #
AWS Parallel Computing Service (AWS PCS) を利用して、クラスターを再構築することなく、主要なSlurmワークロードマネージャーの設定を変更および更新できるようになりました。これまでクラスター作成時に固定されていたアカウンティング設定やワークロード管理設定などの重要なパラメータを、既存のクラスターで調整できるようになりました。
何が嬉しいのか #
この新しい柔軟性により、運用を中断することなく、変化する要件に合わせてハイパフォーマンスコンピューティング (HPC) 環境を適応させることができます。これにより、HPC環境の管理がより効率的になり、研究やイノベーションに集中できるようになります。
これまでとどう変わるのか #
- これまで
- Slurmワークロードマネージャーのアカウンティング設定やワークロード管理設定などの重要なパラメータは、クラスター作成時に固定されており、後から変更するにはクラスターの再構築が必要でした。
- これから
- 既存のAWS PCSクラスターで、クラスターを再構築することなく、主要なSlurmワークロードマネージャーの設定（アカウンティング設定やワークロード管理設定など）を動的に変更・更新できるようになりました。
具体的なユースケース #
- HPC環境の要件が変更された際に、サービスを中断することなく、Slurmワークロードマネージャーの設定を柔軟に調整する。
- 研究や開発のフェーズに応じて、アカウンティングポリシーやリソース割り当て設定をリアルタイムで最適化する。
- AWS Management Console、AWS CLI、またはAWS SDKを通じて、既存のHPCクラスターの設定を容易に管理・更新する。
Amazon Connect がアウトバウンドコールでの顧客からの入力をより簡単に取得できるように #
投稿日: 2025年10月02日
何ができるようになったのか #
Amazon Connect のアウトバウンド音声ウィスパーフローで、「顧客からの入力を取得 (Get Customer Input)」および「顧客からの入力を保存 (Store Customer Input)」フローブロックがサポートされるようになりました。これにより、顧客が電話に応答した後、エージェントに接続される前にプロンプトを再生し、DTMF入力またはAmazon Lex Botを介して顧客の応答を収集できるようになりました。
何が嬉しいのか #
エージェントに接続する前に、アウトバウンドコールでインタラクティブかつ動的な顧客からの入力を取得できるようになります。これにより、顧客とのやり取りを効率化し、特定の情報に基づいてアクションを決定できるようになります。
これまでとどう変わるのか #
- これまで
- アウトバウンドコールにおいて、エージェントに接続する前に顧客からの入力を取得する機能が、フローブロックとして直接サポートされていませんでした。顧客からの入力は、エージェント接続後に行われるか、より複雑なカスタム実装が必要でした。
- これから
- 「顧客からの入力を取得」および「顧客からの入力を保存」フローブロックを使用することで、エージェントに接続する前に顧客からの入力を簡単に収集できるようになり、通話のパーソナライズや自動化が可能になります。
具体的なユースケース #
- エージェントが行うアウトバウンドコールの一部として、通話録音の顧客同意を事前に取得し、Amazon Connect Contact Lensの録音および分析をトリガーする。
Amazon EC2 Instance Connect EndpointがIPv6接続をサポート #
投稿日: 2025年10月02日
何ができるようになったのか #
Amazon EC2 Instance Connect Endpoint (EIC) がInternet Protocol Version 6 (IPv6) 接続をサポートするようになりました。これにより、顧客はEICエンドポイントをデュアルスタックまたはIPv6専用に設定し、IPv6アドレスを持つインスタンスに接続できるようになります。
何が嬉しいのか #
パブリックIPアドレスを使用せずにEC2インスタンスへのSSHおよびRDP接続が可能になるEC2 Instance Connectの機能が、IPv6環境でも利用できるようになります。特に、プライベートサブネット内のIPv6アドレスを持つインスタンスへも接続できるようになり、既存のIPv4アドレスを使用するインスタンスやサブネットとの後方互換性を維持しながら、よりセキュアで柔軟な接続オプションが提供されます。
これまでとどう変わるのか #
- これまで
- EC2 Instance Connect Endpointは主にIPv4接続をサポートしており、IPv6アドレスを持つインスタンスへの接続には、別の方法を検討する必要がありました。
- これから
- EC2 Instance Connect EndpointがIPv6接続をサポートし、デュアルスタックまたはIPv6専用で設定できるようになります。これにより、IPv6アドレスを持つプライベートサブネット内のインスタンスへも、パブリックIPアドレスなしで直接接続できるようになります。
具体的なユースケース #
- IPv6のみのネットワーク環境で、パブリックIPアドレスを持たないEC2インスタンスにセキュアにSSH/RDP接続を行う必要がある場合。
- 厳格なセキュリティポリシーにより、インスタンスがパブリックIPアドレスを持てない環境で、運用者がインスタンスにアクセスする必要がある場合。
- 既存のIPv4環境と共存しながら、徐々にIPv6への移行を進めている企業が、両方のプロトコルでインスタンスにアクセスする必要がある場合。
Amazon MSKがExpressブローカーを8つの追加AWSリージョンに拡大 #
投稿日: 2025年09月25日
何ができるようになったのか #
Amazon Managed Streaming for Apache Kafka (Amazon MSK) のExpressブローカーが、AWS GovCloud (US-West)、AWS GovCloud (US-East)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、アジアパシフィック (大阪)、欧州 (チューリッヒ)、イスラエル (テルアビブ)、アジアパシフィック (香港) の8つの追加AWSリージョンで利用可能になりました。
何が嬉しいのか #
Expressブローカーは、標準のApache Kafkaブローカーと比較して、ブローカーあたりのスループットが最大3倍、スケーリングが最大20倍高速になり、リカバリ時間が90%短縮されます。Kafkaのベストプラクティスがデフォルトで事前設定されており、すべてのKafka APIをサポートし、既存のクライアントアプリケーションに変更を加えることなく、期待される低レイテンシーのパフォーマンスを提供します。これにより、より高性能で回復力のあるストリーミングワークロードを、より多くのリージョンで構築できるようになります。
これまでとどう変わるのか #
- これまで
- これらの8つのリージョンでは、Amazon MSKのExpressブローカーを利用できず、標準ブローカーの性能制限内で運用する必要がありました。
- 高スループットや高速スケーリング、迅速なリカバリが必要な場合、他のリージョンを選択するか、標準ブローカーで追加の最適化やリソースが必要でした。
- これから
- 上記8つのリージョンでもExpressブローカーを選択できるようになり、ブローカーあたりのスループットが最大3倍、スケーリングが最大20倍高速、リカバリ時間が90%短縮される恩恵を享受できます。
- 既存のクライアントアプリケーションに変更を加えることなく、高性能なKafkaクラスターをこれらのリージョンで簡単にデプロイできるようになります。
具体的なユースケース #
- リアルタイム分析: 大量のデータを低レイテンシーで取り込み、処理するリアルタイム分析パイプライン。
- イベント駆動型アーキテクチャ: 高頻度で発生するイベントを迅速に処理し、マイクロサービス間で効率的に伝達するシステム。
- IoTデータ処理: 数百万のデバイスから生成される膨大なIoTデータを効率的に収集・処理するアプリケーション。
- ログ集約: 大規模な分散システムから生成されるログデータを一元的に集約し、分析するためのプラットフォーム。
- 金融取引システム: 高いスループットと低レイテンシーが求められる金融取引データのストリーミング処理。
AWS Clean Rooms がデータアクセス予算をサポート #
投稿日: 2025年10月2日
何ができるようになったのか #
AWS Clean Rooms が、コラボレーションに関連付けられたテーブルに対するデータアクセス予算をサポートするようになりました。これにより、カスタムMLモデルのトレーニングや推論、SQLクエリ、またはPySparkジョブでデータが分析される回数を制限できるようになります。日次、週次、月次で更新される期間ごとの予算、全体の使用量に対するライフタイム予算、またはその両方を同時に設定できます。
何が嬉しいのか #
この新しいプライバシーコントロールにより、パートナーとのデータコラボレーションにおいて、自身のデータが過度に分析されることを防ぎ、より詳細な制御とプライバシー保護を実現できます。予算を使い切った場合、予算が更新されるまで追加の分析が防止されるため、意図しないデータ利用を防ぎます。また、必要に応じて予算をいつでもリセットまたは編集できる柔軟性も提供されます。
これまでとどう変わるのか #
- これまで
- AWS Clean Roomsでのデータコラボレーションにおいて、パートナーが自身のデータを分析できる回数に対する直接的かつ自動的な制限機能がありませんでした。そのため、データ利用のガバナンスを維持するためには、より手動での監視や契約上の取り決めが必要となる場合がありました。
- これから
- データアクセス予算を設定することで、データが分析される回数を自動的に制限できるようになります。これにより、データ提供者は、データ利用の頻度を細かく制御し、プライバシーとセキュリティの要件をより厳密に満たすことが可能になります。
具体的なユースケース #
- 機密データの保護: 医療データや金融データなど、分析回数を厳しく制限する必要がある機密性の高いデータセットをパートナーと共有する際に、データアクセス予算を設定して過度な分析を防ぐ。
- MLモデルの共同開発: 複数の企業が共同で機械学習モデルを開発する際、各社が提供するデータがモデルトレーニングや推論のために利用される回数を制限し、データの公平な利用とプライバシーを確保する。
- データ利用のガバナンス: 広告キャンペーンの効果測定や市場分析など、特定の目的のためにデータコラボレーションを行う際、データ利用の頻度を管理し、契約上の合意事項を技術的に強制する。
Amazon Connect が分析データレイクでエージェントの休暇残高データを提供するようになりました #
投稿日: 2025年10月02日
何ができるようになったのか #
Amazon Connect が分析データレイクでエージェントの休暇残高データを提供するようになりました。これにより、最新および過去のエージェント休暇残高を、有給休暇、病気休暇、休職など、さまざまな休暇カテゴリで分析データレイクから取得できるようになりました。残高に加えて、残高に影響を与えたすべてのトランザクションの時系列リストも確認できます。
何が嬉しいのか #
このデータを利用してレポートやインサイトを生成することが容易になります。また、管理者が残高と休暇トランザクションを手動で調整する必要がなくなり、休暇管理が容易になるため、管理者の生産性が向上し、エージェントからの問い合わせへの対応が迅速になります。
これまでとどう変わるのか #
- これまで
- エージェントの休暇残高データは分析データレイクで利用できず、レポートやインサイトの生成が困難でした。
- 管理者は休暇残高とトランザクションを手動で調整する必要があり、時間と労力がかかっていました。
- これから
- エージェントの休暇残高データが分析データレイクで利用可能になり、最新および過去の残高やトランザクション履歴に簡単にアクセスできます。
- 管理者は手動での調整作業から解放され、生産性が向上し、エージェントからの問い合わせに迅速に対応できるようになります。
具体的なユースケース #
- エージェントの休暇残高に関する詳細なレポートを生成し、人員配置やリソース計画に活用する。
- 管理者がエージェントからの休暇残高に関する問い合わせに対し、リアルタイムで正確な情報を提供し、迅速に回答する。
- エージェントの有給休暇、病気休暇、休職などの各カテゴリにおける残高の推移を追跡し、傾向を分析する。
- 休暇申請やキャンセルなど、個々のトランザクションがエージェントの休暇残高にどのように影響したかを時系列で確認する。
Amazon Managed Workflows for Apache Airflow (MWAA) が Apache Airflow 3.0 のサポートを発表 #
投稿日: 2025年10月01日
何ができるようになったのか #
Amazon Managed Workflows for Apache Airflow (MWAA) が、ワークフローオーケストレーションプラットフォームの最新メジャーリリースである Apache Airflow バージョン 3.0 をサポートするようになりました。これにより、以下の機能が利用可能になります。
- Apache Airflow 3.0 のサポート: 最新バージョンの機能と改善が利用できます。
- 再設計されたインターフェース: ユーザビリティが向上し、より使いやすくなりました。
- 高度なイベント駆動型スケジューリング機能: 外部イベントに基づいて直接ワークフローをトリガーできるようになり、個別の資産更新パイプラインが不要になります。
- 新しい Task SDK: ボイラープレートコードを削減し、DAG を簡素化することで、ワークフローをより簡潔で読みやすく、一貫性のあるものにします。
- Task Execution API: メタデータベースへの直接アクセスを制限し、すべてのランタイムインタラクションを管理することで、セキュリティと分離が強化されます。
- スケジューラー管理のバックフィル機能: 履歴データ処理に対する制御が向上します。
- Python 3.12 のサポート: 最新の Python バージョンが利用可能になります。
- セキュリティ改善とバグ修正: 全体的な信頼性とセキュリティが向上します。
何が嬉しいのか #
- 効率と制御の向上: 複雑なワークフローの作成、スケジュール設定、監視をより効率的かつ高い制御性で行えるようになります。
- 開発の簡素化: Task SDK により、DAG の記述が容易になり、開発時間が短縮されます。
- 運用コストの削減: イベント駆動型スケジューリングにより、個別の更新パイプラインが不要になり、運用が簡素化されます。
- セキュリティの強化: Task Execution API と最新のセキュリティ改善により、ワークフローの安全性が向上します。
- 信頼性の向上: バグ修正と Python 3.12 のサポートにより、より安定した環境でワークフローを実行できます。
- 履歴データ処理の柔軟性: スケジューラー管理のバックフィル機能により、過去のデータの再処理が容易になります。
これまでとどう変わるのか #
- これまで
- Apache Airflow の古いバージョンを使用しており、最新の機能や改善が利用できませんでした。
- ワークフローのスケジューリングは時間ベースが主で、外部イベントへの直接的な対応が困難な場合がありました。
- DAG の記述にはより多くのボイラープレートコードが必要で、複雑になりがちでした。
- メタデータベースへのアクセス制御が限定的で、セキュリティと分離の強化が必要な場面がありました。
- 履歴データのバックフィルには手動または複雑な設定が必要でした。
- Python の古いバージョンに限定されていました。
- これから
- Apache Airflow 3.0 の最新機能と改善をすぐに利用できます。
- 再設計されたインターフェースにより、ワークフローの管理が直感的になります。
- 高度なイベント駆動型スケジューリングにより、外部イベントに即座に反応する動的なワークフローを構築できます。
- Task SDK を使用して、より簡潔で保守しやすい DAG を作成できます。
- Task Execution API により、セキュリティと分離が強化された環境でワークフローを実行できます。
- スケジューラー管理のバックフィル機能により、履歴データ処理が容易かつ効率的になります。
- Python 3.12 のサポートにより、最新のライブラリや機能を利用できます。
具体的なユースケース #
- リアルタイムデータ処理パイプライン: S3 バケットへのファイルアップロードやデータベースの変更などの外部イベントをトリガーとして、データ変換や分析ワークフローを自動的に開始します。
- 機械学習モデルの再トレーニング: 新しいデータが利用可能になった際に、イベント駆動で機械学習モデルの再トレーニングワークフローを起動し、結果をデプロイします。
- 複雑なデータ統合: 複数の異なるデータソースからのデータを統合し、変換、ロードする複雑な ETL (Extract, Transform, Load) パイプラインを効率的にオーケストレーションします。
- 履歴データの再処理: 過去のデータに対して新しい分析ロジックを適用したり、データ品質の問題を修正したりするために、スケジューラー管理のバックフィル機能を使用して効率的に再処理を実行します。
- セキュリティ要件の高いワークフロー: 機密性の高いデータ処理や暗号化操作を含むワークフローにおいて、Task Execution API による強化されたセキュリティと分離を活用します。