AWS EC2 で t4g インスタンスを利用して失敗しないために

公開日:2025/10/09

1 はじめに
2 t3/t3a 系と t4g インスタンスの大きな違い
3 各インスタンスタイプの比較
4 東京（ap-northeast-1）リージョンでのインスタンスタイプ対応
5 まとめ

はじめに

AWS の EC2 ではさまざまなインスタンスタイプが利用可能です。その中で最新のT系インスタンスとして、t4g インスタンスがあります。このインスタンスタイプですが、これまでのT系インスタンスと同じ手順で利用することができません。

この記事では t4g インスタンスを利用するために理解しておくべきポイントと、t4gインスタンスを利用できないケース・注意点についてを説明します。

t3/t3a 系と t4g インスタンスの大きな違い

t4g インスタンスが登場する以前は、t3/t3a 系のインスタンスが広く利用されていました。
さらにその前の世代として t2 インスタンスがあり、これらは同一のアーキテクチャを採用していたため、インスタンスタイプを変更してもそのまま利用することができました。

しかし、t3/t3a 系で稼働しているインスタンスを t4g インスタンスタイプに直接変更することはできません。その理由は、アーキテクチャが異なるためです。 t2/t3/t3a 系は x86（Intel / AMD）アーキテクチャを採用していますが、t4g 系は Arm（Graviton）アーキテクチャで動作します。

このアーキテクチャの違いにより、CPU 命令セットが根本的に異なります。その結果、x86 用にコンパイルされた OS やアプリケーションは Arm 環境では実行できなくなります。
つまり、既存の t3 インスタンスをそのまま t4g に「変更」して起動することはできません。 Arm64 (aarch64) 対応の AMI から新たにインスタンスを作成する必要があります。

また、これは既存の t3 系インスタンスから AMI を作成した場合も同様です。その AMI は x86 アーキテクチャ用として作られているため、t4g インスタンス上では起動できません。

この制約は、新規にインスタンスをローンチする際にも同様に存在します。 AWS の AMI（Amazon Machine Image）には、あらかじめ対応するアーキテクチャが設定されており、マネジメントコンソールのデフォルトでは多くの場合 x86 用の Amazon Linux が選択されています。このままでは t4g インスタンスタイプを選択できません。

t4g インスタンスタイプを指定して、インスタンスを起動するにはAMI 選択時に「Arm64（aarch64）」アーキテクチャを指定する必要があります。

なお、t系をより上位のm/c/r 系などのインスタンスタイプに変更したい場合、x86 / Arm64 のぞれぞれで利用可能なインスタンスタイプが提供されています。

各インスタンスタイプの比較

インスタンスの料金は t3（x86 / Intel）＞ t3a（x86 / AMD）＞ t4g（Arm / Graviton）の順となっており、この中では t4g が最も安価です。

同じクラス（例：medium）であれば、基本的なサーバースペックに大きな差はありません。ただし、t4g インスタンスは Arm64 アーキテクチャを採用しているため、一部の環境ではソフトウェアが動作しない可能性があります。

代表的な例として、以下のようなケースが挙げられます。

Docker Hub で x86 版のイメージしか提供されていない
過去の環境を変更せず、古い構成（例：PHP 5 系）を再現する必要がある場合
古い OS 向けにビルドされたバイナリをそのまま動かす必要がある場合（x86 バイナリのみ存在）
商用ソフトウェアやセキュリティ製品など、外部ベンダーが Arm64 版を提供していない場合
Windows 環境を利用する場合（Arm 版 Windows は EC2 の AMI として提供されていません）

これらの条件に該当する場合は、t4g ではなく t3a などの x86 系インスタンスを選択した方が安全です。

一方で、新規構築のシステムや OSS ベースの環境を利用する場合は、基本的に t4g を選んで問題ありません。近年では多くの主要ソフトウェアが Arm64 に対応しており、たとえば以下のような用途では t4g が最もコスト効率に優れます。

Nginx / Apache / PHP / Python / Node.js / Go などで構成された Web アプリケーション
Docker / Kubernetes 環境を利用したマイクロサービス構成
CI/CD 用のビルド・テストサーバー（GitHub Actions, CodeBuild 等で Arm64 対応が進行）
軽量な API サーバーや WordPress / Laravel などの汎用 CMS

また、AWS Graviton プロセッサ（Arm 系 CPU）はすでに2020年頃から商用利用が進んでおり、現在では多くのリージョン・サービスで標準的に採用されています。既に本格稼働して数年が経過しているため、新規構築やOSSベースの環境では、t4gをデフォルトの選択肢と考えてよいでしょう。

東京（ap-northeast-1）リージョンでのインスタンスタイプ対応

2025年10月現在、東京リージョンには 3つのアベイラビリティゾーン（AZ）が存在します。このうち、t3a インスタンスは一部のゾーンで利用できません。（※かつては4つの AZ が存在していましたが、既に廃止されています）

具体的には、以下のような AWS CLI コマンドを実行することで、各インスタンスタイプがどのアベイラビリティゾーンで利用可能かを確認できます。このコマンドを実行すると、t3a インスタンスが提供されていないゾーンが 1 つ存在することが分かります。

aws ec2 describe-instance-type-offerings \
    --location-type availability-zone \
    --filters Name=instance-type,Values=t3a.micro \
    --region ap-northeast-1

同様に、t4g インスタンスについても確認してみたところ、こちらは東京リージョン内のすべてのアベイラビリティゾーンで利用可能でした。