2026/8/10 9:00:00 ~ 2026/8/11 9:00:00 (JST)

最近の発表

Amazon GameLift Streams Now Offers Service-managed Shader Caching

Amazon GameLift Streams がアプリケーションのシェーダーキャッシュのキャプチャと配信を管理するようになりました。ストリームセッションからシェーダーキャッシュをキャプチャすると、そのシェーダーキャッシュはストリーミングロケーションの今後のセッションで自動的に利用できるようになります。アプリケーションを変更する必要はありません。\n シェーダーキャッシュをキャプチャすると、セッション中のロード時間や視覚的な途切れを減らすのに役立ちます。サービスマネージドシェーダーキャッシュでは、キャプチャするストリームセッションを指定し、アプリケーションを実行してキャッシュを生成します。その後、Amazon GameLift Streams はキャッシュを互換性のあるストリームグループと場所にレプリケートし、今後のセッションで自動的にロードします。 ListApplicationShaderCaches API または Amazon GameLift Streams コンソールを使用して、シェーダーキャッシュのステータスとストレージサイズをモニタリングできます。この機能は Linux (Ubuntu 22.04)、プロトン、および Windows Server 2022 ランタイムをサポートしています。 各シェーダーキャッシュの最新バージョンのストレージには課金されます。料金の詳細については、Amazon GameLift ストリームの料金表ページをご覧ください。サポートされているリージョンについては、AWS リージョンの表を参照してください。

Amazon EC2 introduces application status checks

Amazon EC2 では、アプリケーションステータスチェックが導入されました。これは、お客様が EC2 インスタンス上のアプリケーションレベルの問題を検出して対応するのに役立つ新しいステータスチェックです。アプリケーションステータスチェックでは、EC2 はアプリケーションを監視して、リクエストの受け付けを停止したウェブサーバー、実行中の Docker デーモン、不適切なネットワーク構成、トラフィックを渡さなくなったネットワークインターフェイスなどの問題を検出します。\n 現在、お客様は EC2 のステータスチェックを利用して、インスタンスや基盤となるシステムにアクセスできない場合にアラートを受け取っています。しかし、アプリケーションの問題を監視するには、お客様は独自の監視ソリューションを構築して維持する必要がありました。現在では、アプリケーションステータスチェックにより、既存の EC2 インスタンスやシステムのステータスチェックと並行して、EC2 インスタンスで実行されているアプリケーションのステータスをモニタリングできます。お客様は、監視するプロトコル、ポート、パス、およびアプリケーションが正常であることを示す応答コードを指定してチェックを作成します。お客様がインスタンス ID またはタグでチェックをインスタンスに関連付けると、Amazon EC2 はそのポートとパスに HTTP または HTTPS リクエストを送信し、60 秒ごとにアプリケーションのステータスを報告します。Auto Scaling グループはアプリケーションのステータスに基づいて動作し、アプリケーションで異常が報告されたらインスタンスを置き換えて復旧を開始します。

アプリケーションステータスチェックは、すべての商用 AWS リージョンと AWS GovCloud (米国) リージョンで利用できます。

アプリケーションステータスチェックを開始して料金を確認するには、Amazon EC2 ユーザーガイドを参照してください。

Amazon OpenSearch Serverless now supports up to 10,000 collections per collection group

次世代の Amazon OpenSearch サーバーレスは、1 つのコレクショングループ内で最大 10,000 個のコレクションをサポートするようになりました。これは、以前の制限である 1,500 個から増加しています。コレクショングループは複数のコレクションを整理し、コレクションが異なる AWS KMS キーで暗号化されている場合でも OpenSearch Compute Unit (OCU) を共有できるようにします。この上限値が高いと、はるかに多くのコレクションを 1 つのコレクショングループに統合し、共有の容量制限の下で管理できます。\n お客様はコレクショングループを使用することで、コレクションレベルのセキュリティとアクセス制御を維持しながら、KMS キーごとに個別の OCU をプロビジョニングするのではなく、多数のコレクションにわたってコンピューティングを共有することでコストを削減できます。顧客のワークロードが増大するにつれて、特にテナントごとにコレクションをプロビジョニングするマルチテナントアプリケーションでは、以前は 1 グループあたり 1,500 コレクションという制限があったため、共有コンピューティングプールからメリットを得られるテナントの数が制限されていました。次世代の Amazon OpenSearch Serverless では、コレクションの上限を 10,000 個に引き上げると、コレクショングループを追加で作成して操作しなくても、これらのワークロードをさらに拡張し、コンピューティング使用率を高め、コレクションあたりのコストを削減できます。この上限は、新規および既存の次世代コレクショングループに自動的に適用されます。

制限の引き上げは、利用可能なすべての AWS リージョンの次世代の Amazon OpenSearch サーバーレスで利用できます。詳細については、Amazon OpenSearch サーバーレスの技術文書とクォータを参照してください。

AWS Elastic Disaster Recovery now preserves UEFI boot mode for Linux servers

AWS Elastic ディザスターリカバリー (AWS DRS) では、UEFI ファームウェアで起動する Linux ソースサーバーを復旧する際に UEFI ブートモードが保持されるようになりました。以前、DRS はこれらの Linux サーバーをレガシー BIOS モードで起動していましたが、復旧後に追加の設定が必要になる可能性がありました。これで、リカバリされた Linux インスタンスは、ソースサーバと同じ UEFI ブートモードで起動します。つまり、復旧インスタンスはソース環境により近い状態になるため、UEFI の起動動作に依存するアプリケーションは、復旧後の追加手順なしで、期待どおりに動作するようになります。ブートモードの保存は自動的に行われ、何も設定する必要はありません。\n この機能は、AWS DRS が提供されているすべての AWS リージョンで、追加料金なしで利用できます。詳細については、AWS Elastic ディザスターリカバリーユーザーガイドをご覧ください。

AWS Blogs

Amazon Web Services ブログ (日本語)

AWS News Blog

AWS Cloud Financial Management

AWS Cloud Operations Blog

AWS Big Data Blog

AWS Compute Blog

AWS Contact Center

AWS Database Blog

AWS DevOps & Developer Productivity Blog

AWS for Industries

Artificial Intelligence

Networking & Content Delivery

AWS Security Blog

Open Source Project

AWS CLI

AWS CDK

Karpenter