2026/9/11 9:00:00 ~ 2026/9/14 9:00:00 (JST)

最近の発表

Amazon EC2 X2idn instances are now available in Asia Pacific (Hong Kong)

メモリ最適化された Amazon Elastic Compute Cloud (Amazon EC2) X2IDN インスタンスが、アジアパシフィック (香港) リージョンで利用できるようになりました。これらのインスタンスは、第 3 世代の Intel Xeon スケーラブルプロセッサを搭載し、AWS Nitro System で構築されており、メモリを大量に消費するワークロード向けに設計されており、前世代の X1 インスタンスと比較してパフォーマンスが向上しています。これらのインスタンスは、HANA でビジネススイート、SAP S/4HANA、HANA でデータマートソリューション、HANA でビジネスウェアハウス、SAP BW/4HANA、SAP NetWeaver ワークロードを任意のデータベースで実行することについて SAP 認定を受けています。

Amazon SageMaker HyperPod now supports model caching for faster inference autoscaling and reduced cold starts

Amazon SageMaker HyperPod はモデルキャッシュをサポートするようになりました。これは、モデルの重みとコンテナイメージをクラスターノードにあらかじめロードする推論最適化であり、ポッドは数分ではなく数秒で起動します。\n チャットアシスタント、エージェントパイプライン、RAG、文書分析などのワークロードで LLM 推論を大規模に実行する場合、コールドスタートが大きなボトルネックになります。デプロイメントやスケールアウトイベントでは、ほとんどの時間をコンテナイメージとモデルウェイトのダウンロードに費やします。モデルのサイズが大きくなるにつれて、この状況はさらに悪化し、大規模なモデルがトラフィックを処理できるようになるまでに数十分かかります。

モデルキャッシュは、2 つの独立した機能によってこの問題を解決します。ウェイトキャッシュはモデルのウェイトをローカル NVMe に保存するので、ポッドはネットワーク経由で S3 や FSx からデータを取得するのではなく、高速なローカルストレージから読み取ることができます。イメージキャッシュはコンテナイメージを事前にプルするので、ポッドは ECR のダウンロードを完全にスキップできます。ポッドがウォームキャッシュのないノードに着地した場合、自動的に元のソースからのプルに戻るため、ポッドが動かなくなったり障害が発生したりするリスクはありません。

57 GB から 145 GB までのモデルのベンチマークでは、スケールアウトが約 60% 速くなり、イメージキャッシュはイメージプル時間を 2 分以上短縮しました (97% 削減)。このメリットは、元のソースパスの信頼性を維持しつつ、モデルのサイズが増すにつれて大きくなります。

お客様は、InferenceEndpointConfig または JumpStartModel リソースに ModelCacheConfig セクションを追加することで、HyperPod 推論オペレーターによるモデルキャッシュを有効にします。オペレーターは手動での設定やクリーンアップなしでライフサイクル全体を処理します。

モデルキャッシュは、SageMaker HyperPod が利用できるすべての地域で一般的に利用できるようになりました。はじめに、SageMaker HyperPod のマニュアルを参照してください。

Amazon Bedrock Managed Knowledge Base now supports multimodal embeddings for video, audio, and image content with TwelveLabs Marengo 3.0

AWSは、Amazon Bedrockマネージドナレッジベースの埋め込みモデルとしてTwelveLabs Marengo 3.0が利用可能になったことを発表しました。これにより、お客様は動画、音声、画像コンテンツのマルチモーダル埋め込みを作成できます。Amazon Bedrock Managed Knowledge Base は、音声と動画をテキストに文字起こしテキストベースの埋め込みを生成することで、メディア検索をすでにサポートしています。Marengo 3.0 はさらに進んで、視覚シーン、音声、動画の手がかりをマルチモーダル埋め込みに直接エンコードし、文字起こしだけではできない意味を捉えています。Amazon S3 などのデータソースからメディアアセットをアップロードし、自然言語で同期、検索するだけで済みます。インフラストラクチャを管理する必要はありません。\n Marengo 3.0 はコンパクトな 512 次元のベクターを生成し、最先端の検索精度を実現します。結果にはセグメントの開始時間と終了時間が含まれるため、アプリケーションは動画内の該当する瞬間に直接ジャンプできます。これにより、ゲーム映像のシーズン全体にわたる特定のプレイを見つけることから、キーワードではなくコンセプト別に講義セグメントを検索することまで、スポーツ分析、メディア/エンターテインメント、セキュリティ、教育、小売の分野にわたるユースケースの開拓が可能になります。このモデルには、コンテンツ構造に合わせて設定可能なセグメンテーションオプションが用意されています。 詳細については、Amazon Bedrock ナレッジベースユーザーガイドの「TwelveLabs Marengo 3.0 埋め込みモデル統合」を参照してください。詳細については、Amazon Bedrock ナレッジベースの製品ページをご覧ください。

AWS HealthOmics now publishes real-time run metrics to Amazon CloudWatch

AWS Healthomics は Amazon CloudWatch にリアルタイムの実行メトリクスを公開するようになり、実行中のワークフローリソースの使用状況を可視化できるようになりました。14 種類の新しい実行メトリックスには、CPU と GPU の使用状況、メモリ使用量、ファイルシステムの使用状況と I/O メトリクス、ネットワークスループット、エフェメラルストレージの使用状況が含まれます。AWS Healthomics は HIPAA の対象となるサービスで、フルマネージド型のバイオインフォマティクスワークフローにより、ヘルスケアやライフサイエンスのお客様が大規模な科学的ブレークスルーを加速できるよう支援します。\n リアルタイム実行メトリクスを使用すると、サポートケースを開かなくても、CPU や GPU のボトルネックの特定、タスクが失敗する前にメモリやストレージの枯渇の検出、ファイルシステムのスループットの追跡を行うことができます。実際の使用量を割り当てられたリソースと比較することで、コンピューティングとストレージの構成をワークフローに合わせて適切なサイズに設定できます。これらのメトリクスは Amazon CloudWatch OpenTelemetry 標準を使用して出力されるため、ネイティブの CloudWatch ダッシュボードやアラームに加えてサードパーティのオブザーバビリティツールと統合できます。

リアルタイム実行メトリクスは、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、ヨーロッパ (フランクフルト、アイルランド、ロンドン)、アジアパシフィック (シンガポール、ソウル、東京) の AWS Healthomics リージョンで利用できるようになりました。詳細については、CloudWatch によるモニタリング実行メトリクスのドキュメントをご覧ください。Amazon CloudWatch は、取り込まれたメトリックスデータの量に基づいてこれらの実行メトリックスに対して課金されます。料金の詳細については、Amazon CloudWatch の料金表をご覧ください。

AWS DevOps Agent adds support for bidirectional Slack communication

AWS DevOps Agent により、エンジニアは AWS、マルチクラウド、オンプレミス環境にわたる本番運用を、調査ライフサイクル全体を Slack 内で直接管理できるようになりました。これまで、オンコールのエンジニアと DevOps チームは、重大度の高いインシデントが発生すると、コミュニケーションプラットフォームと調査プラットフォーム間でコンテキストを切り替える必要があったため、ワークフローが断片化していました。今回の更新により、両方の領域が 1 つの統一された場所に統合され、インシデント対応がすでに行われています。\n エンジニアリングチームは、接続されているどの Slack プライベートチャンネルでも @mentioning AWS DevOps Agent だけで調査を開始し、指揮できるようになりました。チームから提供されたコンテキスト、エージェントの調査結果、推奨アクションなど、すべての調査アクティビティが 1 つのスレッドにまとめられます。AWS リソース、システムメトリックス、アラームステータス、デプロイ履歴、インシデントパターンについて質問することで、重要な瞬間の認知的負荷を軽減し、生産業務を大幅に効率化できます。

この機能は、現在 AWS DevOps Agent がサポートされているすべての商用 AWS リージョンで利用できます。

開始するには、ユーザーガイドをお読みください。リリース履歴ページで AWS DevOps Agent の最新機能をすべて確認してください。

Amazon RDS for Oracle now supports Supplemental Patch Bundle for July 2026 Release Update

Oracle 用 Amazon リレーショナルデータベースサービス (Amazon RDS) は、Oracle データベースバージョン 19c および 26ai の 2026 年 7 月リリースアップデート (RU) 用の補足パッチバンドル (SPB) をサポートするようになりました。 \n 2026 年 4 月のリリース以降、Oracle 空間パッチバンドルの名前は補足パッチバンドル (SPB) に変更されました。SPB には、Oracle Spatial、Oracle Data Pump、Oracle GoldenGate など、特定のユースケース向けにオラクルが推奨する追加のデータベースパッチが含まれています。詳細については、「リリースアップデート (RU)」と「補足パッチバンドル (SPB)」を参照してください。

AWS コンソールの「補足パッチバンドルエンジンバージョン」チェックボックスを選択することで、新しいデータベースインスタンスに補足パッチバンドルの更新を適用したり、既存のインスタンスをエンジンバージョン 19.0.0.0.ru-2026-07.spb-1.r1 または 26.0.0.0.ru-2026-07.spb-1.r1 にアップグレードしたりできます。各エンジンバージョンの Amazon RDS でサポートされている Oracle SPB の詳細については、Amazon RDS for Oracle リリースノートを参照してください。

AWS Organizations のアップグレードロールアウトポリシーを使用して、Amazon RDS データベースインスタンスのマイナーバージョン自動アップグレードを段階的に行うこともできます。この機能により、更新を非本番環境に自動的に適用し、更新を検証し、同じ更新を本番環境に自動的に適用できます。AWS Organizations アップグレードロールアウトポリシーを使用してマイナーバージョン自動アップグレードを行う方法の詳細については、Amazon RDS for Oracle のドキュメントを参照してください。

AWS Blogs

Amazon Web Services ブログ (日本語)

AWS Architecture Blog

AWS Database Blog

AWS for Industries

Artificial Intelligence

AWS Storage Blog

Open Source Project

AWS CLI