「EC2 のインスタンスタイプの m7i.large、c8g.xlarge、r6a.2xlarge という名前が暗号のようで、どれを選べばよいか分かりません。移したいオンプレの VM は 2 vCPU・8 GB です」
「SSH の 22 番をインターネットに開けずに、プライベートなサブネットの EC2 へログインする方法はありますか」
第2回では、リージョン・AZ・料金の構造など AWS の全体像を見ました。ここからはサービスを1つずつ見ていきます。最初は、オンプレの仮想化基盤の VM に最も近い EC2 と、その周りのコンピューティングのサービスです。VM の考え方はそのまま使えますが、作って捨てられること、停止と終了で課金が変わること、ログインや認証情報の扱いがオンプレと違います。
第3回と第4回では、コンピューティングを扱います。前編の第3回では、EC2 の基盤とインスタンスタイプ、AMI と起動テンプレート、ストレージ、ログインの方法、IMDS を扱います。
EC2（Elastic Compute Cloud）とは
EC2 は AWS の仮想サーバーのサービスで、オンプレの「仮想化基盤の上の VM」に最も近い存在です。インスタンス（VM）を起動するときに、AMI（OS のイメージ）、インスタンスタイプ（CPU・メモリ・ネットワークの性能）、配置先のサブネット、セキュリティグループ、ストレージ（EBS）、ログイン用のキーペアを指定します。
OS より上はすべて利用者が管理する IaaS であり（第1回の責任分界）、パッチの適用も監視のエージェントの導入も自分で行います。オンプレとの決定的な違いは、起動・停止・削除が API 一発で数十秒〜数分で終わり、停止すれば本体の課金が止まることと、同じ AMI から同じ構成のインスタンスを何台でも複製できることです。この「使い捨てできるサーバー」という発想が、第4回で見る Auto Scaling や、イミュータブルインフラ（サーバーを直さず作り直す）の前提になります。
- EC2＝AWS の VM。OS から上は利用者の管理（IaaS）
- 起動時に AMI・タイプ・サブネット・SG・EBS・キーペアを指定
- 「数分で作れて捨てられる」ことが Auto Scaling などの前提
EC2 の基盤：Nitro System と Graviton
EC2 の物理ホストと CPU の話です。インスタンスタイプの名前を読むときにも関係します。
- Nitro System：2017 年（C5）以降の EC2 の基盤。ストレージ（EBS）・ネットワーク（ENA）・セキュリティ（Nitro Security Chip）の処理を専用カード（Nitro Card）にオフロードし、ホストの CPU はほぼ全部を VM に渡す。ハイパーバイザーは KVM ベースの軽量なもの
- 効果：VM でも物理に近い性能、ベアメタルインスタンス（
*.metal）の提供、AWS の運用者も VM のメモリにアクセスできない設計など。さらに VM の中に隔離した実行環境を作って機密の処理を行う Nitro Enclaves も提供 - Graviton：AWS が自社で設計した ARM（AArch64）の CPU。Graviton2（2020）→ 3 → 4（2024、
m8gなど）→ 5（2026年、m9g。提供リージョンは順次拡大）と進化。同じ性能帯の x86 より 2〜4 割安い価格性能比をうたう。Linux のワークロードの多くはそのまま動くが、x86 専用のバイナリや古い商用ソフトは動かないので、移行の前に確かめる - インスタンスタイプ名の属性の文字（世代の数字の後ろ）で CPU が分かる：
i＝Intel、a＝AMD、g＝Graviton - NIC に TCP の処理を任せるオフロード（TOE など）の発想を、基盤全体に当てはめたものと理解するとよい
インスタンスタイプの読み方
インスタンスタイプの名前には規則があり、読めば性能の見当が付きます。
- 表記は
ファミリー＋世代＋属性 . サイズ。例：m7i.large、c8g.xlarge、r6a.2xlarge、t4g.micro - ファミリー：用途（m＝汎用、c＝コンピュート、r＝メモリ、t＝バースト、i/d＝ストレージ、p/g/inf/trn＝GPU・AI アクセラレータ）
- 世代：数字が大きいほど新しい。同じサイズなら新しい世代の方が速くて安いことが多いので、指定できる範囲で最新の世代を選ぶ
- 属性：
g＝Graviton、i＝Intel、a＝AMD、n＝ネットワーク強化、d＝ローカル NVMe、e＝メモリ・ストレージ増量、flex＝ベースラインの性能を抑えた低価格版（m7i-flex） - サイズ：
large＝2 vCPU を基準に、xlarge＝4、2xlarge＝8 … と倍々。メモリはファミリーごとの比率（m は 4 GiB/vCPU、r は 8、c は 2） - vCPU は多くのタイプでハイパースレッド 1 本（Intel と第6世代までの AMD は「2 vCPU＝物理 1 コア」）。Graviton と第7世代の AMD（
m7a・c7a・r7a）は 1 vCPU＝1 物理コア
インスタンスファミリーの一覧
ファミリーごとの特徴と用途です。
| ファミリー | 特徴 | 代表例 | 用途 |
|---|---|---|---|
| 汎用 M | CPU:メモリ＝1:4 GiB | m7i、m8g | Web／AP サーバー、小規模な DB |
| バースト T | 低いベースライン＋CPU クレジットでバースト。安い | t3、t4g | 開発環境、低負荷のサーバー。クレジットが尽きると性能が落ちる点に注意 |
| コンピュート C | 1:2 GiB。高クロック | c7i、c8g | バッチ、エンコード、ゲームサーバー |
| メモリ R／X／z | 1:8 GiB 以上 | r7i、r8g、x2idn | インメモリ DB、SAP HANA、大規模なキャッシュ |
| ストレージ I／D | ローカルの NVMe SSD／HDD | i4i、i8g、d3 | NoSQL、分散ファイルシステム、DWH |
| アクセラレータ P／G／Inf／Trn | GPU・推論／学習用のチップ | p5、g6、inf2、trn2 | 機械学習、動画処理 |
| HPC Hpc | 高帯域のネットワーク（EFA） | hpc7a | 数値計算 |
迷ったら M（汎用）の最新の世代から始め、CloudWatch のメトリクスを見て C や R に寄せます。「とりあえず大きめ」は、Well-Architected のコスト最適化（第13回）に反します。
冒頭の1つ目の相談がこれです。名前は「ファミリー＋世代＋属性 . サイズ」と読みます。m7i.large は汎用・第7世代・Intel の 2 vCPU（8 GiB）、c8g.xlarge はコンピュート・第8世代・Graviton の 4 vCPU（8 GiB）、r6a.2xlarge はメモリ・第6世代・AMD の 8 vCPU（64 GiB）です。2 vCPU・8 GB の VM なら CPU とメモリの比が 1:4 なので、M の large（m7i.large。x86 専用のソフトが無ければ Graviton の m8g.large）から始め、動かしてからメトリクスを見て C や R に寄せます。
AMI（Amazon Machine Image）と OS の選択
AMI は EC2 を起動するときの型紙で、OS と（必要なら）導入済みのミドルウェア・設定を含みます。AWS が提供する標準の AMI には Amazon Linux 2023、Ubuntu、RHEL、SUSE、Windows Server 2019/2022/2025 などがあり、Windows は OS のライセンス込みの時間単価で提供されます。
Amazon Linux 2023 は Fedora 系で dnf・systemd を使い、IMDSv2（後の「インスタンスメタデータサービス」の節）が必須、SELinux は permissive が既定と、旧 Amazon Linux 2 とは運用が異なります。Amazon Linux 2 は 2026 年 6 月 30 日でサポートが終了しました（延長サポートはありません。AL2023 のサポートは2029年6月まで）。
自分で設定したインスタンスから作る「カスタム AMI」は、オンプレのゴールデンイメージと同じ考え方で、Auto Scaling で複製されるのはこの AMI です。AMI はリージョンごとに ID が異なり（同じ Ubuntu でも東京と大阪で ami- が違います）、ほかのリージョンで使うにはコピーが必要です。Marketplace の AMI（Fortinet、Palo Alto などの仮想アプライアンス）は、AWS の利用料にソフトウェアの料金が上乗せされます。
- AMI＝OS＋設定の型紙。標準 AMI／カスタム AMI／Marketplace AMI
- Amazon Linux 2023 が現行。AL2 は 2026-06-30 でサポート終了（延長なし）
- AMI ID はリージョン固有。Auto Scaling の複製元
起動テンプレートとユーザーデータ（cloud-init）
同じ構成のインスタンスを何度でも作るための仕組みです。
- 起動テンプレート：AMI・インスタンスタイプ・SG・キーペア・ユーザーデータ・タグなどをまとめて保存し、バージョンで管理する。Auto Scaling（第4回）の構成元。旧方式の「起動設定」は、2023 年 6 月 1 日以降に作ったアカウントではコンソールから、2024 年 10 月 1 日以降に作ったアカウントではどの方法でも新しく作れない
- ユーザーデータ：初回の起動時に実行されるスクリプト。Linux では cloud-init が処理し、
#!/bin/bashで始めればシェルスクリプトとして root で実行される。Windows は EC2Launch v2 が<powershell>のブロックを実行する - 既定では初回の起動時だけ実行される。停止→起動で再実行させるには cloud-init の設定の変更が必要
- ユーザーデータは IMDS（後の節）から誰でも読めるので、パスワードやアクセスキーを書いてはいけない（Secrets Manager を使う。第9回）
例として、初回の起動時に Web サーバーを入れるユーザーデータです。
#!/bin/bash
dnf install -y nginx
systemctl enable --now nginx
EC2 のストレージ：EBS とインスタンスストア
EC2 で使うブロックストレージには、ネットワークでつなぐ EBS と、ホストに直付けのインスタンスストアがあります。
| 項目 | EBS | インスタンスストア |
|---|---|---|
| 実体 | ネットワーク接続のブロックストレージ（第5回「EBS のボリュームタイプ」） | ホストに直付けの NVMe／SATA |
| 永続性 | インスタンスを停止・終了しても残る（ルートは終了時に削除が既定） | 停止・終了・ホストの障害で消える |
| 性能 | タイプで選ぶ（gp3 で 3,000 IOPS〜） | 非常に高い（数十万 IOPS） |
| 対応するタイプ | すべて | d/i 属性や一部の大型のサイズのみ |
| 用途 | OS、DB、ほぼすべて | 一時領域、キャッシュ、自前で複製する分散 FS |
| 課金 | 確保した GB・月 | インスタンスの料金に含まれる |
オンプレのストレージの分類でいえば、SAN（ブロック）の位置付けが EBS、DAS がインスタンスストアに当たります（連載「ストレージ入門」第5回「DAS・NAS・SAN」で詳しく扱います）。EBS は 1 つの AZ の中でしか接続できないため、別の AZ のインスタンスに付け替えるには、スナップショットを経由して複製します。
インスタンスへのログイン手段
EC2 へのログインには、SSH の鍵のほかに、ポートを開けない方法があります。
- キーペア＋SSH（22/tcp）：起動時に指定した公開鍵が
~/.ssh/authorized_keysに置かれる。鍵は RSA か ED25519。秘密鍵は AWS に残らないので、なくすとそのままではログインできない（鍵の仕組みは連載「SSH入門」第5回「鍵の種類と長さ」で詳しく扱います）。なくしたときは Session Manager や AMI を経由して復旧する - EC2 Instance Connect：API で一時的な公開鍵（60 秒有効）を送り込んでから SSH する。鍵の配布が要らない。EC2 Instance Connect Endpoint（2023 年）を使うと、パブリック IP や踏み台なしでプライベートサブネットへ接続できる
- Systems Manager Session Manager（第11回）：SSM エージェントを経由する。インバウンドのポートを一切開けず、IAM で認証し、操作のログを S3／CloudWatch に残せる。AWS が推奨する方式で、踏み台サーバーを要らなくする
- Windows：RDP（3389/tcp）。管理者のパスワードはキーペアの秘密鍵で復号して取得する。Session Manager の RDP のトンネルも使える
- シリアルコンソール：Nitro ベースなら、起動できなくなったときに OS のコンソールへ接続できる
- 今の実務では「SG で 22 番を全世界に開ける」構成は避け、Session Manager か Instance Connect Endpoint を第一候補にする
冒頭の2つ目の相談がこれです。Session Manager なら、インスタンスの SSM エージェントから外向きに通信するだけなので、22 番を開けずにログインできます。踏み台やクラウドでの SSH の使い方は、連載「SSH入門」第10回「クラウドの代替手段」でも扱います。
インスタンスメタデータサービス（IMDS）
IMDS は、インスタンス自身が自分の情報（インスタンス ID、AZ、プライベート IP、IAM ロールの一時的な認証情報、ユーザーデータ）を取得するための仕組みで、リンクローカルアドレス 169.254.169.254 に HTTP で問い合わせます。169.254.0.0/16 がここで使われています（連載「TCP/IP入門」第6回「特殊な用途のアドレス」で扱います）。
IAM ロール（第8回）をインスタンスに付けると、アプリケーションは IMDS からアクセスキーを取得でき、鍵をファイルに置かずに済みます。ただし旧方式の IMDSv1 は単純な GET で応答するため、SSRF の脆弱性がある Web アプリを経由して、外部から認証情報を抜かれる事故が起きました（2019 年の Capital One の事件が有名です）。
対策の IMDSv2 は、まず PUT でトークンを取得し、そのトークンをヘッダーに付けて GET する方式で、ホップ制限（既定は 1）により NAT 越しの取得も防ぎます。Amazon Linux 2023 と、最近の起動の経路（コンソールのクイックスタートや、2024 年以降に出たインスタンスタイプ）は IMDSv2 のみが既定であり、既存のインスタンスも v2 必須に変えることが推奨されます。
$ TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
-H "X-aws-ec2-metadata-token-ttl-seconds: 21600") # IMDSv2：まずトークンを取得
$ curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
http://169.254.169.254/latest/meta-data/instance-id
i-0123456789abcdef0
$ aws ec2 describe-instances \
--query "Reservations[].Instances[].MetadataOptions.HttpTokens" # required なら v2 必須
$ aws ec2 modify-instance-metadata-options \
--instance-id i-0123456789abcdef0 --http-tokens required # 既存のインスタンスを v2 必須に
169.254.169.254で自分の情報と IAM ロールの一時的な認証情報を取得- IMDSv1 は SSRF で盗まれる。IMDSv2（トークン方式）を必須に
- 確かめ方：
aws ec2 describe-instances --query "...MetadataOptions.HttpTokens"
考えてみよう
- 今オンプレで運用しているサーバーを1台選び、CPU・メモリの比率から M・C・R のどのファミリーに当たるか、Graviton に移せるか（x86 専用のソフトがないか）を考えてください。
- 22 番をインターネットに開けている EC2 があるとしたら、Session Manager に移すために何が要りますか（SSM エージェント、IAM ロール、外向きの通信の経路）。
- 既存のインスタンスの
HttpTokensがoptionalのままになっていないか確かめ、v2 必須に変えたときに影響を受けるアプリがないかを考えてください。
ヒント：1 は「インスタンスタイプの読み方」と「EC2 の基盤：Nitro System と Graviton」、2 は「インスタンスへのログイン手段」、3 は「インスタンスメタデータサービス（IMDS）」の節を見直してください。
まとめ
- EC2 は AWS の VM で、OS から上は利用者の管理。「数分で作れて捨てられる」ことが Auto Scaling などの前提
- 基盤の Nitro が処理を専用カードに任せ、Graviton（ARM）は価格性能比が高いが、x86 専用のソフトは動かない
- インスタンスタイプは「ファミリー＋世代＋属性 . サイズ」で読み、迷ったら M の最新の世代から
- AMI と起動テンプレートで同じ構成を何台でも作れる。ユーザーデータに秘密を書かない
- インスタンスストアは停止・終了で消える。OS や DB は EBS に置く
- ログインは Session Manager か Instance Connect Endpoint を第一候補に。22 番を全世界に開けない
- IMDS は IAM ロールの一時的な認証情報を渡す仕組み。IMDSv2 を必須にする
次回は、停止・終了と課金、購入オプション、Auto Scaling、ELB、コンテナ、Lambda、使い分けと Azure との対応を扱います。
連載「クラウド入門」全14回
- クラウドとは（定義・歴史・責任分界）
- AWSの全体像
- コンピューティング 前編（EC2・Nitro・インスタンスタイプ・AMI・IMDS）（この記事）
- コンピューティング 後編（課金と購入オプション・Auto Scaling・ELB・コンテナ・Lambda）
- ストレージ
- ネットワーキング 前編（VPC・サブネット・SG・NACL）
- ネットワーキング 後編（DNS・接続・Route 53・CloudFront）
- IAMとセキュリティ 前編（IAM・ポリシー・STS・ID連携・Organizations）
- IAMとセキュリティ 後編（KMS・シークレット・ACM・検知と防御）
- データベース
- 運用・監視・コスト 前編（CloudWatch・CloudTrail・Config・SSM）
- 運用・監視・コスト 後編（タグ・転送料金・コスト管理・Control Tower・IaC）
- Well-Architectedフレームワーク
- これまでのテーマとAWSの対応・まとめ
コメント