タグアーカイブ EC2

AWSが低コストなEC2 T8iインスタンスを発表!T3比で最大70%の性能向上

AWSが低コストなEC2 T8iインスタンスを発表!T3比で最大70%の性能向上

AWSが新型の低コストバースト可能インスタンス「Amazon EC2 T8i」の一般提供を開始した。T3インスタンスの後継となるもので、価格性能比が最大30%改善している。

T8iはカスタム設計された第6世代Intel Xeon Scalable Processorを搭載し、AWSのNitro System上で動作する。既存のT3ユーザーは同じCPUクレジット方式のまま移行できる設計だ。

T8iインスタンスの位置づけ

T8iインスタンスの位置づけ

EC2のTシリーズは「バースト可能インスタンス」と呼ばれる。平時はベースライン性能で動作し、負荷が上がった時にCPUクレジットを消費して性能を一時的に引き上げる仕組みを持っている。

この仕組みが適しているのは、普段はCPU使用率が低いが瞬間的に負荷が上がるワークロードだ。低トラフィックのWebサイト、開発・テスト環境、小規模データベース、マイクロサービス、ログインゲートウェイなどが代表例になる。

T3時代の課題(Before)
T3インスタンス 旧世代のCPU・最大5Gbpsのネットワーク帯域
コストは安いが、負荷が集中する場面で性能不足を感じるケースがあった
↓
T8i導入後の改善(After)
T8iインスタンス 新型CPU・最大6.25Gbpsのネットワーク帯域・EBS帯域2.4倍
同じバーストモデルのまま、価格性能比が最大30%改善

T8iはこのバーストモデルを踏襲しつつ、CPUとネットワーク性能を大幅に引き上げたモデルだ。

性能向上の内訳

性能向上の内訳

価格性能比とコンピューティング性能

AWSの発表によると、T8iはT3と比較して以下の改善が実現されている。

  • 価格性能比が最大30%向上
  • コンピューティング性能が最大70%向上
  • ネットワーク帯域が最大1.25倍
  • EBS帯域が最大2.4倍

特にEBS帯域の2.4倍という数字は見逃せない。ディスクI/Oがボトルネックになりがちな小規模データベースやデータ処理ジョブでは、体感できる改善が期待できる。

性能改善の度合い
コンピューティング 最大70%向上
ネットワーク帯域 最大1.25倍
EBS帯域 最大2.4倍
価格性能比 最大30%改善
■ コンピューティング ■ ネットワーク ■ ストレージ ■ 価格性能比

CPUクレジット方式と無制限モード

T8iはT3と同じCPUクレジット方式を採用している。StandardとUnlimitedの2つのモードがあり、デフォルトはUnlimitedモードだ。Unlimitedモードではクレジット残高がゼロになっても、追加料金を支払うことでベースラインを超える性能を維持できる。

クレジットは時間の経過とともに自動で蓄積される。例えばt8i.microなら1時間に6クレジット、t8i.smallなら12クレジットが付与される仕組みだ。

インスタンスタイプとスペック

インスタンスタイプとスペック

T8iは4つのサイズで提供される。すべて2 vCPUを1コアとして提供するのが特徴で、vCPUとメモリの比率が他シリーズにはない特殊な構成になっている。

  • t8i.nano
  • t8i.micro
  • t8i.small
  • t8i.medium
T8iインスタンスのラインナップ
t8i.nano 0.25GiBメモリ・ベースライン5%・3クレジット/時
t8i.micro 0.5GiBメモリ・ベースライン10%・6クレジット/時
t8i.small 1GiBメモリ・ベースライン20%・12クレジット/時
t8i.medium 2GiBメモリ・ベースライン20%・12クレジット/時
■ nano ■ micro ■ small ■ medium

メモリ比率はnanoが1対0.25、microが1対0.5、smallが1対1、mediumが1対1となっている。2 vCPUでメモリ0.25GiBという構成は他のEC2インスタンスにはない特徴的なスペックだ。

利用シーンと移行方法

利用シーンと移行方法

どんな場面で使うべきか

T8iは低〜中程度のCPU使用率で動くワークロードに向いている。具体的には以下のようなケースが想定されている。

  • フリーミアムサービスの小規模プラン
  • トレーニング・デモ環境
  • ステージング・開発環境
  • データ処理ジョブ
  • マイクロサービスアーキテクチャの一部
  • 低トラフィックのWebサイト
  • ログインゲートウェイ
  • バッチ処理やCI/CDパイプライン

常に高いCPU使用率が続く本番環境や、大規模なデータベースサーバーには向かない。そうした用途ではM8i Flexなど、より大きなインスタンスの選択が推奨されている。

T3からの移行手順

既存のT3ユーザーにとって移行はシンプルだ。インスタンスタイプをT3からT8iに変更するだけで、アプリケーションの設定変更やコードの書き換えは原則不要とされている。

STEP 1 現在のT3インスタンスを停止
↓
STEP 2 インスタンスタイプをT8iに変更
↓
STEP 3 インスタンスを起動して動作確認
↓
STEP 4 性能向上を確認して本番利用へ

CPUクレジット方式もT3と同じなので、運用ノウハウはそのまま活かせる。Auto ScalingやCloudWatchの設定も流用できるため、移行コストは最小限だ。

提供リージョンと利用方法

提供リージョンと利用方法

T8iは以下のAWSリージョンで利用できる。

  • 米国東部(バージニア北部・オハイオ)
  • 米国西部(オレゴン・北カリフォルニア)
  • アジアパシフィック(ハイデラバード・マレーシア・ムンバイ・ソウル・シンガポール・シドニー・東京)
  • カナダ(中部)
  • ヨーロッパ(フランクフルト・アイルランド・ロンドン・パリ)

購入方法はオンデマンドとスポットインスタンスに対応している。Savings Planは近日対応予定だ。t8i.microとt8i.smallはAWS無料利用枠でも使えるため、新規ユーザーがAWSの使い方を学ぶ用途にも適している。

共有テナンシーのみ対応しており、専有テナンシーや専有ホストは利用できない点には注意が必要だ。

この記事のポイント

  • T8iはT3の後継となる低コストバースト可能インスタンス
  • コンピューティング性能が最大70%向上し、EBS帯域は2.4倍に
  • CPUクレジット方式はT3と同じで移行が容易
  • 4サイズ構成で東京リージョンでも利用可能
  • 無料利用枠の対象サイズもあり、新規ユーザーの入門にも適している
AWS Graviton5搭載のEC2 R9gが一般提供開始。R8g比で最大25%の性能向上

AWS Graviton5搭載のEC2 R9gが一般提供開始。R8g比で最大25%の性能向上

AWSがGraviton5プロセッサを搭載したEC2 R9gとR9gdインスタンスを一般提供開始した。メモリ最適化インスタンスの新世代で、R8gと比較してコンピュート性能が最大25%向上している。

Graviton5はDDR5メモリの高速化、L3キャッシュの5倍拡大、ネットワーク帯域幅の最大2倍化など、複数のハードウェア改良を備える。データベースやインメモリキャッシュなどメモリ集約型のワークロードで効果が大きい。

この記事ではR9gの技術的な変更点、インスタンススペック、移行手順、利用可能リージョンを解説する。

Graviton5がもたらす性能向上の全容

Graviton5がもたらす性能向上の全容

Graviton5プロセッサはGraviton4から複数のハードウェア改良が加えられた。まずコンピュート性能がvCPUあたり最大25%向上している。これは命令処理の効率化と高クロック動作によるものだ。またAWSがこれまでに構築した中で最もエネルギー効率の高いプロセッサでもある。

従来のR8gインスタンス(Graviton4)
コンピュート性能 基準値
メモリ DDR5 5600 MT/s
L3キャッシュ 標準サイズ
ネットワーク帯域幅 最大50 Gbps
EBS帯域幅 最大36 Gbps
↓
新しいR9gインスタンス(Graviton5)
コンピュート性能 最大25%向上
メモリ DDR5 8800 MT/s
L3キャッシュ 5倍拡大
ネットワーク帯域幅 最大100 Gbps
EBS帯域幅 最大72 Gbps
※48xlargeサイズでの比較。ネットワークとEBS帯域幅は最大値。

このデモはGraviton4(R8g)とGraviton5(R9g)の主要スペックを比較している。特にL3キャッシュの5倍拡大とメモリ帯域の高速化がデータ処理の遅延低減に効く。

メモリとキャッシュの大幅強化

メモリはDDR5 8800 MT/sに対応した。Graviton4の5600 MT/sから大幅に高速化されており、AWSのクラウド上で利用可能な最速のメモリ帯域を実現している。これは大量のデータを扱うインメモリキャッシュ・データベースにとって応答時間の短縮に直結する。

L3キャッシュも5倍に拡大された。L3キャッシュとはCPU内部にある高速なメモリ領域で、頻繁にアクセスするデータを一時的に保持する役割を持つ。この容量が増えると、主メモリへのアクセス回数が減り、データ処理の遅延が小さくなる。データ局所性が高いワークロードほど恩恵を受けやすい。

ネットワーク帯域幅とパケット処理の改善

ネットワーク帯域幅とAmazon EBSの帯域幅は、最大サイズのインスタンスで最大2倍に向上した。48xlargeではネットワークが最大100 Gbps、EBSが最大72 Gbpsに達する。またパケット処理性能は最大3倍に改善されている。

さらにR9gとR9gdはInstance Bandwidth Configuration(IBC)に対応している。これはEBSとネットワークの帯域配分を25%単位で調整できる機能だ。データベースやキャッシュなど、帯域要件が特定方向に偏るワークロードで性能を最適化できる。例えばネットワーク処理が少なくディスクI/Oが多いワークロードでは、帯域をEBS側に寄せるといった調整が可能になる。

Nitro Isolation Engineによるセキュリティ強化

Nitro Isolation Engineによるセキュリティ強化

すべてのR9gとR9gdインスタンスはAWS Nitro System上で動作する。Nitro Systemは仮想化、ストレージ、ネットワークを専用ハードウェアにオフロードする仕組みだ。これにより仮想マシンのオーバーヘッドが減り、ベアメタルに近い性能と強固なセキュリティ分離を両立できる。

R9gとR9gdにはNitro Isolation Engine(NIE)が搭載されている。NIEはC9gとM9gで今年前半に導入されたコンポーネントで、仮想マシン間の分離を強制する役割を担う。仮想マシンのメモリ、CPUレジスタ状態、I/Oデバイスへのすべてのアクセスを最小限のAPIセットで仲介する。

仮想マシンA 独立して動作
仮想マシンB 独立して動作
↓
Nitro Isolation Engine メモリ・CPU・I/Oアクセスを仲介
↓
Nitro System 専用ハードウェア 仮想化・ストレージ・ネットワークを処理
※NIEがすべてのアクセスを仲介することで、仮想マシン間の分離を保証する。

このデモはNIEが仮想マシンとハードウェアの間に位置し、すべてのアクセスを仲介する関係を示している。分離の保証はソフトウェア的な工夫ではなく、形式的な数学証明によって裏付けられている点が特徴だ。

NIEの特徴は形式検証(formal verification)という手法を活用している点にある。これはハードウェアやソフトウェアが意図通りに動作することを数学的に証明する手法だ。特定のテストケースだけでなく、あらゆる条件下で正しく動作することを保証する。この取り組みにより、Nitroはクラウドハイパーバイザーとして初めて形式検証を受けた存在になった。

形式検証の対象範囲や前提条件などの詳細はAWSのテクニカルホワイトペーパーで公開されている。セキュリティ要件が厳しい金融系ワークロードやマルチテナント環境を扱う場合には、このホワイトペーパーを参照してリスク評価に役立てるとよい。

R9gとR9gdのインスタンススペック

R9gとR9gdのインスタンススペック

R9gとR9gdはそれぞれ11サイズで提供される。最小のmediumから最大のmetal-48xlまで、幅広い要件に対応する。以下では2つの違いを中心に説明する。

R9gインスタンス
EBSストレージのみ使用
データベースやキャッシュに最適
最大192 vCPU / 1536 GiBメモリ
R9gdインスタンス
ローカルNVMe SSDを搭載
低レイテンシの一時ストレージが必要な用途に最適
最大192 vCPU / 1536 GiBメモリ / 11.4 TB NVMe
※どちらも同じコンピュート性能とネットワーク性能を持つ。ストレージ構成のみ異なる。

このデモはR9gとR9gdの違いを整理している。NVMe SSDの有無が唯一の差で、用途に応じて選べる。

R9gのスペック

R9gはEBSストレージのみを使用する構成だ。最小のr9g.mediumは1 vCPUと8 GiBメモリ、最大のr9g.48xlargeとr9g.metal-48xlは192 vCPUと1536 GiBメモリを搭載する。ネットワーク帯域幅はmediumから2xlargeまで最大15 Gbps、8xlargeで17 Gbps、12xlargeで25 Gbps、16xlargeで34 Gbps、24xlargeで50 Gbps、48xlargeで100 Gbpsに達する。

EBS帯域幅はmediumから4xlargeまで最大12 Gbps、8xlargeで12 Gbps、12xlargeで18 Gbps、16xlargeで24 Gbps、24xlargeで36 Gbps、48xlargeで72 Gbpsとなっている。データベース用途ではEBS帯域幅が性能のボトルネックになりやすいため、サイズ選定の際はこの値にも注目したい。

R9gdのNVMeストレージ

R9gdはR9gと同じコンピュート性能とネットワーク性能を持ちながら、ローカルNVMe SSDを搭載している。mediumでは59 GB、largeで118 GB、xlargeで237 GBとサイズに応じて容量が増える。最大のr9gd.48xlargeでは3台の3800 GB NVMe SSD(合計11.4 TB)を備える。

ローカルNVMe SSDはEBSと比べてレイテンシが低く、一時的なスクラッチ領域やキャッシュ用途に向いている。オープンソースデータベース、分散リアルタイムビッグデータ分析、大規模インメモリデータベース、大容量キャッシュワークロードで効果を発揮する。

R8gからの移行と始め方

R8gからの移行と始め方

R8gで運用中のワークロードがある場合、R9gへの移行はシンプルだ。多くのアプリケーションでコード変更は不要。同等サイズのR9gインスタンスを選択すれば、そのままより高い性能を得られる。

STEP 1 R8gインスタンスを運行中か確認
↓
STEP 2 同等サイズのR9gインスタンスを選択
↓
STEP 3 Arm64対応のAMIから起動
↓
STEP 4 アプリケーションを実行して性能を確認
※多くのアプリケーションではコード変更不要。Arm64対応イメージを使えばそのまま動作する。

このデモはR8gからR9gへの移行手順を4ステップで示している。インスタンスタイプを変更するだけで性能が向上するケースが多い。

対応OSとコンテナ環境

R9gはAmazon Linux 2023、Amazon Linux 2、Ubuntu 22.04以降、RHEL 8.4以降、SUSE Linux Enterprise Server 15 SP3以降、Debian 12以降など主要なLinuxディストリビューションに対応する。EC2コンソールからArmベースのAMIを選択すれば、すぐに起動できる。

コンテナワークロードではAmazon EKS、Amazon ECS、標準的なKubernetes環境で動作する。Arm64向けにビルドされたマルチアーキテクチャのコンテナイメージなら変更なしで動く。Dockerイメージをマルチアーキテクチャ対応にしておくと、x86からArmへの移行がスムーズになる。

移行を支援するツール

AWSはGravitonへの移行を支援する複数のリソースを提供している。Graviton Getting Started Guideは構築、実行、最適化の方法をまとめたガイドだ。Graviton Savings Dashboardではコスト削減効果を追跡できる。AWS TransformはJavaアプリケーションをx86からGraviton向けに変換するコード変換を自動化するツールだ。

Javaアプリケーションの場合、依存ライブラリにネイティブコードが含まれているとArm64への移行が難しいことがある。AWS Transformはこうしたコード変換を自動化して移行の手間を減らす。まず小規模なワークロードで試し、問題がないことを確認してから本番移行に進むのが現実的な進め方だ。

料金と利用可能リージョン

料金と利用可能リージョン

R9gとR9gdは米国東部(バージニア北部、オハイオ)、米国西部(オレゴン)、欧州(フランクフルト)の各リージョンで利用できる。日本国内のリージョン(アジアパシフィック東京)では現時点で提供されておらず、今後の展開が待たれる。

購入オプションはSavings Plans、On-Demand、Spot Instances、Dedicated Instances、Dedicated Hostsから選択可能だ。長期運用する場合はSavings Plans、一時的なバッチ処理やテスト用途ではSpot Instancesがコスト効率に優れる。料金の詳細はAmazon EC2の料金ページで確認できる。

インスタンスサイズや購入オプションによって価格が異なるため、ワークロードに合わせて最適な組み合わせを選ぶことが重要だ。特にR8gと比較した場合、同じサイズでも性能が向上しているため、より小さなサイズに移行してコストを削減できる可能性もある。

この記事のポイント

  • AWS Graviton5搭載のEC2 R9gとR9gdが一般提供を開始した
  • R8g比でコンピュート性能が最大25%向上し、エネルギー効率も改善
  • DDR5 8800 MT/sメモリとL3キャッシュ5倍拡大でデータ処理が高速化
  • Nitro Isolation Engineにより形式検証されたセキュリティ分離を実現
  • R9gはEBSのみ、R9gdはローカルNVMe SSDを搭載した構成
  • R8gからの移行はコード変更不要のケースが多く、Arm64対応イメージでそのまま動作
AWS Graviton5搭載EC2 C9gインスタンスが一般提供開始

AWS Graviton5搭載EC2 C9gインスタンスが一般提供開始

計算負荷の高いワークロードを扱う企業にとって、「もう少しだけ処理が速ければ」という場面は多い。AWSが6月30日に発表したEC2 C9g/C9gdインスタンスは、その不満を根本から解決する新世代の計算特化型インスタンスだ。Graviton5プロセッサの投入により、前世代からvCPUあたり最大25%の性能向上を実現した。今回の発表で特に注目すべきは、クラウド最速級となるDDR5-8800MT/sメモリの採用と、正式検証済みのハイパーバイザー分離エンジン「Nitro Isolation Engine」の搭載だ。本記事では、CPU負荷の高いバッチ処理や動画エンコーディングを中心に、新しいインスタンスがどのような場面で威力を発揮するのかを詳しく解説する。

C9g/C9gdインスタンスの位置づけを見極める

C9g/C9gdインスタンスの位置づけを見極める

AWSのEC2には多様なインスタンスファミリーが存在する。頭文字の「C」はCompute Optimized(計算最適化)を意味し、他のメモリ最適化(Rシリーズ)やストレージ最適化(Iシリーズ)とは設計思想が異なる。計算最適化インスタンスは、vCPUあたりの演算性能を最大化することに特化している。リアルタイム分析、機械学習の推論、動画エンコーディングなど、1秒でも短く計算を終えたい処理に適している。

今回発表されたC9g/C9gdは、2024年秋に登場したGraviton4搭載C8gの後継にあたる。AWS GravitonシリーズはArmベースの独自プロセッサで、x86系のIntel XeonやAMD EPYCと比較して、コストパフォーマンスに優れる点が強みだ。C9gの「g」はGravitonを示し、末尾に「d」がつくC9gdはNVMe SSDによる高速なローカルストレージを内蔵する。

Graviton5プロセッサの進化点を知る

Graviton5の最大の改良点は、メモリ帯域幅の拡張とレイテンシの低減にある。C9gインスタンスはDDR5-8800MT/sのDIMMを採用し、これは現在クラウド上で提供されているプロセッサインスタンスの中で最速のメモリ速度だ。数字だけでは実感しにくいが、これはメモリとCPU間のデータ転送速度が秒間8800メガトランスファー(MT/s)ということを意味する。前世代のC8gがDDR5-5600MT/sだったため、実に57%もの速度向上にあたる。

さらに、CPUのL3キャッシュ容量が5倍に拡張された。キャッシュはCPUとメインメモリの間に位置する超高速なデータ置き場で、容量が大きいほどメモリアクセスの待ち時間を減らせる。AWS News Blogの著者Seb氏によると、これらの改善により、インメモリ分析のスループット向上や、より応答性の高いエージェント型AIループが期待できるという。

ネットワーク面でも強化が施されている。パケット処理性能はGraviton4ベースのインスタンスと比較して最大3倍に向上し、インスタンスサイズ全体の平均でネットワーク帯域が約15%、EBS帯域が約20%増加した。

C9g/C9gdの主要スペック詳細と設計思想

C9g/C9gdの主要スペック詳細と設計思想

スペック表を見ると、C9g/C9gdは最小のmedium(1vCPU/2GBメモリ)から、最大のmetal-48xl(192vCPU/384GBメモリ)まで11サイズで展開される。48xlargeではネットワーク帯域が100Gbps、EBS帯域が72Gbpsに達し、これは前世代の2倍にあたる。大規模な分散処理やリアルタイム分析基盤において、ネットワークがボトルネックになる状況を回避しやすくなるだろう。

C9gdシリーズには、ローカルのNVMe SSDストレージが追加される。容量は最小のmediumで59GB、最大の48xlargeでは3台合計で11,400GB(3×3,800GB)に達する。NVMe SSDはEBSよりもレイテンシが低いため、以下のような用途に適している。

  • HPCシミュレーションのスクラッチスペース(一時的な作業領域)
  • 機械学習推論の一時キャッシュ
  • アドサーバーのローカルバッファ

ストレージ性能も向上しており、ローカルストレージのパフォーマンスは前世代比で約30%向上した。NVMe経由の詳細なI/Oパフォーマンス統計はCloudWatchやnvme-cli経由で取得可能で、I/Oサイズ別のレイテンシヒストグラムが1秒単位で確認できる。この機能は追加料金なしで利用できる。

Instance Bandwidth Configurationの実用性を測る

C9g/C9gdには、Instance Bandwidth Configuration(IBC)と呼ばれる帯域調整機能が搭載されている。これは、EBSとVPCネットワークの帯域配分を最大25%の範囲で調整できる仕組みだ。例えば、データベースやキャッシュ用途でEBSの帯域を優先したい場合、ネットワーク側を絞ってEBS側に割り当てを寄せることが可能になる。逆に、ネットワーク集約型の分散処理ではVPC側を優先すればよい。固定的な割り当てに縛られない柔軟性は、実運用のチューニングで大きな武器になる。

C9gとC9gdの使い分けフローを整理する

C9gとC9gdはスペックが似ているため、どちらを選ぶべきか迷う場面があるだろう。選択の決め手は「ローカルのNVMe SSDが必要かどうか」に尽きる。AWS News Blogでは、C9gを「バッチジョブ、動画エンコードパイプライン、分散分析」向け、C9gdを「HPCシミュレーションのスクラッチスペース、ML推論の一時キャッシュ、アドサーバーのローカルバッファ」向けとしている。EBSで十分な永続ストレージが足りるならC9g、一時的でも高速なローカルストレージが不可欠ならC9gdを選べばよい。

C9g を選ぶケース
EBS の永続ストレージで十分な場合
バッチジョブ 動画エンコード 分散分析
↓
C9gd を選ぶケース
高速なローカル NVMe SSD が必要な場合
HPC スクラッチ ML 推論キャッシュ アドサーバー
C9g と C9gd の選択フローは「ローカル NVMe SSD の要否」で分岐する

Graviton5がもたらすエージェント型AIへの適性を読み解く

Graviton5がもたらすエージェント型AIへの適性を読み解く

AWS News Blogの発表では、C9gのワークロード例として「エージェント型AI(agentic AI)」が明記されている。エージェント型AIとは、単なる質問応答を超えて、コードを実行し、複数ステップのタスクを自律的に組み立てて完了させるAIシステムを指す。OpenAIのOperatorやAnthropicのComputer Useが代表例だ。

この種のワークロードでは、大規模言語モデル(LLM)の推論そのものに加えて、Pythonコードの実行、API呼び出し、結果の検証といったCPUバウンドな処理が連続的に発生する。Graviton5のコア数向上と大容量キャッシュは、こうした「思考と行動のループ」を高速化する土台となる。AWSの著者Seb氏によれば、アプリケーションがデータを待つ時間を削減し、結果的にエージェントループの応答性が高まるとのことだ。

AI推論といえばGPUの印象が強いが、実際には前処理、後処理、オーケストレーションの多くがCPU上で動く。ArmベースのGraviton5は、これらの処理を低コストでさばける点が実務的な魅力となる。

Nitro Isolation Engineのセキュリティ強化を理解する

Nitro Isolation Engineのセキュリティ強化を理解する

C9g/C9gdは、計算最適化インスタンスとして初めて「Nitro Isolation Engine」を搭載した。これはAWS Nitro Systemの拡張機能で、仮想マシン間のメモリ空間、CPUレジスタ状態、I/Oデバイスへのアクセスを数学的正確さで強制的に分離する仕組みだ。

通常、ハイパーバイザーによる分離はソフトウェアの実装品質に依存する部分があるが、Nitro Isolation Engineは形式検証(formal verification)と呼ばれる数学的手法を用いて分離の正しさを証明している。形式検証とは、仕様を数理論理で記述し、実装がその仕様を厳密に満たすことを機械的に検証する手法だ。テストのように「見つかったバグがない」ではなく、「特定の前提条件下でバグが存在し得ない」ことを保証する。

AWSは2025年にこの技術を発表した際、ハイパーバイザーの分離を形式検証する取り組みについてホワイトペーパーを公開している。今回のC9g/C9gdで初めて、計算最適化インスタンスに実装されたことになる。

セキュリティ要件の厳しい金融サービスや医療データの分析をEC2上で行うケースでは、この正式検証済みの分離機構はインフラ選定の重要な判断材料になる。ソフトウェアレベルではなく、ハードウェア支援と形式検証の組み合わせで隔離を実現している点は、AWSの設計思想として特筆に値する。

利用可能リージョンと料金モデルを確認する

利用可能リージョンと料金モデルを確認する

2026年6月30日時点で、C9g/C9gdは米国東部(オハイオ、バージニア北部)、米国西部(オレゴン)、欧州(フランクフルト)の4リージョンで利用可能だ。AWSは追加リージョンへの展開も予定している。

料金モデルはSavings Plans、オンデマンド、スポットインスタンス、Dedicated Instances、Dedicated Hostsに対応する。常時稼働させるワークロードではSavings Plans、短期的なバッチ処理ではスポットインスタンスと使い分けられる。EBSボリュームは仮想インスタンス1台あたり最大128個までアタッチ可能で、大規模データの処理でもストレージ不足に悩むことは少ない。

インスタンスの起動はAWSマネジメントコンソール、AWS CLI、AWS SDKのいずれからでも可能だ。GravitonはArmアーキテクチャのため、AMIやコンテナイメージはArm向けにビルドされたものを選ぶ必要がある。公式のAmazon Linux 2023やUbuntuのArm版AMIはすでに提供されているため、新規導入時の障壁は低い。

この記事のポイント

  • C9g/C9gdはGraviton5搭載の計算最適化インスタンス、vCPUあたり25%の性能向上を達成
  • DDR5-8800MT/sメモリと5倍のL3キャッシュにより、メモリ待ち時間を大幅に削減
  • 48xlargeでは100Gbpsネットワーク帯域と72GbpsのEBS帯域、前世代比2倍に拡張
  • Nitro Isolation Engine搭載、形式検証による仮想マシン分離を実現
  • エージェント型AIやHPC、動画エンコードなどCPU負荷の高い処理に最適
AWS Graviton5搭載EC2 M9g/M9gdがGA。汎用インスタンス性能限界突破の全容

AWS Graviton5搭載EC2 M9g/M9gdがGA。汎用インスタンス性能限界突破の全容

AWSが2026年6月10日、Graviton5プロセッサを搭載したEC2 M9gおよびM9gdインスタンスの一般提供を開始した。Armアーキテクチャベースの第5世代カスタムシリコンであり、前世代比で最大25%の計算性能向上を実現したとされている。

2025年末のプレビュー公開から半年、ClickHouseやHoneycombといった企業が実運用環境で検証を重ね、コード変更ゼロで36%の性能向上を確認している。HubSpotではMySQLデータベースのクエリ処理時間が最大60%短縮されたとの報告もある。

Arm系インスタンスはこれまでも存在したが、192コア、5倍のL3キャッシュ、DDR5-8800対応メモリを搭載したGraviton5は次元が異なる。本記事ではM9g/M9gdの技術的進化と、それがビジネスにどう影響するかを具体的に解説する。

Graviton5とは何か。5世代の進化がもたらしたもの

AWSのGravitonプロセッサは、Armアーキテクチャを採用したAWS独自設計のカスタムシリコンだ。第1世代が登場したのは2018年。以来8年にわたり継続的に投資が続けられ、現在では350以上のインスタンスタイプがGravitonで稼働している。

Arm系クラウドインスタンスの現在地

Armアーキテクチャとは、スマートフォンやタブレットで広く使われている省電力設計のCPU命令セットだ。これに対し、従来のサーバCPUの多くはx86アーキテクチャ(IntelやAMDが採用)で動作していた。Armは消費電力あたりの処理効率に優れており、クラウドの大規模データセンターで電気代を抑えつつ高性能を発揮できる点が評価されている。

AWS広報情報によれば、現在12万以上の顧客がGravitonを採用。スタートアップから大企業まで幅広く、Webアプリケーション、マイクロサービス、データベース、機械学習推論、ゲームサーバ、動画エンコーディングなど多様な用途で使われている。x86依存の強い従来のクラウド常識を、Armが着実に塗り替えつつある。

従来のクラウド選択肢(5年前)
x86系 Intel / AMD がほぼ独占
※Armは選択肢として存在せず
↓
現在のクラウド選択肢(Graviton5登場後)
x86系 従来通り利用可
Arm系 Graviton5 で性能・省電力両立

クラウドインスタンスの選択肢は、この5年で一変した。Armはもはや「実験的な選択肢」ではなく、x86と並ぶ本流の一つとして位置づけられる。特にGraviton5では、その傾向がさらに加速するだろう。

Graviton5が前世代から飛躍した3つの要素

Graviton5の改良点を、AWS公式発表から整理する。最も注目すべきは次の3つだ。

  • 計算性能の大幅向上:Graviton4比で最大25%の計算性能向上。Webアプリケーションで最大35%、機械学習推論で最大35%、データベースで最大30%の高速化が実測されている
  • 5倍のL3キャッシュ:CPUが頻繁にアクセスするデータを一時保存する高速メモリ領域が前世代比5倍に拡大。コア間のデータ待ち時間が最大33%削減された
  • DDR5-8800メモリとPCIe Gen6対応:クラウド上のプロセッサインスタンスとして最速水準のメモリ帯域幅を実現。PCIe Gen6はGen5比でデータ転送速度が2倍となり、NVMeストレージや高速ネットワークとの連携性能が飛躍的に伸びる

L3キャッシュの増量は、単なる数値スペックの向上ではない。CPUは計算のたびにメインメモリまでデータを取りに行くと時間がかかる。L3キャッシュが大きければ近くにデータを置けるため、処理待ちが減り、結果として体感性能が大きく向上する仕組みだ。

実際にAWSの広報記事で紹介された顧客事例では、ClickHouseがコード変更なしでM8g比36%の性能向上を達成。Honeycombは6カ月にわたるA/Bテストで、コアあたりのスループットが36%向上したと報告している。これらの数字は、CPUそのものの改良がアプリケーションレベルで直接的な効果を生むことを示している。

M9g/M9gdのラインアップと性能スペック

インスタンスサイズと性能の詳細

M9gは汎用用途向けで、1vCPUあたり4GiBのメモリ比率を採用している。M9gdはこれに加え、高速ローカルNVMe SSDストレージを搭載したバリエーションだ。ラインアップは1vCPUの小規模構成から、192vCPU・768GiBメモリの大規模構成まで幅広く用意されている。

M9g 汎用タイプ
1〜192 vCPU 4〜768 GiB RAM 最大100 Gbps NW
Webアプリ、マイクロサービス、コンテナ、Java大規模アプリに好適
↓
M9gd ローカルNVMe搭載タイプ
1〜192 vCPU 59GB〜11.4TB SSD IOPS 30%向上
キャッシュ、メディア処理、バッチ処理、一時ストレージ用途に好適

最大サイズの48xlarge(192vCPU)では、ネットワーク帯域が100Gbpsに達する。前世代比で最大2倍の帯域幅になっており、大量のデータを扱うデータベースやログ処理基盤での効果が特に大きい。

IBC(Instance Bandwidth Configuration)の実用性

M9g/M9gdでは、IBC(インスタンス帯域幅設定)と呼ばれる新機能が利用可能になった。これはEBS(永続ストレージ)とVPCネットワーク間で、帯域幅の配分を最大25%調整できる仕組みだ。

IBC未使用時(デフォルト配分)
EBS帯域 50%
データベース書き込み速度が制限される
VPC帯域 50%
ネットワーク通信には十分
↓
IBC使用時(DB重視に調整、最大25%シフト)
EBS帯域 62.5%
データベース書き込みが高速化
VPC帯域 37.5%
ネットワーク通信には依然十分

たとえばデータベースサーバではEBSへの書き込み性能がボトルネックになりやすい。IBCを使えばEBS側に帯域を多めに割り当て、クエリ処理やログ書き込みを高速化できる。ネットワーク通信が少ないバッチ処理やキャッシュサーバでも有効だ。

Nitro Isolation Engineが実現する「数学的に証明されたセキュリティ」

Graviton5と同時に発表された技術の中で、最も静かでありながら最も革新的なものがNitro Isolation Engineだ。聞き慣れない用語だが、クラウドセキュリティの考え方を根本から変える可能性がある。

形式検証(Formal Verification)とは何か

通常、ソフトウェアのセキュリティは「テスト」で検証する。攻撃パターンを想定し、実際に動かして問題がないかを確認する手法だ。しかしこの方法では、想定外の攻撃や未知の脆弱性を見逃すリスクが常に残る。

形式検証(Formal Verification)はこれとは根本的に異なる。数学の定理証明と同じアプローチで、「このシステムは絶対に想定外の動作をしない」ことを数理的に証明する技術だ。特定のテストケースだけでなく、あらゆる入力パターンで期待通りに動作することを保証する。

AWSによれば、Nitro Isolation Engineはこの形式検証を適用したクラウドハイパーバイザーとして業界初の事例となる。ハイパーバイザーとは、1台の物理サーバ上で複数の仮想マシンを安全に隔離する基盤ソフトウェアだ。この隔離機能が破られると、他の顧客のデータにアクセスされる重大なセキュリティ事故につながる。Nitro Isolation Engineは、その隔離が破られる可能性を数学的にゼロにする設計となっている。

従来のセキュリティ検証 対 形式検証
従来のテストベース検証
「考えられる攻撃」を列挙し、それらが失敗することを確認。想定外の攻撃は見逃す可能性あり
形式検証(Nitro Isolation Engine)
数学的に「あらゆる入力・あらゆる状況で隔離が破れない」ことを証明。未知の攻撃にも原理的に耐性

この技術は金融機関や医療機関など、厳格なデータ保護が求められる業界にとって特に重要な意味を持つ。セキュリティ監査のレベルが一段引き上げられることになるからだ。なおNitro Isolation EngineはM9g/M9gd専用の機能であり、既存のインスタンスタイプには搭載されない。

エージェントAI時代のCPU需要とGraviton5の位置づけ

AIが「考える」から「行動する」へのシフト

ここ数年、AIの進化は大規模言語モデル(LLM)のテキスト生成能力に注目が集まってきた。しかし現在、AIの主戦場は「質問に答える」から「行動を実行する」へと急速に移行している。いわゆるエージェントAIと呼ばれる分野だ。

エージェントAIとは、ユーザーの指示に対して、コードを実行し、ツールを使い、結果を評価し、複数ステップのタスクを自律的に組み立てるAIシステムを指す。たとえば「今月の売上データを分析してグラフ化し、経営陣向けのサマリをSlackに投稿して」という指示に対し、AIがデータベースに接続し、集計処理を実行し、グラフを生成し、メッセージを送信する一連の流れを自律的に処理する。

このような処理は、GPUなどのアクセラレータだけで完結しない。指示の解釈、コードのコンパイル、データベースクエリの実行、APIの呼び出しなど、CPUに依存する処理が大量に発生する。AWSの広報記事で、MetaがエージェントAI基盤として数千万コア規模のGravitonを導入していると報告されているのは、このトレンドを象徴している。

エージェントAIの処理フローとCPU需要
STEP 1 ユーザー指示の解釈
自然言語の解析、意図の抽出。CPUが実行
↓
STEP 2 コード生成と実行
PythonやSQLのコードを生成し、実際に実行。CPU負荷が高い
↓
STEP 3 ツール操作と結果評価
API呼び出し、データベース接続、結果の検証。並列処理が発生

エージェントAIが実用段階に入るにつれ、クラウド上のCPU需要はむしろ増大する。Graviton5が192コアという高密度設計を採用したのは、こうした並列処理ニーズを先取りしたものといえる。

Web開発者にとっての実務的意味

中小企業のWeb担当者や個人事業主にとって、「エージェントAI」や「192コア」という言葉は遠い世界に感じられるかもしれない。しかし実際には、以下のような形でM9gの恩恵は身近な領域に及ぶ。

  • MySQL/PostgreSQLの応答速度向上:HubSpotの事例ではクエリ時間が最大60%短縮。WordPressサイトやECサイトのデータベース応答が高速化する可能性がある
  • コスト効率の改善:Graviton5はGraviton4比でエネルギー効率も向上。同じ処理をより少ない電力で実行できるため、ランニングコストの削減につながる
  • セキュリティの底上げ:Nitro Isolation Engineによる隔離保証は、顧客データを扱うあらゆるサービスに恩恵がある

重要なのは、これらの恩恵がコード変更ゼロで得られるケースが多い点だ。ClickHouseやHoneycombの報告にあるように、Armネイティブ対応が済んでいるアプリケーションであれば、インスタンスタイプをM8gからM9gに変更するだけで性能向上が見込める。

M9g/M9gdへの移行を検討する際の実践ステップ

Graviton5インスタンスの利用を始めるには、いくつかの準備と確認が必要だ。AWS公式が提供する移行ガイドやツールを活用すれば、想定よりスムーズに移行できる。

Arm対応状況の確認と移行パス

最初に行うべきは、現在稼働中のアプリケーションがArmアーキテクチャに対応しているかの確認だ。Java、Python、Node.js、Go、PHPなど主要な言語ランタイムはすでにArm対応が完了している。ただし、x86固有のアセンブリコードを含むC/C++プログラムや、特定のx86向けバイナリに依存しているアプリケーションでは注意が必要になる。

Graviton移行の3ステップ
ステップ1:対応状況の確認
言語ランタイム、依存ライブラリ、DockerイメージがArm対応か確認。AWS公式のGetting Started Guideを参照
ステップ2:テスト環境での検証
小規模なM9gインスタンスでワークロードを試験運用。性能と安定性を確認
ステップ3:本番移行とコスト最適化
Savings Plansの活用、Graviton Savings Dashboardでのコスト効果測定を並行実施

Javaアプリケーションの場合、AWSが提供する「AWS Transform」というAI支援サービスが利用できる。x86用にコンパイルされたJavaアプリケーションをArm向けに自動変換し、互換性分析や依存関係の更新まで処理するツールだ。コードの書き換えが必要なケースでも、変換作業の多くを自動化できる。

コスト面の評価ポイント

M9g/M9gdは、Savings Plans、オンデマンド、スポットインスタンス、Dedicated Hostsのいずれでも購入可能だ。一般にGraviton系インスタンスはx86系より低価格に設定されており、さらにSavings Plansを組み合わせることで長期利用時のコストを大幅に抑えられる。

AWS公式が提供する「Graviton Savings Dashboard」を使えば、Graviton移行によるコスト削減効果を可視化できる。費用対効果を数字で把握しながら、段階的に移行を進めるのが実務的なアプローチだ。

この記事のポイント

  • AWS Graviton5搭載M9g/M9gdが一般提供開始。前世代Graviton4比で最大25%の計算性能向上
  • ClickHouseで36%、HubSpotのMySQLクエリで最大60%の高速化を実測。コード変更不要のケースが多い
  • Nitro Isolation Engineにより、形式検証を用いた数学的に証明されたVM隔離をクラウドで初めて実現
  • エージェントAIの普及でCPU需要が急増する中、192コアの高密度設計が新たな計算基盤として台頭
  • 移行にはArm対応状況の確認から段階的に進めるのが安全。AWS TransformやSavings Dashboardが支援ツールとして利用可能
AWS最新動向(5月11日週) Bedrock AgentCoreの支払い機能とAgent Toolkitを解説

AWS最新動向(5月11日週) Bedrock AgentCoreの支払い機能とAgent Toolkitを解説

2026年5月11日の週、AWSはAIエージェントの自律的な動作を根本から変える発表を相次いで行った。最も注目すべきは、Amazon Bedrock AgentCoreがエージェント自身による支払い機能のプレビューを開始したことだ。これによりAIエージェントはAPIや外部サービスの利用料を自ら決済し、実行タスクに必要なリソースを動的に調達できるようになる。

AWS News Blogの著者であるChanny Yun氏が執筆した週次ラウンドアップによれば、この支払い機能はCoinbaseおよびStripeとの提携で構築された。さらに、AIコーディングエージェント向けの「Agent Toolkit for AWS」や、エージェントにデスクトップ環境を提供する「WorkSpaces for AI agents」も発表されている。本記事ではこれらの新機能を技術面とビジネスインパクトの両面から分析する。

Amazon Bedrock AgentCoreの支払い機能が示す「エージェント経済圏」の到来

Amazon Bedrock AgentCoreの支払い機能が示す「エージェント経済圏」の到来

AIエージェントが「考える」だけでなく「支払う」時代が来た。Amazon Bedrock AgentCoreにプレビューとして追加された支払い管理機能は、エージェントがAPI、MCPサーバー、Webコンテンツ、さらには他のエージェントの利用料を自律的に支払うことを可能にする。これは単なる便利機能ではない。エージェントが経済活動の主体になるための第一歩といえる。

従来のエージェント(Before)
エージェントが有料APIに遭遇
↓
決済手段がないためタスク中断
↓
AgentCore Payments導入後(After)
エージェントが有料APIに遭遇
↓
予算枠内で自動決済しタスク続行

この図が示すように、従来は有料サービスへのアクセスがエージェントのボトルネックだった。AgentCore Paymentsによってその制約が取り払われる。

CoinbaseとStripeとの提携が意味するもの

AWSはこの支払い基盤を単独で構築しなかった。暗号資産ウォレットのCoinbase(CDP Wallet)と決済プラットフォームのStripe(Privy Wallet)という、まったく異なる決済レイヤーの企業と提携している。Coinbase連携によりオンチェーン決済が可能になり、Stripe連携は従来型の法定通貨決済をカバーする。この二段構えが示唆するのは、AWSが特定の決済手段に依存せず、マルチペイメントレイヤーのエコシステムを目指しているということだ。

セッション単位の支出制限とガバナンス設計

エージェントに支払い権限を与えると聞いて、真っ先に浮かぶ懸念は「使いすぎ」や「不正利用」だろう。AWSはこの点をセッションレベルの支出制限で対策している。開発者はエージェントの実行セッションごとに予算上限を設定でき、その範囲内でのみ決済が実行される。企業の与信管理と同じ考え方をエージェント単位に落とし込んだ設計だ。

さらに、認証情報管理とコンプライアンス対応も組み込まれている。各エージェントは決済手段に直接アクセスするのではなく、事前に登録されたウォレット接続を通じて取引を実行する。AWSのIAM(Identity and Access Management)に似た権限管理の考え方が、支払い領域にも適用された形だ。

エージェント経済圏が実務にもたらす変化

Channy Yun氏がブログ記事で最も興奮していると述べたポイントは、この機能が解き放つユースケースの広がりだ。たとえば、リサーチエージェントがリアルタイムの市場データを動的に購入して分析に組み込む、あるいはコーディングエージェントがタスク実行中に有料APIを呼び出して機能を補完する、といった動作が実現する。

これはクラウドの従量課金モデルをエージェント自身が直接操作できるようになることを意味する。開発者はあらかじめすべてのAPI契約を整備する必要がなくなり、エージェントが実行時に必要なリソースを判断して調達する。インフラ構築の手間が一段階抽象化されるわけだ。

Agent Toolkit for AWSが実現する「AI時代のインフラ構築」

Agent Toolkit for AWSが実現する「AI時代のインフラ構築」

AgentCore Paymentsと並んで注目を集めたのが、AIコーディングエージェント向けの「Agent Toolkit for AWS」の発表だ。これはエージェントがAWS上で構築作業を行う際のエラー削減、トークンコスト低減、エンタープライズグレードのセキュリティ制御を実現する本番環境向けツールスイートである。追加料金なしで利用できる。

AWS MCPサーバーの一般提供とAgent Toolkitの関係

Agent Toolkitの中核コンポーネントとして、AWS MCP Serverが一般提供(GA)に移行した。MCP(Model Context Protocol)サーバーは、AIエージェントやコーディングアシスタントがAWSの全サービスに対して安全かつ認証付きでアクセスするためのマネージドなリモートサーバーだ。少数の固定ツールセットを通じて、複雑なAWS APIを抽象化する。

端的にいえば、エージェントに「AWS全体への安全なアクセス権」を渡す仕組みである。従来は開発者がIAMポリシーやAPIキーを個別に設定し、エージェントに渡す必要があった。MCPサーバーを使えば、これが統合認証のレイヤーで一元管理される。

ツールキットがエンジニアのワークフローをどう変えるか

Agent Toolkitは、これまでAWS Labsで提供されていたMCPサーバーやプラグイン、スキルの後継に位置づけられる。実験段階から本番利用への移行を意図した製品だ。具体的には以下の3つの価値を提供する。

  • エラー削減: エージェントがAWSリソースを操作する際の設定ミスや権限違反を減らす
  • トークンコスト低減: 最小限のツール呼び出しで済むよう最適化され、LLMのAPI利用料を抑える
  • セキュリティ制御: 企業のセキュリティポリシーに準拠したアクセス制御を適用できる

開発者にとっては、AIエージェントに「AWSの操作方法」を一から教え込む必要がなくなる点が大きい。ツールキットが提供するスキルとプラグインを組み込むだけで、エージェントはAWSリソースのプロビジョニングや監視、トラブルシューティングを標準化された方法で実行できる。

AIエージェントにデスクトップを提供するWorkSpacesの狙い

AIエージェントにデスクトップを提供するWorkSpacesの狙い

プレビューとして発表された「Amazon WorkSpaces for AI agents」は、一見すると奇妙な機能に思える。AIエージェントが仮想デスクトップを使うとはどういうことか。狙いは、エージェントにGUIアプリケーションを操作させることにある。

従来の自動化(Before)
APIがあるアプリだけ自動化可能
↓
レガシーGUIアプリは自動化の対象外
↓
WorkSpaces for AI agents導入後(After)
エージェントが仮想デスクトップ上でGUIを操作
↓
レガシーアプリも含めた全社ワークフローを自動化

多くの企業には、Web APIを持たない古い業務アプリケーションが残っている。WorkSpaces for AI agentsは、エージェントがこうしたGUIアプリケーションの画面を認識し、クリックやキー入力をエミュレートすることで、人間のオペレーターと同じ操作を実行できるようにする。

セキュリティ面では、エージェント専用のマネージドWorkSpaces環境が割り当てられ、エンタープライズグレードのガバナンスとコンプライアンスを維持したまま動作する。企業が長年抱えてきた「API化できない業務の自動化」という課題に対する、AWSなりの回答といえる。

第6世代Intel搭載の新型EC2インスタンスがもたらす性能向上

第6世代Intel搭載の新型EC2インスタンスがもたらす性能向上

AI関連の発表に隠れがちだが、基盤となるコンピュートリソースにも重要なアップデートがあった。Amazon EC2のM8idn/M8idbおよびR8idn/R8idbインスタンスが発表されたのだ。これらはAWS専用にカスタマイズされた第6世代Intel Xeon Scalableプロセッサと、最新の第6世代AWS Nitroカードを搭載する。

vCPUあたり最大43%の性能向上

発表データによれば、前世代インスタンスと比較してvCPUあたりのコンピュート性能が最大43%向上している。この数字は単なるベンチマーク上の改善ではない。同じコストでより多くのワークロードを処理できることを意味する。

ネットワーク帯域とEBS帯域の強化

インスタンスタイプによって提供されるネットワーク性能も明確に差別化されている。M8idn/R8idnは最大600Gbpsのネットワーク帯域を提供し、M8idb/R8idbは最大300GbpsのEBS(Elastic Block Store)帯域に対応する。前者はネットワーク集約型ワークロードに、後者はストレージI/Oが重要なデータベースや分析ワークロードに最適化されている。

実務的には、機械学習のトレーニングデータを高速に読み込む必要があるケースや、大規模な分散データベースを運用するケースで効果を発揮する。M8idnとR8idnの選択肢が増えたことで、ワークロード特性に応じた細かいインスタンス選定が可能になった。

ValkeyとS3 Vectorsに見るデータ基盤の「ベクトル化」と「オープン化」

ValkeyとS3 Vectorsに見るデータ基盤の「ベクトル化」と「オープン化」

5月11日の週には、データ基盤に関する注目すべき動きもあった。OSS(オープンソースソフトウェア)のキーバリューストアであるValkeyが2周年を迎え、Amazon S3 VectorsとAurora PostgreSQLの統合に関する詳細なガイドが公開された。

Valkeyの急成長が証明するコミュニティ駆動開発の強さ

AWSのデータベースブログが報じたところによれば、ValkeyはDocker Pull数が1億を突破し、前年比17倍という急成長を遂げた。225人以上のコントリビューターが1,500以上のプルリクエストを提出しており、これは同期間におけるRedisの開発ペースの約2倍に相当する。

この数字が示すのは、単一ベンダー主導の開発モデルよりも、オープンでコミュニティ駆動の開発の方が速く、広範囲にイノベーションを起こせるという事実だ。Valkey 9.0はすでにAmazon ElastiCacheでも利用可能になっており、マネージドサービスとしての利便性とOSSの革新性を両立させている。

10億スケールのベクトル検索をSQLで

Aurora PostgreSQLからS3 Vectorsを標準SQLでクエリできるようになったことも見逃せない。具体的には、ベクトル類似度検索の結果とリレーショナルフィルタを1つのSQL文で組み合わせられる。たとえば、「意味的に最も類似した商品を検索し、その中から価格や在庫状況で絞り込む」といったクエリが単一ステートメントで完結する。

これはベクトルデータベース専用のクエリ言語を習得する必要がなくなることを意味する。すでにSQLを使いこなしているエンジニアであれば、追加学習なしでベクトル検索を業務に組み込める。データ基盤の民主化という観点から、非常に実用的なアップデートだ。

この記事のポイント

  • Amazon Bedrock AgentCoreに支払い管理機能が追加され、AIエージェントが自律的にAPIやサービスの利用料を決済できるようになった
  • Agent Toolkit for AWSが発表され、AIコーディングエージェントのエラー削減やトークンコスト低減を実現する
  • WorkSpaces for AI agentsのプレビュー開始により、レガシーGUIアプリケーションの自動化が現実的になった
  • 新型EC2インスタンスはvCPUあたり最大43%の性能向上を達成し、ネットワーク帯域とEBS帯域も強化された
  • Valkeyの成長とS3 VectorsのSQL統合は、データ基盤のオープン化とベクトル検索の民主化が加速していることを示している