AWS初学者が“実務を意識して”Webアプリ基盤を構築する【① 設計と準備編】

Posted at 2026-01-21

本記事は、AWS 初学者が
「とりあえず EC2 を立てて動かしてみた」で終わらず、
実務で説明できる Web アプリ実行環境を構築できるようになること
を目的とした連載の第1回です。

世の中には
「EC2を立てる → nginxを入れる → なんとなく動いた」
という記事は数多く存在しますが、

なぜその構成なのか
なぜそのインスタンスタイプなのか
なぜ Docker を使うのか
なぜ本番構成と違うのか

といった 設計上の理由 まで説明しているものは、実は多くありません。

本連載では、
「手順」よりも「判断理由」 を重視し、
有志開発・学習用途から一歩進んだ
“実務を意識した AWS 環境構築” を段階的に解説します。

第1回となる本記事では、
まだ AWS 上で何も作り始めません。

代わりに、

今回構築する全体像
一般的な本番構成との違い
コストをどう考えるか
事故を防ぐための IAM / MFA 設計

といった、
後から修正が効かない「前提条件」 を整理します。

ここを飛ばすと、
後続の記事が「なぜそうしているのか分からない手順書」になります。

まずはこの回で、
安心して AWS を触り始められる状態 を作りましょう。

第1章：全体構成と方針決定

— 今回の構成と「一般的な本番構成」との違いを理解する —

1. はじめに（この記事で何をやるのか）

本記事では、以下の目的で AWS 上に Web アプリの実行環境を構築します。

AWS 初学者でも理解できること
「とりあえず動いた」で終わらせないこと
実務を意識した判断理由をすべて説明すること

本記事は「手順書」ですが、
操作の羅列ではなく「なぜそうするのか」 を重視します。

2. 今回構築する最終ゴール

今回のゴール（本記事）

AWS EC2 上に Docker を導入
nginx を入口とした Web アクセスを実現
HTTPS 化まで含めた 実務レベルの公開環境
将来的なスケールアップ（t5.large）を前提とした設計

3. 今回の構成（学習・有志開発向け）

本記事で最終的に到達する構成は以下です。

[ Browser ]
     |
   HTTPS
     |
[ nginx (Docker) ]
     |
[ EC2 (AWS) ]

EC2：1台構成
Docker：アプリ実行基盤
nginx：すべての入口
データは EC2 上で管理

👉
「まずは 1 台で全体像を理解する」 ことを最優先します。

4. 一般的な本番構成（業務システム）との違い

では、業務システムではどうなるか。

一般的な本番構成例

[ Browser ]
     |
   HTTPS
     |
[ ALB ]
     |
[ Web / API EC2 or ECS ]
     |
[ RDS (PostgreSQL) ]

主な違い

項目	今回	一般的な本番
サーバ台数	1台	複数
DB	EC2内	RDS
LB	なし	ALB
冗長化	なし	あり
運用自動化	最小	必須

👉
本番構成は「安全・冗長・分離」が最優先
👉
今回は「理解しやすさ・手を動かすこと」が最優先

5. なぜ「本番構成そのまま」で始めないのか

よくある疑問です。

最初から ALB / RDS / 複数 EC2 にすべきでは？

答え：NO

理由は明確です。

構成要素が多すぎて全体像を見失う
どこで通信しているのか分からない
トラブル時に切り分けできない

👉
最初は「1台構成で流れを理解」→ 段階的に分離が正解

6. Docker を使う理由（具体例付き）

本記事では Docker を前提 とします。
理由を曖昧にせず、具体例で説明します。

理由① 環境差分を消す

ローカル / EC2 / 将来の別EC2
同じ docker-compose で同じ状態

例：
t3.micro → t5.large に変更しても

docker-compose up -d

で同じ環境が再現できる。

理由② EC2 を「使い捨て」にできる

OS に直接アプリを入れない
EC2 は ただの実行基盤

例：
EC2 障害 → 新EC2作成 → Docker 起動 → 復旧

理由③ 将来の構成変更に耐えられる

今：nginx だけ
次：API コンテナ追加
将来：複数サービス分離

👉
Docker を使わない理由がほぼ存在しない

7. RDS とは何か（今回なぜ使わないか）

RDS（Relational Database Service）とは

AWS が提供する マネージド DB
バックアップ・冗長化・パッチ適用を AWS が担当

なぜ今回は使わないか

DB 単体で構成理解が難しくなる
コストが上がる
今回の目的は「Web 実行基盤の理解」

👉
学習初期は「DBを分ける」より「流れを理解」

※
実務では DBはほぼ確実に RDS を使います。

8. 今回の設計方針まとめ

本記事の設計方針は以下です。

最初から完璧を目指さない
ただし 実務で否定される構成は取らない
将来のスケールを邪魔しない
すべての選択に理由を持つ

9. この章のまとめ

今回は 1台構成で全体像を理解する
本番構成とは意図的に差をつけている
Docker は必須
RDS / ALB は将来段階で導入すべき
「なぜ」を説明できる構成が重要

第2章：コスト設計と最安構成の考え方

— 数字で納得するインフラ初期設計 —

1. この章の目的

この章の目的は次の2点です。

AWSの料金が「なんとなく不安」な状態を脱する
感覚ではなく 数値ベースでインスタンススペックを判断できるようになる

👉
「最安だから t3.micro」ではなく、
**「この規模なら t3.micro で足りる」**と説明できる状態を目指します。

2. AWS料金の全体像（最初に押さえるべき整理）

AWSの料金は大きく分けて以下です。

計算資源（EC2）
ストレージ（EBSなど）
ネットワーク転送量
（使えば）マネージドサービス（RDS 等）

今回の構成では ①〜③が主 です。

3. EC2インスタンス料金（t3.micro）

t3.micro の基本スペック

項目	値
vCPU	2
メモリ	1GB
種別	バースト型

料金目安（東京リージョン）

約 $0.013 / 時間
1日3時間 × 30日稼働の場合：

0.013 × 3 × 30 ≒ $1.17 / 月（約200円）

👉
インスタンス代自体は非常に安い

4. ネットワーク転送量の料金と単位

基本ルール

受信（IN）：無料
送信（OUT）：有料

単位料金（東京リージョン目安）

約 $0.114 / GB（最初の10TBまで）

具体例①：今回のPJ想定（小規模）

仮定：

1ページ表示：300KB
1ユーザ：20ページ/日
ユーザ数：10人

300KB × 20 × 10 ≒ 60MB / 日
60MB × 30日 ≒ 1.8GB / 月

料金：

1.8GB × $0.114 ≒ $0.20（約30円）

👉
無視できるレベル

具体例②：一般的な小規模Webアプリ

仮定：

1ユーザ：50MB / 日
100ユーザ

50MB × 100 × 30 ≒ 150GB / 月

料金：

150 × 0.114 ≒ $17（約2,500円）

👉
ユーザ数が増えると転送量が支配的になる

5. 処理の重さを「CPU / メモリ」で見積もる

ここが この章の核心 です。

6. 処理ごとのリソース消費目安（超概算）

※ 実務でもよく使う ラフ見積り です。

nginx（静的配信）

項目	目安
CPU	1リクエストあたり 1〜3ms
メモリ	常駐 20〜50MB

簡易API（軽い処理）

項目	目安
CPU	10〜30ms / リクエスト
メモリ	常駐 50〜150MB

Dockerオーバーヘッド

メモリ：+50〜100MB（合計）

7. 想定ユーザ数を掛け算する

今回の想定

同時アクセス：最大 5人
1人あたり：1リクエスト / 秒

5 req/s × 30ms ≒ 150ms / 秒

👉
CPUは全然余裕

メモリ見積り

要素	使用量
OS	約300MB
nginx	50MB
Docker	100MB
合計	約450MB

👉
1GB中、半分以上余る

8. なぜ t3.micro で始めてよいのか（結論）

CPU：余裕あり
メモリ：余裕あり
転送量：誤差レベル
コスト：月数百円〜

👉
この規模で t3.micro を否定する理由がない

9. では、いつスペックを上げるのか？

判断基準（実務的）

CPU使用率が 常時70%以上
メモリ不足で OOM が出る
レスポンスが体感で遅い

👉
数字を見てから上げる

10. t5.large へ移行した場合の目安

項目	t3.micro	t5.large
vCPU	2	2
メモリ	1GB	8GB
月額（目安）	数百円	数千円

👉
性能は一気に伸びるが、判断は後でいい

11. 「最初から大きくすべき？」への答え

答えは NO。

理由：

使っていないリソースに金を払う
問題点が見えない
成長の判断材料がない

👉
スモールスタートが唯一の正解

12. この章のまとめ

AWS料金は「足し算」で考える
転送量は OUT が課金対象
処理負荷は概算で十分
想定ユーザ数を掛け算する
t3.micro は合理的な選択

第3章：AWSアカウント作成とIAM設計

— 事故らないための「入口設計」—

1. この章の目的

この章の目的は次の3点です。

AWSを安全に使い始めるための最低条件を満たす
ルートユーザーと IAM ユーザーの役割を正しく理解する
学習用途と業務用途の設計思想の違いを把握する

👉
この章を軽視すると、
**後工程がどれだけ正しくても「構成として失格」**になります。

2. AWSアカウント作成（最初に一度だけ）

2.1 事前に用意するもの

メールアドレス（ログインID）
クレジットカード
※ 登録＝即課金ではない
スマートフォン（SMS / MFA 用）

2.2 アカウント作成手順

https://aws.amazon.com/jp/ にアクセス
「アカウントを作成」をクリック
以下を入力
- メールアドレス
- アカウント名（任意）
- パスワード
連絡先情報を入力（個人でOK）
クレジットカード登録
電話番号認証（SMS または音声）
サポートプランは ベーシック（無料） を選択

👉
この時点では課金は発生しない

3. ルートユーザーとは何か

ルートユーザーの正体

AWSアカウント作成時の 最上位ユーザー
すべての操作が可能
権限を制限できない

ルートユーザーにしかできないこと

アカウントの削除
支払い方法の変更
サポートプランの変更
一部の IAM 管理操作

👉
AWSアカウントそのものを管理する存在

4. なぜルートユーザーを常用してはいけないのか

理由① 権限が強すぎる

誤操作＝全リソース破壊
被害範囲が最大

理由② 操作履歴の追跡が困難

誰がやったか追いづらい
監査で問題になる

理由③ 業務では即是正対象

セキュリティレビュー
内部監査
ISMS / SOC2

👉
「ルート常用」は実務では論外

5. ルートユーザーで最初に必ずやること：MFA

MFA（多要素認証）とは

パスワード + 追加認証（ワンタイムコード）
パスワード漏洩対策の要

👉
ルートユーザーには必須

MFA設定手順（概要）

ルートユーザーでログイン
「セキュリティ認証情報」へ移動
MFA → 「デバイスを割り当て」
仮想MFAデバイス を選択
認証アプリ（Google Authenticator 等）でQRを読み取り
表示された6桁コードを 2回入力

👉
これ以降、ルートログイン時にMFA必須

6. IAMユーザーとは何か

IAM（Identity and Access Management）

AWSを日常的に操作するためのユーザー管理機構

人ごとにユーザーを作る
権限を制御できる
操作履歴を追跡できる

👉
実作業はすべて IAM ユーザーで行う

7. 学習用途におけるIAM設計（今回）

今回の方針

IAMユーザー：1人
権限：AdministratorAccess
MFA：有効化

理由

学習効率を優先
権限エラーで詰まらない
構成理解に集中できる

👉
「学習段階としては正解」

8. 業務におけるIAM設計（一般論）

業務では以下が基本です。

8.1 最小権限の原則

必要な操作だけを許可する

8.2 役割ベース設計（RBAC）

役割	例
管理者	インフラ責任者
開発者	アプリ開発
運用	再起動・監視
閲覧	監査・レビュー

👉
人ではなく「役割」に権限を持たせる

8.3 IAMロールの活用

EC2 → S3
CI/CD → AWS
Lambda → RDS

👉
「人」ではなく「システム」に権限を渡す

9. 今回と業務構成の違いまとめ

項目	今回	業務
ルート	初期設定のみ	封印
IAMユーザー	1人	複数
権限	管理者	最小権限
ロール	未使用	多用

10. よくある初学者の誤解

「最初から業務設計にすべき？」

→ NO

理由：

学習効率が著しく落ちる
権限エラーで詰まる
AWSの動きが見えない

👉
段階的に近づけるのが正解

11. この章のまとめ

AWS利用の入口は「IAM設計」
ルートユーザーは封印前提
MFAは必須
学習と業務では設計が異なる
理由を理解した上で割り切ることが重要

おわりに

ここまでで、

なぜ 1 台構成から始めるのか
なぜ t3.micro が妥当なのか
なぜ Docker を前提にするのか
なぜ IAM / MFA が最初に必要なのか

といった、
構築前に必ず押さえるべき判断軸 を整理しました。

次回は、いよいよ AWS 上で実際に手を動かします。

第2回では、

デフォルト VPC を使わずに
VPC / Subnet / Internet Gateway を自分で作成し
実務を意識したネットワーク構成で EC2 を起動する

ところまでを扱います。

「なんとなく通信できている」状態から一歩進み、
ネットワークを理解しながら EC2 を立てる 回になります。

👉 次回：AWS初学者が“実務を意識して”Webアプリ基盤を構築する【② AWS基盤構築編】）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

AWS初学者が“実務を意識して”Webアプリ基盤を構築する 【① 設計と準備編】

第1章：全体構成と方針決定

1. はじめに（この記事で何をやるのか）

2. 今回構築する最終ゴール

今回のゴール（本記事）

3. 今回の構成（学習・有志開発向け）

4. 一般的な本番構成（業務システム）との違い

一般的な本番構成例

主な違い

5. なぜ「本番構成そのまま」で始めないのか

答え：NO

6. Docker を使う理由（具体例付き）

理由① 環境差分を消す

理由② EC2 を「使い捨て」にできる

理由③ 将来の構成変更に耐えられる

7. RDS とは何か（今回なぜ使わないか）

RDS（Relational Database Service）とは

なぜ今回は使わないか

8. 今回の設計方針まとめ

9. この章のまとめ

第2章：コスト設計と最安構成の考え方

1. この章の目的

2. AWS料金の全体像（最初に押さえるべき整理）

3. EC2インスタンス料金（t3.micro）

t3.micro の基本スペック

料金目安（東京リージョン）

4. ネットワーク転送量の料金と単位

基本ルール

単位料金（東京リージョン目安）

具体例①：今回のPJ想定（小規模）

具体例②：一般的な小規模Webアプリ

5. 処理の重さを「CPU / メモリ」で見積もる

6. 処理ごとのリソース消費目安（超概算）

nginx（静的配信）

簡易API（軽い処理）

Dockerオーバーヘッド

7. 想定ユーザ数を掛け算する

今回の想定

メモリ見積り

8. なぜ t3.micro で始めてよいのか（結論）

9. では、いつスペックを上げるのか？

判断基準（実務的）

10. t5.large へ移行した場合の目安

11. 「最初から大きくすべき？」への答え

12. この章のまとめ

第3章：AWSアカウント作成とIAM設計

1. この章の目的

2. AWSアカウント作成（最初に一度だけ）

2.1 事前に用意するもの

2.2 アカウント作成手順

3. ルートユーザーとは何か

ルートユーザーの正体

ルートユーザーにしかできないこと

4. なぜルートユーザーを常用してはいけないのか

理由① 権限が強すぎる

理由② 操作履歴の追跡が困難

理由③ 業務では即是正対象

5. ルートユーザーで最初に必ずやること：MFA

MFA（多要素認証）とは

MFA設定手順（概要）

6. IAMユーザーとは何か

IAM（Identity and Access Management）

7. 学習用途におけるIAM設計（今回）

今回の方針

理由

8. 業務におけるIAM設計（一般論）

8.1 最小権限の原則

8.2 役割ベース設計（RBAC）

8.3 IAMロールの活用

9. 今回と業務構成の違いまとめ

10. よくある初学者の誤解

「最初から業務設計にすべき？」

11. この章のまとめ

おわりに

AWS初学者が“実務を意識して”Webアプリ基盤を構築する【① 設計と準備編】