AWS EC2構築実践：個人ブログ環境の立ち上げ記録

はじめに

個人ブログを公開するためのインフラ構築において、AWS EC2は最も基本的で確実な選択肢の一つです。しかし、最小限の構成であっても、DNSの設定、セキュリティグループの適切な構成、そして開発環境の準備には多くの知識が必要となります。

本記事では、実際にゼロからEC2環境を構築する過程で発生した問題と、その解決方法を実践的に解説します。Route 53でのDNS設定、セキュリティグループのアウトバウンドルールに関する重要な学び、そしてUbuntu 24.04における最新のDocker導入方法まで、実際の作業をもとに詳しくお伝えします。

まずRoute 53でのホストゾーン作成から始め、次にEC2インスタンスの構築、そして実際に遭遇したトラブルシューティングについて順を追ってご紹介します。

Route 53によるDNS環境の構築

ホストゾーンの作成と設定

独自ドメインをブログに割り当てるため、AWS Route 53でパブリックホストゾーンを作成しました。AWS Route 53は、信頼性の高いDNSサービスを提供するマネージドサービスです。

ホストゾーン作成時、AWSが自動的に4つのネームサーバを割り当てます。これらのネームサーバは、以下のような形式で提供されます。

• ns-357.awsdns-44.com
• ns-1447.awsdns-52.org
• ns-908.awsdns-49.net
• ns-1649.awsdns-14.co.uk

この段階では、Aレコードはまだ設定せず、後ほどEC2インスタンスのElastic IPが確定してから割り当てる方針としました。この段階的なアプローチにより、インフラの各要素を確実に構築できます。

ドメインレジストラのネームサーバ変更

ドメインを管理しているレジストラ側のネームサーバ設定を、AWS Route 53が提供するネームサーバに変更する必要があります。今回のケースでは、ConoHaのネームサーバが残っていたため、AWS側で払い出された4つのネームサーバに書き換えて保存しました。

DNS情報の伝播には、通常24時間から48時間程度かかることに注意してください。この期間中は、一部のユーザーが古いDNS情報を参照する可能性があります。

EC2インスタンスの構築と基本設定

最小構成のインスタンス作成

個人ブログに必要な最小限の構成でEC2インスタンスを作成しました。過剰なリソースを避けることで、コストを抑えながら十分なパフォーマンスを確保できます。

選択した構成は以下の通りです。

• AMI：Ubuntu Server 24.04 LTS
• インスタンスタイプ：t3.micro
• セキュリティグループ：SSH（22）、HTTP（80）、HTTPS（443）

Ubuntu 24.04 LTSを選択した理由は、長期サポートが提供される安定したバージョンであり、最新のセキュリティアップデートが継続的に提供されるためです。t3.microインスタンスは、個人ブログ程度のトラフィックであれば十分な処理能力を持ちます。

Elastic IPの割り当てと関連付け

Elastic IPをインスタンスに紐付けることで、公開用の固定IPv4アドレスを確保しました。EC2インスタンスは再起動時にIPアドレスが変わる可能性がありますが、Elastic IPを使用することでこの問題を回避できます。

重要な注意点：Elastic IPを取得しただけでは不十分です。必ずEC2インスタンスに関連付ける（Associate）操作を実行する必要があります。この関連付けを忘れると、以下のような問題が発生します。

• Route 53のAレコードがElastic IPを指していても、EC2インスタンスに到達できない
• ドメイン名での接続が失敗する
• SSH接続やHTTP/HTTPS通信が確立できない

Elastic IPの関連付けは、AWSコンソールの「Elastic IPs」画面から、対象のIPアドレスを選択し、「Associate Elastic IP address」を実行することで完了します。関連付け後は、以下のような形式のパブリックDNSが提供されます。

ec2-xx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com

このDNS名を使用して、初回のSSH接続を試みることができます。また、Route 53のAレコードには、このElastic IPアドレスを設定することで、独自ドメインとEC2インスタンスを正しく結びつけることができます。

インフラ構成の全体像

構築したインフラの全体像を図示すると、以下のような構成になります。

flowchart TB

subgraph Registrar["Route 53（レジストラ）"]
    NS["ネームサーバ設定（4つのAWS NS）"]
end

subgraph HostedZone["Route 53 Hosted Zone"]
    ARec["Aレコード → Elastic IP"]
end

subgraph VPC["VPC（東京リージョン）"]
    SG["Security Group（SSH/HTTP/HTTPS）"]
    EIP["Elastic IP"]
    EC2["EC2（Ubuntu 24.04 / t3.micro）"]
end

NS --> HostedZone
HostedZone --> ARec
ARec --> EIP
EIP --> EC2
EC2 --> SG

この構成により、ドメイン名からEC2インスタンスまでの通信経路が確立されます。Route 53がDNSクエリを処理し、AレコードがElastic IPを指し、最終的にEC2インスタンスに到達する流れです。

トラブルシューティング：SSH接続の問題

アウトバウンドルールの重要性

EC2インスタンスを作成後、AWSが推奨するSSH接続コマンドを実行しても、接続が確立できない問題に直面しました。この問題の原因は、セキュリティグループのアウトバウンド（送信）ルールにありました。

初期設定では、アウトバウンドルールがICMPのみを許可する状態になっていました。この設定では、EC2インスタンスからインターネットへの通信が完全に遮断されるため、以下のような重要な通信がすべて失敗します。

• SSHハンドシェイク
• NTP（時刻同期）
• DNS解決
• HTTPS通信
• パッケージマネージャ（apt）の更新

解決方法と設定変更

アウトバウンドルールを以下のように変更することで、問題を解決しました。

• プロトコル：All traffic
• 送信先：0.0.0.0/0

この設定により、EC2インスタンスから外部への通信が可能になり、SSHも安定して接続できるようになりました。セキュリティの観点から、アウトバウンド通信を制限したい場合は、必要なポートとプロトコルを個別に許可する方法も検討できます。

パッケージ管理におけるネットワーク問題

apt updateのタイムアウト

SSH接続が確立した後も、パッケージ管理システムの更新コマンド（apt update）が完全に停止する状態が続きました。ログには以下のようなエラーメッセージが繰り返し表示されました。

Could not connect to ap-northeast-1.ec2.archive.ubuntu.com:80

この問題も、前述のアウトバウンド通信の制限が原因でした。aptコマンドは、パッケージリポジトリサーバとHTTP（ポート80）またはHTTPS（ポート443）で通信する必要があります。

ネットワーク設定の確認方法

アウトバウンドルールを修正した後は、aptコマンドが正常に実行されるようになりました。このような問題が発生した場合、以下の手順で確認することをお勧めします。

1. セキュリティグループのアウトバウンドルールを確認

2. VPCのネットワークACL設定を確認

3. インスタンス内でネットワーク接続をテスト（pingやcurlコマンド）

開発環境の自動構築

セットアップスクリプトの作成

毎回手動でパッケージをインストールする手間を省くため、必要なツールを一括でインストールするシェルスクリプト（setup.sh）を作成しました。スクリプト化することで、環境の再現性が高まり、複数のサーバで同じ環境を簡単に構築できます。

スクリプトに含めた主要なカテゴリは以下の通りです。

• 基本ツール：git、curl、jq、build-essentialなど
• Node.js：Nodesource提供のLTS版
• Python環境：pip、venv
• Docker：コンテナ実行環境
• Nginx：Webサーバ
• Fail2ban：セキュリティ対策ツール

Ubuntu 24.04における課題

スクリプト実行時に、docker-compose-pluginパッケージがaptリポジトリに存在しないというエラーが発生しました。これは、Ubuntu 24.04（コードネーム：noble）において、Dockerのパッケージ提供方式が変更されたことが原因です。

従来の方法では、Ubuntuの標準リポジトリからdocker.ioパッケージをインストールできましたが、Ubuntu 24.04では異なるアプローチが必要になります。

Ubuntu 24.04における正しいDocker導入方法

Docker公式リポジトリの追加

Ubuntu 24.04では、Docker社が提供する公式リポジトリを追加してからインストールする方法が推奨されます。この方法により、最新のDocker CEと関連ツールを確実にインストールできます。

実際の作業手順は以下の通りです。

1. 既存のDocker関連パッケージを削除（purge）

2. GPGキーを /etc/apt/keyrings/docker.gpg に配置

3. noble用のdocker.listファイルを作成

4. apt updateでリポジトリ情報を更新

5. docker-ce、docker-compose-pluginなどを一括インストール

インストールコマンドの例

具体的なコマンド例を以下に示します。

# 古いDockerパッケージの削除
sudo apt-get purge -y docker.io docker-compose

# GPGキーのダウンロードと配置
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Dockerリポジトリの追加
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# インストール
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

この手順により、Docker CEとCompose v2が正常に導入されます。インストールサイズは約96MBで、比較的軽量です。

カーネルアップデートと再起動

カーネル更新の通知

開発ツールのインストール中に、Ubuntuから以下のような警告メッセージが表示されました。

Pending kernel upgrade!
The currently running kernel version is not the expected kernel version.

これは、新しいカーネルバージョンがインストールされており、再起動することで反映されるという通知です。この状態は直ちに問題を引き起こすわけではありませんが、セキュリティアップデートを含む可能性があるため、適切なタイミングで再起動することをお勧めします。

再起動時の権限エラー

最初に通常ユーザー権限でrebootコマンドを実行したところ、以下のエラーが発生しました。

Call to Reboot failed: Interactive authentication required.

このエラーは、再起動には管理者権限が必要であることを示しています。正しくは、sudoを使用して再起動を実行する必要があります。

sudo reboot

このコマンドにより、EC2インスタンスは正常に再起動し、新しいカーネル（6.14.0-1016-aws）が適用されました。再起動後は、インスタンスの状態が最新になり、セキュリティパッチも適用されます。

実践から得られた重要な学び

アウトバウンド通信の必要性

今回の作業を通じて最も重要な学びは、EC2インスタンスのアウトバウンド通信の重要性です。以下のような基本的な機能は、すべて外部への通信を必要とします。

• パッケージマネージャによる更新（apt、yum）
• 外部APIへのアクセス（curl、wget）
• SSL証明書の取得（certbot）
• 外部リポジトリからのソフトウェア取得（NodeSource、Docker公式リポジトリ）

アウトバウンドルールをICMPのみに制限する設定は、実質的にEC2インスタンスを封じ込める結果となります。セキュリティを重視する場合でも、必要な通信を適切に許可する設定が求められます。

Ubuntu 24系のパッケージ管理の変化

Ubuntu 24.04では、Dockerを含む一部のソフトウェアのインストール方法が大きく変更されています。従来のdocker.ioパッケージや古いdocker-composeは使用できなくなり、Docker公式リポジトリからのインストールが必須となりました。

この変更は、より最新のバージョンを提供し、セキュリティアップデートを迅速に適用するための改善ですが、既存の自動化スクリプトを更新する必要があります。

Elastic IPの関連付け忘れに注意

実際の構築過程で最も見落としがちな問題の一つが、Elastic IPの関連付け忘れです。Elastic IPを取得しただけで満足してしまい、EC2インスタンスへの関連付けを忘れると、ドメインとEC2インスタンスが正しく紐づきません。

この状態では、Route 53のAレコードが正しく設定されていても、DNSクエリの結果がEC2インスタンスに到達せず、接続が失敗します。構築作業のチェックリストには、必ず「Elastic IPの関連付け確認」を含めることをお勧めします。

最小構成でも学びが多い理由

個人ブログ程度の用途であっても、AWS上で正常に動作させるには多くの基礎知識が必要です。DNS設定、EC2の基本構成、Elastic IPの適切な関連付け、セキュリティグループの適切な設定、そしてDockerなどの開発ツールの導入まで、それぞれに注意すべきポイントがあります。

これらの基礎をしっかりと理解することで、将来的により複雑なシステムを構築する際の土台となります。小規模な環境から始めることで、各要素を確実に理解しながら進めることができます。

終わりに

本記事では、AWS EC2を使用した個人ブログインフラの構築過程について、実際の作業をもとに解説しました。Route 53でのDNS設定から、EC2インスタンスの構築、Elastic IPの適切な関連付け、セキュリティグループの適切な設定、そしてUbuntu 24.04における最新のDocker導入方法まで、実践的な内容をお伝えしました。

特にElastic IPの関連付けとセキュリティグループのアウトバウンドルール設定は、EC2の基本動作に直結する重要な要素です。これらの知識は、今後のAWS環境構築において必ず役立ちます。まずは小規模な環境から始めて、各要素を確実に理解することをお勧めします。

本記事で紹介した構築方法と問題解決のアプローチは、個人プロジェクトだけでなく、小規模なビジネス用途にも応用できます。ぜひ実際のプロジェクトで試してみてください。