はじめに #
AWSの基礎力をつけるためにAWS What’s Newを毎日目を通す事を始めました。 最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。
本情報が役立つ人もいるかなと思い公開します。 個人的な理解なので、実際の情報は原典をあたってください。
Amazon RDS for SQL Server が Oracle OLEDB ドライバーバージョン 21.16 のリンクサーバーをサポート #
投稿日: 2025年7月17日
何ができるようになったのか #
Amazon RDS for SQL Serverで、Oracle OLEDB ドライバーバージョン 21.16 を使用したリンクサーバーがサポートされるようになりました。
何が嬉しいのか #
- パフォーマンスが向上し、Oracle データベースへの信頼性の高いアクセスが可能になります。
具体的なユースケース #
- SQL Server 2017、2019、2022 から、Oracle データベースバージョン 18c、19c、21c を使用してリモートの Oracle データベースサーバーに対するデータの読み取りやコマンドの実行ができます。
AWS Clean Rooms ML が Parquet ファイル形式のサポートを開始 #
投稿日: 2025年7月17日
何ができるようになったのか #
AWS Clean Rooms MLで、Parquetファイル形式のデータを使用したカスタム機械学習モデルのトレーニングがサポートされるようになりました。
何が嬉しいのか #
- 大量のデータをより効率的に処理できます。
- テキストベース以外のデータ（画像やその他のバイナリでエンコードされたデータ型）でトレーニングできるようになります。
具体的なユースケース #
- 機密性の高い知的財産を共有することなく、大規模な集合データセットを使用してカスタム機械学習モデルをトレーニングする際に、Parquet形式のデータを利用できます。
Amazon ECS で組み込みのブルー/グリーンデプロイが利用可能に #
投稿日: 2025年7月17日
何ができるようになったのか #
Amazon ECSで、組み込みのブルー/グリーンデプロイ戦略とデプロイライフサイクルフックがサポートされるようになりました。
何が嬉しいのか #
- カスタムのデプロイツールを構築しなくても、高い信頼性でより迅速にソフトウェアをリリースできます。
- 本番環境で新しいアプリケーションバージョンをテストし、失敗したデプロイを迅速にロールバックできます。
具体的なユースケース #
- Application Load Balancer (ALB)、Network Load Balancer (NLB)、または ECS Service Connect からのトラフィックを処理する Amazon ECS サービスに対して、ブルー/グリーンデプロイ戦略を利用してソフトウェア更新をデプロイできます。
- デプロイライフサイクルフックを使用して、カスタムの検証ステップを実行できます。
- 新しいブルー/グリーンデプロイと既存のCloudWatchアラームやECSデプロイサーキットブレーカーを組み合わせることで、デプロイをモニタリングし、障害を自動的に検出できます。
Amazon SNS がクロスリージョン配信機能を強化 #
投稿日: 2025年7月17日
何ができるようになったのか #
Amazon SNSのクロスリージョン配信機能が拡張され、オプトインリージョンへの配信が強化されました。
:::message オプトインリージョンとは？ デフォルトでは有効になっておらず、使用するためにアカウントで明示的に有効化する必要があるAWSリージョンのことです。 :::
何が嬉しいのか #
- AWSリージョン全体にわたる分散システムをより柔軟に設計できるようになり、アーキテクチャにおいてオプトインリージョンを活用しやすくなります。
具体的なユースケース #
- オプトインリージョン間の配信:
- 特定のオプトインリージョンにあるSNSトピックから、別のオプトインリージョンにあるSQSキューへのメッセージ配信。
- 特定のオプトインリージョンにあるSNSトピックから、別のオプトインリージョンにあるLambda関数へのメッセージ配信。
- デフォルトリージョンからオプトインリージョンへの配信:
- デフォルトで有効なリージョンにあるSNSトピックから、特定のオプトインリージョンにあるLambda関数へのメッセージ配信。
AWS Lambda、VS Code IDE からクラウドで実行されている関数のデバッグが可能に #
投稿日: 2025年7月17日
何ができるようになったのか #
Visual Studio Code (VS Code) でのリモートデバッグがサポートされ、クラウドで実行されている Lambda 関数をローカル IDE から直接デバッグできるようになりました。
何が嬉しいのか #
- 既存の開発ワークフローを変更することなく、クラウドにデプロイされた関数でブレークポイント、変数検査、ステップスルーデバッグなどの使い慣れたデバッグツールを使用できます。
- 複雑なローカルデバッグのセットアップや繰り返しのデプロイが不要になり、問題の特定と修正にかかる時間が数時間から数分に短縮されます。
具体的なユースケース #
- VPCに接続されていたり、特定のIAM権限が必要なAWSサービスとの連携をテスト・デバッグする際に、VPCリソースとIAMロールに完全にアクセスした状態で、クラウドで実行されている関数の実行環境をデバッグできます。
AWS Lambda が Kafka イベントの低レイテンシー処理を発表 #
投稿日: 2025年7月17日
何ができるようになったのか #
AWS LambdaのプロビジョンドモードのKafka ESMで、MaximumBatchingWindowInSeconds パラメータを0に設定することで、100ミリ秒未満の低レイテンシーでのイベント処理が可能になりました。
何が嬉しいのか #
- Kafkaイベントのリアルタイム処理が可能になり、迅速な処理が求められるビジネスアプリケーションのエンドツーエンドの処理レイテンシーが大幅に低減されます。
- これにより、ミッションクリティカルでレイテンシーの影響を受けやすいKafkaアプリケーションをLambdaで構築できるようになります。
具体的なユースケース #
- 金融サービスにおける市場データフィードの処理やアルゴリズム取引
- eコマースプラットフォームにおけるリアルタイムのパーソナライズされたレコメンデーション
- ゲームにおけるライブプレーヤー間のインタラクション管理
:::message
コストに関する注意
MaximumBatchingWindowInSeconds を 0 に設定すると、Lambda関数の呼び出し回数が増加し、コストが増加する可能性があります。この設定は、低レイテンシーが最優先される特定のユースケース向けです。
:::
AWS Lambda がコンソールと VS Code を連携し、サーバーレス開発エクスペリエンスを統合 #
投稿日: 2025年7月17日
何ができるようになったのか #
AWS LambdaコンソールからVisual Studio Code (VS Code) IDEへのシームレスな移行が可能になりました。この統合により、サーバーレスアプリケーションのクラウド開発環境とローカル開発環境の間の課題が解消されます。
何が嬉しいのか #
- 開発者は、アプリケーションの複雑性が増しても、ローカルIDEの高度な開発機能を簡単に利用できます。
- 従来必要だった手動でのローカル開発環境設定（IDEのインストール、コードのコピー、設定など）が不要になります。
- ワンクリックでLambda関数をVS Codeに移行でき、コードと設定が維持されます。
- セットアップのオーバーヘッドなしで、npmやpipなどのパッケージマネージャー、リンター、フォーマッターなどの開発ツールを活用できます。
- VS Code IDEの新機能により、アプリケーションをAWS SAMテンプレートに簡単に変換でき、Infrastructure as Code (IaC)の実践とCI/CDパイプラインの統合が簡素化されます。
具体的なユースケース #
- コンソールで開発を開始し、アプリケーションが複雑になったらVS Codeに移行して開発を継続する。
- 外部依存関係の管理や、リンター、フォーマッターなどの高度なIDE機能を使用する。
- 開発した関数をAWS SAMテンプレートに変換し、CI/CDパイプラインに統合する。
Amazon DynamoDB Streams が、ストリームシャードの検出をより迅速かつ効率的に行う新しい API 機能を導入 #
投稿日: 2025年7月17日
何ができるようになったのか #
Amazon DynamoDB Streams の DescribeStream API で新しい ShardFilter パラメータがサポートされるようになりました。
何が嬉しいのか #
- 親シャードが閉じられた後に子シャードをすばやく検出できるため、DynamoDB Streams からのデータ処理がより効率的かつ応答性が向上します。
DescribeStreamAPI を繰り返し呼び出してシャードマップ全体を取得・走査する必要がなくなり、シャード間の切り替えがスムーズになり、レイテンシーが低減し、コスト効率も向上します。
これまでとどう変わるのか #
-
従来の DescribeStream の問題点
- 全シャード情報を列挙し、手動で親→子シャードのリレーションをたどる必要がある
- シャードが多いと DescribeStream 呼び出しの回数が膨大になり、レイテンシやコストが増加
-
ShardFilter の導入による改善
- ShardFilter = { “Type”: “CHILD” } のように指定すると、閉鎖されたシャードの子シャードのみを絞って取得できます
- 全シャードを探索する必要がなくなり、効率的／高速な次シャードの検知が可能に
具体的なユースケース #
- イベント駆動型アプリケーションの構築
- データレプリケーション
- 監査
- データ分析や機械学習機能の実装
Amazon Connect エージェントワークスペースにリアルタイムのエージェントパフォーマンスメトリクスを追加 #
投稿日: 2025年7月17日
何ができるようになったのか #
Amazon Connectのエージェントワークスペースに、すぐに利用可能な分析ダッシュボードが追加されました。
何が嬉しいのか #
- エージェントは、対応した問い合わせ数や平均対応時間など、個人のパフォーマンスに関するインサイトを得ることができます。
- ダッシュボードには、キュー内の連絡先や最長待ち時間など、エージェントに割り当てられたキューメトリクスも表示されます。
- これらのインサイトにより、エージェントは自身のパフォーマンスを向上させ、カスタマーエクスペリエンスを向上させる意思決定を行うことができます。
これまでとどう変わるのか #
従来、エージェントは自身のパフォーマンス指標をリアルタイムで確認する簡単な方法がなく、スーパーバイザーからのフィードバックや別のダッシュボードに頼る必要がありました。今回のアップデートにより、エージェントは自身のワークスペース内で直接、個人のパフォーマンスとキューの状態をリアルタイムで把握できるようになり、より自律的に業務の改善や顧客対応の優先順位付けを行えるようになります。
具体的なユースケース #
- キューの量が多い場合に休憩を遅らせることで、お客様の待ち時間を短縮するなど、エージェントが自身のパフォーマンスを改善するための意思決定に役立てることができます。
AWS Outposts が外部ストレージアレイからの Amazon EC2 インスタンスの起動をサポート #
投稿日: 2025年7月17日
何ができるようになったのか #
AWS Outpostsで、NetApp® オンプレミスエンタープライズストレージアレイと Pure Storage® FlashArray™ にバックアップされたブートボリュームを使用して、Amazon EC2インスタンスを起動できるようになりました。
何が嬉しいのか #
- オンプレミスのストレージへの投資を最大限に活用しながら、Outpostsのクラウド運用モデルを利用できます。
- 互換性のあるエンタープライズストレージアレイをブートボリュームとデータボリュームの両方に使用し、高度なデータ管理機能と高パフォーマンスの利点を活用できます。
- 外部ブートボリュームのサポートにより、オンプレミスのストレージアレイでデータレジデンシー要件を満たしつつ、ブートボリュームの管理を一元化してOS管理を合理化できます。
これまでとどう変わるのか #
これまでOutposts上のEC2インスタンスのブートは、内蔵のAmazon EBSボリュームまたはローカルインスタンスストアに限定されていました。今回のアップデートにより、既存のオンプレミスストレージアレイ（NetApp, Pure Storage）をブートボリュームとして直接利用できるようになり、ストレージ資産の活用柔軟性が大幅に向上しました。
具体的なユースケース #
- 既存のNetAppやPure StorageのアレイをEC2インスタンスのブートボリュームとして利用し、ストレージへの投資を保護する。
- データレジデンシー要件が厳しいワークロードで、オンプレミスストレージ上のブートボリュームからインスタンスを起動する。
- ストレージアレイの高度なデータ管理機能（スナップショット、クローニングなど）をブートボリュームに活用し、OS管理を効率化する。
Amazon MemoryDB がマルチリージョンクラスターのレプリケーションを一時停止する AWS FIS アクションのサポートを開始 #
投稿日: 2025年7月17日
何ができるようになったのか #
Amazon MemoryDBで、マルチリージョンクラスターのレプリケーションを一時停止するAWS Fault Injection Service (FIS) アクションがサポートされるようになりました。
何が嬉しいのか #
- FISを使用してリージョンレプリケーションの中断に対するアプリケーションの反応を監視し、モニタリングとリカバリのプロセスを調整して、回復性とアプリケーションの可用性を改善できます。
- マルチリージョンクラスターでレプリケーションが中断・再開した際の実際の動作を再現し、アプリケーションが意図通りに応答することをテスト・確認できます。
これまでとどう変わるのか #
これまで、MemoryDBのマルチリージョン構成におけるレプリケーション障害のテストは、手動での操作やカスタムスクリプトが必要で、再現が困難でした。今回のアップデートにより、AWS FISの標準アクションとしてレプリケーションの一時停止を簡単に実行できるようになり、より手軽かつ確実にカオスエンジニアリングを実践し、アプリケーションの回復力を検証できるようになりました。
具体的なユースケース #
- マルチリージョンアプリケーションのディザスタリカバリ計画をテストする。
- リージョン間のレプリケーションが中断された場合のアプリケーションのフェイルオーバー動作を検証する。
- CI/CDパイプラインにFIS実験を統合し、継続的にアプリケーションの回復力をテストする。
Amazon RDS データベースプレビュー環境で Amazon RDS for PostgreSQL 18 Beta 2 が利用可能に #
投稿日: 2025年7月17日
何ができるようになったのか #
Amazon RDS for PostgreSQL 18 Beta 2が、Amazon RDS データベースプレビュー環境で利用可能になりました。
何が嬉しいのか #
- PostgreSQL 18のプレリリース版を、フルマネージドなRDS環境で手軽に評価できます。
- 複数列Bツリーインデックスの「スキップスキャン」サポートによるOR/IN句の処理改善、並列GINインデックス構築など、PostgreSQL 18の新機能を先行して試すことができます。
- クエリ実行中のバッファ使用回数やインデックスルックアップ、接続ごとのI/O使用状況メトリクスなど、オブザーバビリティの向上も体験できます。
これまでとどう変わるのか #
これまで、PostgreSQLの新しいベータ版を試すには、自身でサーバーを構築し、環境をセットアップする必要がありました。今回のアップデートにより、RDSのプレビュー環境を利用することで、インフラ管理の手間なく、数クリックでPostgreSQL 18 Beta 2の環境を構築し、新機能の評価に集中できるようになります。
具体的なユースケース #
- アプリケーションがPostgreSQL 18の「スキップスキャン」機能によってどの程度パフォーマンスが向上するかを検証する。
- 新しいオブザーバビリティ機能を活用して、既存のクエリのパフォーマンスボトルネックを分析する。
- 正式リリース前に、自社アプリケーションとPostgreSQL 18との互換性を確認する。
:::message 注意 プレビュー環境のDBインスタンスは最大60日間で自動的に削除されます。本番環境での利用はできません。 :::
Amazon AppStream 2.0 が GPU ベースのインスタンスのサポートを拡張 #
投稿日: 2025年7月17日
何ができるようになったのか #
Amazon AppStream 2.0で、NVIDIA L4 TensorコアGPUを搭載したEC2 G6ファミリーベースの「Graphics G6インスタンス」がサポートされるようになりました。
何が嬉しいのか #
- グラフィックスを多用するアプリケーション向けに、9種類の新しいインスタンスサイズが提供され、料金とパフォーマンスの選択肢が広がります。
- vCPUとメモリの比率が1:4または1:8の構成を選択でき、ワークロードに最適な構成を選べます。
これまでとどう変わるのか #
これまでのGPUインスタンスファミリーに加えて、より新しく高性能なNVIDIA L4 GPUを搭載したG6インスタンスが利用可能になりました。これにより、最新のグラフィックスアプリケーションやAI/MLワークロードなどを、より高いパフォーマンスとコスト効率で実行できるようになります。
具体的なユースケース #
- CAD/CAM/CAEなどのエンジニアリングアプリケーション
- メディアおよびエンターテイメント業界でのコンテンツ制作
- AI/ML推論ワークロード
- その他、高いグラフィックス性能を必要とするデスクトップアプリケーションのストリーミング
Amazon OpenSearch Service が Amazon Aurora MySQL および Amazon Aurora PostgreSQL との統合をサポート #
投稿日: 2025年7月17日
何ができるようになったのか #
Amazon OpenSearch Serviceで、Amazon Aurora MySQLおよびPostgreSQLからシームレスにデータを取り込めるようになりました。
何が嬉しいのか #
- リレーショナルデータベースのデータに対して全文検索、ハイブリッド検索、ベクトル検索などの高度な検索機能を利用できます。
- データを書き込んでから数秒以内にAuroraからOpenSearch Serviceにデータを同期できます。
- カスタムコードで複雑なETLパイプラインを構築・維持する必要がなくなります。
これまでとどう変わるのか #
従来、AuroraのデータをOpenSearch Serviceで利用するためには、AWS GlueやLambdaなどを使ってカスタムのETL処理を実装する必要がありました。今回の統合により、Amazon OpenSearch Ingestionを介して、コーディングなしでほぼリアルタイムにデータを同期できるようになり、開発と運用の手間が大幅に削減されます。
具体的なユースケース #
- ECサイトの商品カタログデータをAuroraに格納し、OpenSearch Serviceで高速な商品検索機能を提供する。
- 複数のアプリケーションのデータをAuroraから単一のOpenSearchクラスターに集約し、横断的な分析やインサイトを得る。
- ログやトランザクションデータをリアルタイムでOpenSearch Serviceに同期し、監視や異常検知に活用する。
Amazon OpenSearch Service が Amazon RDS for MySQL および Amazon RDS for PostgreSQL との統合をサポート #
投稿日: 2025年7月17日
何ができるようになったのか #
Amazon OpenSearch Serviceで、Amazon RDS for MySQLおよびPostgreSQLからシームレスにデータを取り込めるようになりました。
何が嬉しいのか #
- リレーショナルデータベースのデータに対して全文検索、ハイブリッド検索、ベクトル検索などの高度な検索機能を利用できます。
- データを書き込んでから数秒以内にRDSからOpenSearch Serviceにデータを同期できます。
- カスタムコードで複雑なETLパイプラインを構築・維持する必要がなくなります。
これまでとどう変わるのか #
従来、RDSのデータをOpenSearch Serviceで利用するためには、AWS GlueやLambdaなどを使ってカスタムのETL処理を実装する必要がありました。今回の統合により、Amazon OpenSearch Ingestionを介して、コーディングなしでほぼリアルタイムにデータを同期できるようになり、開発と運用の手間が大幅に削減されます。
具体的なユースケース #
- ECサイトの商品カタログデータをRDSに格納し、OpenSearch Serviceで高速な商品検索機能を提供する。
- 複数のアプリケーションのデータをRDSから単一のOpenSearchクラスターに集約し、横断的な分析やインサイトを得る。
- ログやトランザクションデータをリアルタイムでOpenSearch Serviceに同期し、監視や異常検知に活用する。
Amazon S3 マルチリージョンアクセスポイントが、新たに 12 の AWS リージョンで利用可能に #
投稿日: 2025年7月17日
:::message マルチリージョンアクセスポイントは、S3バケットを複数リージョンに分散配置しても、単一のエンドポイントからアクセスできる仕組みです。
- 目的
- リージョンを意識せず、最寄りのリージョンのS3に自動ルーティング
- 災害対策（リージョン障害時に自動フェイルオーバー）
- グローバルユーザーへのレイテンシ低減 :::
何ができるようになったのか #
Amazon S3 マルチリージョンアクセスポイントが、新たに12のAWSオプトインリージョンで利用可能になりました。 対象リージョン: アジアパシフィック (ジャカルタ、香港、ハイデラバード、メルボルン)、欧州 (チューリッヒ、スペイン、ミラノ)、中東 (バーレーン、アラブ首長国連邦)、カナダ西部 (カルガリー)、アフリカ (ケープタウン)、イスラエル (テルアビブ)。
何が嬉しいのか #
- これまで以上に多くのリージョンでマルチリージョンアクセスポイントを利用できるようになり、グローバルアプリケーションのパフォーマンス、回復力、およびデータ管理が向上します。
- アプリケーションは、地理的に最も近いAWSリージョンに自動的にリクエストをルーティングすることで、レイテンシーを削減できます。
これまでとどう変わるのか #
S3 マルチリージョンアクセスポイントが利用できるリージョンが限定されていましたが、今回のアップデートでオプトインリージョンを含む12のリージョンが追加され、より広範な地域でこの機能を利用できるようになりました。これにより、グローバルに展開するアプリケーションのアーキテクチャ設計の柔軟性が向上します。
具体的なユースケース #
- グローバルに展開するアプリケーションで、世界中のユーザーに対して低レイテンシーでのデータアクセスを提供する。
- 複数のリージョンにまたがるデータセットに対して、単一のグローバルエンドポイントを提供し、アプリケーションの構成を簡素化する。
- ディザスタリカバリ構成において、リージョン障害時に自動的に別のリージョンにフェイルオーバーする回復力の高いストレージを構築する。
AWS Glue が大規模でメモリを大量に消費するワークロード向けの新しいワーカーをサポート #
投稿日: 2025年7月17日
何ができるようになったのか #
AWS Glue に、以下の新しいワーカータイプが追加されました:
- G.12X, G.16X: より多くの vCPU／メモリ／ストレージを備えた汎用タイプ
- R.1X, R.2X, R.4X, R.8X: メモリ最適化型で G タイプの2倍メモリ
何が嬉しいのか #
- G.12X／16X: 最もリソース要求が高いデータ統合処理でも、垂直スケールで短時間に処理可能
- R タイプ: キャッシュ、シャッフル、集約などメモリ負荷の強い Spark ジョブでも安定実行できる
具体的なユースケース #
- 大容量データセットの複雑な変換・集約・結合処理
- Spark ドライバープランが大きい場合の安定実行
- メモリによる OOM 問題の解消が必要なバッチ／ETL ジョブ
さいごに #
AWS Lambda、VS Code IDE からクラウドで実行されている関数のデバッグが可能に は熱いですね！
従来deploy後の権限エラーなどの修正が面倒でしたが簡単になりますね 👍