2025/10/15 9:00:00 ~ 2025/10/16 9:00:00 (JST)

最近の発表

Amazon WorkSpaces Core Managed Instances is now available in 5 additional AWS Regions

AWS は本日、Amazon WorkSpaces コアマネージドインスタンスを米国東部 (オハイオ)、アジアパシフィック (マレーシア)、アジアパシフィック (香港)、中東 (UAE)、およびヨーロッパ (スペイン) で利用できるようになったことを発表しました。これにより、これらの AWS リージョンに初めて Amazon WorkSpaces 機能が導入されました。これらのリージョンの WorkSpaces コアマネージドインスタンスは、シトリックス、ワークスポット、レオストリーム、ディジオンなどのパートナーによってサポートされています。\n Amazon WorkSpaces コアマネージドインスタンスは、高度にカスタマイズ可能なインスタンス設定により、仮想デスクトップインフラストラクチャ (VDI) の移行を簡素化します。WorkSpaces Core Managed Instances は AWS アカウントにリソースをプロビジョニングし、永続ワークロードと非永続ワークロードの両方のインフラストラクチャライフサイクル管理を行います。マネージドインスタンスは、特定のコンピューティング、メモリ、またはグラフィック設定を必要とする組織に柔軟性を提供します。 WorkSpaces Core Managed Instances では、既存の割引や割引プラン、オンデマンドキャパシティ予約 (ODCR) などの他の機能を、WorkSpaces のシンプルな運用と併せて、すべて AWS アカウントのセキュリティとガバナンスの範囲内で利用できます。このソリューションは、オンプレミスの VDI 環境から移行する組織や、インフラストラクチャ構成の管理を犠牲にすることなくコスト最適化を強化したいと考えている既存の AWS のお客様に最適です。アクセラレーテッドグラフィックインスタンスを含む幅広いインスタンスタイプを使用できますが、コアパートナーソリューションは使い慣れた管理ツールを使用してデスクトップとアプリケーションのプロビジョニングとセッション管理を行います。 お客様には、WorkSpaces Core の時間単位の料金に加えて、標準のコンピューティングコストが発生します。詳細については、WorkSpaces コアの料金表ページをご覧ください。 Amazon WorkSpaces コアマネージドインスタンスの詳細については、製品ページをご覧ください。技術文書と入門ガイドについては、Amazon WorkSpaces コアドキュメントを参照してください。

AWS SAM CLI adds Finch support, expanding local development tool options for serverless applications

AWS サーバーレスアプリケーションモデルコマンドラインインターフェイス (SAM CLI) は、サーバーレスアプリケーションのローカル開発とテスト用に Docker の代わりに Finch をサポートするようになりました。これにより、開発者は SAM CLI を使用してサーバーレスアプリケーションを構築およびテストする際に、希望するローカル開発環境をより柔軟に選択できるようになります。\n サーバーレスアプリケーションを構築する開発者は、ローカル開発環境で多くの時間を費やします。SAM CLI は、サーバーレスアプリケーションをローカルで開発およびテストするためのコマンドラインツールです。AWS クラウドにデプロイする前に、サーバーレスアプリケーションをローカルでビルド、テスト、デバッグ、パッケージ化できます。SAM CLI では、アプリケーションのローカル開発およびテスト環境を提供するために、ローカルデバイス上でコンテナを実行できるツールを使用しています。以前は、SAM CLI はコンテナをローカルで実行するためのツールとして Docker のみをサポートしていました。本日より、SAM CLI はコンテナ開発ツールとして Finch もサポートするようになりました。Finch はローカルコンテナ開発用のオープンソースツールで、AWS が開発、サポートしています。つまり、SAM CLI を使用する場合、ローカル開発用のコンテナツールとして Docker と Finch のどちらかを選択できるようになりました。 SAM CLI を使用すると、AWS クラウドと同じエクスペリエンスで Lambda 関数をローカルで呼び出したり、API エンドポイントをテストしたり、サーバーレスアプリケーションをデバッグしたりできます。Finch のサポートにより、SAM CLI は Docker が利用できない場合に Finch を自動的に検出してコンテナ開発ツールとして使用するようになりました。Finch を SAM CLI の推奨コンテナツールとして設定することもできます。この新機能は、sam build、sam local invoke、sam local start-api、sam local start-lambda など、すべての SAM CLI のコアコマンドをサポートします。 Finch で SAM CLI を使用する方法の詳細については、SAM CLI 開発者ガイドをご覧ください。

Claude 4.5 Haiku by Anthropic now in Amazon Bedrock

クロード・ハイク 4.5 が Amazon Bedrock で利用できるようになりました。Claude Haiku 4.5 は、Claude Sonnet 4 のコーディング、コンピューター使用、エージェントタスクの機能とほぼ同等の性能を、大幅に低いコストと高速で提供します。これにより、大規模デプロイや予算重視のアプリケーションでも最先端の AI を利用できるようになります。\n このモデルでは速度が向上しているため、リアルタイムのカスタマーサービスエージェントや応答時間が重要なチャットボットなど、遅延の影響を受けやすいアプリケーションに最適です。コンピューターを使用するタスクでは、Haiku 4.5 は以前のモデルに比べてパフォーマンスが大幅に向上し、より高速で応答性の高いアプリケーションが可能になります。このモデルはビジョンをサポートし、これまでは顧客がパフォーマンスとコストのどちらかを選択しなければならなかった新しいユースケースを開拓します。経済的に実行可能なエージェントエクスペリエンスを実現し、複雑なコーディングプロジェクトのためのマルチエージェントシステムをサポートし、大規模な財務分析および調査アプリケーションを強化します。Haiku 4.5 は Claude の独特な性格を保ちながら、本番環境でのデプロイに必要なパフォーマンスと効率性を実現しています。 クロード・ハイク 4.5 は、複数の場所でのグローバルなクロスリージョン推論によって Amazon Bedrock で利用できるようになりました。利用可能なリージョンの全リストを確認するには、ドキュメントを参照してください。Amazon Bedrock で Haiku 4.5 を使い始めるには、Amazon Bedrock コンソール、Anthropic の Claude in Amazon Bedrock 製品ページ、および Amazon Bedrock の料金表ページをご覧ください。

Second-generation AWS Outposts racks now supported in the AWS Europe (Ireland) Region

第 2 世代の AWS Outposts ラックが AWS ヨーロッパ (アイルランド) リージョンでサポートされるようになりました。Outposts ラックは、AWS インフラストラクチャ、AWS サービス、API、ツールを事実上すべてのオンプレミスのデータセンターまたはコロケーションスペースに拡張し、真に一貫したハイブリッド体験を実現します。\n スタートアップ企業から大企業、ヨーロッパ内外の公共機関に至るまで、Outposts ラックをこの新しいサポート地域に接続して注文できるようになりました。これにより、レイテンシーやデータレジデンシーのニーズに合わせて最適化できます。Outposts を利用すると、お客様はオンプレミスシステムへの低レイテンシーアクセスを必要とするワークロードをローカルで実行しながら、アプリケーション管理のためにホームリージョンに接続し直すことができます。また、お客様は Outposts と AWS のサービスを使用して、データレジデンシー要件を満たすためにオンプレミスに留めておく必要のあるデータを管理および処理することもできます。このリージョンの拡大により、お客様の Outposts が接続できる AWS リージョンの柔軟性がさらに高まります。 第 2 世代の Outposts ラックの詳細については、このブログ投稿とユーザーガイドをお読みください。第二世代の Outposts ラックがサポートされている国と地域、および AWS リージョンの最新リストについては、Outposts ラックに関する FAQ ページをご覧ください。

AWS Backup enhances backup plan management with schedule preview

AWS Backup では、バックアッププランのスケジュールプレビューが可能になり、バックアップの実行スケジュールを確認できるようになりました。スケジュールプレビューには、継続バックアップ、インデックス作成、またはコピー設定が有効になるタイミングを含め、次の 10 回の予定されたバックアップ実行が表示されます。\n バックアップ計画のスケジュールプレビューでは、すべてのバックアップルールが 1 つのタイムラインに統合され、それらがどのように連携しているかがわかります。ライフサイクル、コールドストレージへのライフサイクル、ポイントインタイムリカバリ、インデックス作成などの設定とともに、すべてのバックアップルールで各バックアップがいつ行われるかを確認できます。この統一されたビューにより、バックアップ戦略と実際の構成の間の矛盾やギャップを迅速に特定して解決できます。

バックアップ計画のスケジュールのプレビューは、AWS Backup が利用できるすべての AWS リージョンで利用できます。この機能は、追加設定なしで AWS Backup コンソール、API、または CLI から自動的に使用を開始できます。詳細については、当社のドキュメントをご覧ください。

AWS Step Functions now supports Diagnose with Amazon Q

AWS は、AWS Step Functions コンソールの Amazon Q 統合による AI を活用したトラブルシューティング機能を発表しました。AWS Step Functions は、お客様が AWS サービスを使用して分散アプリケーションを構築し、IT とビジネスプロセスを自動化し、データおよび機械学習パイプラインを構築できるようにする視覚的なワークフローサービスです。この統合により、Amazon Q のインテリジェントなエラー分析が AWS Step Functions コンソールに直接取り込まれ、ワークフローの問題をすばやく特定して解決できるようになります。\n AWS Step Functions ワークフローでエラーが発生した場合、エラーアラートとコンソールのエラー通知領域に表示される [Diagnose with Amazon Q] ボタンをクリックすると、AI によるトラブルシューティングガイダンスを受け取ることができます。この機能は、ステートマシンの実行エラーや Amazon ステートランゲージ (ASL) の構文エラーや警告など、一般的な問題を解決するのに役立ちます。トラブルシューティングの推奨事項は、エラー状況に合わせた修正手順とともに専用ウィンドウに表示されるため、より迅速な解決と運用効率の向上が可能になります。 AWS Step Functions 用 Amazon Q による診断は、Amazon Q が利用できるすべての商用 AWS リージョンでご利用いただけます。この機能は、お住まいの地域で Amazon Q にアクセスできるお客様には自動的に有効になります。 Diagnose with Amazon Q の詳細については、「Amazon Q によるコンソールエラーの診断とトラブルシューティング」を参照するか、AWS Step Functions コンソールにアクセスして開始してください。

Amazon Bedrock simplifies access with automatic enablement of serverless foundation models

Amazon Bedrock では、すべての商用 AWS リージョンのユーザーが、デフォルトですべてのサーバーレス基盤モデルへの即時アクセスを提供するようになりました。今回の更新により、モデルアクセスを手動でアクティブ化する必要がなくなり、Amazon Bedrock コンソールのPlayground、AWS SDK、およびエージェント、フロー、ガードレール、ナレッジベース、プロンプト管理、評価などの Amazon Bedrock 機能を通じて、これらのモデルの使用をすぐに開始できるようになりました。\n ほとんどのプロバイダーのサーバーレス基盤モデルはすぐに使い始めることができますが、Anthropic モデルではデフォルトで有効になっていますが、最初に使用する前に 1 回限りの使用フォームを送信する必要があります。このフォームは、API または Amazon Bedrock コンソールを使用して Playground から Anthropic モデルを選択して記入できます。AWS 組織管理アカウントを使用してフォームを送信すると、組織内のすべてのメンバーアカウントで Anthropic モデルが自動的に有効になります。 このシンプルなアクセスは、Amazon Bedrock がサポートされているすべての商用 AWS リージョンで利用できます。アカウント管理者は IAM ポリシーとサービスコントロールポリシー (SCP) を通じてモデルアクセスを完全に制御し、必要に応じてアクセスを制限できます。アクセス制御の実装ガイダンスと例については、当社のブログを参照してください。

DeepSeek, OpenAI, and Qwen models available in Amazon Bedrock in additional Regions

Amazon Bedrockは、DeepSeek-V3.1、OpenAIオープンウェイトモデル、Qwen3モデルを世界中のより多くのAWSリージョンに導入し、世界中のお客様に最先端のAIへのアクセスを拡大しています。このリージョンの拡大により、より多くの国や地域の組織がこれらの強力な基盤モデルをローカルにデプロイできるようになり、データレジデンシー要件へのコンプライアンスを確保し、ネットワークレイテンシーを削減し、AI を活用したより高速なエクスペリエンスをユーザーに提供できるようになります。\n DeepSeek-V3.1 と Qwen3 Coder-480B は、米国東部 (オハイオ) とアジアパシフィック (ジャカルタ) の AWS リージョンで利用できるようになりました。OpenAI オープンウェイトモデル (20B、120B) と Qwen3 モデル (32B、235B、Coder-30B) が、米国東部 (オハイオ)、ヨーロッパ (フランクフルト)、およびアジアパシフィック (ジャカルタ) の AWS リージョンで利用できるようになりました。 今後の更新については、リージョンの全リストをご覧ください。これらのモデルの詳細については、Amazon Bedrock 製品ページをご覧ください。開始するには、Amazon Bedrock コンソールにアクセスしてドキュメントを参照してください。

Amazon Aurora PostgreSQL zero-ETL integration with Amazon SageMaker is now available

Amazon Aurora PostgreSQL 互換エディションが Amazon SageMaker とのゼロETL統合をサポートするようになり、分析ワークロードのデータをほぼリアルタイムで利用できるようになりました。この統合により、PostgreSQL テーブルからデータが自動的に抽出されてレイクハウスに読み込まれ、さまざまな分析エンジンや機械学習ツールからすぐにアクセスできるようになります。レイクハウスに同期されたデータは Apache Iceberg オープンスタンダードと互換性があるため、SQL、Apache Spark、BI、AI/ML ツールなど、お好みの分析ツールやクエリエンジンを使用できます。\n シンプルなノーコードインターフェイスにより、本番環境のワークロードに影響を与えることなく、レイクハウス内の PostgreSQL データの最新のレプリカを作成して維持できます。この統合により、すべての分析ツールとエンジンに一貫して適用される、包括的できめ細かなアクセス制御が可能になり、組織全体での安全なデータ共有が保証されます。このソリューションは Amazon Redshift との既存のゼロETL統合を補完するものであり、運用データから即座に洞察を引き出すことができると同時に、運用の複雑さを軽減します。 Amazon Aurora PostgreSQL Zero-ETL と Amazon SageMaker の統合は、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、カナダ (中部)、南米 (サンパウロ)、アジアパシフィック (香港)、アジアパシフィック (シンガポール)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、ヨーロッパ (フランクフルト)、ヨーロッパ (アイルランド) で利用可能になりました、ヨーロッパ (ロンドン)、およびヨーロッパ (ストックホルム) の AWS リージョン。 詳細については、「Zero-ETLとは」をご覧ください。この新しいインテグレーションを使い始めるには、Aurora PostgreSQL のゼロ ETL ドキュメントをご覧ください。

Amazon EC2 R8g instances now available in additional regions

本日より、Amazon Elastic Compute Cloud (Amazon EC2) の R8g インスタンスは、南米 (サンパウロ)、ヨーロッパ (ロンドン)、およびアジアパシフィック (メルボルン) の各リージョンでご利用いただけます。これらのインスタンスは AWS Graviton4 プロセッサを搭載しており、AWS Graviton3 ベースのインスタンスと比較してパフォーマンスが最大 30% 向上しています。Amazon EC2 R8g インスタンスは、データベース、インメモリキャッシュ、リアルタイムのビッグデータ分析など、メモリを大量に消費するワークロードに最適です。これらのインスタンスは AWS Nitro System 上に構築されており、CPU の仮想化、ストレージ、ネットワーキング機能を専用のハードウェアとソフトウェアにロードして、ワークロードのパフォーマンスとセキュリティを強化します。\n AWS Graviton4 ベースの Amazon EC2 インスタンスは、Amazon EC2 で実行される幅広いワークロードに最高のパフォーマンスとエネルギー効率をもたらします。AWS Graviton4 ベースの R8g インスタンスは、Graviton3 ベースの R7g インスタンスよりも最大 3 倍多い vCPU (最大 48 倍) とメモリ (最大 1.5 TB) を備え、インスタンスサイズが大きくなっています。これらのインスタンスは、AWS Graviton3 ベースの R7g インスタンスと比較して、ウェブアプリケーションの場合は最大 30%、データベースの場合は最大 40%、大規模 Java アプリケーションの場合は 45% 高速です。R8g インスタンスには、2 つのベアメタルサイズを含む 12 種類のインスタンスサイズがあります。最大 50 Gbps の拡張ネットワーキング帯域幅と Amazon エラスティックブロックストア (Amazon EBS) への最大 40 Gbps の帯域幅を提供します。 詳細については、「Amazon EC2 R8g インスタンス」を参照してください。ワークロードを Graviton ベースのインスタンスに移行する方法については、AWS Graviton ファストスタートプログラムおよび Graviton 用ポーティングアドバイザーを参照してください。開始するには、AWS マネジメントコンソールを参照してください。

Amazon ECS supports running Firelens as a non-root user

Amazon Elastic Container Services (Amazon ECS) では、タスク定義でユーザー ID を指定することで、Firelens コンテナを非ルートユーザーとして実行できるようになりました。\n 特定のユーザー ID を持つ非ルートユーザーを指定することで、そのようなソフトウェアにアクセスする可能性のあるユーザーによる潜在的な攻撃を減らすことができます。これはセキュリティのベストプラクティスであり、AWS Security Hub などの一部の業界やセキュリティサービスではコンプライアンス要件となっています。今回のリリースでは、Amazon ECS では、タスク定義の Firelens ContainerDefinition 要素の「ユーザー」フィールドにユーザー ID を指定できるようになりました。「ユーザー」:「0" (ルートユーザー) のみを許可するのではなく、ユーザー ID を指定できるようになりました。 この新機能はすべての AWS リージョンでサポートされています。Firelens コンテナを非ルートで実行するように設定する方法の詳細については、Firelens の使用に関するドキュメントを参照してください。

AWS Backup expands information in job APIs and Backup Audit Manager reports

AWS Backup では、バックアップ設定とコンプライアンス設定をよりよく把握できるように、バックアップジョブ API レスポンスと Backup Audit Manager レポートでより詳細な情報が提供されるようになりました。1 回の API 呼び出しでバックアップポリシーを検証できます。\n バックアップ、コピー、復元ジョブの List API と Describe API が、以前は複数の API 呼び出しが必要だったフィールドを返すようになりました。委任された管理者は、組織全体のバックアップジョブの詳細を表示できるようになりました。バックアップジョブ API には、保持設定、ボールトロックステータス、暗号化の詳細、およびプラン名、ルール名、スケジュールなどのバックアッププラン情報が含まれます。コピージョブ API は、宛先ボールト設定、ボールトタイプ、ロック状態、暗号化設定を返します。復元ジョブ API には、ソースリソースの詳細とボールトアクセスポリシーが表示されます。Backup Audit Manager レポートには、ボールトの種類、ロックステータス、暗号化の詳細、アーカイブ設定、および保存期間を示す新しい列が含まれています。この情報を使用して監査記録を強化し、データ保護ポリシーへの準拠を検証できます。

これらの拡張情報フィールドは、現在 AWS Backup と AWS Backup Audit Manager がサポートされているすべての AWS リージョンで、追加料金なしでご利用いただけます。

AWS Backup Audit Manager の詳細については、製品ページとドキュメントをご覧ください。開始するには、AWS Backup コンソールにアクセスしてください。

AWS Application Load Balancer launches URL and Host Header Rewrite

アマゾンウェブサービス (AWS) は、アプリケーションロードバランサー (ALB) の URL とホストヘッダーの書き換え機能を発表しました。この機能により、お客様はリクエストをターゲットにルーティングする前に、正規表現ベースのパターンマッチングを使用してリクエスト URL とホストヘッダーを変更できます。\n URL とホストヘッダーの書き換えにより、正規表現パターンを使用して URL を変換したり (たとえば、「/api/v1/users」を「/users」に書き換えたり)、さまざまなアプリケーションで URL パターンを標準化したり、内部サービスルーティング用にホストヘッダーを変更したり、URL パスプレフィックスを削除または追加したり、レガシー URL 構造を新しい形式にリダイレクトしたりできます。この機能により、プロキシ層を追加する必要がなくなり、アプリケーションアーキテクチャが簡素化されます。この機能は、外部ホスト名を 1 つ維持しながら別の内部サービスへのルーティングが不可欠なマイクロサービスのデプロイメントに役立ちます。

URL とホストヘッダーの書き換えは、AWS マネジメントコンソール、AWS CLI、AWS SDK、AWS API を使用して設定できます。URL とホストヘッダーの書き換えには追加料金はかかりません。アプリケーションロードバランサーの料金に基づいて、アプリケーションロードバランサーの使用分のみお支払いいただきます。

この機能は現在、すべての AWS 商用リージョンで利用可能です。

詳細については、ALB ドキュメントと、アプリケーションロードバランサーによる URL とホストヘッダーの書き換えに関する AWS ブログ投稿をご覧ください。

Amazon RDS for MySQL and PostgreSQL zero-ETL integration with Amazon Redshift now available in 8 additional regions

Amazon RDS for MySQL および Amazon RDS for PostgreSQL Zero-ETL と Amazon Redshift の統合が、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、カナダ西部 (カルガリー)、ヨーロッパ (スペイン)、ヨーロッパ (チューリッヒ)、イスラエル (テルアビブ)、および中東 (UAE) の各リージョンで利用できるようになりました。ゼロETL統合により、Amazon Redshiftを使用してペタバイト規模のトランザクションデータに対するほぼリアルタイムの分析と機械学習 (ML) が可能になります。MySQL 用の Amazon RDS または PostgreSQL 用の Amazon RDS にデータが書き込まれてから数秒以内に、データは Amazon Redshift にレプリケートされます。 \n 単一の Amazon RDS データベースから複数のゼロ ETL 統合を作成できます。また、統合ごとにデータフィルタリングを適用して特定のデータベースやテーブルを含めたり除外したりして、Zero-ETL 統合をニーズに合わせて調整できます。また、AWS CloudFormation を使用して、ゼロETL 統合に必要なリソースの設定とデプロイを自動化することもできます。 ゼロ ETL の詳細と開始方法については、Amazon RDS と Amazon Redshift のドキュメントを参照してください。

Amazon Kinesis Data Streams announces new Fault Injection Service (FIS) actions for API errors

Amazon Kinesis データストリームでは、Kinesis API エラーに対するフォールトインジェクションサービス (FIS) アクションがサポートされるようになりました。お客様は、制御された環境で、アプリケーションのエラー処理機能、再試行メカニズム (指数バックオフパターンなど)、CloudWatch アラームをテストできるようになりました。これにより、お客様は実際の障害に遭遇する前にモニタリングシステムと復旧プロセスを検証できるようになり、最終的にアプリケーションの耐障害性と可用性が向上します。この統合により、Amazon Kinesis Data Streams のスロットリング、内部エラー、サービスの利用不可、期限切れのイテレータ例外などの Kinesis Data Streams API エラーがサポートされます。\n Amazon Kinesis Data Streams は、お客様があらゆる規模でリアルタイムのデータストリームを取得、処理、保存できるようにするサーバーレスのデータストリーミングサービスです。これで、お客様は実際の Kinesis Data Stream API エラー (GET および PUT オペレーションの 500、503、400 エラーを含む) を作成して、アプリケーションの耐障害性をテストできるようになりました。この機能により、以前はカスタム実装をする必要がなくなり、エラー処理メカニズムを検証するために実際に本番環境で障害が発生するまで待つ必要がなくなります。まず始めに、お客様はFISコンソールから実験テンプレートを作成して直接テストを実行したり、継続的インテグレーションパイプラインに統合したりできます。安全性を高めるため、FIS実験には、お客様が定義した閾値に達するとトリガーされる自動停止メカニズムが組み込まれているため、アプリケーションの安定性を損なうことなくテストを制御できます。 これらのアクションは通常、AWS GovCloud (米国) リージョンを含む、FIS が利用可能なすべての AWS リージョンで利用できます。これらのアクションの使用方法の詳細については、『Kinesis Data Streams ユーザーガイド』と『FIS ユーザーガイド』を参照してください。

Amazon MSK adds support for Apache Kafka version 4.1

Amazon マネージドストリーミング for Apache Kafka (Amazon MSK) では、Apache Kafka バージョン 4.1 がサポートされるようになりました。プレビュー機能としてキューが導入され、早期アクセスでの新しいストリームリバランスプロトコルと適格リーダーレプリカ (ELR) が導入されました。Apache Kafka バージョン 4.1 には、これらの機能に加えて、さまざまなバグ修正と改善が含まれています。詳細については、バージョン 4.1 の Apache Kafka リリースノートを参照してください。 \n Kafka 4.1 の主な特長は、プレビュー機能としてキューが導入されたことです。お客様は複数のコンシューマーを使用して同じトピックパーティションからのメッセージを処理できるため、ポイントツーポイントのメッセージ配信を必要とするワークロードの並列処理とスループットが向上します。新しい Streams リバランス・プロトコルは Kafka 4.0 のコンシューマー・リバランス・プロトコルを基盤としており、ブローカーの調整機能を Kafka Streams にまで拡張して、最適なタスク割り当てとリバランスを実現しています。さらに、可用性を強化するために ELR がデフォルトで有効になりました。 Amazon MSK で Apache Kafka 4.1 を使い始めるには、AWS マネジメントコンソール、AWS CLI、または AWS SDK を使用して新しいクラスターを作成するときに、バージョン 4.1.x を選択するだけです。インプレースローリングアップデートを使用して、既存の MSK プロビジョニングクラスターをアップグレードすることもできます。Amazon MSK はブローカーの再起動を調整して可用性を維持し、アップグレード中もデータを保護します。Kafka バージョン 4.1 のサポートは、現在 Amazon MSK が提供されているすべての AWS リージョンでご利用いただけます。開始方法については、Amazon MSK 開発者ガイドを参照してください。

Amazon RDS for Oracle zero-ETL integration with Amazon Redshift is now available in 8 additional AWS regions

Amazon RDS for Oracle Zero-ETL と Amazon Redshift の統合は、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、カナダ西部 (カルガリー)、ヨーロッパ (スペイン)、ヨーロッパ (チューリッヒ)、イスラエル (テルアビブ)、および中東 (UAE) の各リージョンで利用できるようになりました。Amazon RDS for Oracle Zero-ETL を Amazon Redshift と統合すると、ほぼリアルタイムの分析と機械学習 (ML) が可能になり、抽出/変換/読み込み (ETL) 操作のための複雑なデータパイプラインを使用せずに、Amazon Redshift 内のペタバイト規模のトランザクションデータを分析できます。データが Amazon RDS for Oracle データベースインスタンスに書き込まれてから数秒以内に、データは Amazon Redshift にレプリケートされます。ETL なしの統合により、Amazon RDS for Oracle データベースインスタンスからのデータ分析プロセスが簡素化され、複数のアプリケーションにわたる総合的な洞察を簡単に引き出すことができます。 \n AWS マネジメントコンソール、API、CLI、AWS CloudFormation を使用して、RDS for Oracle と Amazon Redshift の間のゼロETL インテグレーションを作成して管理できます。Oracle マルチテナントアーキテクチャを使用している場合は、特定のプラガブルデータベース (PDB) を選択してそれらを選択的に複製できます。さらに、特定のテーブルを選択し、必要に応じてレプリケーションをカスタマイズできます。 RDS for Oracle Zero-ETL と Redshift との統合は Oracle Database バージョン 19c で利用できます。詳細については、Amazon RDS と Amazon Redshift のドキュメントを参照してください。

AWS Blogs

Amazon Web Services ブログ (日本語)

AWS Cloud Financial Management

AWS Cloud Operations Blog

AWS Big Data Blog

AWS Compute Blog

Containers

Artificial Intelligence

AWS for M&E Blog

Networking & Content Delivery

AWS Security Blog

AWS Storage Blog

Open Source Project

AWS CLI