本記事は、
「AWS 上に安全に入れるサーバを用意する」ことに集中した回です。
第1回では、構成方針やコスト、IAM 設計といった
AWS を触る前の準備 を行いました。
本記事ではその続きとして、
- デフォルト VPC を使わずに VPC を作成し
- Public / Private Subnet を分け
- EC2 を適切なネットワークに配置し
- SSH で安全に接続し
- Docker を使える状態まで初期セットアップする
ところまでを一気に進めます。
ここで作る EC2 は、
「とりあえず触れる検証用サーバ」ではなく、
今後どんなアプリ構成にも拡張できる“土台” です。
少し地味な作業が続きますが、
この工程を雑にすると、
後から必ず構成を作り直すことになります。
腰を据えて、
実務を意識した AWS 基盤 を作っていきましょう。
第4章：EC2とネットワーク設計
— デフォルトVPCを使わず、実務を意識して構築する —
1. この章の目的
この章では、以下をゴールとします。
- デフォルトVPCに頼らず 自分でVPCを設計・作成できる
- EC2が「どのネットワークに、なぜ配置されているのか」を説明できる
- 将来的なスケールアップ（t3.micro → t5.large）を 設計段階で邪魔しない構成を作る
👉
業務レベルでAWSを使えるかどうかは、VPC設計でほぼ決まると言っても過言ではありません。
2. なぜデフォルトVPCを使わないのか
AWSには最初から「デフォルトVPC」が用意されていますが、
本記事では あえて使用しません。
デフォルトVPCの問題点
- すべてのサブネットがPublic前提
- なぜ通信できているのかが分かりにくい
- 業務システムではほぼ使われない
- 設計意図を説明できない
👉
「動くが説明できない構成」は、実務では通用しない
3. 今回作成するネットワーク構成
構成イメージ
VPC: 10.0.0.0/16
├─ Public Subnet (10.0.1.0/24)
│ └─ EC2（nginx / Docker）
│
└─ Private Subnet (10.0.2.0/24)
└─（将来用：DB / 内部サービス）
設計ポイント
- Public / Private を論理的に分離
- EC2は Public Subnet に配置
- Private Subnet は 今は使わないが設計に含める
👉
「今使わないが、将来を見据えて用意する」
これが実務的な設計です。
4. VPCの作成
4.1 基本設定
| 項目 | 値 |
|---|---|
| 名前 | webapp-vpc |
| IPv4 CIDR | 10.0.0.0/16 |
| IPv6 | なし |
CIDR設計の考え方
-
/16：将来サブネットを増やしやすい -
10.0.x.0/24：用途ごとに分割しやすい
👉
業務でも非常によく使われる定番パターン
5. サブネットの作成
5.1 Public Subnet
| 項目 | 値 |
|---|---|
| 名前 | public-subnet-1a |
| AZ | ap-northeast-1a |
| CIDR | 10.0.1.0/24 |
5.2 Private Subnet
| 項目 | 値 |
|---|---|
| 名前 | private-subnet-1a |
| AZ | ap-northeast-1a |
| CIDR | 10.0.2.0/24 |
👉
AZは1つで十分。冗長化は今回の目的ではありません。
6. インターネットゲートウェイ（IGW）
IGWとは
VPCをインターネットに接続するための出口
作成・設定
- 名前：webapp-igw
- 作成後、必ずVPCにアタッチ
👉
IGWが無いVPCは外部通信できない
7. ルートテーブルの設定（最重要）
7.1 Public Subnet 用ルートテーブル
| 宛先 | ターゲット |
|---|---|
| 0.0.0.0/0 | Internet Gateway |
- 名前：public-rt
- public-subnet-1a に関連付け
7.2 Private Subnet 用ルートテーブル
- 名前：private-rt
- デフォルトルートのみ（外向き通信なし）
- private-subnet-1a に関連付け
👉
Private Subnet は インターネットに出られない 状態が正解。
8. EC2インスタンス作成（ネットワーク指定）
EC2作成時、以下を必ず指定します。
| 項目 | 値 |
|---|---|
| VPC | webapp-vpc |
| サブネット | public-subnet-1a |
| パブリックIP | 有効 |
インスタンスタイプ
- t3.micro
理由は第2章で説明した通りです。
9. セキュリティグループ設計
設計思想
セキュリティグループは
「サブネット」ではなく「役割」に付ける
今回の設定
| 用途 | ポート | 許可元 |
|---|---|---|
| SSH | 22 | 自分のグローバルIP |
| HTTP | 80 | 0.0.0.0/0 |
| HTTPS | 443 | 後で追加 |
⚠️
SSH を 0.0.0.0/0 で開けるのは論外
10. 将来のスケールアップ（t5.large）を見据えた設計
なぜ今から意識するのか
- インスタンスタイプ変更は「停止 → 起動」が必要
- 停止時にIPが変わると運用が破綻する
👉
このため、後続章で Elastic IP を必ず設定します。
11. よくある初学者のNG構成
❌ すべてPublic Subnet
- セキュリティ事故の温床
- レビューで即修正対象
❌ CIDRを適当に決める
- 後から拡張できない
- VPC作り直しになる
❌ Private Subnetの意味を理解していない
- インターネットに出られず詰まる
- 「壊れた」と誤解しがち
12. この章のまとめ
- VPCは「ネットワークの箱」
- Public / Private 分離は実務の基本
- IGWとルートテーブルが通信を決める
- EC2はPublic、DBはPrivateが原則
- 将来のスケールを設計段階で潰さないことが重要
第5章：EC2へのSSH接続と初期セットアップ
— サーバに安全に入り、Dockerを使える状態を作る —
1. この章の目的
この章では、以下をゴールとします。
- EC2 インスタンスへ SSHで安全に接続できる
- Linux サーバとしての 最低限の初期設定 を行う
- Docker / docker-compose を導入し、
今後どんな構成にも拡張できる実行基盤を整える
👉
この章は、以降すべての章の土台になります。
2. SSH接続前の前提条件チェック
以下がすべて満たされていることを確認してください。
- EC2 が
running状態 - セキュリティグループで以下を許可
- TCP 22（SSH）
- 許可元：自分のグローバルIPのみ
- キーペア（
.pemファイル）を手元に保存済み - Elastic IP が EC2 に関連付け済み
👉
この時点で SSH ができない場合、
ほぼ100% セキュリティグループ設定ミスです。
3. SSHでEC2に接続する
3.1 秘密鍵ファイルの権限設定
Linux / macOS / WSL 環境では、
秘密鍵のパーミッションを制限する必要があります。
chmod 400 your-key.pem
理由：
- 秘密鍵が他人に読める状態だと SSH が拒否される
- セキュリティ事故防止のため
3.2 SSH接続コマンド
ssh -i your-key.pem ec2-user@<Elastic-IP>
例：
ssh -i webapp-key.pem ec2-user@18.xxx.xxx.xxx
3.3 接続成功時の状態
以下のようなプロンプトが表示されれば成功です。
[ec2-user@ip-10-0-1-xx ~]$
👉
AWS上のLinuxサーバに入った状態です。
4. 初回ログイン後に必ず行う基本設定
4.1 OSアップデート
sudo dnf update -y
なぜ必要か
- セキュリティパッチの適用
- 既知の脆弱性対策
- 古いパッケージによる不具合防止
👉
EC2初回ログイン時の定石
4.2 タイムゾーンを日本時間に設定
sudo timedatectl set-timezone Asia/Tokyo
確認：
timedatectl
理由
- ログの時刻ズレを防ぐ
- 障害調査・ログ解析を容易にする
5. Docker のインストール
5.1 Docker のインストール
sudo dnf install docker -y
5.2 Docker サービスの起動と自動起動設定
sudo systemctl start docker
sudo systemctl enable docker
5.3 ec2-user を docker グループに追加
sudo usermod -aG docker ec2-user
⚠️
この設定を反映させるため、一度ログアウトが必要です。
5.4 再ログイン
exit
ssh -i your-key.pem ec2-user@<Elastic-IP>
5.5 Docker 動作確認
docker --version
docker ps
- エラーが出なければOK
-
permission deniedが出る場合は、再ログインできていない可能性あり
6. docker-compose のインストール
6.1 docker-compose バイナリ取得
sudo curl -L \
https://github.com/docker/compose/releases/download/v2.27.0/docker-compose-linux-x86_64 \
-o /usr/local/bin/docker-compose
6.2 実行権限付与
sudo chmod +x /usr/local/bin/docker-compose
6.3 動作確認
docker-compose version
👉
バージョンが表示されれば成功。
7. 作業ディレクトリの作成（実務前提）
推奨ディレクトリ構成
mkdir -p ~/app
cd ~/app
なぜこの構成にするのか
- OS設定とアプリを分離できる
- EC2移行・再構築時に扱いやすい
- バックアップ範囲を限定できる
👉
以降の作業はすべて ~/app 配下で行う
8. SSH周りのセキュリティ確認
8.1 パスワードログインの確認
Amazon Linux 2023 では、
デフォルトで無効になっています。
sudo grep PasswordAuthentication /etc/ssh/sshd_config
no であれば問題ありません。
8.2 root ログインの確認
sudo grep PermitRootLogin /etc/ssh/sshd_config
no であればOK。
👉
SSHは「鍵認証＋一般ユーザー」が原則
9. 初学者がやりがちなNG例
❌ Dockerを sudo 付きで使い続ける
sudo docker ps
- 権限設計が破綻する
- CI/CDやスクリプト化が困難になる
❌ OS直下にアプリを配置する
/var/www
/usr/local/app
- 管理不能になりがち
- 移行・バックアップが困難
❌ docker-compose を yum / dnf で探す
- バージョンが古い
- 公式仕様とズレる
👉
公式バイナリを使うのが正解
10. この章のまとめ
- SSHは鍵認証＋IP制限が基本
- 初回ログインでOS更新・TZ設定
- Dockerは公式手順で導入する
- docker-composeは手動配置
- 作業ディレクトリを明確に分ける
おわりに
本記事では、
- 自前 VPC の作成
- ネットワーク設計の考え方
- EC2 の配置
- SSH 接続と初期セットアップ
- Docker / docker-compose の導入
までを行い、
「Docker を動かせる EC2」 が完成しました。
次回はいよいよ、この EC2 上で
実際にコンテナを起動し、
ブラウザからアクセスできるところまで進めます。
まずは最小構成として、
- nginx コンテナを起動し
- 自作 HTML が表示されることを確認する
ところから始め、
徐々に実務的な構成へ発展させていきます。
👉 次回：AWS初学者が“実務を意識して”Webアプリ基盤を構築する 【③ Docker × nginx 実践編】