本記事は、
「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 実践編】