AWSの基礎力をつけるためにAWS What’s Newを毎日目を通す事を始めました。 最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。
本情報が役立つ人もいるかなと思い公開します。 個人的な理解なので、実際の情報は原典をあたってください。
¥3,520 Amazonで見る![AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11](https://m.media-amazon.com/images/I/61ftnZ09WvL._SY522_.jpg)
AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11
Amazon Aurora PostgreSQL が動的データマスキングを導入 #
投稿日: 2025年11月24日
何ができるようになったのか #
Amazon Aurora PostgreSQL-Compatible Edition は、新しい pg_columnmask 拡張機能を通じて動的データマスキングをサポートするようになりました。これにより、データベース内の機密データ保護を簡素化できます。pg_columnmask は、PostgreSQL のネイティブな行レベルセキュリティと列レベルの権限を補完する列レベルの保護を可能にすることで、Aurora のセキュリティ機能を拡張します。pg_columnmask を使用すると、SQL ベースのマスキングポリシーを通じて機密データへのアクセスを制御し、ユーザーの役割に基づいてクエリ時にデータがどのように表示されるかを定義できるため、GDPR、HIPAA、PCI DSS などのデータプライバシー規制への準拠に役立ちます。
pg_columnmask を使用すると、組み込み関数またはユーザー定義関数を使用して柔軟なマスキングポリシーを作成できます。情報を完全に非表示にしたり、部分的な値をワイルドカードに置き換えたり、カスタムマスキングアプローチを定義したりできます。さらに、単一の列に複数のマスキングポリシーを適用し、重みを使用してそれらの優先順位を制御できます。pg_columnmask は、WHERE、JOIN、ORDER BY、GROUP BY 句を含む複雑なクエリでもデータを保護します。データはクエリ処理中にデータベースレベルでマスクされ、保存されたデータは変更されません。
pg_columnmask は、Aurora PostgreSQL バージョン 16.10 以降、および 17.6 以降で、Aurora PostgreSQL が利用可能なすべての AWS リージョンで利用可能です。
何が嬉しいのか #
この新機能により、データベース内の機密データ保護が大幅に簡素化されます。GDPR、HIPAA、PCI DSS などのデータプライバシー規制への準拠が容易になり、企業はより厳格なセキュリティ要件を満たすことができます。柔軟なマスキングポリシーにより、特定のユーザーの役割やビジネスニーズに合わせて、データの表示方法をきめ細かく制御できるようになります。また、複雑なクエリに対してもデータ保護が適用されるため、アプリケーションの変更なしにセキュリティを強化できます。保存されたデータは変更されないため、データの整合性を維持しつつ、セキュリティを向上させることが可能です。
これまでとどう変わるのか #
- これまで: PostgreSQL のネイティブな行レベルセキュリティや列レベルの権限は存在しましたが、ユーザーの役割やポリシーに基づいてクエリ時に動的にデータをマスクする機能は提供されていませんでした。
- これから:
pg_columnmask拡張機能の導入により、データベースレベルで動的な列レベルのデータマスキングが可能になります。これにより、機密データへのアクセスをより詳細に制御し、規制遵守を強化できます。
具体的なユースケース #
- 顧客の個人情報（氏名、住所、電話番号など）を、特定の役割を持つユーザーには完全に非表示にする、または一部をマスクして表示する。
- 財務データ（クレジットカード番号、口座番号など）を、監査担当者にはフルアクセスを許可し、一般従業員には下4桁のみ表示する。
- 医療記録（患者 ID、診断情報など）を、HIPAA などの規制に準拠するため、特定の研究者や分析ツールに対してのみ匿名化された形式で提供する。
- 開発環境やテスト環境で、本番データをマスキングして使用し、機密情報の漏洩リスクを低減する。
Amazon CloudFront が相互 TLS 認証のサポートを発表 #
投稿日: 2025年11月24日
何ができるようになったのか #
Amazon CloudFront が相互 TLS 認証 (mTLS) のサポートを開始しました。mTLS は、サーバーとクライアントの両方が X.509 証明書を使用して相互に認証することを要求するセキュリティプロトコルです。これにより、お客様は CloudFront のエッジロケーションでクライアントの身元を検証できるようになります。信頼された証明書を提示するクライアントのみがディストリビューションにアクセスできるようになり、不正アクセスやセキュリティ脅威から保護されます。
何が嬉しいのか #
CloudFront のエッジでクライアントの身元を簡単に検証できるようになり、アプリケーションサーバーや API との接続が確立される前にセキュリティを強化できます。また、クライアント認証が必要なワークロードに対して、CloudFront のパフォーマンスとスケーラビリティの恩恵を受けられます。
これまでとどう変わるのか #
- これまで: お客様は、独自のクライアントアクセス管理ソリューションを実装・維持するために継続的な労力を費やす必要があり、差別化につながらない重労働となっていました。
- これから: 相互 TLS のサポートにより、AWS エッジでクライアントの身元を簡単に検証できるようになり、アプリケーションサーバーや API との接続が確立される前にセキュリティを強化できます。
具体的なユースケース #
- 企業向けの B2B セキュア API 統合や、IoT のクライアント認証。
- B2B API セキュリティでは、企業は信頼できるサードパーティやパートナーからの API リクエストを mTLS を使用して認証できます。
- IoT ユースケースでは、デバイスがファームウェアアップデートなどのプロプライエタリなコンテンツを受信する権限があることを検証できます。
mTLSは「mutual TLS Authentication」の略です。 サーバーとクライアントの両方が X.509 証明書を使用して相互に認証することを要求するセキュリティプロトコルです。 主な特徴は以下の通りです。
- クライアントの身元を CloudFront のエッジで検証
- 信頼された証明書を提示するクライアントのみがアクセス可能
- 不正アクセスやセキュリティ脅威からの保護
Amazon Connect がエージェントによるEメールコンタクトへのフォローアップ返信を可能に #
投稿日: 2025年11月21日
何ができるようになったのか #
Amazon Connect が、エージェントがEメールコンタクトに対してフォローアップの返信を送信できるようになりました。これにより、新しいスレッドを開始することなく、追加情報を共有したり、顧客のサポートを継続したりすることが容易になります。
何が嬉しいのか #
この機能により、完全な会話履歴が保持され、エージェントはコンテキストを維持し、一貫性のあるシームレスなサポートを提供できるようになります。
これまでとどう変わるのか #
- これまで: 新しいスレッドを開始する必要があったため、会話履歴が分断される可能性がありました。
- これから: 新しいスレッドを開始することなくフォローアップ返信が可能になり、完全な会話履歴が保持されます。
具体的なユースケース #
- 顧客からの問い合わせに対し、一度返信した後にさらなる情報提供が必要になった場合や、顧客が追加の質問をしてきた場合に、既存の会話スレッド内で継続して対応できます。
Amazon Connectのフローモジュールがカスタム入力、出力、バージョン管理に対応 #
投稿日: 2025年11月24日
何ができるようになったのか #
Amazon Connectのフローモジュールが、カスタム入力、出力、ブランチ、およびバージョン管理とエイリアス管理に対応しました。これにより、再利用可能なフローモジュールに対して、特定のビジネスロジックに合わせて柔軟なパラメータを定義できるようになります。また、高度なバージョン管理とエイリアス機能により、モジュールの更新をよりシームレスに管理できます。不変のバージョンをスナップショットとして作成し、エイリアスを特定のバージョンにマッピングすることが可能です。エイリアスを新しいバージョンに更新すると、そのモジュールを使用するすべてのフローが自動的に更新されたバージョンを参照します。
何が嬉しいのか #
これらの新機能により、フローモジュールはより強力で再利用性が高まり、フローの構築と保守をより効率的に行えるようになります。
これまでとどう変わるのか #
- これまで: フローモジュールでカスタム入力、出力、ブランチ、バージョン管理、エイリアス管理ができなかった、または限定的でした。
- これから: フローモジュールでカスタム入力、出力、ブランチ、バージョン管理、エイリアス管理が完全にサポートされ、より柔軟で効率的なフロー開発が可能になります。
具体的なユースケース #
- 電話番号とPINを入力として受け取り、顧客名と認証ステータスを「認証済み」または「未認証」などのブランチとともに返す認証モジュールを作成できます。
Amazon EC2 が中断可能なキャパシティ予約を発表 #
投稿日: 2025年11月24日
何ができるようになったのか #
Amazon EC2 は、予約済みキャパシティをより有効活用し、コストを節約できる中断可能なキャパシティ予約を発表しました。オンデマンドキャパシティ予約 (ODCR) は、特定の AWS アベイラビリティゾーンで任意の期間、コンピューティングキャパシティを予約するのに役立ちます。ODCR が使用されていない場合、一時的に中断可能な ODCR として利用可能にできるようになり、組織内の他のワークロードがそれを利用できるようになります。これにより、重要なオペレーションのためにキャパシティを再要求する能力は維持されます。
何が嬉しいのか #
未使用のキャパシティを中断可能な ODCR として再利用することで、バッチ処理、データ分析、機械学習トレーニングなど、柔軟でフォールトトレラントなオペレーションに適したワークロードは、一時的に利用可能なキャパシティから恩恵を受けることができます。予約の所有者はいつでもキャパシティを再要求でき、中断可能な ODCR の利用者は、終了前に中断通知を受け取るため、正常なシャットダウンやチェックポイントの保存を行うことができます。中断可能な ODCR は、すべてのキャパシティ予約のお客様に追加費用なしで利用可能です。
これまでとどう変わるのか #
- これまで: オンデマンドキャパシティ予約 (ODCR) は予約されていましたが、重要なオペレーションで使用されていない間はアイドル状態になる可能性がありました。
- これから: 未使用の ODCR を一時的に中断可能な ODCR として他のワークロードに提供できるようになりました。予約所有者はいつでもキャパシティを再要求でき、利用者は終了前に中断通知を受け取ります。
具体的なユースケース #
- バッチ処理
- データ分析
- 機械学習トレーニング
Amazon MSK Replicatorが5つの追加AWSリージョンで利用可能に #
投稿日: 2025年11月24日
何ができるようになったのか #
Amazon MSK Replicator を使用して、アジアパシフィック (タイ)、メキシコ (セントラル)、アジアパシフィック (台北)、カナダ西部 (カルガリー)、欧州 (スペイン) の5つの追加AWSリージョンで Amazon Managed Streaming for Apache Kafka (Amazon MSK) クラスター間でストリーミングデータをレプリケートできるようになりました。
何が嬉しいのか #
MSK Replicator を利用することで、数クリックで異なるまたは同じAWSリージョン内の Amazon MSK クラスター間でデータを確実にレプリケートできます。これにより、可用性とビジネス継続性を高めるために、リージョン間で回復力のあるストリーミングアプリケーションを簡単に構築できます。MSK Replicator は、カスタムコードの記述、インフラストラクチャの管理、クロスリージョンネットワークのセットアップの必要性を排除し、MSK クラスター間で自動的に非同期レプリケーションを提供します。また、基盤となるリソースを自動的にスケーリングするため、キャパシティの監視やスケーリングなしでオンデマンドでデータをレプリケートできます。トピック設定、ACL、コンシューマーグループオフセットなどの必要な Kafka メタデータもレプリケートされます。
これまでとどう変わるのか #
- これまで: MSKクラスター間のデータレプリケーションには、カスタムコードの記述、インフラストラクチャの管理、クロスリージョンネットワークのセットアップが必要な場合がありました。また、レプリケーションのキャパシティを監視・スケーリングする必要がありました。
- これから: MSK Replicator が自動的に非同期レプリケーションを行い、カスタムコードやインフラ管理が不要になります。キャパシティの監視やスケーリングも不要で、オンデマンドでデータをレプリケートできます。予期せぬイベントが発生した場合でも、他のAWSリージョンにフェイルオーバーしてシームレスに処理を再開できます。
具体的なユースケース #
- リージョン間で回復力のあるストリーミングアプリケーションを構築し、可用性とビジネス継続性を向上させる。
- 災害復旧戦略の一環として、異なるリージョンにデータのコピーを保持する。
- 地理的に分散したユーザーベースに低レイテンシーでデータを提供する。
Amazon OpenSearch Service が OpenSearch バージョン 3.3 をサポート開始 #
投稿日: 2025年11月24日
何ができるようになったのか #
Amazon OpenSearch Service で OpenSearch バージョン 3.3 を実行できるようになりました。OpenSearch 3.3 では、検索パフォーマンス、可観測性、エージェント AI 統合をよりシンプルかつ強力にする新機能など、いくつかの改善が導入されています。
このリリースには、ベクトル検索機能のいくつかの改善が含まれます。まず、エージェント検索により、複雑なドメイン固有言語 (DSL) クエリを構築することなく、自然言語入力を使用して正確な検索結果を達成できるようになりました。次に、セマンティックハイライターのバッチ処理により、オーバーヘッドのレイテンシーを削減し、GPU 使用率を向上させることでパフォーマンスが向上します。最後に、Neural Search プラグインの機能強化により、セマンティック検索がより効率的になり、特定のデータ、パフォーマンス、関連性のニーズに合わせた最適化オプションが提供されます。
また、このリリースでは、PPL のデフォルトクエリエンジンとして Apache Calcite のサポートが導入され、最適化機能、クエリ処理効率の向上、および新しい PPL コマンドと関数の広範なライブラリが提供されます。さらに、このリリースには、ページネーションされた検索結果、リアルタイムダッシュボード、および大規模な時系列データセットや数値データセットを介した深いページネーションを必要とするアプリケーションの応答性を向上させる近似フレームワークの機能強化が含まれています。最後に、ワークロード管理プラグインにより、検索トラフィックをグループ化し、ネットワークリソースを分離できるようになりました。これにより、特定の要求がネットワークリソースを過度に使用するのを防ぎ、テナントレベルの分離を提供します。
何が嬉しいのか #
自然言語でより正確な検索結果を得られるようになり、複雑なクエリ構築の手間が省けます。セマンティック検索のパフォーマンスが向上し、GPU の利用効率も高まります。Apache Calcite の導入により、PPL クエリの最適化と処理効率が向上し、より多くのコマンドと関数を利用できます。ページネーションされた検索結果やリアルタイムダッシュボードの応答性が改善され、大規模データセットの深いページネーションもスムーズに行えます。ワークロード管理機能により、リソースの競合を防ぎ、安定したサービス運用が可能になります。
これまでとどう変わるのか #
- これまで: OpenSearch 3.3 の新機能や改善されたベクトル検索機能、Apache Calcite を利用した PPL クエリの最適化、強化されたページネーション応答性、ワークロード管理によるリソース分離機能が利用できませんでした。自然言語での検索には複雑な DSL クエリが必要な場合があり、大規模データセットの深いページネーションやリアルタイムダッシュボードの応答性に課題がありました。
- これから: Amazon OpenSearch Service で OpenSearch 3.3 の最新機能が利用可能になり、検索パフォーマンス、可観測性、エージェント AI 統合が強化されます。自然言語によるエージェント検索でより正確な結果が得られ、セマンティック検索の効率と最適化オプションが向上します。Apache Calcite が PPL のデフォルトクエリエンジンとなり、クエリ処理が効率化されます。近似フレームワークの強化により、ページネーションされた検索結果やリアルタイムダッシュボードの応答性が向上し、ワークロード管理プラグインでネットワークリソースの分離とテナントレベルの分離が可能になります。
具体的なユースケース #
- 顧客が自然言語で製品を検索する eコマースサイトで、より関連性の高い結果を迅速に提供する。
- 大量のログデータやメトリクスを扱う監視システムで、リアルタイムダッシュボードの応答性を向上させ、深い時間範囲でのデータ分析をスムーズに行う。
- 複数のテナントが利用する SaaS アプリケーションで、各テナントの検索トラフィックが他のテナントのパフォーマンスに影響を与えないようにネットワークリソースを分離する。
Amazon Redshiftがマルチウェアハウスアーキテクチャ全体でフェデレーテッドパーミッションをサポート #
投稿日: 2025年11月24日
何ができるようになったのか #
Amazon Redshiftがフェデレーテッドパーミッションをサポートするようになりました。これにより、複数のRedshiftデータウェアハウスにわたるパーミッション管理が簡素化されます。
何が嬉しいのか #
マルチウェアハウスアーキテクチャを採用しているお客様は、ワークロードのスケーリングと分離を行いつつ、ウェアハウス全体でシンプルで一貫したパーミッション管理を求めていました。Redshiftのフェデレーテッドパーミッションにより、任意のRedshiftウェアハウスからデータパーミッションを一度定義するだけで、アカウント内のすべてのウェアハウスに自動的に適用されます。既存のワークフォースID（AWS IAM Identity Centerを使用）または既存のIAMロールを使用して、ウェアハウス間でデータをクエリできます。どのウェアハウスがクエリに使用されても、行レベル、列レベル、およびマスキングコントロールが常に自動的に適用され、きめ細かなアクセスコンプライアンスが実現されます。
これまでとどう変わるのか #
- これまで: マルチウェアハウスアーキテクチャにおけるパーミッション管理は複雑で、一貫性の確保が課題でした。
- これから: パーミッションを一度定義するだけで、すべてのウェアハウスに自動的に適用され、管理が簡素化され、ガバナンスの複雑さを増すことなく水平スケーラビリティが実現されます。
具体的なユースケース #
- Redshift Serverless名前空間またはRedshiftプロビジョニング済みクラスターをAWS Glue Data Catalogに登録し、Redshift Query Editor V2またはサポートされている任意のSQLクライアントを使用してウェアハウス間でクエリを開始できます。
Amazon U7i インスタンスがアジアパシフィック (ジャカルタ) リージョンで利用可能に #
投稿日: 2025年11月24日
何ができるようになったのか #
本日より、6TBメモリを搭載した Amazon EC2 High Memory U7i インスタンス (u7i-6tb.112xlarge) がアジアパシフィック (ジャカルタ) リージョンで利用可能になりました。
何が嬉しいのか #
U7i-6tb インスタンスは、カスタムの第4世代 Intel Xeon Scalable プロセッサ (Sapphire Rapids) を搭載し、6TBのDDR5メモリを提供することで、急速に成長するデータ環境においてトランザクション処理スループットを拡張できます。また、448 vCPU、最大100Gbpsの Elastic Block Storage (EBS) による高速なデータロードとバックアップ、最大100Gbpsのネットワーク帯域幅、および ENA Express をサポートします。
これまでとどう変わるのか #
- これまで: アジアパシフィック (ジャカルタ) リージョンでは、U7i インスタンスが利用できませんでした。
- これから: アジアパシフィック (ジャカルタ) リージョンで、6TBメモリを搭載した Amazon EC2 High Memory U7i インスタンスが利用可能になり、より大規模なインメモリデータベースワークロードに対応できるようになりました。
具体的なユースケース #
- SAP HANA、Oracle、SQL Server などのミッションクリティカルなインメモリデータベースを使用する顧客に最適です。
AWS Elemental MediaTailorがライブストリーム向けHLS Interstitialsをサポート #
投稿日: 2025年11月24日
何ができるようになったのか #
AWS Elemental MediaTailorがライブストリーム向けHTTP Live Streaming (HLS) Interstitialsをサポートしました。これにより、ブロードキャスターやストリーミングサービスプロバイダーは、HLS.js、Shaka Player、Bitmovin Player、およびiOS 16.4以降を搭載したAppleデバイスなどの幅広い最新のビデオプレーヤーで、シームレスでパーソナライズされた広告体験を提供できるようになります。
何が嬉しいのか #
HLS Interstitialsのサポートにより、開発の複雑さが軽減され、一貫した再生動作が保証されます。MediaTailorの既存のサーバーサイド広告挿入 (SSAI) 機能と統合することで、コンテンツとインタースティシャル間のバッファリングなしで、フレーム精度の高いトランジションを実現します。サーバーサイドビーコンもHLS Interstitialsで引き続き機能するため、広告トラッキングと測定ワークフローが維持されます。この機能は、正確な広告タイミングと最小限のレイテンシーが重要なスポーツ放送、ライブニュース、イベントストリーミングに特に価値があります。プリロールおよびミッドロール挿入をサポートし、ライブコンテンツの収益化に柔軟性をもたらします。また、基礎となるMediaTailorの設定を変更することなく、再生セッションごとにHLS Interstitialsを有効または無効にできます。
これまでとどう変わるのか #
- これまで: クライアントプレーヤー側でカスタムのスティッチングロジックが必要でした。
- これから: MediaTailorがHLS Interstitials仕様 (RFC 8216) を使用して、必要なメタデータタグ（InterstitialクラスのEXT-X-DATERANGEとX-ASSET-LIST属性）を自動的に生成し、クライアントプレーヤーにインタースティシャルコンテンツの再生タイミングと方法を通知します。
具体的なユースケース #
- スポーツ放送、ライブニュース、イベントストリーミングで、正確な広告タイミングと最小限のレイテンシーが求められる場合に、シームレスな広告挿入を行う。
- プリロールおよびミッドロール広告を挿入してライブコンテンツを収益化し、視聴者体験を向上させる。
AWS Glue がリモート Apache Iceberg カタログのカタログフェデレーションを発表 #
投稿日: 2025年11月24日
何ができるようになったのか #
AWS Glue は、リモート Iceberg カタログのカタログフェデレーションの一般提供を発表しました。この機能により、Amazon S3 に保存され、リモートカタログにカタログ化された Iceberg テーブルに、AWS 分析エンジンを使用して直接かつ安全にアクセスできるようになります。カタログフェデレーションを使用すると、テーブルを移動またはコピーすることなく、お好みの AWS 分析エンジンを使用してリモート Iceberg カタログにフェデレーションし、リモート Iceberg テーブルをクエリできます。データチームがリモートテーブルをクエリする際に、AWS Glue Data Catalog とリモートカタログ間でメタデータをリアルタイムで同期するため、クエリ結果は常に完全に最新の状態に保たれます。
何が嬉しいのか #
リモート Iceberg テーブルを分析する際に、お好みの AWS 分析エンジンを使用しながら、データ検出時やクエリ時に一貫したセキュリティ制御を維持しつつ、ワークロードに最適な価格性能を選択できるようになります。テーブルの移動やコピーが不要で、クエリ結果は常に最新です。また、AWS Lake Formation を使用して、きめ細やかなアクセス制御、クロスアカウント共有、信頼できる ID 伝播を適用し、リモートカタログテーブルを他のデータコンシューマと共有できます。
これまでとどう変わるのか #
- これまで: リモートの Iceberg テーブルに直接アクセスし、リアルタイムでメタデータを同期しながら、複数の AWS 分析エンジンから一貫したセキュリティ制御でクエリを実行することは困難でした。テーブルの移動やコピーが必要になる場合がありました。
- これから: AWS Glue のカタログフェデレーションにより、テーブルを移動またはコピーすることなく、AWS 分析エンジンからリモート Iceberg テーブルに直接かつ安全にアクセスできます。メタデータはリアルタイムで同期され、AWS Lake Formation を介したきめ細やかなアクセス制御が可能です。
具体的なユースケース #
- Amazon Redshift、Amazon EMR、Amazon Athena、AWS Glue、Apache Spark などのサードパーティエンジン、およびサーバーレスノートブックを備えた Amazon SageMaker など、さまざまな AWS 分析エンジンを使用してリモート Iceberg テーブルをクエリする。
- Lake Formation コンソール、AWS Glue および Lake Formation SDK、API を使用して、リモートカタログにフェデレーションし、データベースとテーブルを検出し、テーブルデータへのアクセス許可を付与し、リモート Iceberg テーブルをクエリする。
- きめ細やかなアクセス制御、クロスアカウント共有、信頼できる ID 伝播を活用して、リモートカタログテーブルを他のデータコンシューマと安全に共有する。
AWS Lambda が Kafka イベント処理の強化されたエラー処理機能を発表 #
投稿日: 2025年11月24日
何ができるようになったのか #
AWS Lambda は、Amazon Managed Streaming for Apache Kafka (Amazon MSK) およびセルフマネージド Apache Kafka (SMK) イベントソース向けの強化されたエラー処理機能を発表しました。これにより、カスタムリトライ設定の構築、失敗したメッセージのリトライの最適化、および失敗したイベントをオンデッドレターキュー (DLQ) として Kafka トピックに送信することが可能になります。Provisioned モードで Kafka イベントソースマッピング (ESM) を使用する際に、開発者は失敗したイベント処理をより詳細に制御し、Kafka トピックを追加のオンフェイルデスティネーションとして活用できるようになりました。
何が嬉しいのか #
これらの機能により、顧客はカスタムリトライ設定を構築し、失敗したメッセージのリトライを最適化し、失敗したイベントを Kafka トピックにオンフェイルデスティネーションとして送信することで、堅牢なエラー処理戦略を持つ回復力のある Kafka ワークロードを構築できます。開発者は失敗したイベント処理を正確に制御できるようになり、リトライプロセスを最適化できます。
これまでとどう変わるのか #
- これまで: Kafka ESM は、指数バックオフによるイベントのリトライや、Amazon SQS、Amazon S3、Amazon SNS などのオンフェイルデスティネーションに失敗したイベントを保持することで、失敗したイベントの堅牢なエラー処理を提供していました。
- これから: 開発者は失敗したイベント処理を正確に制御できるようになり、Provisioned モードで Kafka ESM を使用する際に、Kafka トピックを追加のオンフェイルデスティネーションとして活用できます。顧客は特定のリトライ制限と時間境界を定義し、これらの制限を超えた失敗したレコードを顧客指定のデスティネーションに自動的に破棄できます。また、バッチ内の失敗したレコードの自動リトライを設定し、個々の失敗したメッセージを報告するように関数コードを強化することで、リトライプロセスを最適化できます。
具体的なユースケース #
- カスタムリトライ設定を構築する。
- 失敗したメッセージのリトライを最適化する。
- 失敗したイベントをオンフェイルデスティネーションとして Kafka トピックに送信する。
- 特定のリトライ制限と時間境界を定義し、制限を超えた失敗したレコードを自動的に破棄する。
- バッチ内の失敗したレコードの自動リトライを設定する。
- 個々の失敗したメッセージを報告するように関数コードを強化する。
Claude Opus 4.5 が Amazon Bedrock で利用可能に #
投稿日: 2025年11月24日
何ができるようになったのか #
お客様は、主要なAI企業が提供する高性能な基盤モデルを選択できるフルマネージドサービスである Amazon Bedrock で、Claude Opus 4.5 を利用できるようになりました。Opus 4.5 は Anthropic の最新モデルであり、コーディング、エージェントワークフロー、コンピューター利用、オフィス業務において新たな基準を打ち立てるとともに、Opus レベルのインテリジェンスを従来の3分の1のコストで提供します。
Opus 4.5 はプロフェッショナルなソフトウェアエンジニアリングタスクに優れており、SWE-bench で最先端のパフォーマンスを達成しています。このモデルは曖昧な状況に対応し、トレードオフを推論し、複数のシステムにまたがる推論を必要とするバグの修正方法を見つけ出すことができます。多言語コーディング機能の向上により、数日かかるチーム開発プロジェクトを数時間で完了できるよう支援します。この Claude の世代は、Opus 4.5（本番コードおよびリードエージェント向け）、Sonnet 4.5（迅速なイテレーションおよびスケーラブルなユーザーエクスペリエンス向け）、Haiku 4.5（サブエージェントおよびフリーティア製品向け）と、開発ライフサイクル全体をカバーします。
コーディング以外にも、このモデルは、一貫性、プロフェッショナルな完成度、ドメイン認識を持ってドキュメント、スプレッドシート、プレゼンテーションを作成するエージェントを強化し、金融などの精度が重要視される業界に最適です。Anthropic 最高のビジョンモデルとして、複雑な視覚的解釈と多段階ナビゲーションに依存するワークフローを可能にします。Amazon Bedrock API を通じて、Opus 4.5 はツール検索とツール使用例という2つの新機能を導入します。これらの更新により、Claude は大規模なツールライブラリをナビゲートし、複雑なタスクを正確に実行できるようになります。ベータ版で利用可能な新しい「effort」パラメータを使用すると、Claude が思考、ツール呼び出し、応答に割り当てる労力を制御し、パフォーマンス、レイテンシー、コストのバランスを取ることが可能です。
Claude Opus 4.5 は、Amazon Bedrock のグローバルクロスリージョン推論を通じて、複数のロケーションで利用可能になりました。利用可能なリージョンの完全なリストについては、ドキュメントを参照してください。
何が嬉しいのか #
Opus レベルの高度な AI を従来の3分の1のコストで利用できるため、コスト効率が大幅に向上します。プロフェッショナルなソフトウェア開発タスクの効率が大幅に向上し、数日かかるプロジェクトを数時間で完了できる可能性があるため、開発期間の短縮と生産性の向上が期待できます。曖昧な指示や複雑な問題に対しても、モデルが自律的に推論し、解決策を見つけ出す能力があるため、開発者の負担を軽減し、より戦略的な業務に集中できます。金融など高い精度が求められる業界でのドキュメント作成、データ分析、プレゼンテーション作成の品質と効率が向上し、ビジネスプロセスの自動化を推進します。複雑な視覚情報や多段階の操作を伴うワークフローを自動化し、新たなビジネス機会を創出します。大規模なツールライブラリを効果的に活用し、複雑なタスクを正確に実行できるため、エージェントの能力が飛躍的に向上し、より高度な自動化が可能になります。「effort」パラメータにより、パフォーマンス、レイテンシー、コストのバランスを柔軟に調整し、特定のニーズに合わせた最適な運用が可能になります。
これまでとどう変わるのか #
- これまで: 高度なコーディングや複雑なエージェントワークフロー、多システムにまたがるバグ修正には、より多くの時間とコスト、人間の介入が必要でした。また、大規模なツールライブラリの活用や複雑な視覚的解釈を伴うタスクの自動化には限界がありました。AIモデルのコストとパフォーマンスのバランス調整も困難でした。
- これから: Claude Opus 4.5 の導入により、これらのタスクが大幅に効率化され、コストも削減されます。ツール検索やツール使用例といった新機能により、Claude がより自律的に複雑なタスクを実行できるようになります。さらに、「effort」パラメータで、パフォーマンス、レイテンシー、コストを細かく制御し、最適化できるようになりました。
具体的なユースケース #
- プロフェッショナルなソフトウェア開発において、コード生成、バグ修正、リファクタリングなどを効率化し、開発サイクルを加速します。
- 多言語対応のコーディングプロジェクトで、言語の壁を越えた開発を支援し、開発期間を大幅に短縮します。
- 金融業界など、高い精度と専門知識が求められる分野での契約書、レポート、財務分析などのドキュメント、スプレッドシート、プレゼンテーションの自動生成と品質向上に活用します。
- 複雑な視覚情報（グラフ、図、画像など）を解釈し、それに基づいて多段階の操作を必要とするワークフロー（例: 医療画像の分析と診断支援、製造ラインの品質検査）の自動化を実現します。
- 大規模な API やツールセットを活用し、顧客サポート、データ分析、ビジネスインテリジェンスなど、複雑なビジネスプロセスを自動実行するインテリジェントエージェントを構築します。
OpenSearch Serviceが新しいPPLエクスペリエンスでログ分析を強化 #
投稿日: 2025年11月24日
何ができるようになったのか #
Amazon OpenSearch Serviceにおいて、ログ分析機能が強化されました。OpenSearch UIのObservabilityワークスペースで、Piped Processing Language (PPL) と自然言語がデフォルトのエクスペリエンスとして利用可能になりました。このアップデートにより、実績のあるパイプライン構文と簡素化されたワークフローが組み合わされ、直感的な可観測性エクスペリエンスが提供されます。新しいエクスペリエンスには、インフラストラクチャ、セキュリティ、ビジネスメトリクス全体でより深い洞察を得るための35以上の新しいコマンド、ファセット探索、自然言語クエリが含まれています。
何が嬉しいのか #
この強化により、顧客は使い慣れたパイプライン構文を使用しながら、高度な分析機能を活用してログ分析ワークフローを効率化できます。エンタープライズグレードのクエリ機能と自然言語を使用した高度なイベント相関により、チームは意味のあるパターンをより迅速に発見できるようになります。ユーザーは単一のインターフェース内でクエリから視覚化へシームレスに移行でき、問題の検出と解決にかかる平均時間を短縮します。また、AWSコンソールでOpenSearchの「Get Started」ワークフローを使用することで、エンドツーエンドのOpenTelemetryソリューションを迅速にセットアップできます。統合されたワークフローには、OpenTelemetryデータ用のすぐに使えるOpenSearch Ingestionパイプラインが含まれており、チームが迅速に開始するのを容易にします。
これまでとどう変わるのか #
- これまで: OpenSearch UIのObservabilityワークスペースでPPLと自然言語クエリがデフォルトのエクスペリエンスではなく、ログ分析ワークフローがより複雑であった可能性があります。
- これから: PPLと自然言語がデフォルトのエクスペリエンスとなり、35以上の新しいコマンドや自然言語クエリを含む直感的なログ分析が可能になります。これにより、高度な分析と迅速な問題解決が実現します。
具体的なユースケース #
- インフラストラクチャ、セキュリティ、ビジネスメトリクス全体でより深い洞察を得る。
- 意味のあるパターンをより迅速に発見する。
- 単一のインターフェース内でクエリから視覚化へシームレスに移行し、問題の検出と解決にかかる平均時間を短縮する。
- AWSコンソールでOpenSearchの「Get Started」ワークフローを使用して、エンドツーエンドのOpenTelemetryソリューションを迅速にセットアップする。
Amazon SageMaker HyperPodが生成AIタスク向けNVIDIA Multi-Instance GPU (MIG)をサポート #
投稿日: 2025年11月24日
何ができるようになったのか #
Amazon SageMaker HyperPodがNVIDIA Multi-Instance GPU (MIG)テクノロジーをサポートするようになりました。これにより、管理者は単一のGPUを複数の独立したGPUパーティションに分割できるようになります。
何が嬉しいのか #
この機能により、管理者はパフォーマンスとタスクの分離を維持しながら、多様な小規模な生成AI (GenAI)タスクをGPUパーティション上で同時に実行することで、リソース利用率を最大化できます。データサイエンティストは、軽量な推論タスクやインタラクティブなノートブックをGPUパーティションで並行して実行できるようになり、フルGPUの可用性を待つ時間をなくし、市場投入までの時間を短縮できます。
これまでとどう変わるのか #
- これまで: 単一のGPUを分割して利用できなかったため、小さなGenAIタスクではリソースの利用効率が低く、フルGPUが必要ないタスクでもGPUの空きを待つ必要がありました。
- これから: NVIDIA MIGにより、単一GPUを複数の独立したGPUパーティションに分割できます。これにより、リソース利用率が最大化され、パフォーマンスとタスク分離を維持しつつ、多様な小さなGenAIタスクを同時に実行できます。データサイエンティストは、軽量な推論タスクやインタラクティブなノートブックをGPUパーティションで並行して実行でき、フルGPUの可用性を待つ時間をなくし、市場投入までの時間を短縮できます。
具体的なユースケース #
- 管理者は、SageMaker HyperPodコンソールまたはカスタム設定アプローチのいずれかを選択して、フルGPU容量を必要としない特定のタスク要件に対して、きめ細かくハードウェア分離されたリソースを有効にできます。
- 管理者は、コンピューティングクォータを割り当てて、チーム間でGPUパーティションの公平かつ効率的な配分を確保できます。
- 管理者は、GPUパーティション全体のリアルタイムパフォーマンスメトリクスとリソース利用状況監視ダッシュボードを通じて、リソース割り当てを最適化できます。
- データサイエンティストは、軽量な推論タスクやインタラクティブなノートブックをGPUパーティションで並行して実行することで、待機時間を削減し、市場投入までの時間を加速できます。
NVIDIA Multi-Instance GPU (MIG)は、単一のGPUを複数の独立したGPUパーティションに分割できるテクノロジーです。 主な特徴は以下の通りです。
- 単一GPUの複数パーティション化
- タスクの分離とパフォーマンス維持
- リソース利用率の最大化
Amazon CloudFrontがVPC IPAMと統合し、BYOIPをサポート #
投稿日: 2025年11月24日
何ができるようになったのか #
Amazon CloudFrontが、VPC IPアドレスマネージャー (IPAM) を介したAnycast Static IP向けに、独自のIPアドレス (BYOIP) の持ち込みをサポートするようになりました。この機能により、ネットワーク管理者は自身のパブリックIPv4アドレスプールをCloudFrontディストリビューションで使用できるようになり、AWSのグローバルインフラストラクチャ全体でのIPアドレス管理が簡素化されます。
何が嬉しいのか #
CloudFront Anycast Static IPにより、お客様はパートナーや顧客に専用のIPアドレスリストを提供できるようになり、セキュリティが強化され、ネットワーク管理が簡素化されます。また、CloudFrontに移行する際にアプリケーションの既存のIPアドレス空間を変更する必要がなくなり、既存の許可リストやブランディングを維持できます。
これまでとどう変わるのか #
- これまで: Anycast Static IPを実装するお客様は、ワークロードに対してAWSが提供する静的IPアドレスを受け取っていました。
- これから: IPAMの統合インターフェースを使用することで、お客様はBYOIPを使用して専用のIPアドレスプールを作成し、CloudFront Anycast Static IPリストに割り当てることができるようになりました。
具体的なユースケース #
- CloudFrontへの移行時に、既存のIPアドレス空間を変更することなく、許可リストやブランディングを維持したい場合。