AWS EC2の設計と構築入門｜インスタンス選定・AMI・起動テンプレートまで

HTML形式で、3000～5000字の完全な記事に仕上げます。

※本記事はプロモーションを含みます。

EC2をただ起動するだけでなく、本番環境で安定稼働させるための設計判断が重要です。インスタンスタイプの選び方からAMI作成・起動テンプレート、さらにマルチAZ構成まで、現役IT講師が実務で使える知識をわかりやすく解説します。この記事を読むことで、インスタンス選定の判断軸、カスタムAMIの作成フロー、本番環境での構築パターンが身につきます。読了時間：約10分

EC2とは何か？クラウドコ…

Amazon EC2（Elastic Compute Cloud）は、AWS提供のクラウドサーバーサービスです。オンプレミスでサーバーを購入・設置・保守する必要なく、Webコンソールまたはコマンドラインから数分でサーバーを起動できます。

EC2の最大の特徴は、柔軟なスケーリングが可能という点とされています。需要に応じてインスタンス台数を増減させたり、インスタンスのサイズを変更したりできるため、固定的なオンプレミスインフラとは異なる運用が可能です。

ただし、EC2をただ起動するだけでは本番環境に耐えられません。「とりあえずt3.microで立てた」というアプローチでは、トラフィック増加時にサーバーがダウンしたり、コスト面で不利になったりするリスクがあります。以降は、EC2を本番環境で安定稼働させるための設計判断のポイントを、実務経験に基づいて解説します。

インスタンスタイプの選び方…

インスタンスファミリーの特…

AWS EC2のインスタンスタイプは、大きく6つのファミリーに分類されるとされています。各ファミリーは、vCPU（仮想CPU）・メモリ・ネットワーク帯域という3つの主要リソースの組み合わせで成り立っています。

本番環境では、「どのリソースがボトルネックになるか」を先に見極めることが重要です。

• CPU処理が主体の場合：c系（CPU最適化）を選定。ただし過度な選定は避け、定期的に CloudWatch でCPU使用率を監視する必要があります
• メモリ消費が多い場合：r系（メモリ最適化）。キャッシュDBやメモリ上の大規模データ処理に適しています
• 一般的なWebアプリ・APIサーバーの場合：m系（汎用）がバランスの取れた選択肢とされています
• 開発・テスト環境の場合：t系（バースト型）で十分です。ただし本番環境では注意が必要です

vCPU・メモリ・ネットワ…

インスタンスタイプの選定では、vCPUやメモリの「個数」だけを見てはいけません。ネットワーク帯域とストレージIOPS（Input/Output Operations Per Second）も考慮する必要があります。

例えば、m6i.large（vCPU 2・メモリ8GB）と m6i.xlarge（vCPU 4・メモリ16GB）を比較すると、単にvCPUとメモリが2倍になるだけでなく、ネットワーク帯域も増加するということをご存知でしょうか。

データベースとの通信が多いアプリケーションの場合、ネットワーク帯域が不足すると、CPU・メモリに余裕があってもボトルネックになる可能性があります。AWS公式ドキュメント（出典：AWS EC2 インスタンスタイプ）では、各インスタンスタイプのネットワーク帯域が詳細に記載されているため、設計段階で必ず確認しましょう。

AMI（Amazon Ma…

ベースAMI選定のポイント

AMIとは、EC2から起動可能なOSイメージです。AWSは複数の公式ベースAMIを提供しており、以下の中から選定することが一般的とされています。

• Amazon Linux 2023：AWS最適化。yumパッケージマネージャーを搭載。AWSと親和性が高く、セキュリティパッチも迅速に提供されます
• Ubuntu 22.04 LTS：コミュニティサポートが充実。エンジニアに広く使われており、ドキュメントが豊富です
• RHEL 9（Red Hat Enterprise Linux）：企業向け。有償サポートが手厚く、大規模環境での利用が増えています
• CentOS Stream：RHELのコミュニティ版。RHELよりも新機能が先に入りますが、サポート期間に注意が必要です

組織のスキルセット・既存環境・サポート体制を考慮したうえで、長期的にメンテナンス可能なOSを選定することが重要です。「なんとなく見かけたから」という理由で選ぶと、数年後にサポート終了を迎えるリスクが生じます。

カスタムAMI作成の実践フロー

本番環境では、単体のベースAMIから毎回手動でミドルウェアをインストールする方法は避けるべきとされています。理由は、手作業による人的ミスやドリフト（構成の乖離）が発生するためです。

以下が、カスタムAMI作成の推奨フローです。

1. ベースAMIを選定：Amazon Linux 2023 や Ubuntu 22.04 LTS など目的に応じて選択
2. EC2インスタンスを起動：選定したAMIからインスタンスを起動
3. ミドルウェアをインストール：SSHで接続し、Nginx・Java・Python・その他必要なソフトウェアをセットアップ。可能な限りシェルスクリプトで自動化することが望ましいとされています
4. アプリケーション設定を投入：本番環境用の設定ファイルをコピー
5. テストを実行：起動したインスタンス上で簡易的な動作確認を実施
6. カスタムAMIを作成：AWSコンソールで「イメージを作成」を選択するか、AWS CLIで以下を実行：
   aws ec2 create-image --instance-id i-1234567890abcdef0 --name "MyCustomAMI-20250102" --description "Production Web Server Image"
7. イメージID（AMI ID）を確認：ami-xxxxxxxx の形式で、起動テンプレートに登録する際に必要になります

カスタムAMIを一度作成すれば、その後Auto Scalingによる自動スケーリング時も、確実に同じ構成のインスタンスが起動される可能性が高まります。

起動テンプレートと本番構成…

起動テンプレートの役割と設…

起動テンプレート（Launch Template）は、EC2起動時の各種設定（インスタンスタイプ・AMI・セキュリティグループ・ストレージ設定等）を一つのテンプレートとして保存する機能です。

起動テンプレートの主な設定項目は以下の通りとされています。

• AMI ID：前章で作成したカスタムAMI、または公式ベースAMIを指定
• インスタンスタイプ：t3.medium・m6i.large など、ワークロードに応じた選定
• キーペア：SSH接続用。本番環境では Systems Manager Session Manager の利用を検討し、SSHキーの管理負荷を減らす手段も存在します
• セキュリティグループ：インバウンド・アウトバウンドルール。後述します
• EBSボリューム設定：ルートボリューム・データボリュームのタイプ・サイズ・IOPS・スループットを指定
• ユーザーデータ：インスタンス起動時に自動実行するシェルスクリプト。ただし複雑な初期化は避け、カスタムAMIに予め含めることが推奨されています
• IAMインスタンスロール：EC2がAWSサービスにアクセスする際の権限。S3・RDS・CloudWatch ログなど、アプリケーションが必要とする権限のみをIAMポリシーで定義
• タグ：本番・ステージング・開発 などの環境を識別。コスト配分タグとしても機能します

マルチAZ構成と可用性の確保

AWS東京リージョン（ap-northeast-1）には複数のアベイラビリティーゾーン（AZ：a・c・d など）が存在するとされています。本番環境では、単一AZではなく複数AZにEC2インスタンスを分散配置することが重要です。

1AZが障害を起こした場合も、別AZのインスタンスでサービスを継続できる仕組みを構築します。構成図は以下の通りです。

• Application Load Balancer（ALB）：複数AZのEC2に対してトラフィックを分散
• EC2インスタンス：AZ-a に2台、AZ-c に2台（計4台）を配置。Auto Scalingで台数を自動調整
• RDS Database：マルチAZデプロイメントで、プライマリ・スタンバイを異なるAZに配置

この構成により、1AZ障害時もサービスがダウンしない冗長性が実現されるとされています。

本番環境で必須のセキュリテ…

セキュリティグループの設定…

セキュリティグループは、EC2に対するファイアウォールの役割を果たします。インバウンド（外部からのアクセス）・アウトバウンド（EC2からの発信）のトラフィックを制御します。

本番環境では、「必要なポート・ソースIPのみを明示的に許可する」という最小権限の原則が重要です。よくある誤りを以下に列挙します。

セキュリティグループの設定は、AWS公式ドキュメント（出典：AWS セキュリティグループ ベストプラクティス）で最新の推奨事項を確認することをお勧めします。

EBSボリューム設計のポイント

EBS（Elastic Block Store）は、EC2に接続するブロックストレージです。ルートボリューム（OS・アプリケーションが入る）とデータボリュームに分けて設計することが推奨されているとされています。

• ルートボリューム：通常 gp3（汎用SSD）を選定。サイズは50～100GB程度。OSとアプリケーション、ログディレクトリが入ります
• データボリューム：ログ・キャッシュ・アップロードファイルなどを格納。こちらも gp3 推奨。IOPSとスループットを個別調整可能（デフォルトは 3000IOPS・125MB/s）です。大規模ログの場合はIOPSを上げることで性能向上の可能性があります
• io2（高性能SSD）：金融システム・大規模DB等、極めて高いIOPS要求がある場合に限定

また、EBSボリュームはスナップショット機能で定期バックアップを取得することが重要です。AWSバックアップサービスにより、スナップショット取得を自動化できます。

コスト最適化とモニタリング

本番環境の設計段階で、コスト予測も欠かせません。以下の施策で、無駄を削減しつつ安定性を確保できるとされています。

• Auto Scaling の下限・上限設定：常に最大構成を保つのではなく、スケーリングポリシーで「CPU 70% を超えたらスケールアウト」などの条件を設定。スケールインも同様に設定し、不要な時間帯の台数を削減
• Reserved Instance（RI）の活用：本番環境で常時稼働するインスタンスについて、RIを購入すると最大72%のコスト削減になる可能性があります
• Spot Instance の活用（テスト環境・非本番向け）：オンデマンド価格の70～90%割引で利用可能。ただし突然終了する可能性があるため、本番環境では推奨されません
• CloudWatch での監視：CPU・メモリ・ネットワーク・ディスク使用率を常時監視。アラーム設定により、リソース不足を事前に検知できます

AWS Compute Optimizer サービスを活用すると、現在のリソース使用パターンに基づいて、最適なインスタンスタイプを提案してくれるとされています。定期的に確認することで、過剰なスペック・過少なスペックを是正できます。

まとめ～EC2設計で押さえ…

AWS EC2を本番環境で安定稼働させるための設計判断について、以下の5点をまとめます。

1. インスタンスタイプは、ワークロードのボトルネックに基づいて選定する：vCPU・メモリ・ネットワーク帯域を総合的に判断し、t系・m系・c系・r系を使い分ける
2. カスタムAMIで環境の再現性を確保する：ベースAMI選定→ミドルウェアインストール→テスト→AMI化のフローを定型化し、手作業を最小化する
3. 起動テンプレートで構成を一元管理する：インスタンスタイプ・AMI・セキュリティグループ・EBS設定を起動テンプレートに保存し、Auto Scaling と組み合わせる
4. マルチAZ構成と ALB 分散で可用性を確保する：1AZ障害でもサービス継続できる冗長構成を構築する
5. セキュリティグループ・IAMロール・セキュリティ設定は常に最新ドキュメントで確認する：AWSセキュリティベストプラクティス公式ドキュメント（出典：AWS セキュリティ ベストプラクティス）の最新情報を参照し、定期的に設定を見直す

本番環境構築は、初期段階での設計判断が後々のトラブルや追加コストに大きく影響します。この記事で解説した知識を基に、ワークロード・予算・チームスキルに応じたバランスの取れたEC2設計を実現していただきたいと思います。

著者：吉田たかし｜元ネットワークエンジニア・現役IT講師

CCNA・CCNP・LPIC-1・AZ-900 取得。14年のインフラエンジニア経験を持つ現役IT講師。AWS研修・SES案件でEC2設計を多数経験した立場から、インフラエンジニアが最初に知るべき設計ポイントをまとめました。

Infra Academy｜インフラエンジニアの育成・転職支援

AWS・Azure・GCP の実務トレーニングからCCNA/LPIC資格取得サポート、SES案件マッチングまで、現役IT講師がトータルでサポートします。無料相談はお問い合わせページからご連絡ください。

※ AWSのインスタンスタイプ・サービス仕様・料金・セキュリティベストプラクティスは変更される場合があります。最新情報は AWS公式ドキュメント でご確認ください。

—

完成した記事の特徴

ABOUT ME

たから

サラリーマンをしながら開業して経営やってます。 今年、本業で独立・別事業を起業予定です。 ◆経験：IT講師/インフラエンジニア/PM/マネジメント/採用/運用・保守・構築・設計 ◆取得資格：CCNA/CCNP/LPIC-1/AZ-900/FE/サーティファイC言語 ◆サイドビジネス：アパレル事業/複数のWEBメディアを運営