2025/9/16 9:00:00 ~ 2025/9/17 9:00:00 (JST)

最近の発表

Amazon EKS introduces a new catalog of community add-ons in the AWS GovCloud (US) Regions

本日、Amazon Elastic Kubernetes Service (EKS) は、メトリクスサーバー、キューブステートメトリクス、証明書マネージャー、プロメテウスノードエクスポーター、フルーエントビット、および外部DNSを含むコミュニティアドオンの新しいカタログを発表しました。これにより、人気の高いオープンソース Kubernetes アドオンを EKS から直接簡単に検索、選択、設定、管理できるようになります。各アドオンは、EKS が所有するプライベート Amazon Elastic Container Registry (ECR) リポジトリにコンテナイメージが安全にホストされ、EKS によってパッケージ化され、スキャンされ、互換性が検証されています。\n Kubernetes クラスターを本番環境で使用できるようにするには、さまざまな運用ツールとアドオンを統合する必要があります。これらのアドオンは、AWS やオープンソースのコミュニティリポジトリなど、さまざまなソースから提供されている可能性があります。EKS では、さまざまなアドオンに簡単にアクセスできるようになり、AWS アドオンとコミュニティアドオンを一元的に管理できるようになりました。EKS コンソール、API、CLI、eksctl、または AWS CloudFormation などの IaC ツールを使用して、利用可能なアドオン、互換性のあるバージョン、設定オプションを表示し、それらを直接インストールして管理できます。 この機能はすべての AWS GovCloud (米国) リージョンで利用できます。詳細については、EKS のドキュメントをご覧ください。

Amazon EC2 I7i instances now available in South America (São Paulo), Canada West (Calgary) regions

アマゾンウェブサービス (AWS) は、AWS 南米 (サンパウロ)、カナダ西部 (カルガリー) リージョンで高性能ストレージ最適化 Amazon EC2 i7i インスタンスが利用可能になったことを発表しました。これらの新しいインスタンスは、3.2 GHz のオールコアターボ周波数の 5 世代 Intel Xeon Scalable プロセッサを搭載し、前世代の i4i インスタンスに比べて、コンピューティングパフォーマンスが最大 23% 向上し、価格パフォーマンスが 10% 以上向上しています。第 3 世代 AWS Nitro SSD を搭載した i7i インスタンスは、最大 45 TB の NVMe ストレージを提供し、i4i インスタンスと比較して、リアルタイムストレージパフォーマンスが最大 50% 向上し、ストレージ I/O レイテンシーが最大 50% 低くなり、ストレージ I/O レイテンシーの変動が最大 60% 低くなります。\n I7i インスタンスは、Amazon EC2 の x86 ベースのストレージ最適化インスタンスとして最高のコンピューティングおよびストレージパフォーマンスを提供します。小～中サイズのデータセット (マルチ TB) にアクセスするために、リアルタイムのレイテンシーを伴う非常に高いランダム IOPS パフォーマンスを必要とする、I/O 集約型でレイテンシーの影響を受けやすいワークロードに最適です。さらに、破れた書き込み防止機能は最大 16 KB のブロックサイズをサポートしているため、お客様はデータベースパフォーマンスのボトルネックを解消できます。 i7i インスタンスには 11 種類のサイズ (最大 48xlarge の 9 つの仮想サイズ、2 つのベアメタルサイズ) が用意されており、最大 100 Gbps のネットワーク帯域幅と 60 Gbps の Amazon Elastic Block Store (EBS) 帯域幅を実現します。 詳細については、i7i インスタンスページをご覧ください。

Amazon Lex provides generative AI based enhanced natural language understanding in eight new languages

Amazon Lex では、中国語、日本語、韓国語、ポルトガル語、カタロニア語、フランス語、イタリア語、ドイツ語の 8 つの新しい言語で、大規模言語モデル (LLM) を活用して、決定論的な会話 AI ボットの自然言語理解を向上させることができるようになりました。この機能により、音声ボットやチャットボットは複雑な発話をより適切に処理し、スペルミスがあっても正確さを保ち、冗長な入力から重要な情報を抽出して顧客の要求に応えることができます。たとえば、顧客が「こんにちは、妻と2人の子供、そして自分のためにフライトを予約したいです」と言うと、LLMは4人分の航空券を適切に識別して予約します。\n この機能は、Amazon Connect を利用できる 10 の商用 AWS リージョン (ヨーロッパ (アイルランド)、ヨーロッパ (フランクフルト)、米国東部 (バージニア北部)、アジアパシフィック (ソウル)、ヨーロッパ (ロンドン)、アジアパシフィック (東京)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、カナダ (セントラル) で利用できます。この機能の詳細については、Amazon Lex のドキュメントをご覧ください。また、Amazon Connect と Amazon Lex がコンタクトセンターにクラウドベースの会話型 AI エクスペリエンスを提供する方法については、Amazon Connect のウェブサイトをご覧ください。

New fault action in AWS FIS to inject I/O latency on Amazon EBS volumes

本日、Amazon EBS は、障害注入実験を実行するための完全マネージド型サービスである AWS Fault Injection Service (FIS) の新しいレイテンシー注入アクションを発表しました。ミッションクリティカルなアプリケーションがストレージ障害にどのように反応するかを理解するための統制テストの一環として、このアクションを使用してボリュームに I/O レイテンシーを注入できるようになりました。新しいフォールトアクションでは、ストレージレイテンシーが上昇してもアーキテクチャをテストできるため、アプリケーションの動作を観察し、監視と復旧のプロセスを微調整して高可用性を確保できます。\n EBS ボリュームは、Oracle、SAP HANA、Microsoft SQL Server など、可用性が高くレイテンシーの影響を受けやすいアプリケーションのニーズを満たすように設計されています。レイテンシーインジェクションアクションは、ストレージのパフォーマンスに問題があるときに発生する Amazon CloudWatch アラームやオペレーティングシステムのタイムアウトなどの実際の信号を再現して、ボリュームの I/O パフォーマンスの低下をシミュレートします。このアクションを使用すると、EBS ボリュームの I/O レイテンシーが高くなるような中断にアプリケーションが耐え、迅速に復旧できるという確信を得ることができます。まず、EBS および FIS コンソールにある事前定義済みのレイテンシー注入実験テンプレートを直接使用できます。また、これらの実験テンプレートをカスタマイズしたり、アプリケーション固有のテストニーズに合わせて独自の実験テンプレートを作成したりすることもできます。これらのレイテンシー注入実験は、既存のカオスエンジニアリングテスト、継続的インテグレーション、リリーステストに統合できるほか、複数の FIS アクションを 1 つの実験にまとめることができます。 この新しいアクションは、AWS FIS が利用可能なすべての AWS リージョンで利用できます。詳細については、EBS FIS アクションユーザーガイドをご覧ください。

Amazon EC2 supports detailed performance stats on all NVMe local volumes

本日、Amazon は Amazon EC2 インスタンスストア NVMe ボリュームの詳細なパフォーマンス統計の提供を発表しました。この新機能により、AWS Nitro System ベースの EC2 インスタンスストア NVMe ボリュームのパフォーマンスをリアルタイムで可視化できるため、ストレージの状態を簡単に監視し、アプリケーションパフォーマンスの問題を迅速に解決できます。\n EC2 の詳細なパフォーマンス統計を使用すると、11 の包括的なメトリクスに 1 秒単位でアクセスして、キュー長の測定、IOPS、スループット、詳細な I/O レイテンシーヒストグラムなど、ローカルに接続された NVMe ボリュームの入出力 (I/O) 統計をモニタリングできます。これらのメトリクスは EBS ボリュームの詳細なパフォーマンス統計に似ており、どちらのストレージタイプでも一貫したモニタリングが可能です。これらのメトリックスによってきめ細かな可視性が得られるため、パフォーマンスの変動の影響を受ける特定のワークロードを特定し、アプリケーションの IO パターンを最適化して効率を最大化できます。さらに、メトリクスには IO サイズごとに分類されたレイテンシーヒストグラムが含まれているため、パフォーマンスパターンに関するより詳細なインサイトが得られます。 EC2 インスタンスストア NVMe ボリュームの詳細なパフォーマンス統計は、すべての AWS 商用地域と中国地域で NVMe ボリュームがローカルにアタッチされたすべての Nitro ベースの EC2 インスタンスについて、デフォルトで追加料金なしで利用できます。

EC2 インスタンスストア NVMe の詳細なパフォーマンス統計とそのアクセス方法の詳細については、こちらのドキュメントをご覧ください。

Amazon AppStream 2.0 adds support for fractional GPU instances

本日、Amazon AppStream 2.0 は、GPU サイズが細分化された Graphics G6 インスタンスのサポートを発表しました。これは EC2 G6 ファミリー上に構築されており、より小さい GPU 端数を必要とするグラフィックアプリケーションに対応するように設計されています。\n GPU サイズが細分化された Graphics G6 インスタンス (G6f と Gr6f) では、ユーザーは完全な GPU インスタンスをプロビジョニングするのではなく、必要な GPU リソースのみを利用できます。このアプローチにより、GPU 容量を共有することでリソースの最適化が改善され、特定のワークロード要件に合わせて、より小さい GPU フラクション (1/2、1/4、1/8 など) を柔軟に選択できます。組織は、GPU の全機能を必要としないアプリケーションでも GPU 機能へのアクセスを維持しながら、オーバープロビジョニングを回避することで、コスト削減の恩恵を受けることができます。 これらの新しいインスタンスタイプは、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、カナダ (中部)、ヨーロッパ (フランクフルト、ロンドン)、アジア太平洋 (東京、ムンバイ、シドニー)、南米 (サンパウロ) を含む 10 の AWS リージョンで利用できます。AppStream 2.0 は従量課金制です。詳細については、「Amazon AppStream 2.0 料金表」を参照してください。 まず、イメージビルダーの起動時または新しいフリートを作成するときに、GPU サイズが分割された AppStream 2.0 Graphics G6 インスタンスを選択してください。Graphics G6 インスタンスは、AWS マネジメントコンソールまたは AWS SDK を使用して分割された GPU サイズで起動できます。詳細については、「AppStream 2.0 インスタンスファミリー」を参照してください。

AWS Storage Gateway now supports IPv6

AWS Storage Gateway は、AWS Storage Gateway エンドポイント、API、およびゲートウェイアプライアンスインターフェイスのインターネットプロトコルバージョン 6 (IPv6) サポートを発表しました。この強化により、IPv6 と IPv4 の両方から新しいデュアルスタックのエンドポイントにアクセスできるようになります。IPv4 のみをサポートする既存の AWS Storage Gateway エンドポイントは、後方互換性のため引き続き使用できます。\n AWS Storage Gateway では、AWS ストレージに保存されているデータにオンプレミスでアクセスできます。今回のローンチにより、お客様は IPv4 クライアントとの下位互換性を維持しながら、IPv6 で AWS Storage Gateway リソースを管理するためのアプリケーションとワークフローを標準化できます。Storage Gateway アプライアンス、サービスエンドポイント、API の新しいデュアルスタック機能を使用することで、お客様はすべてのネットワークを一度に切り替える必要なく、IPv4 から IPv6 に徐々に移行できます。 AWS Storage Gateway の IPv6 サポートは、サービスが提供されているすべての AWS リージョンで利用できます。詳細については、AWS Storage Gateway ユーザーガイドをご覧ください。

Amazon Aurora PostgreSQL Limitless Database is now available in the AWS GovCloud (US-East, US-West) Regions

Aurora PostgreSQL Limitless Database が AWS GovCloud (米国東部、米国西部) リージョンで利用できるようになりました。単一データベースのトランザクションの一貫性を維持しながら、データやクエリを複数の Amazon Aurora Serverless インスタンスに自動的に分散するサーバーレスエンドポイントを提供することで、リレーショナルデータベースのワークロードを簡単にスケーリングできます。Aurora PostgreSQL Limitless Database は、分散クエリプランニングやトランザクション管理などの機能を備えているため、カスタムソリューションを作成したり、複数のデータベースを管理してスケーリングしたりする必要がありません。Aurora PostgreSQL Limitless Database は、ワークロードが増えるにつれて、指定された予算内でコンピューティングリソースを追加できるため、ピーク時にプロビジョニングする必要がなく、需要が低くなるとコンピューティングが自動的にスケールダウンします。\n Aurora PostgreSQL リミットレスデータベースは、これらのリージョンで PostgreSQL 16.6、16.8、16.9 との互換性を維持して利用できます。 料金の詳細と利用可能なリージョンについては、Amazon Aurora 料金表をご覧ください。詳細については、Aurora PostgreSQL 無制限データベースのドキュメントを読み、Amazon RDS コンソールのわずか数ステップで Aurora PostgreSQL 無制限データベースを作成することから始めましょう。

Amazon S3 now supports conditional deletes in S3 general purpose buckets

Amazon S3 は S3 汎用バケットの条件付き削除をサポートするようになりました。これにより、オブジェクトが変更されていないことを確認してから削除できます。これにより、同時実行頻度が高く、複数の書き込みがあるシナリオで誤って削除されるのを防ぐことができます。\n HTTP if-match ヘッダーに ETag 値を指定して条件付き削除を実行できるようになりました。Amazon S3 では、指定された Etag がオブジェクトの Etag と一致する場合のみ、削除リクエストが成功します。さらに、S3 バケットポリシーで s3: if-match 条件キーを使用して、条件付き削除オペレーションを適用できます。たとえば、S3 DeleteObject API リクエストと S3 DeleteObjects API リクエストの両方で HTTP if-match ヘッダーを使用するようクライアントに要求できます。これにより、バケット内のオブジェクトを誤って削除してしまうリスクを最小限に抑えることができます。 条件付き削除は、すべての AWS リージョンで S3 汎用バケットで追加料金なしで利用できます。Amazon S3 API、SDK、CLI を使用して条件付き削除を実行できます。詳細については、S3 ユーザーガイドをご覧ください。

Amazon EC2 R8i and R8i-flex instances are now available in additional regions

本日より、Amazon Elastic Compute Cloud (Amazon EC2) の R8i インスタンスと R8i-Flex インスタンスは、アジアパシフィック (マレーシア、シンガポール) およびヨーロッパ (フランクフルト) リージョンでご利用いただけます。これらのインスタンスは AWS でのみ利用可能なカスタム Intel Xeon 6 プロセッサを搭載しており、クラウドで同等の Intel プロセッサの中で最高のパフォーマンスと最速のメモリ帯域幅を提供します。R8i インスタンスと R8i-Flex インスタンスは、前世代の Intel ベースのインスタンスと比較して、コストパフォーマンスが最大 15% 向上し、メモリ帯域幅が 2.5 倍も増えています。R7i インスタンスよりも 20% 優れたパフォーマンスを提供し、特定のワークロードではさらに大きなメリットが得られます。R7i と比較して、PostgreSQL データベースでは最大 30%、NGINX ウェブアプリケーションでは最大 60%、AI ディープラーニングレコメンデーションモデルでは最大 40% 高速です。\n 当社初のメモリ最適化された Flex インスタンスである R8i-Flex は、メモリを大量に消費するワークロードの大半でコストパフォーマンスのメリットを得る最も簡単な方法です。Large から 16 xlarge までの最も一般的なサイズがあり、すべてのコンピューティングリソースを十分に活用していないアプリケーションには最適な選択肢です。 R8i インスタンスは、メモリを大量に消費するすべてのワークロード、特に最大のインスタンスサイズや継続的に高い CPU 使用率を必要とするワークロードに最適です。R8i インスタンスには、2 つのベアメタルを含む 13 のサイズと、大規模アプリケーション向けの新しい 96xlarge サイズがあります。R8i インスタンスは SAP 認定を受けており、オンプレミスとクラウド環境にある同等のマシンの中で最高 142,100 台の ASAP を提供し、ミッションクリティカルな SAP ワークロードに優れたパフォーマンスを提供します。 開始するには、AWS マネジメントコンソールにサインインしてください。お客様は貯蓄プラン、オンデマンドインスタンス、スポットインスタンスを通じてこれらのインスタンスを購入できます。新しい R8i および R8i-Flex インスタンスの詳細については、AWS ニュースブログをご覧ください。

AWS Transfer Family is now available in AWS Asia Pacific (Taipei) region

AWS アジアパシフィック (台北) リージョンのお客様は、セキュアファイル転送プロトコル (SFTP)、ファイル転送プロトコル (FTP)、FTP over SSL (FTPS)、および適用性ステートメント 2 (AS2) を介したファイル転送に AWS Transfer Family を使用できるようになりました。\n AWS 転送ファミリーは、SFTP、FTP、FTPS、AS2 プロトコルを介して、アマゾンシンプルストレージサービス (Amazon S3) とアマゾンエラスティックファイルシステム (Amazon EFS) 向けに、フルマネージド型のファイル転送を提供します。Transfer Family では、ファイル転送に加えて、マネージドファイル転送 (MFT) ワークフローの一般的なファイル処理とイベント駆動型の自動化が可能になり、お客様が企業間ファイル転送を最新化して AWS に移行できるよう支援します。 AWS Transfer Family の詳細については、製品ページとユーザーガイドをご覧ください。リージョンの提供状況の詳細については、AWS リージョン表をご覧ください。

Amazon OpenSearch Service announces Star-Tree Index

OpenSearchはスターツリーインデックスを導入しました。これは、カーディナリティの高いクエリや多次元クエリの集計パフォーマンスを大幅に向上させる新機能です。このインデックスは、設定されたディメンションや指標のデータを取り込み時に事前に集計するため、用語、ヒストグラム、範囲などの頻繁な集計でも 1 秒以内の応答時間が可能になります。\n Star-Tree Index はリアルタイム分析用に設計されており、クエリ構文を変更する必要はありません。OpenSearch は、サポートされているクエリが検出されると、自動的に最適化されたパスを使用します。初期のベンチマークでは、大規模なデータセットの集計パフォーマンスが速いことが示されています。そのため、オブザーバビリティ、パーソナライゼーション、時系列ダッシュボードなどのユースケースに最適です。追加のみのデータで最適に機能し、取り込みスループットへの影響を最小限に抑えながら、セグメントの更新/マージ中にビルドを行います。 スターツリーインデックスは OpenSearch 3.1 がサポートされているすべてのリージョンで利用できます。この機能はオプトインで、複合インデックス設定を使用してインデックスの作成時に有効にできます。 Amazon OpenSearch サービスの可用性に関する詳細については、AWS 地域サービスリストを参照してください。スターツリーインデックスの詳細については、OpenSearch ドキュメントを参照してください。

Amazon OpenSearch Service announces Derived Source for storage optimization

Amazon OpenSearch Service では、OpenSearch Service ドメインに必要なストレージ量を削減するのに役立つ新機能である派生ソースのサポートが導入されました。派生ソースのサポートにより、ソースフィールドを保存する必要がなく、必要に応じて動的に派生させることができます。 \n OpenSearch は、取り込まれた各ドキュメントを _source フィールドに保存し、検索用に個々のフィールドにもインデックスを付けます。_source フィールドはストレージ容量を大量に消費する可能性があります。ストレージの使用量を減らすには、_source フィールドの保存を省略し、検索、get、mget、再インデックス、更新操作などに必要なときに動的に再構築するように OpenSearch を設定できます。 派生ソースは OpenSearch 3.1 がサポートされているすべてのリージョンで利用できます。この機能はオプトインで、複合インデックス設定を使用してインデックスの作成時に有効にできます。 Amazon OpenSearch サービスの可用性に関する詳細については、AWS 地域サービスリストを参照してください。派生ソースの詳細については、OpenSearch のドキュメントを参照してください。

AWS Blogs

Amazon Web Services ブログ (日本語)

AWS Big Data Blog

Containers

Artificial Intelligence

AWS Security Blog

Open Source Project

AWS CLI

Amplify for iOS