はじめに
業務でEC2 T4gインスタンス（t4g.medium）を使っていて、「Gravitonって何が違うの？」「Nitro Systemって結局何してるの？」という疑問が出てきたので、実際のインスタンスのスペックを見ながら整理しました。
EC2 T4gインスタンスとは
T4gは、AWSが独自設計したARMベースのCPU「Graviton2」を搭載したバースト可能なインスタンスです。
同じバースト型のT3（x86ベース）と比べて、最大40%コストパフォーマンスが高いとされています。
T3との違いを一言で言うと
T3はIntelやAMDのx86 CPU、T4gはAWS独自のARM CPUを使っています。アーキテクチャが違います。
x86とARMの違い
ここを理解しないとGravitonの立ち位置がわかりません。
CPUには設計思想が2つあります。
CISC（Complex Instruction Set Computer）
1つの命令で複雑な処理をこなす設計です。メモリが高価だった時代に「少ない命令で多くの処理を」という発想から生まれました。IntelやAMDのx86系がこれにあたります。
通常のEC2インスタンス（T3、M5、C5など）はx86ベースです。
RISC（Reduced Instruction Set Computer）
命令をシンプルにして、1命令あたりの実行を速くする設計です。省電力で処理できるため、スマートフォンやタブレット（Apple M1/M2チップなど）で広く使われています。
GravitonのEC2インスタンス（T4g、M6g、C6gなど）はARMベースで、こちらの設計思想です。
Gravitonとは
AWSが独自に設計したARMベースのプロセッサです。x86インスタンスと同程度の性能であれば、20%程度コストが抑えられます。EC2だけでなくAurora、RDS、EKSなどのマネージドサービスでも利用可能です。
Graviton2では、初代Gravitonと比較してパフォーマンスが7倍、コンピューティングコア数が4倍、キャッシュが2倍、メモリ速度が5倍に向上しています。2023年末にはGraviton4が発表されており、インスタンス名に「g」が含まれるものがGravitonベースです。
T4gのバースト動作の仕組み
T4gは「バースト可能」なインスタンスです。常にフルパワーで動くのではなく、普段は低いベースラインCPUで動作し、必要なときだけ一時的にCPU使用率を引き上げます。
CPUクレジットの仕組み
ベースライン未満で動作しているとき → クレジットが貯まる
ベースラインを超えて動作しているとき → クレジットを消費する
無制限モードと標準モード
T4gはデフォルトで無制限モードで動作します。24時間の平均CPU使用率がベースラインを下回っていれば、一時的なスパイクに追加料金はかかりません。
長時間ベースラインを超え続ける場合は、vCPU時間あたり0.04 USDの追加料金が発生します。標準モードでは、貯まったクレジットを使い切るとバーストが止まります。
T4gインスタンスのスペック一覧
| サイズ | vCPU | メモリ(GiB) | ベースライン/vCPU | クレジット取得/時間 | ネットワーク(Gbps) | EBS帯域(Mbps) |
|---|---|---|---|---|---|---|
| t4g.nano | 2 | 0.5 | 5% | 6 | 最大5 | 最大2,085 |
| t4g.micro | 2 | 1 | 10% | 12 | 最大5 | 最大2,085 |
| t4g.small | 2 | 2 | 20% | 24 | 最大5 | 最大2,085 |
| t4g.medium | 2 | 4 | 20% | 24 | 最大5 | 最大2,085 |
| t4g.large | 2 | 8 | 30% | 36 | 最大5 | 最大2,780 |
| t4g.xlarge | 4 | 16 | 40% | 96 | 最大5 | 最大2,780 |
| t4g.2xlarge | 8 | 32 | 40% | 192 | 最大5 | 最大2,780 |
実際のt4g.mediumの使用状況
実運用中のt4g.mediumインスタンスのリソース使用状況を見てみます。
インスタンス情報
| 項目 | 値 |
|---|---|
| インスタンスタイプ | t4g.medium |
| vCPU | 2 |
| メモリ | 約4GB（3.7GiB） |
| CPUアーキテクチャ | ARM64 (aarch64) Neoverse-N1 |
| OS | Ubuntu 24.04.3 LTS / Kernel 6.8.0-1029-aws |
| EBSルートディスク | 6.8GB（使用率58%） |
CPU使用率（プロセス別）
| プロセス | %CPU | 備考 |
|---|---|---|
| amazon-cloudwatch-agent | 0.3% | CloudWatchログ転送 |
| ssm-session-worker | 0.2% | SSMセッション |
| quarkus-run.jar | 0.1% | Javaバックエンド（Quarkus） |
| その他 | 0%付近 | 待機または低負荷 |
全体的なCPU使用率は約1%以下で、ほぼアイドル状態です。t4g.mediumのベースラインは20%なので、クレジットが常に貯まり続けている状態です。
メモリ使用状況
| 項目 | 値 |
|---|---|
| メモリ総量 | 3.7 GiB |
| 使用中 | 685 MiB |
| 空き | 247 MiB |
| バッファ/キャッシュ | 3.0 GiB（実質利用可能 3.1 GiB） |
| Swap | なし（未設定） |
Java（Quarkus）が最もメモリを使っていますが、全体の6%未満です。Swap無しでも余裕があります。
ディスク使用状況
| マウント | サイズ | 使用済 | 空き | 使用率 |
|---|---|---|---|---|
| / (ルート) | 6.8G | 3.9G | 2.9G | 58% |
| /boot | 891M | 107M | 722M | 13% |
| /boot/efi | 98M | 6.4M | 92M | 7% |
ルートディスクが58%で、ログやビルド成果物が増えてきたら拡張を検討するラインです。
アプリ別リソース使用率まとめ
| コンポーネント | %CPU | %MEM | 備考 |
|---|---|---|---|
| Quarkus (Java) | 0.1% | 5.9% | 主力アプリ。ヒープがやや大きめ |
| Nginx | - | 微量 | 軽量のため無視レベル |
| Vite/JS (フロント) | - | - | 常駐していない。ビルド時のみ一時的に負荷増 |
| CloudWatch Agent | 0.3% | 2.9% | 監視用途として適正 |
| FluentBit | 0.0% | 1.6% | ログ収集。軽量 |
| SSM Agent | 0.2% | 0.6% | 定常動作 |
このワークロードならt4g.mediumで十分すぎるくらいです。t4g.smallでも動きそうですが、Javaのヒープを考えるとmediumが安全圏です。
AWS Nitro System
ここからが本題です。T4gを含むすべての最新EC2インスタンスは、Nitro System上で動いています。
Nitro Systemとは
2013年に発表された、EC2の仮想化を支える基盤技術です。従来のXenハイパーバイザーを置き換えました。
従来は1つのソフトウェア（Dom0）がネットワーク・ストレージ・セキュリティを全部管理していましたが、Nitroではそれぞれを専用のハードウェアチップ（カード）に分担させています。
従来のXenベース仮想化の課題
従来のXenでは、Dom0（Domain 0）という管理用の仮想マシンがネットワークやストレージの処理を一手に引き受けていました。
これには問題がありました。
- CPUリソースがDom0のI/O処理に奪われる
- オーバーヘッドが増大する
- セキュリティ上の攻撃面が大きく複雑になる
Nitro SystemではDom0を廃止し、これらの処理を専用ハードウェアにオフロード（別の部品に仕事を任せて本体の負荷を減らすこと）しています。
ハイパーバイザーとは
物理サーバーのハードウェア上に直接載せる仮想化ソフトウェアです。この上に仮想マシン（EC2インスタンス）を複数動かします。このタイプの仮想化を「ハイパーバイザ型」と呼びます。
Nitro Systemの構成要素
Nitro Systemは5つの主要コンポーネントで構成されています。
1. Nitro Card
サーバー内の「分担チップ」です。ネットワーク通信・ディスクIO・セキュリティなどの処理を、それぞれ専用のカードが担当します。
| カード | 役割 |
|---|---|
| Nitro Card for VPC | ネットワーク通信の処理（データの出入りを高速化） |
| Nitro Card for EBS | EBSボリュームとのデータ転送を高速化 |
| Nitro Card for Instance Storage | ローカルNVMeストレージの制御 |
| Nitro Card Controller | 各カードのまとめ役 |
2. Nitro Security Chip
セキュリティを専用ハードウェアで守るチップです。AWSのエンジニアですらインスタンス内部に直接アクセスできないようにするロックダウン設計です。人為的なミスや不正を、人に頼らずハードウェアレベルで防止します。
3. Nitro Hypervisor
EC2インスタンスを動かすための仮想化ソフトです。ただし従来のハイパーバイザーと違い、CPUとメモリの管理だけを行います。ネットワークやストレージの処理はNitro Cardに任せるため、非常に軽量で、ほぼベアメタル（物理サーバー直接）と同じ性能が出ます。
4. AWS Nitro Enclaves
EC2インスタンスの中に「外部と完全に隔離された空間」を作る仕組みです。メインOSからもアクセスできず、個人情報・医療データ・金融データなどを安全に処理できます。暗号化キーの一時的な取り扱いなどに使います。
5. NitroTPM
TPM（Trusted Platform Module）のクラウド版です。サーバーが「自分は安全に起動した」と証明するための仕組みで、OSやアプリが安全に鍵を管理できます。鍵はAWS内部で暗号化・分離され、インスタンス自身も中身を読めません。WindowsのBitLockerやLinuxのSecure Bootにも対応しています。
各コンポーネントの役割分担
| 目的 | 担当 |
|---|---|
| 高速化 | Nitro Card（VPC/EBS等） |
| セキュリティ | Nitro Security Chip / Nitro Enclaves / NitroTPM |
| 性能維持 | Nitro Hypervisor（軽量） |
| 人為ミス防止 | ロックダウン設計（AWS社員も触れない） |
パケットの流れ：EC2からネットワークへ
Nitro Systemがどう動いているのか、パケットの送信を例に見てみます。
アプリケーション
↓
OS（Linuxカーネル）のネットワークスタック
↓
ENAドライバ（仮想NICを制御）
↓
Nitroカード（ハードウェアNIC）
↓
Ethernet
ENA（Elastic Network Adapter）は新世代のネットワークアダプターで、旧世代の最大10Gbpsから最大20Gbpsまでサポートするようになりました。AWSの基本的なAMIではデフォルトで有効です。
Nitroカード内部の5段階処理
Nitroカード内部ではパケットを以下の流れで処理します。
第1段階：Txリングバッファへの投入
OSがENAドライバ経由でパケットをリングバッファ（キュー）に書き込みます。パケットの5-tuple（送信元IP、宛先IP、プロトコル、送信元ポート、宛先ポート）からハッシュを計算し、複数のキューに分散します。
第2段階：パケット読み取りとVPC情報の処理
Nitroカードがキューからパケットをポーリングし、VPC情報を参照して処理します。ルートテーブルで宛先経路を決定し、NACLとセキュリティグループで評価して、許可されないパケットはドロップします。
NitroカードにはVPCの情報が記録されているため、ハードウェアレベルでAWSの仮想ネットワーク機能を実現できます。
第3段階：物理位置のマッピング
AWS内部のマッピングサービスから宛先インスタンスの物理的な場所を取得し、隣接情報を記録して次回の処理を高速化します。
第4段階：コネクショントラッキングとフローキャッシュ
パフォーマンス向上の要です。
コネクショントラッキングでは、初回パケットで5-tupleをキーとして通信の関係性やSG/NACLの許可済み判定を保存します。
フローキャッシュでは、隣接情報などをNitroカード内に保存します。キャッシュにヒットすれば、SGやNACLの再評価をスキップして即転送できます。同じフローのパケットは2回目以降の処理が大幅に高速化されます。
第5段階：パケットの物理送出
Nitroカード内の処理が完了したパケットを、物理NICを通じて外部へ送信します。
Nitro Systemが速い3つの理由
ハードウェアオフロード
従来ソフトウェアでやっていた処理をハードウェアに移すことで、CPUオーバーヘッドを大幅に削減しています。
5-tuple最適化
パケットの5-tupleをハッシュ化して複数のCPUコアやNICキューに分散する仕組み（RSS: Receive Side Scaling）を使っています。同じフローは常に同じCPUコアで処理されるため、キャッシュ局所性が維持され、キャッシュミスやロック競合を防ぎます。
結果として毎秒数百万パケットのスループットを実現しています。
フローキャッシュ
Nitroカード上のハードウェア（SmartNIC / DPU）のSRAMやDRAMにキャッシュされています。OSカーネルやEC2インスタンスのメモリではなく、ハイパーバイザーを極力通さず、NIC上のハードウェア内で完結します。
キャッシュにヒットすればルーティング判定やセキュリティチェックをスキップして即転送。ミスした場合のみ再計算してキャッシュに格納します。これにより、DPUレベルでワイヤレート（線速）転送が可能になります。
Nitro Card for EBSとNitro Card for Instance Storageの違い
この2つは名前が似ていますが、役割がまったく違います。
Nitro Card for EBS
EBS（Elastic Block Store）との通信をハードウェアで処理するカードです。EBSは実体が別の物理ストレージ（ネットワーク接続型）にあり、永続的なストレージです。インスタンスを削除してもデータは残ります。
EC2インスタンスが /dev/nvme1n1 などを通じてEBSにアクセスすると、Nitro Card for EBSがリクエストを受け取り、AWSバックエンド（EBSサーバ）に直接転送します。
Nitro Card for Instance Storage
ホストマシン上のNVMe SSDを直接インスタンスに割り当てるカードです。一時的なストレージ（ephemeral）で、EC2を停止・削除するとデータは消えます。高速なI/Oが特徴です。
一言で言うと、EBS用は「永続ストレージとのネットワーク通信を最適化するカード」、Instance Storage用は「ローカルNVMeを直接制御するカード」です。
EBSのKMS暗号化とNitro Cardの連携
EBSボリュームをKMSで暗号化した場合、その暗号化処理はOSではなくNitro Card for EBSがハードウェアレベルで実行します。
処理の流れ
- EBSボリューム作成時にKMSキー（CMK）を指定して暗号化を有効にする
- KMSがデータ暗号鍵（DEK）を生成し、CMKで暗号化した状態でNitroに渡す
- Nitro Card for EBSがハードウェア内部のセキュア領域でDEKを復号し、専用メモリに保持する。OSやハイパーバイザーはDEKにアクセスできない
- EC2がEBSに読み書きするたびに、Nitro CardがリアルタイムでAES-256暗号化/復号を実行する。Nitroカード内で完結するため、CPU負荷はほぼゼロ
- 暗号化済みデータだけがネットワークを通ってEBSバックエンドに保存される。EBSバックエンドやホストOSは平文を見ない
LUKSやBitLockerのようにOSが暗号化しているわけではないので、パフォーマンス低下がほぼありません。管理者が鍵を直接扱う必要もなく、ハイパーバイザー経由でも復号できないという設計です。
NitroTPMに保管されるもの・されないもの
NitroTPMが扱うのは「システムの信頼性や鍵管理のための低レベルな暗号鍵」です。
保管されるもの
- BitLocker / LUKS のディスク暗号化鍵
- Secure Boot の署名検証鍵
- OS が TPM API 経由で生成する鍵
- Windows Hello / Credential Guard の秘密鍵
保管されないもの
EC2にインストールしたSSL/TLS証明書（/etc/ssl/certs/に置くWebサーバ証明書など）は保管されません。NitroTPMは「プラットフォームレベルの暗号鍵」を管理するものであり、アプリケーションレベルの証明書は対象外です。
まとめ
T4gインスタンスは、Graviton2（ARM）による低コストと、Nitro Systemによる高速化・セキュリティ強化の両方を享受できるインスタンスです。
Nitro Systemの設計思想は「速く、安全で、人間にも触れられないクラウド基盤」です。ネットワーク・ストレージ・セキュリティの処理を専用ハードウェアにオフロードし、ハイパーバイザーを極限まで軽量化することで、ほぼベアメタルと同等の性能を仮想環境で実現しています。