Amazon EC2 M9g/M9gdが一般提供開始：Graviton5とNitro Isolation Engineで移行前に確認すべきこと
このテーマをもう少し広げて見るなら、AWS Cost ExplorerのAmazon Qコスト説明とは：異常コスト調査と分けて確認すべきこと と Amazon RDS for SQL Server BYOMとは：既存ライセンス移行で確認すべき料金・地域・制約 も合わせて確認してください。M9g/M9gd検証後の月次費用、予測、異常コストをCost Explorerでどう読むかにつながるため。
3行まとめ
2026年6月10日に、Graviton5搭載のAmazon EC2 M9g/M9gdが一般提供されたと発表されました。
M8g/M8gd比の最大25%、30%、35%という数字は、自社ワークロードの実測値ではありません。
発表時点の提供リージョンは米国東部、米国西部、欧州フランクフルトです。
検証候補に入れる前に、リージョン、料金、Arm64対応、ロールバック計画を確認します。
- AWSは2026年6月10日、AWS Graviton5搭載のAmazon EC2 M9g/M9gdインスタンスを一般提供したと発表しました。M9gはEBS前提の汎用候補、M9gdはローカルNVMe SSDが必要な一時領域や低レイテンシ処理向けの候補です。
- 公式発表では、Graviton4ベースのM8g/M8gd比で最大25%のコンピュート性能向上、データベースで最大30%、Webアプリケーションと機械学習で最大35%高速という主張が示されています。ただし、これは自社ワークロードの実測値ではありません。
- 発表時点の提供リージョンは米国東部、米国西部、欧州フランクフルトです。東京や大阪で使う前提なら、リージョン、料金、Arm64対応、ロールバック計画を確認してから検証候補に入れるのが現実的です。
Amazon EC2 M9g/M9gdは、AWSの新しい汎用インスタンスとして見るだけなら「Graviton5で速くなった」で終わります。けれど、導入側に必要なのはもう少し細かい判断です。いま使っているM8g/M8gdから移すのか、x86系からArmへ移すのか。EBSだけで足りるのか、ローカルNVMeが必要なのか。使いたいリージョンで提供されているのか。購入形態はOn-Demand検証なのか、Savings Plans前提の本番利用なのか。
この記事では、2026年6月11日JST時点で確認したAWS公式情報をもとに、M9g/M9gdを検証候補に入れる前の見方を整理します。Amazon Watch JapanはAmazonおよび関係会社とは非提携の独立サイトです。サービス仕様、料金、提供リージョンは変わり得るため、実際の導入前にはAWS公式ページと自社アカウント上の表示を再確認してください。
何が一般提供になったのか
発表の事実と、自社環境で使えるかどうかは分けて確認します。
AWSの発表で確認できる中心点は、Amazon EC2 M9gとM9gdが、AWS Graviton5プロセッサを搭載した汎用インスタンスとして一般提供されたことです。プレビューの続報として、M9gだけでなくM9gdも同時に扱われています。
| 項目 | AWS公式で確認できる内容 | 読者が誤解しやすい点 |
|---|---|---|
| 発表内容 | Amazon EC2 M9g/M9gdの一般提供 | すべてのリージョンで使えるわけではない |
| プロセッサ | AWS Graviton5 | x86互換ではなくArm64前提で確認が必要 |
| M9g | EBS-onlyの汎用インスタンス | ローカルディスクがある構成ではない |
| M9gd | ローカルNVMe SSD付き | 永続保存先として使える、とは読まない |
| 購入形態 | Savings Plans、On-Demand、Spot、Dedicated Instances、Dedicated Hosts | 料金はリージョン、OS、テナンシーで変わる |
AWS公式で確認できる発表内容
根拠
AWS What’s Newは、M9g/M9gdを「Starting today」として一般提供したと説明しています。AWS News Blogも同日、M9gがプレビューから一般提供へ進み、M9gdがローカルNVMe SSDを必要とする利用者向けに加わった流れを説明しています。
この記事で扱う事実認定は、AWS What’s New、AWS News Blog、Amazon EC2 M9g instance typesページ、Amazon EC2 Pricing、AWS Graviton Getting Startedをもとにしています。SiliconANGLEやSDxCentralなどの専門メディアでも話題化していますが、性能値、リージョン、料金、仕様の根拠にはAWS公式情報を使います。
注意点
「一般提供」は、読者の使いたいAWSリージョンで今すぐ使えることを意味しません。特に日本のワークロードでは、東京リージョンや大阪リージョンでの提供有無、既存VPCや接続先DBとの距離、社内のデータ所在地ルールを先に見る必要があります。
AWS公式発表の確認先を整理したい場合は、固定ページの<a href="https://amzn-watch.blog.mo-gmo.com/source-checks/">資料・確認ログ</a>も入口になります。今回のようにWhat’s New、News Blog、製品ページ、料金ページを横断する発表では、1ページだけで判断しないことが大切です。
M9gとM9gdをまず分けて見る
条件
M9gは、アプリケーションサーバー、マイクロサービス、コンテナ、Webアプリケーション、一般的な中規模データストア周辺の処理など、EBSや外部DBを前提にした汎用候補です。M9gdは、ローカルNVMeベースのSSDブロックレベルストレージを持ち、メディア処理、バッチ処理、ログ処理、キャッシュ、スクラッチファイルのような低レイテンシな一時領域を必要とする処理に向きます。
この違いを飛ばすと、ローカルNVMeが不要なシステムでM9gdを選んだり、逆に一時ファイルやキャッシュのI/Oが重い処理でM9gだけを見たりします。まずは「永続データをどこに置くか」と「ローカル一時領域に価値があるか」を分けてください。
確認項目
M9gを見る場合は、EBSボリュームタイプ、IOPS、スループット、スナップショット、暗号化、Auto Scaling、Launch Template、Blue/Green切り替えを確認します。M9gdを見る場合は、インスタンスストアの消失前提、再起動や停止時の扱い、バックアップ対象、キャッシュ再構築時間、障害時の再処理を確認します。
M8g/M8gdからの世代更新として読む
評価基準
AWSは、M9g/M9gdがGraviton4ベースのM8g/M8gdに比べて最大25%高いコンピュート性能を提供し、データベースで最大30%、Webアプリケーションと機械学習で最大35%高速だと説明しています。AWS News Blogでは、ネットワーク帯域、Amazon EBS帯域、DDR5-8800メモリ、PCIe Gen6、L3キャッシュの改善にも触れています。
ただし、比較値はあくまで公式が示す最大値です。読者のアプリケーションでは、CPUよりもDB接続、ロック競合、外部API待ち、EBS待ち、GC、ログ出力、ネットワーク経路が支配的なこともあります。M8g/M8gdで動いているからM9g/M9gdへ無検証で置き換える、という読み方は避けた方がいいです。
性能主張はどこまで移行判断に使えるか
性能値はAWS公式の最大表現です。外部API待ち、ロック競合、ストレージ待ち、Arm64非対応がある環境では別に実測します。
M9g/M9gdの発表で目を引くのは、性能向上の数字です。ただ、インフラ移行で大切なのは「公式値が大きいか」より、「自社のSLOやコスト目標に効くか」です。
| AWSの表現 | 比較対象 | 読者が検証する指標 | 断定してはいけないこと |
|---|---|---|---|
| 最大25% better compute performance | Graviton4ベースのM8g/M8gd | CPU使用率、処理時間、同時実行数 | すべての処理が25%速くなる |
| 最大30% faster for databases | データベース系ワークロード | クエリ時間、P95/P99、I/O待ち | DB全体の応答が30%改善する |
| 最大35% faster for web applications | Webアプリケーション | レイテンシ、スループット、エラー率 | 外部API待ちまで改善する |
| 最大35% faster for machine learning | 機械学習ワークロード | 推論時間、CPU利用、バッチ時間 | GPU向け処理まで置き換えられる |
最大25%、30%、35%の読み方
根拠
AWS What’s NewとAWS News Blogは、M9g/M9gdの性能をM8g/M8gdなど前世代のGraviton4ベースインスタンスとの比較として示しています。これを記事や社内メモで使う場合は、「公式発表では最大値として示された」と書くのが安全です。
AWS News Blogでは、ClickHouse、Honeycomb、HubSpotなどの顧客例も紹介されています。こうした事例は、性能改善の可能性を見るには有用ですが、自社環境で同じ改善率が出る根拠にはなりません。ワークロード、データ量、チューニング、OS、ランタイム、ネットワーク、ストレージ条件が違うからです。
注意点
性能主張を移行判断に使うなら、最低でも比較条件を揃えます。同じインスタンスサイズで比較するだけでは足りないことがあります。同等コスト、同等SLO、同等スループット、同等可用性で見たときに、台数、レイテンシ、エラー率、運用負荷、料金がどう変わるかを見てください。
CPUだけでなくI/Oも見る
条件
AWS News Blogは、M9g/M9gdでネットワーク帯域とEBS帯域も拡張されたと説明しています。さらに、Instance Bandwidth Configurationを使って、Amazon EBSとAmazon VPCネットワークの帯域配分を調整できる点にも触れています。つまり、CPUだけを見て「速い」と判断するのではなく、I/Oの詰まりも含めて見る必要があります。
確認項目
検証時は、CPU使用率、ロードアベレージ、メモリ、GC、スレッド数、EBSキュー、EBSスループット、ネットワーク帯域、P95/P99レイテンシ、エラー率、Auto Scalingの発火、ログ出力遅延を並べて見ます。DBが絡む場合は、クエリ時間、接続数、ロック待ち、バッファキャッシュ、ストレージ待ちも必要です。
コスト面では、公開済みの<a href="https://amzn-watch.blog.mo-gmo.com/amzn-37-cost-explorer-amazon-q-cost-explanations/">AWS Cost ExplorerのAmazon Qコスト説明</a>で扱ったように、月次のコスト変化と異常コスト調査を分けて見ます。M9g/M9gdの検証では、インスタンス単価だけでなく、台数、EBS、データ転送、Spot中断、Savings Plansの適用状況まで含めて比較してください。
顧客事例は期待値であり保証ではない
上振れと下振れ
上振れしやすいのは、CPU待ち、メモリ帯域、キャッシュ効率、ネットワークやEBS帯域が効いている処理です。Webアプリケーション、APIサーバー、バッチ、Javaアプリケーション、ログ処理、推論周辺の前処理などでは、検証する価値があります。
下振れしやすいのは、Arm64非対応の依存がある処理、外部API待ち、DB待ち、ロック競合、ディスク待ち、商用ソフトの対応待ち、監視エージェントやセキュリティエージェントが未対応の環境です。Graviton5のCPU性能だけでは解けない詰まりもあります。
評価基準
「速くなったか」だけでなく、「同じSLOをより少ない台数で満たせるか」「同じ台数でピーク時の余裕が増えるか」「移行後の障害対応が簡単になるか」を見ます。性能改善があっても、リージョン制約、運用制約、購入契約、監査要件が合わなければ本番移行は待つべきです。
提供リージョンと購入形態でまず止める
- 1使いたいリージョンを決める
本番候補、検証候補、データ所在地の条件を分けます。
- 2M9g/M9gd提供有無を確認
発表時点では米国東部、米国西部、欧州フランクフルトが対象です。
- 3購入形態を選ぶ
On-Demand、Spot、Savings Plans、Dedicated系の条件を確認します。
- 4既存契約を確認
既存の利用形態、契約、予約、社内の予算条件と照合します。
- 5検証環境を作る
別リージョン検証は性能傾向を見る目的にとどめます。
東京や大阪が必須の本番ワークロードでは、提供リージョンの更新を公式ページと自社アカウントで確認します。
M9g/M9gdを日本の読者が見るとき、最初に確認すべきなのは提供リージョンです。発表時点では、US East (N. Virginia)、US East (Ohio)、US West (Oregon)、Europe (Frankfurt)が示されています。
| 確認項目 | 発表時点の状態 | 日本読者の見方 |
|---|---|---|
| 提供リージョン | 米国東部、米国西部、欧州フランクフルト | 東京・大阪前提なら未確認として扱う |
| 検証環境 | 対象リージョンで作成可能 | 本番移行ではなく性能傾向を見る目的にする |
| レイテンシ | 日本からは距離がある | 国内ユーザー向け本番の根拠にしない |
| データ所在地 | リージョン依存 | 社内規定、法務、監査要件を確認する |
| 代替候補 | M8g/M8gd、M7g系、x86系など | 東京提供済みの現実的な候補と比べる |
発表時点の提供リージョン
根拠
AWS News Blogは、M9g/M9gdの提供リージョンとしてUS East (N. Virginia)、US East (Ohio)、US West (Oregon)、Europe (Frankfurt)を挙げています。AWS What’s Newも同じ文脈で、提供開始と購入形態を案内しています。
注意点
AWSのリージョン対応は変わります。この記事の確認時点で東京リージョンや大阪リージョンは発表内に含まれていませんでしたが、公開後に追加される可能性はあります。実際に検証する直前には、EC2コンソール、M9g製品ページ、料金ページ、AWS Region Tableの表示を確認してください。
購入形態を先に確認する
条件
公式発表では、M9g/M9gdはSavings Plans、On-Demand、Spot Instances、Dedicated Instances、Dedicated Hostsで購入可能と説明されています。短期検証ならOn-Demand、本番の継続利用ならSavings Plans、変動に耐えられるバッチならSpot、物理ホストやライセンス要件が絡む場合はDedicated系を確認する、という切り分けになります。
確認項目
既存のCompute Savings PlansやEC2 Instance Savings Plansがある場合、M9g/M9gdへの移行が請求にどう効くかは個別に確認してください。インスタンス単価だけでなく、リージョン、OS、テナンシー、EBS、データ転送、NAT Gateway、ロードバランサー、監視ログ、バックアップまで含める必要があります。
東京未提供なら何を見るか
評価基準
東京リージョンや大阪リージョンが必須のワークロードでは、別リージョンでM9g/M9gdを検証できても、その結果をそのまま本番移行の根拠にはできません。日本のユーザー向けアプリなら、レイテンシ、データ所在地、DR、既存のDirect ConnectやVPN、接続先DB、監査ログの保管場所を優先してください。
注意点
別リージョン検証は、Arm64対応やCPU/I/O傾向を見るには役立ちます。ただし、データ転送費やネットワーク距離が変わるため、国内本番の料金やユーザー体験を直接示すものではありません。東京で使うなら東京で、欧州で使うなら欧州で、という原則は崩さない方が安全です。
M9gとM9gdの違いをストレージ要件から判断する
M9gdは速いローカル領域を使う候補ですが、データ消失を前提にした設計が必要です。
M9gとM9gdの選択は、最初にストレージ要件から切ると読みやすくなります。M9gはEBS-only、M9gdはローカルNVMe SSD付きです。
| 観点 | M9g | M9gd |
|---|---|---|
| インスタンスストレージ | EBS-only | ローカルNVMe SSDあり |
| 向く処理 | アプリ、API、マイクロサービス、コンテナ | キャッシュ、スクラッチ、ログ、メディア処理、バッチ |
| データ保持 | EBSや外部DB側で設計 | インスタンスストア消失前提で設計 |
| バックアップ | EBSスナップショットやDBバックアップ | 重要データは別ストレージへ退避 |
| 避けたい用途 | ローカル低レイテンシが必須の処理 | 永続データの唯一の保存先 |
M9gはEBS前提の汎用候補
条件
M9gは、永続データをEBS、RDS、DynamoDB、S3などに置き、EC2側はアプリケーション実行環境として使う構成に向きます。アプリケーションサーバー、API、マイクロサービス、ECS/EKSのワーカーノード、Webアプリケーション、コード実行基盤などが候補です。
確認項目
EBSのボリュームタイプ、IOPS、スループット、暗号化、スナップショット、AMI、ユーザーデータ、起動テンプレート、Auto Scaling、ロードバランサー、ヘルスチェックを確認します。M9gへ移ってCPUが速くなっても、EBSやDBが詰まっていればアプリ全体は速くなりません。
M9gdはローカルNVMeが必要な時だけ候補にする
根拠
AWS公式は、M9gdについてローカルNVMeベースのSSDブロックレベルストレージを持つと説明しています。製品ページの表では、サイズごとにNVMe SSD容量が示され、最大クラスでは3 x 3800 NVMe SSDという構成も確認できます。
注意点
ローカルNVMeは速い一方で、永続保存先として扱うものではありません。キャッシュ、スクラッチ、再生成可能な一時ファイル、途中結果、ログ処理のバッファなど、失われても復旧できるデータに向けるのが基本です。重要データをM9gdのローカルNVMeだけに置く設計は避けてください。
サイズ表は必要最小限で読む
評価基準
Amazon EC2 M9g instance typesページでは、M9gとM9gdの各サイズ、vCPU、メモリ、インスタンスストレージ、ネットワーク帯域、EBS帯域が確認できます。M9gはmediumから48xlarge、metal-48xlまであり、最大クラスでは192 vCPU、768 GiBメモリの表記があります。M9gdも同じく最大クラスでは192 vCPU、768 GiBメモリで、ローカルNVMe SSDが付く構成です。
確認項目
記事や社内資料に全サイズを貼り付けるより、検討中のサイズだけ公式表で再確認する方が実務的です。特にネットワーク帯域、EBS帯域、ローカルNVMe容量はサイズで変わります。移行候補サイズを決める前に、現行インスタンスの実使用量、ピーク時のCPU、メモリ、EBS、ネットワークを棚卸ししてください。
Nitro Isolation Engineはどう説明するか
第6世代AWS Nitro System上で、隔離に関する保証をさらに強化する材料として扱えます。
IAM、Security Group、OSパッチ、鍵管理、ログ監査、脆弱性管理は引き続き必要です。
共有責任モデル、監査証跡、暗号化、データ所在地の確認と合わせて説明します。
セキュリティの話は単純な勝敗にせず、AWS基盤側の隔離説明と自社側の統制項目を分けて判断します。
M9g/M9gdのもう一つの注目点は、Nitro Isolation Engineです。AWS公式は、M9g/M9gdが第6世代AWS Nitro System上に構築され、Nitro Isolation Engineを初めて搭載すると説明しています。
公式が主張していること
根拠
AWS News Blogでは、Nitro System内のNitro Hypervisorがインスタンス同士とAWSオペレーターからの隔離を設計上担うことに触れたうえで、M9g/M9gdではNitro Isolation Engineにより隔離の保証をさらに強化すると説明しています。正式検証を使い、隔離に関する保証を高めるという文脈です。
注意点
ここで避けたいのは、「数学的に安全」「完全隔離」「セキュリティ対策不要」のような広すぎる読み替えです。Nitro Isolation Engineはクラウド基盤側の隔離強化として評価すべきで、アプリケーション脆弱性、IAM設定ミス、Security Groupの公開、OSパッチ、ログ監査、鍵管理を不要にするものではありません。
セキュリティ担当者が確認する観点
確認項目
セキュリティ担当者は、共有責任モデル、AMIの更新、OSパッチ、IAM、Security Group、KMS、EBS暗号化、SSM、CloudTrail、脆弱性スキャン、監査証跡を分けて確認します。Nitro Isolation Engineは、そのリストのうちクラウド基盤側の隔離に関する材料です。
評価基準
社内説明では、「AWS基盤側の隔離説明が強化された」と「自社側の運用統制は引き続き必要」を同じ表に置くと誤解を減らせます。特に金融、医療、公共、規制産業では、性能値よりも統制文書、監査ログ、暗号化、データ所在地の確認が先に来る場合があります。
見出しで煽りすぎない
注意点
Nitro Isolation Engineは重要な更新ですが、見出しで万能セキュリティのように扱うと危険です。読者が取るべき行動は、AWS公式の説明を読み、既存のセキュリティ設計にどの説明を追加できるかを確認することです。
x86や旧Gravitonから移る前のArm確認
- 棚卸し
OS、AMI、コンテナ、言語ランタイム、ネイティブ依存を洗い出します。
- Arm64ビルド
arm64 AMI、multi-arch image、依存ライブラリのビルド可否を確認します。
- ステージング検証
P95/P99、エラー率、スループット、EBS待ち、ネットワーク待ちを測ります。
- 本番カナリア
限定トラフィックで代表的な処理、ピーク、バッチ、障害復旧を確認します。
- ロールバック確認
起動テンプレート、ASG、ECS/EKS、AMI、接続先を戻せる状態にします。
同じArm系からの移行でも、世代更新によるCPU、帯域、ストレージ挙動の違いは実測します。
M9g/M9gdはGraviton5なので、Arm64前提の確認が必要です。M8g/M8gdなど既存Gravitonからの移行でも、世代更新による性能や帯域の変化を見ます。x86系からの移行なら、互換性確認がさらに重要になります。
| 確認項目 | 見る場所 | 止める条件 |
|---|---|---|
| OS/AMI | 利用中AMI、対応アーキテクチャ | arm64 AMIが用意できない |
| コンテナ | Docker base image、multi-arch image | x86_64専用イメージしかない |
| 言語ランタイム | Java、Node.js、Python、Go、Rustなど | 実行環境や依存が未対応 |
| ネイティブ依存 | C/C++拡張、Python wheel、商用ライブラリ | arm64ビルドや検証ができない |
| 監視/セキュリティ | エージェント、ログ、脆弱性管理 | 本番監視が欠ける |
| ロールバック | 起動テンプレート、ASG、ECS/EKS | 元へ戻す手順がない |
x86からの移行は互換性から見る
根拠
AWS Graviton Getting Startedは、Graviton系インスタンスを使う開発者向けの移行・最適化情報をまとめています。言語、OS、コンテナ、ライブラリ、ビルド、検証の観点は、M9g/M9gdでも移行前チェックの出発点になります。
確認項目
x86から移す場合は、AMI、パッケージ、Docker base image、multi-arch image、C/C++拡張、Python wheel、Java/JIT、.NET、Node.js、Go、Rust、PHP、監視エージェント、セキュリティエージェントを確認します。ビルドは通っても、負荷時にだけ問題が出ることがあります。ステージングで本番に近いトラフィックを流す準備が必要です。
M8g/M8gdからでも性能検証は省かない
条件
同じArm系でも、M8g/M8gdからM9g/M9gdへの移行では、CPU、キャッシュ、メモリ、EBS、ネットワーク、ローカルNVMeの挙動が変わります。アプリケーションが起動するだけで移行完了とは見ないでください。
評価基準
検証では、本番同等データ、代表的トラフィック、ピーク時間帯、バッチ、障害復旧、Auto Scaling、コストを比較します。P95/P99レイテンシ、エラー率、スループット、CPU、メモリ、EBS、ネットワーク、ログ出力、アラーム閾値を同じ条件で並べます。
ロールバックを移行条件に入れる
注意点
移行計画で抜けやすいのは、戻し方です。Launch Template、Auto Scaling Group、ECS/EKSのnode group、AMI、DB接続先、キャッシュ、ログ出力、アラーム、ダッシュボードを元へ戻せるか確認してください。
確認項目
カナリア比率、切り戻し時間、アラーム閾値、データ整合性、Spot中断、Savings Plans影響、ログの欠落、監視ダッシュボードの比較を移行条件に入れます。M9g/M9gdの検証は、成功時だけでなく失敗時にどれだけ早く戻せるかまで含めて設計します。
導入判断チェックリスト
検証してよい条件と、本番移行してよい条件は分けて判断します。
最後に、M9g/M9gdを今すぐ検証するか、条件付きで見るか、待つかを整理します。
| 状況 | 判断 | 理由 |
|---|---|---|
| 対象リージョンで動かせる | 今すぐ検証候補 | On-Demandで短期検証しやすい |
| M8g/M8gd利用中でCPUやI/Oが詰まる | 今すぐ検証候補 | 世代更新の効果を測りやすい |
| x86依存が多い | 条件付き検証 | Arm64対応の棚卸しが先 |
| ローカルNVMeが必要 | M9gdを検証候補 | 一時領域の再構築設計が必要 |
| 東京リージョン必須 | 待つ、または別候補 | 発表時点の提供リージョンに含まれない |
| 監視やロールバックが未整備 | 待つ | 性能検証より運用条件が先 |
今すぐ検証してよいケース
評価基準
対象リージョンで動かせる、Arm64対応の見通しがある、現行環境でCPUやI/Oがボトルネックになっている、短期のOn-Demand検証ができる、ロールバック計画がある。この条件が揃うなら、M9g/M9gdは検証候補に入ります。
注意点
検証してよいことと、本番移行してよいことは違います。検証で良い結果が出ても、購入形態、セキュリティ、データ所在地、監視、コスト、障害時対応が未確認なら、本番切り替えは止めるべきです。
先に待つ、または別候補を見るケース
下振れ
東京リージョンが必須、Arm64非対応の商用ソフトがある、ローカルNVMeを永続保存に使おうとしている、既存の予約やSavings Plansの制約が大きい、監視が未整備、ロールバックがない。この場合は、M9g/M9gdの話題性よりも前提条件を整える方が先です。
確認項目
代替候補として、M8g/M8gd、M7g/M7gd、C系、R系、x86系、マネージドサービス移行、アプリ改修、コスト最適化を分けて見ます。agentic AIや検索基盤のような用途まで広げる場合は、公開済みの<a href="https://amzn-watch.blog.mo-gmo.com/amzn-31-opensearch-serverless-nextgen-agentic-ai/">次世代Amazon OpenSearch Serverlessの記事</a>のように、実行基盤だけでなくデータや検索の設計も一緒に見てください。
本文末の実務チェック
CTA
導入前に、次の6点だけはメモとして残すと判断しやすくなります。
- 使いたいリージョンでM9g/M9gdが提供されているか。
- 現行アプリ、AMI、コンテナ、依存ライブラリがArm64で動くか。
- M9gとM9gdのどちらがストレージ要件に合うか。
- 比較するメトリクスと成功条件を決めたか。
- On-Demand、Spot、Savings Plans、Dedicated系のどれで検証・本番利用するか。
- 問題が出た時に元の構成へ戻せるか。
まとめと更新履歴
M9g/M9gdは、条件が合うワークロードから検証候補に入れる新世代の汎用インスタンスです。
本文は2026年6月11日 JST時点で確認したAWS公式情報をもとにしています。
東京・大阪リージョンでの提供、読者環境での実測性能、個別アカウントの料金は未確認として扱います。
公式情報は変わり得るため、導入前にはAWS公式ページと自社アカウント上の表示を再確認します。
M9g/M9gdは、Graviton5世代の汎用EC2インスタンスとして、性能、I/O、隔離説明の面で注目する価値があります。一方で、日本の読者にとっては、発表時点の提供リージョン、Arm64互換性、M9g/M9gdのストレージ差、料金、購入形態、ロールバックが導入判断の中心です。
今回の記事では、M9g/M9gdを「すぐ本番へ移す対象」ではなく、「条件が合うワークロードから検証候補に入れる対象」として整理しました。特に東京リージョン必須のシステムでは、公式ページのリージョン更新を待ちつつ、Arm64対応の棚卸しやメトリクス設計だけ先に進めるのが現実的です。
更新通知としてAmazon/AWSの公式発表や月次まとめを追いたい場合は、<a href="https://amzn-watch.blog.mo-gmo.com/newsletter/">ニュースレター</a>から確認できます。本文の判断材料を置き換えるものではなく、公式情報を見に行くきっかけとして使ってください。
- 最終確認日: 2026年6月11日 JST
- 公式発表日: 2026年6月10日
- 確認した状態: M9g/M9gdの一般提供、Graviton5、M9gdのローカルNVMe SSD、公式性能主張、Nitro Isolation Engine、発表時点の提供リージョン、購入形態
- 未確認として扱ったこと: 東京リージョンおよび大阪リージョンでの提供、読者環境での実測性能、個別アカウントの料金・契約適用
次に読むなら
参照した主な情報源
- AWS What’s New「Amazon EC2 M9g and M9gd general purpose instances are now available」確認日 2026年6月11日 https://aws.amazon.com/about-aws/whats-new/2026/06/ec2-m9g-m9gd-instances-graviton5-processors-available/
- AWS News Blog「Now available: Amazon EC2 M9g and M9gd instances powered by new AWS Graviton5 processors」確認日 2026年6月11日 https://aws.amazon.com/blogs/aws/now-available-amazon-ec2-m9g-and-m9gd-instances-powered-by-new-aws-graviton5-processors/
- AWS「Amazon EC2 M9g Instances」確認日 2026年6月11日 https://aws.amazon.com/ec2/instance-types/m9g/
- AWS「Amazon EC2 Pricing」確認日 2026年6月11日 https://aws.amazon.com/ec2/pricing/
- GitHub aws/aws-graviton-getting-started 確認日 2026年6月11日 https://github.com/aws/aws-graviton-getting-started