本日の主なトピック #
- Amazon Athena Spark が AWS PrivateLink をサポート: VPC 内からパブリックインターネットを経由せずにセキュアにアクセス可能になりました。
- AWS Lambda、Amazon S3 バケットをファイルシステムとしてマウント可能に: POSIX 互換のファイル操作で S3 上のデータに直接アクセスでき、大容量データの処理が容易になります。
- Amazon Aurora Serverless、パフォーマンスが最大30%向上: プラットフォームバージョン 4 へのアップデートにより、スケーリングがよりスマートになり、より高負荷なワークロードに対応します。
- Amazon Connect、AI 音声対話機能（Speech-to-Speech）をアジア圏へ拡大: ソウル、シンガポールを含む新リージョンと韓国語を含む多言語をサポートしました。
- AWS Transform (custom) が東京リージョンで利用可能に: コードのモダナイゼーションやアップグレードを支援するサービスが日本でも利用可能になりました。
¥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 Athena Spark が AWS PrivateLink のサポートを開始 #
投稿日: 2026年04月21日
何ができるようになったのか #
Amazon Athena Spark において AWS PrivateLink がサポートされました。これにより、パブリックインターネットを経由することなく、Amazon VPC 内から Athena Spark の API やエンドポイント（Spark Connect、Spark Live UI、Spark History Server など）に安全にアクセスできるようになります。
何が嬉しいのか #
パブリックインターネットを通らないため、セキュリティ要件やコンプライアンス基準が厳しい環境でも Athena Spark を利用しやすくなります。VPC エンドポイント（インターフェース型）を作成するだけで、すべての通信を AWS ネットワーク内に完結させることが可能です。
これまでとどう変わるのか #
- これまで: Athena Spark の API やエンドポイントにアクセスする際、パブリックネットワークを経由する必要がありました。
- これから: AWS PrivateLink を使用することで、VPC 内のクライアントから AWS 内部ネットワークのみを通るセキュアな経路でアクセス可能です。
具体的なユースケース #
- 金融や医療など、データの外部露出を厳格に制限している環境でのインタラクティブなデータ分析。
- 社内ネットワークからのみアクセスを許可したい Spark UI や履歴サーバーの管理。
Amazon Connect、AIエージェントによるSpeech-to-Speech機能をソウル、シンガポール、フランクフルト地域に拡大 #
投稿日: 2026年04月20日
何ができるようになったのか #
Amazon Connect の AI エージェント（エージェンティック・セルフサービス）による Speech-to-Speech（音声対話）体験が、アジアパシフィック（ソウル、シンガポール）および欧州（フランクフルト）の3つのリージョンに拡大されました。また、韓国語、フランス語、ドイツ語、イタリア語、スペイン語、および各地域の英語（豪、英、シンガポール）を含む10のロケールが新たに追加されました。
何が嬉しいのか #
より多くの地域と多言語において、人間のように自然な対話を行う音声 AI エクスペリエンスを顧客に提供できるようになります。AI エージェントは単に言葉を理解するだけでなく、トーンや感情を汲み取り、自然な会話のペースを維持しながら複雑なサービス要求にも対応可能です。
これまでとどう変わるのか #
- これまで: これらのリージョンや言語では、高度な Speech-to-Speech AI エージェント機能が限定的でした。
- これから: ソウルやシンガポールなどのリージョンで、韓国語や各国語に対応した最新の音声対話型 AI を導入し、カスタマーサービスの自動化を推進できます。
具体的なユースケース #
- アジアやヨーロッパの多言語ユーザーを抱えるグローバル・コンタクトセンターでの音声対話自動化。
- 顧客の感情やニュアンスを理解し、適切なトーンで回答する必要がある高度な顧客サポート。
Amazon Connect Outbound Campaigns、配信リスト（セグメント）の更新頻度が最短1時間に #
投稿日: 2026年04月20日
何ができるようになったのか #
Amazon Connect Outbound Campaigns において、キャンペーン対象者のリスト（セグメント）を更新する頻度が、これまでの最短24時間から「最短1時間」に短縮されました。これにより、その日に新しく条件に合致した顧客に対しても、翌日を待たずに当日のうちにアウトリーチを開始できるようになります。
何が嬉しいのか #
ビジネス状況の変化に即座に対応できるようになります。例えば、支払遅延が発生した顧客への当日中の催促や、予約が入ってから1時間以内のリマインドコールなど、タイミングが重要な施策の有効性が大幅に向上します。
これまでとどう変わるのか #
- これまで: セグメントの更新は最短でも24時間おきだったため、新しい顧客がリストに追加されるまで最大1日のタイムラグがありました。
- これから: 最短1時間おきにリストが更新されるため、ほぼリアルタイムに近い形でアウトバウンド施策を実行できます。
具体的なユースケース #
- 債権回収チームが、午後フラグが立った未払いアカウントに対してその日のうちに連絡を開始する。
- 医療機関が、新規予約から1時間以内に自動で予約確認の電話を入れる。
- SMS送信後に反応がない顧客に対し、数時間後に自動で音声通話によるフォローアップを行う。
Amazon Connect Outbound Campaigns、最大10個の属性による優先順位付け（Priority Ordering）をサポート #
投稿日: 2026年04月21日
何ができるようになったのか #
Amazon Connect Outbound Campaigns で、最大10個のユーザープロフィール属性に基づいた優先順位で発信を行えるようになりました。これにより、エージェントのリソースを最も価値の高い顧客や緊急性の高い案件に優先的に割り当てることが可能になります。
何が嬉しいのか #
キャンペーンの有効性と成約率（コンバージョン率）を向上させることができます。LTV（顧客生涯価値）やアカウントのランク、予約日などの属性でリストをソートし、重要な顧客から順にアプローチできるため、限られた時間内での成果を最大化できます。
これまでとどう変わるのか #
- これまで: キャンペーン内での発信順序を柔軟に制御することが難しく、一律の順序で処理される傾向がありました。
- これから: ビジネス価値に直結する属性に基づいて順序を構成でき、最初の試行（Initial attempts）は常に再試行（Reattempts）よりも優先されるため、優先順位が維持されます。
具体的なユースケース #
- 金融サービスにおいて、契約更新が近い高価値顧客から優先的に連絡する。
- ヘルスケアにおいて、予約日時が最も近い患者から順に確認の電話を入れる。
- セールスにおいて、見込み度の高いリードから優先的にアウトバウンドを行う。
Amazon Connect、AIパワード・セルフサービスのためのコンテキストパスをサポート #
投稿日: 2026年04月20日
何ができるようになったのか #
Amazon Connect において、通話開始時に顧客のコンテキスト（顧客ID、セッションリファレンス、キャンペーンコードなど）を自動的に引き継ぐことができるようになりました。これにより、ウェブサイト、モバイルアプリ、または通知リンクから電話をかけた際に、AI エージェントが即座に誰が何の目的でかけてきたかを認識できるようになります。
何が嬉しいのか #
顧客は電話がつながった後に、自分の名前や問い合わせ内容を改めて説明する必要がなくなります。AI エージェントが最初からコンテキストを把握しているため、パーソナライズされたセルフサービスを提供でき、問題解決までの時間を短縮できます。
これまでとどう変わるのか #
- これまで: 通話が開始された後、顧客が本人確認を行ったり、要件を口頭やプッシュボタン（DTMF）で入力したりする手間が発生することがありました。
- これから: デジタルチャネルでの操作情報を通話に引き継ぐことで、AI エージェントが最初から適切な対応を開始できます。
具体的なユースケース #
- モバイルアプリで注文状況を確認している最中にサポートへ電話した際、AI エージェントが「ご注文の配送状況についてお電話ですね？」と即座に対応する。
- 特定のキャンペーン通知から電話した顧客に対し、そのキャンペーンに関連したメニューを優先的に案内する。
Amazon MSK Replicator、双方向レプリケーション時のコンシューマーオフセット同期を強化 #
投稿日: 2026年04月20日
何ができるようになったのか #
Amazon MSK Replicator において、双方向レプリケーション（bidirectional replication）時のコンシューマーオフセット同期機能が強化されました。プロデューサーがどのクラスターで稼働しているかに関わらず、ソースとターゲット間でオフセットが同期されるようになり、クラスター間でのアプリケーション移動がより自由に行えるようになります。
何が嬉しいのか #
プロデューサーとコンシューマーのアプリケーションを、順序や依存関係を気にすることなく、独立してクラスター間で移動できるようになります。これにより、データの重複処理や損失のリスクを抑えつつ、メンテナンスや障害復旧時の切り替えがスムーズになります。
これまでとどう変わるのか #
- これまで: 双方向レプリケーションでは、プロデューサーとコンシューマーが同一のクラスターでアクティブな場合にのみオフセットが同期されていました。そのため、移行時の順序を慎重に管理する必要があり、ロールバック時に重複処理が発生するリスクがありました。
- これから: プロデューサーの稼働場所に関係なくオフセットが同期されるため、調整の手間やデータ重複のリスクが解消されます。
具体的なユースケース #
- Kafka クラスター間のワークロード移行時に、プロデューサーを先に移動させ、後からコンシューマーを移動させるような柔軟なスケジュール。
- マルチリージョンでのアクティブ/アクティブ構成において、障害発生時にアプリケーションを迅速かつ正確な位置から再開させる。
Amazon MSK Replicator、外部 Apache Kafka から MSK Express へのレプリケーションをサポート #
投稿日: 2026年04月20日
何ができるようになったのか #
Amazon MSK Replicator が、外部の Apache Kafka クラスター（オンプレミス、他社クラウド、セルフマネージドなど）から Amazon MSK Express ブローカーへのデータレプリケーションをサポートしました。また、MSK Express から外部 Kafka へのフェイルバックも可能です。
何が嬉しいのか #
オンプレミスや他の環境から、高性能な MSK Express（標準ブローカーに比べスループット最大3倍、スケーリング最大20倍高速）への移行が容易になります。マネージドサービスである MSK Replicator を使うことで、トピック名を維持したまま、無限ループを自動回避しつつ、セキュアで信頼性の高いレプリケーションを構築できます。
これまでとどう変わるのか #
- これまで: 外部 Kafka から MSK Express へのレプリケーションには、MirrorMaker 2 などのオープンソースツールを自身で管理・構築する必要がありました。
- これから: MSK Replicator を使用して、インフラ管理不要で外部 Kafka と MSK Express 間の双方向同期が可能になります。
具体的なユースケース #
- オンプレミスの Kafka ワークロードを、高パフォーマンスな Amazon MSK Express へ移行する。
- ハイブリッドクラウドやマルチクラウド環境でのデータ配信・バックアップ。
- MSK Express をメインとし、外部 Kafka を災害復旧（DR）用の待機系として利用する。
Amazon MSK Replicator、レプリケーションの可視性を高めるログ転送をサポート #
投稿日: 2026年04月20日
何ができるようになったのか #
Amazon MSK Replicator が、詳細なレプリケーターログを Amazon CloudWatch Logs、Amazon S3、または Amazon Data Firehose に転送できるようになりました。これにより、レプリケーション中のイベントやエラー、解決策などの詳細な情報を直接確認できるようになります。
何が嬉しいのか #
トラブルシューティングが大幅に迅速化されます。権限不足、パーティションクォータの超過、レコードサイズ制限違反など、よくあるエラーが具体的な解決策とともにログに出力されるため、AWS サポートに問い合わせることなく自身で問題を解決しやすくなります。
これまでとどう変わるのか #
- これまで: レプリケーションの状況把握には主に CloudWatch メトリクスが使用されており、エラーの具体的な原因特定には情報が不足する場合がありました。
- これから: 詳細なアクションログが得られるため、レプリケーションの健全性をエンドツーエンドで把握し、異常発生時に即座に対応可能です。
具体的なユースケース #
- 新しいレプリケーション設定時の権限エラーや設定ミスの特定.
- 稼働中のレプリケーションにおいて、特定のレコードが原因で発生したエラーの調査.
- 監査やコンプライアンス目的でのレプリケーション活動のログ保存.
Amazon Aurora Serverless、パフォーマンスが最大30%向上しスケーリングがよりスマートに #
投稿日: 2026年04月21日
何ができるようになったのか #
Amazon Aurora Serverless がプラットフォームバージョン 4 にアップデートされ、前バージョンと比較してパフォーマンスが最大 30% 向上しました。また、ワークロードをより深く理解する「スマートスケーリング」機能が強化され、特にリソースを競合しがちなビジーなウェブアプリや API サービス、活動が断続的な AI エージェントアプリケーションにおいて、より効率的にキャパシティを調整できるようになりました。
何が嬉しいのか #
パフォーマンスの向上により、これまで以上に要求の厳しいワークロードをサーバーレスで運用できるようになります。また、利用していないときはゼロまで自動スケールダウンする特性は維持されているため、コスト効率を最大化しつつ、予測不能なバーストトラフィックにも柔軟に対応可能です。
これまでとどう変わるのか #
- これまで: プラットフォームバージョン 1〜3 が提供されていました。
- これから: バージョン 4 が標準となり、新規クラスターやリストア時に自動で適用されます。既存のクラスターもメンテナンスや再起動、ブルー/グリーンデプロイを通じて簡単にアップグレード可能です。
具体的なユースケース #
- 稼働時間が不定期で、リクエストが来たときだけ即座にリソースが必要になる AI エージェントのバックエンドデータベース。
- 複数のタスクがリソースを奪い合うような、高負荷なウェブアプリケーションのデータベース。
- 開発・テスト環境など、夜間や週末は利用しないためコストを抑えたい環境。
AWS Transform (custom) が東京を含む6つのリージョンで利用可能に #
投稿日: 2026年04月21日
何ができるようになったのか #
大規模なコードのモダナイゼーションや変換を支援する「AWS Transform custom」が、東京、ムンバイ、ソウル、シドニー、カナダ（中部）、ロンドンの6つのリージョンで新たに利用可能になりました。これにより、合計8つのリージョンでこのサービスを利用できます。
何が嬉しいのか #
日本のユーザーも東京リージョンで AWS Transform を利用し、言語バージョンのアップグレード、フレームワークの移行、パフォーマンスの最適化などをマネージドな環境で行えるようになります。組織固有の要件に合わせたカスタム変換（custom transformations）も可能です。
これまでとどう変わるのか #
- これまで: バージニア北部（米国東部）とフランクフルト（欧州）の2リージョンに限定されていました。
- これから: 東京リージョンを含む主要なアジアパシフィックおよびカナダ、英国のリージョンで利用可能です。
具体的なユースケース #
- 東京リージョンで稼働している既存システムの古いプログラミング言語バージョンを、一括で最新版に変換・アップグレードする。
- 特定のサードパーティ製フレームワークから別のフレームワークへの大規模なコード移行。
- 組織内のコーディング規約に合わせたカスタムなコードリファクタリングの自動実行。
AWS Lambda、Amazon S3 バケットをファイルシステムとしてマウント可能に #
投稿日: 2026年04月21日
何ができるようになったのか #
AWS Lambda において「Amazon S3 Files」がサポートされました。これにより、Lambda 関数から S3 バケットをファイルシステムとして直接マウントし、データのダウンロード・アップロードを行うことなく、標準的なファイル操作（POSIX 互換）で S3 上のデータにアクセスできるようになります。
何が嬉しいのか #
大きなオブジェクトを扱う際、一時ストレージ（/tmp）の制限を気にしたり、手動で S3 からダウンロード/アップロードしたりするロジックを実装する必要がなくなります。複数の Lambda 関数から同一の S3 バケットを共有ワークスペースとしてマウントできるため、パイプライン間でのデータ共有も容易になります。
これまでとどう変わるのか #
- これまで: Lambda で S3 のデータを処理するには、SDK を使用してオブジェクト全体をメモリや一時ディスクにダウンロードする必要がありました。
- これから: S3 バケットを特定のパス（例: /mnt/s3）にマウントし、ローカルファイルと同様に
open()やread()で直接扱えます。
具体的なユースケース #
- AI/機械学習モデルの推論において、大きなモデルファイルやデータセットをマウントして直接読み込む。
- 動画や画像処理など、大きなファイルをストリーム処理するバッチジョブ。
- Lambda Durable Functions を使用したマルチステップのワークフローにおいて、チェックポイントデータや中間結果を S3 上で共有する。
AWS Managed Microsoft AD、Kerberos暗号化の監査イベントログをサポート #
投稿日: 2026年04月20日
何ができるようになったのか #
AWS Managed Microsoft AD において、Kerberos 暗号化に関する監査イベントログ（イベント ID 201〜209）を Amazon CloudWatch Logs へ転送できるようになりました。これにより、アプリケーションやサービスがどの暗号化タイプ（RC4 または AES）を使用しているかを可視化できます。
何が嬉しいのか #
セキュリティの向上に役立ちます。脆弱性が指摘されている古い RC4 暗号化を使用しているリソースを特定し、よりセキュアな AES 暗号化へのアップグレードが必要なクライアントを正確に把握できます。互換性維持のために RC4 が必要な環境においても、利用状況を監査できるため安全性が向上します。
これまでとどう変わるのか #
- これまで: どのクライアントがどの Kerberos 暗号化タイプを使用しているかを詳細に把握することは困難でした。
- これから: CloudWatch Logs を通じて、暗号化設定の状況をリアルタイムまたは蓄積されたログから分析可能です。
具体的なユースケース #
- 組織内のレガシーなアプリケーションが依然として RC4 暗号化を使用していないかの定期的なセキュリティ監査。
- ドメイン全体のセキュリティレベルを引き上げるための、AES 暗号化移行計画の策定と進捗確認。
AWS Marketplace、欧州・英・ノルウェーにおけるVAT請求・支払いプロセスを効率化 #
投稿日: 2026年04月21日
何ができるようになったのか #
AWS Marketplace において、欧州連合（EU）、ノルウェー、および英国におけるデジタルサービスの「みなし供給（deemed supply）」取引に関する付加価値税（VAT）の請求・支払いプロセスが簡素化されました。セルフサービス形式で VAT 請求書を提出し、自動で VAT の支払い（Disbursement）を受け取ることが可能になります。
何が嬉しいのか #
これまでの手動プロセスや別のプラットフォームへの登録が不要になります。AWS Marketplace Management Portal または AWS Partner Central から一括して請求書の提出、ステータスのリアルタイム追跡、自動支払いの受領が可能になり、税務コンプライアンス遵守のための事務負担が大幅に軽減されます。
これまでとどう変わるのか #
- これまで: みなし供給取引に関する VAT 支払いを受けるためには、手動での請求プロセスや煩雑な事務作業が必要でした。
- これから: システムが自動的に請求書の必須項目を検証し、購入者からの支払いが確認され次第、自動で VAT 分が支払われます。複数の取引を1通の請求書にまとめることも可能です。
具体的なユースケース #
- 欧州や英国の顧客にデジタルサービスを販売している AWS Marketplace セラーが、現地法に基づいた VAT 処理を効率化する。
- 複数の AWS EMEA ブランチを通じた取引の VAT 請求状況をレポート機能で一元管理し、監査や財務報告に活用する。
AWS Organizations のバックアップポリシーが Redshift Serverless と Aurora DSQL をサポート #
投稿日: 2026年04月21日
何ができるようになったのか #
AWS Organizations のバックアップポリシーにおいて、Amazon Redshift Serverless のネームスペースおよび Amazon Aurora DSQL のクラスターを直接的なリソースタイプとして指定できるようになりました。組織の管理者は、メンバーアカウントを横断してこれらのリソースに対するバックアップルールを一括定義できます。
何が嬉しいのか #
タグベースの選択や「すべてのアカウント内リソース」を対象にする必要がなくなり、特定のリソースタイプに対してより精密なバックアップ管理が可能になります。組織全体のデータ保護戦略において、サーバーレスな分析基盤や分散 SQL データベースを容易に、かつ正確にバックアップ計画に組み込めます。
これまでとどう変わるのか #
- これまで: Redshift Serverless や Aurora DSQL を組織レベルでバックアップするには、リソースに特定のタグを付与するか、アカウント内の全リソースを対象にするなどの間接的な方法が必要でした。
- これから: バックアップポリシー内でリソースタイプを直接選択でき、除外設定なども含めた柔軟なコントロールが可能になります。
具体的なユースケース #
- 組織内のすべての開発・本番アカウントにある Redshift Serverless ネームスペースに対し、一貫した保存期間（Retention period）のバックアップルールを適用する。
- 新しく作成された Aurora DSQL クラスターを、タグの付け忘れに関わらず自動的に組織全体のバックアップ対象に含める。
Amazon EC2 G7e インスタンスがロサンゼルスの AWS Local Zones で利用可能に #
投稿日: 2026年04月21日
何ができるようになったのか #
NVIDIA RTX PRO 6000 Blackwell Server Edition GPU と 第5世代 Intel Xeon Scalable プロセッサを搭載した Amazon EC2 G7e インスタンスが、カリフォルニア州ロサンゼルスの AWS Local Zones で一般提供（GA）されました。
何が嬉しいのか #
ロサンゼルス近郊のユーザーに対し、極めて低レイテンシーな高性能 GPU コンピューティングを提供します。クリエイティブなワークロード（VFX 編集、カラーグレーディング、リアルタイムレンダリングなど）や、エッジでの大規模言語モデル（LLM）の推論、AI エージェントのデプロイに最適です。
これまでとどう変わるのか #
- これまで: ロサンゼルスの Local Zone では最新の G7e インスタンスのパワーを直接利用することはできず、リージョン（us-west-2 など）にアクセスする必要があり、レイテンシーが課題となる場合がありました。
- これから: 地理的に近い Local Zone で最新 GPU インスタンスを実行できるため、インタラクティブな作業やリアルタイム性が求められる AI 推論のパフォーマンスが向上します。
具体的なユースケース #
- ロサンゼルスのスタジオにおける、ローカルストレージと低レイテンシーで連携した VFX 制作ワークフロー。
- エッジでのリアルタイムな AI 推論や、低遅延な対話型 AI エージェントの実行。
- クラウドワークステーションを使用した、2D/3D のリアルタイムレンダリングとコンポジット。
AWS Lambda Durable Execution SDK for Java が一般提供（GA）開始 #
投稿日: 2026年04月21日
何ができるようになったのか #
Java 開発者が Lambda durable functions（耐久性のある関数）を使用して、回復力の高い長時間実行ワークフローを構築するための SDK「AWS Lambda Durable Execution SDK for Java」が一般提供（GA）されました。Java 17 以上に対応しており、外部のオーケストレーションサービス（AWS Step Functions など）を使わずに、コード内で直接マルチステップの処理を記述できます。
何が嬉しいのか #
進捗状況の自動チェックポイント、外部イベント待ちによる最大1年間の実行停止、関数の連鎖（チェーン）などを、Java のイディオムに沿った形で実装できます。ローカルテスト用のエミュレータも含まれており、本番デプロイ前にローカル環境でデバッグすることが可能です。
これまでとどう変わるのか #
- これまで: Lambda で複雑な長時間ワークフローを実現するには、Step Functions を組み合わせるか、独自の進捗管理ロジックを実装する必要がありました。
- 以前の状態: 特定の言語向け SDK が先行していましたが、今回 Java 開発者向けに GA となりました。
- これから: アプリケーションコード内で直接「待機」や「チェックポイント」を記述でき、インフラ構成をシンプルに保ちながら堅牢なワークフローを実現できます。
具体的なユースケース #
- 注文処理パイプラインなど、複数のステップを経て完了する長時間ワークフロー。
- 人間による承認（Human-in-the-loop）や AI エージェントのオーケストレーション。
- 外部 API からの応答待ちなど、不定期な待機時間が発生する処理の効率的な実装。