Amazon EC2入門｜インスタンスタイプの選び方からAMI・セキュリティグループ設定まで現場で使える基礎知識

AWSを使い始めて最初につまずくのが、「どのインスタンスタイプを選べばいいのか」という問いです。オンプレミスなら物理サーバーのスペックを購買部門に申請して1週間後に届く——そういう世界から来たエンジニアにとって、数百種類もあるAWSのインスタンスタイプ一覧を前にすると、何から始めればいいかわからなくなります。

この記事では、Amazon EC2の基本的な仕組みをオンプレ経験者の目線で解説します。AMIやインスタンスタイプ、セキュリティグループといったEC2特有の概念から、コンソールを使った起動手順、料金の仕組みまで、現場ですぐ実践できる内容を網羅します。

なぜAmazon EC2なのか？オンプレサーバーとの決定的な違い

Amazon EC2（Elastic Compute Cloud）は、AWSが提供する仮想サーバーサービスです。オンプレミスで言えばVMware上の仮想マシンに相当しますが、根本的に違う点が3つあります。

・起動速度: オンプレではハードウェアの調達・設定に数日から数週間かかります。EC2は数分でサーバーを立ち上げられます。
・スケーラビリティ: 負荷が増えたときに数クリックでスペックを変更できます。オンプレでCPUを増やすには物理的な交換作業が必要でした。
・課金モデル: 使った時間だけ払うオンデマンド課金が基本です。電源を切れば課金は止まります（ただしストレージは別途課金されます）。

EC2の「Elastic」という名前は、負荷に応じて柔軟にサイズを変えられることを意味しています。この柔軟性がクラウドの本質であり、オンプレとの最大の違いです。

オンプレ時代は「とりあえず大きめのサーバーを買っておく」という発想が一般的でした。調達し直すコストと手間を考えると、余裕を持ったスペックで購入するのが合理的だったからです。EC2では逆で、「小さく始めて、必要になったら大きくする」が正しいアプローチです。

EC2の基本概念を4つ押さえる

EC2を使いこなすには、4つの概念を理解することが重要です。

1. AMI（Amazon Machine Image）

AMIはOSのテンプレートです。オンプレで言えば、標準化されたOSイメージ（ゴールデンイメージ）に相当します。AmazonがAmazon Linux 2023・Ubuntu・Windows Server等の公式AMIを提供しており、そこからインスタンスを起動するのが基本的な流れです。

自社独自の設定を加えたカスタムAMIを作成することもできます。ミドルウェアをインストール済みのインスタンスをAMIとして保存しておけば、同一構成のサーバーを何台でも素早く複製できます。オンプレ時代にKickstartやPXEブートで標準イメージを管理していた経験があれば、すぐにイメージが掴めるはずです。

AMIにはリージョンという概念があります。東京リージョン（ap-northeast-1）で作成したAMIを、大阪リージョン（ap-northeast-3）でそのまま使うことはできません。AMIのコピー機能でリージョン間コピーが可能です。

2. インスタンスタイプ

インスタンスタイプとは、仮想サーバーのスペック（vCPU・メモリ・ネットワーク帯域）の組み合わせです。「t3.medium」「m6i.large」といった記号で表されます。

左端のアルファベット（t、m、c、r等）がインスタンスファミリーを示します。

・t系（汎用バースト型）: 平均的なCPU使用率が低いワークロード向け。開発環境や軽量なWebサーバーに適しています。
・m系（汎用バランス型）: CPUとメモリのバランスが良く、本番のWebアプリやAPIサーバーに向いています。
・c系（コンピューティング最適化）: CPUヘビーなバッチ処理・画像変換・高トラフィックWebに向いています。
・r系（メモリ最適化）: インメモリDB・大規模キャッシュ・高負荷RDBMSに向いています。
・i系（ストレージ最適化）: NVMe SSDを搭載し、高IOPSが必要なDBやHadoopに向いています。

数字はプロセッサの世代（数字が大きいほど新しい）、末尾の文字はオプション（n=高ネットワーク帯域、g=AWS Graviton等）を意味します。m6i.largeの「6」は第6世代、「i」はIntelプロセッサ搭載を意味します。

3. セキュリティグループ

セキュリティグループは、インスタンスに適用するファイアウォールルールです。オンプレのiptablesやファイアウォールアプライアンスに相当しますが、「ステートフル」な点が異なります。インバウンド（外→EC2）とアウトバウンド（EC2→外）のルールを設定します。

インバウンドを許可すれば、そのセッションの戻りパケットは自動的に許可されます。iptablesのESTABLISHED,RELATEDルールを意識しなくて済む分、シンプルです。

一つのインスタンスに複数のセキュリティグループを割り当てることができます。「Webサーバー用SG」と「監視サーバーからのアクセス許可SG」を分けて管理するのがベストプラクティスです。

4. キーペア

キーペアはEC2インスタンスへのSSH接続に使う公開鍵・秘密鍵のペアです。AWSコンソールで作成すると、秘密鍵ファイル（.pemファイル）をダウンロードできます。このファイルは一度しかダウンロードできないため、厳重に保管してください。

LinuxインスタンスへのSSH接続はキーペアが基本です。Windows Serverの場合はRDPのパスワード取得にキーペアを使います。

本番環境では、AWS Systems Manager Session Manager（SSM）を使うことでキーペアなし・SSHポート開放なしでインスタンスにアクセスする方法もあります。セキュリティ要件が厳しい環境ではこちらを検討してください。

基本的な使い方（コンソール操作でEC2を起動する）

では実際にEC2インスタンスをコンソールから起動してみましょう。AWSマネジメントコンソールにログインして「EC2」を検索し、EC2ダッシュボードを開きます。

1. AMIの選択

「インスタンスを起動」ボタンをクリックすると、まずAMI選択画面が表示されます。

初めてAWSを触る場合は「Amazon Linux 2023」を選ぶのが無難です。AWSが最適化した軽量なLinuxディストリビューションで、パッケージ管理はdnfを使います（CentOS系に近い操作感です）。Amazon Linux 2023はKernel 6系を採用しており、AWS特有のサービスとの親和性も高く設計されています。

Ubuntuを選ぶ場合はLTS版（例: Ubuntu 24.04 LTS）を選びましょう。apt管理に慣れているDebian/Ubuntu系エンジニアに向いています。

2. インスタンスタイプの選択

AMIを選んだらインスタンスタイプを選択します。まずは「t3.micro」か「t3.small」で始めることを推奨します。t3.microはAWSの無料利用枠（12ヶ月間、月750時間）の対象なので、学習用途なら料金を気にせず試せます。

本番環境では以下を参考に選びましょう。

3. ネットワーク設定とセキュリティグループの設定

次にネットワーク設定を行います。デフォルトではアカウント作成時に自動生成された「デフォルトVPC」が選択されています。

セキュリティグループは新規作成するか、既存のものを選びます。SSH（ポート22）接続が必要な場合は、「マイIPのみ許可」を選ぶことを強く推奨します。0.0.0.0/0（全インターネット）に開放するのは絶対に避けてください。ブルートフォース攻撃の標的になります。

Webサーバーとして使う場合は、HTTP（80番）とHTTPS（443番）を0.0.0.0/0で開放し、SSHは管理者のIPのみに絞るのが基本的な設定です。

4. キーペアの設定とインスタンス起動

「新しいキーペアを作成」を選び、キーペア名を入力して「キーペアを作成」をクリックします。.pemファイルが自動ダウンロードされます。

# ダウンロードした秘密鍵ファイルの権限を設定（Linux/Mac）
chmod 400 my-keypair.pem

# EC2インスタンスへのSSH接続（パブリックIPは実際の値に置き換える）
ssh -i my-keypair.pem ec2-user@[パブリックIPアドレス]

# Amazon Linux 2023の場合、デフォルトユーザーはec2-user
# Ubuntuの場合はubuntu、Debianの場合はadmin、RHELの場合はec2-user

設定が完了したら「インスタンスを起動」ボタンをクリックします。数分でインスタンスが「実行中」ステータスに変わります。インスタンスIDをメモしておくと、後からコンソールで素早く見つけられます。

インスタンスタイプの選び方——現場での判断基準

オンプレからクラウド移行する際、既存サーバーのスペックをそのままEC2に当てはめようとするエンジニアが多いですが、これは注意が必要です。

CPUは「vCPU数」ではなく「使用率」で判断する

オンプレの物理サーバーが32コアだったからといって、c6i.8xlarge（32vCPU）を選ぶ必要はありません。多くの場合、実際のCPU使用率は20〜30%程度です。移行前にサーバーのCPU・メモリ使用率を計測し、ピーク時の値に合わせたインスタンスを選ぶことで、コストを大幅に削減できます。

CloudWatchエージェントをオンプレサーバーに導入して事前に使用率を収集しておくと、適切なインスタンスタイプ選定に役立ちます。AWS Migration Hubの「リフト＆シフト計算ツール」も参考になります。

t系の「バースト」を誤解しない

t3インスタンスは「CPUクレジット」を使ったバースト型課金モデルです。平時はCPUクレジットを蓄積し、負荷急増時に使い切ります。クレジットを使い切るとCPU使用率が20〜30%程度に制限されます。継続的に高負荷がかかるワークロードにはt系ではなくm系・c系を選びましょう。

t3インスタンスには「unlimited」モードがあり、追加料金でバースト制限を解除できます。ただし想定外の高額請求につながることもあるため、本番環境では要注意です。

インスタンスタイプはあとから変更できる

EC2の大きなメリットの一つが、インスタンスタイプの変更が容易なことです。インスタンスを一時停止（Stop）してタイプを変更し、再起動するだけです。オンプレで物理メモリを追加するような手間はありません。

本番前は小さめから始めて、CloudWatchでCPU・メモリ使用率を監視しながらスペックを上げていく「右サイジング」のアプローチが合理的です。AWS Compute Optimizerを使うと、使用率データをもとに最適なインスタンスタイプを自動的に提案してくれます。

料金の仕組み（コスト感覚を掴む）

EC2の料金は主に「インスタンスの稼働時間」と「EBSストレージ」で構成されます。

オンデマンドインスタンスの料金（2026年4月時点）

代表的なインスタンスタイプの東京リージョン（ap-northeast-1）での料金です。

【重要】インスタンスを停止しても課金が続くものがある

インスタンスを「停止（Stop）」するとインスタンス本体の課金は止まります。しかしEBSボリューム（ルートボリューム）は停止中も課金され続けます。gp3ボリュームで$0.096/GB/月（2026年4月時点）なので、30GBのルートボリュームなら月約$2.88の課金が続きます。完全に不要になったインスタンスは「終了（Terminate）」することでEBSも削除されます。

また、Elastic IPアドレス（固定パブリックIP）はインスタンスに紐付いていない状態だと課金されます。停止中のインスタンスに割り当てたEIPは、インスタンス停止中でも課金されるため注意が必要です。

リザーブドインスタンスとSavings Plansで大幅割引

1年・3年の長期利用コミットメントをすることで、オンデマンド比最大72%割引になります。本番環境の24時間稼働インスタンスには積極的に活用しましょう。

よくあるトラブルと対処法

【トラブル1】SSH接続できない

最も多いトラブルです。原因の切り分けは以下の順で確認します。

・セキュリティグループ: インバウンドにポート22/TCPが自分のIPから許可されているか確認します。
・パブリックIPの確認: EC2コンソールで「パブリックIPv4アドレス」が割り当てられているか確認します（サブネットがパブリックでない場合は割り当てられません）。
・秘密鍵の権限: chmod 400 でパーミッションが設定されているか確認します。Permission denied (publickey) というエラーが出る場合は権限不足が疑われます。
・接続ユーザー名: AMIによってデフォルトユーザー名が異なります（Amazon Linux: ec2-user、Ubuntu: ubuntu、RHEL: ec2-user、Debian: admin）。
・インターネットゲートウェイ: VPCにインターネットゲートウェイがアタッチされているか、サブネットのルートテーブルに0.0.0.0/0→IGWのルートがあるか確認します。

【トラブル2】インスタンスが起動直後に停止する

ユーザーデータ（起動スクリプト）のエラーが原因であることが多いです。「システムログを取得」からEC2コンソールで起動ログを確認できます。また、インスタンスに十分なIAMロールの権限がない場合も起動後のスクリプトが失敗します。

【トラブル3】インスタンスタイプを変更しようとしたが変更できない

インスタンスが「実行中」状態のままではタイプを変更できません。必ず「停止（Stop）」してから変更してください。また、仮想化タイプ（HVM vs PV）が異なるインスタンスファミリーへの変更は制限があります。古いPVインスタンスをHVMに変更したい場合は、AMIを作成してHVMインスタンスとして起動し直す必要があります。

【トラブル4】予期せぬ高額請求が来た

よくある原因として、不要になったインスタンスを「停止」のみで放置したケースがあります。EBSやEIPの課金が積み重なります。AWS Budgetsで月額上限を設定してアラートを受け取る習慣をつけましょう。「$XX を超えたらメール通知」という設定を最初にしておくと安心です。

本記事のまとめ

Amazon EC2の基本について、オンプレ経験者の視点で解説しました。要点をまとめます。

・EC2とオンプレの違い: 起動速度・スケーラビリティ・オンデマンド課金が根本的に異なります。「大きめを買っておく」発想から「小さく始めて大きくする」発想への転換が重要です。
・4つの基本概念: AMI（OSテンプレート）・インスタンスタイプ（スペック）・セキュリティグループ（FW）・キーペア（SSH認証）を押さえることが出発点です。
・インスタンスタイプ選択: 用途に合ったファミリー選択が重要。開発環境はt3系、本番WebはCPU使用率を計測してからm6i系で選定しましょう。
・コスト管理: 停止中もEBSとEIPは課金されます。不要なリソースはTerminateする習慣を。Budgetsでアラートを設定しましょう。
・SSHトラブル: セキュリティグループ・パブリックIP・ユーザー名・IGWルートの4点を確認する順序で切り分けます。

EC2の基礎を身につけたら、次のステップとしてVPCのネットワーク設計やAuto Scalingによる可用性向上に進むことをお勧めします。

姉妹サイトLinuxMaster.JPでは、EC2上で動かすLinuxサーバーの管理コマンドやシェルスクリプトについて詳しく解説しています。クラウド上のLinuxを扱うなら、ぜひあわせてご確認ください。