SNSアプリの最終インフラ構成図

このドキュメントは、カリキュラム全体を通して「最終的に何を組み上げるのか」を最初に俯瞰するための 北極星 です。個別の技術（React / Hono / Docker / AWS など）を学ぶときも、常にこの図の「どのピースを今作っているか」を意識することで、点の知識が線でつながります。

最終インフラ構成図

構成要素と、関連する beginner-stepup docs

コンポーネント	役割	関連 docs
CloudFront	CDN・HTTPS 終端・エッジキャッシュ	b05 Webアーキ / b17 ホスティング
S3	React SPA（静的ファイル）の配信元	b17 ホスティング
ALB（Application Load Balancer）	HTTP(S) を受けて EC2 に振り分ける	b05 Webアーキ / b06 HTTP/REST
App EC2（private subnet）	Docker Compose 上で Hono API を動かす	b13 API設計 / b17 ホスティング
RDS PostgreSQL（private subnet）	永続データストア	b15 DB設計 / b16 マイグレーション
Bastion EC2（public subnet）	管理 SSH の踏み台（private リソースへの穴）	b01 シェル / b07 認証・認可
VPC	AWS ネットワーク境界。public/private subnet に分離	b17 ホスティング
GitHub Actions	CI/CD（build / test / deploy）	b19 CI/CD
環境変数 / Secrets Manager	DB 接続文字列・JWT secret 等の秘匿管理	b18 環境変数

通信経路（リクエストの流れ）

ユーザーからのアクセス

ブラウザ
  ↓ HTTPS
CloudFront
  ├─ /            → S3（React SPA の index.html）
  └─ /api/*       → ALB → App EC2（Hono API）
                          ↓ SQL over SSL
                        RDS PostgreSQL

管理者の運用アクセス（SSH ProxyJump）

管理者の PC
  ↓ SSH
Bastion EC2（public subnet）
  ↓ SSH（VPC 内通信）
App EC2（private subnet）
  ↓ psql
RDS PostgreSQL

Private subnet のリソースはインターネットから直接アクセス不能。「踏み台を経由して VPC の中に入る」が AWS セキュリティの基本パターン。

なぜこの構成なのか（学習ポイント）

1. Public / Private Subnet 分離

Public subnet: インターネットからの窓口（ALB・Bastion）
Private subnet: アプリ本体・DB（外部から直接触れない）
セキュリティ境界を明示する設計

2. コンテナ化（Docker Compose）

アプリを環境に依存しない形でパッケージング
ローカル開発 → EC2 本番 → 同じコンテナイメージで動く
再現性・デプロイの高速化

3. CloudFront + S3（フロント）

静的ファイルは CDN で高速配信
サーバー不要 → コスト低
グローバル配信（世界中から速い）

4. ALB + EC2（API）

将来的な水平スケールへの布石（ALB 配下に複数 EC2 を並べられる）
ヘルスチェック・スティッキーセッション等の機能

5. Bastion 踏み台

Private リソースへの SSH アクセス経路を 1 箇所に集約
ログ・アクセス制御を1台に集中できる
「最小権限の法則」の実践例

6ヶ月で組み上げるピースのマップ

Month	組み上げるピース
Month 1	上図のピースをローカル開発として凝縮した状態（web + api + Docker PostgreSQL）で動かす
Month 2	要求から要件を起こし、自前アプリとしてコード再設計
Month 3-4	自前アプリを Month 1 と同じローカル構成で完成させる
Month 5	本図の AWS 構成を実際に組み立てる（VPC→SG→RDS→Bastion→EC2→ALB→CloudFront→S3）
Month 6	CI/CD で自動化し、監視・セキュリティ診断を導入

よくある質問

Q. なぜ Amplify ではなく EC2/RDS？ Amplify は確かに速く立ち上がるが、ブラックボックス化されていて中身の理解が浅くなる。このカリキュラムは「本番運用で使える実務スキル」を目指すので、VPC/SG/Docker/RDS など、実務でよく使われるピースを 自分の手で 組み立てる経験を重視する。

Q. 全部自分でやる必要がある？ 初見では複雑に見えるが、Month 5 の4週間をかけて Step-by-Step で一緒に構築する。 AWS Console での操作と、AWS CLI での確認を並行させることで、GUI に頼らない理解も育てる。

Q. コストは大丈夫？ t3.micro（EC2・Bastion）と db.t3.micro（RDS）は AWS Free Tier の対象。 使わない時は停止を徹底すれば、月 100 ドル以内に収まる設計。Month 5 の冒頭で Budget Alert を設定する。

確認クイズ

Q1. このドキュメントが「北極星」と呼ばれる理由はなぜか。

正解: カリキュラム全体を通して最終的に何を組み上げるのかを最初に俯瞰するためのドキュメントだから

解説: 個別の技術（React / Hono / Docker / AWS など）を学ぶときも、常にこの図の「どのピースを今作っているか」を意識することで、点の知識が線でつながる設計になっている。迷ったときの方向指針として機能する。

Q2. ブラウザから /api/* へのリクエストが通る経路として正しいものはどれか。　A. ブラウザ → ALB → S3 → RDS　B. ブラウザ → CloudFront → ALB → App EC2 → RDS　C. ブラウザ → Bastion → App EC2 → RDS　D. ブラウザ → CloudFront → S3 → App EC2

正解: B. ブラウザ → CloudFront → ALB → App EC2 → RDS

解説: CloudFront は / へのリクエストをS3に、/api/* へのリクエストをALB経由でApp EC2（Hono API）に振り分ける。App EC2はRDS PostgreSQLへSSL経由でSQLを発行する。

Q3. 管理者がRDS PostgreSQLに接続するための運用アクセス経路として正しいものはどれか。

正解: 管理者のPC → SSH → Bastion EC2（public subnet）→ SSH（VPC内通信）→ App EC2（private subnet）→ psql → RDS PostgreSQL

解説: Private subnetのリソースはインターネットから直接アクセス不能なため、Bastion EC2を踏み台として経由する必要がある。「踏み台を経由してVPCの中に入る」がAWSセキュリティの基本パターンとされている。

Q4. App EC2がprivate subnetに配置される理由として正しいものはどれか。　A. EC2のコストを削減するため　B. デプロイ速度を向上させるため　C. 外部から直接触れないようにするセキュリティ境界を設けるため　D. CloudFrontとの通信を高速化するため

正解: C. 外部から直接触れないようにするセキュリティ境界を設けるため

解説: Public subnetにはインターネットからの窓口（ALB・Bastion）を配置し、アプリ本体・DBはPrivate subnetに置いて外部から直接触れないようにする設計。セキュリティ境界を明示する構成である。

Q5. CloudFront + S3 構成をフロントエンドに採用している理由として正しいものはどれか。

正解: 静的ファイルをCDNで高速配信でき、サーバー不要でコストを低く抑えられ、グローバル配信にも対応できるため

解説: React SPA（静的ファイル）はS3に置いてCloudFrontで配信することで、サーバーを維持するコストなしに世界中から高速にアクセスできる。サーバーレスな配信が可能なため、スケールアップも容易である。

Q6. AmplifyではなくEC2/RDSを使う理由として、このドキュメントが挙げているものはどれか。　A. Amplifyはコストが高すぎるから　B. Amplifyはブラックボックス化されていて中身の理解が浅くなるから　C. AmplifyはJavaScriptに対応していないから　D. AmplifyはDockerと互換性がないから

正解: B. Amplifyはブラックボックス化されていて中身の理解が浅くなるから

解説: Amplifyは速く立ち上がるが、このカリキュラムは「本番運用で使える実務スキル」を目標としているため、VPC/SG/Docker/RDSなどのピースを自分の手で組み立てる経験を重視している。

Q7. Bastion踏み台サーバーを設ける目的として正しいものはどれか。

正解: Private リソースへのSSHアクセス経路を1箇所に集約し、ログ・アクセス制御を1台に集中させるため

解説: Bastionを経由することで、誰がいつPrivateリソースにアクセスしたかのログを一元管理できる。「最小権限の法則」の実践例としても位置づけられており、直接アクセスを遮断することでセキュリティリスクを低減する。

Q8. AWS本番構成を実際に組み立てるのは6ヶ月カリキュラムのどのフェーズか。　A. Month 1　B. Month 2　C. Month 3-4　D. Month 5

正解: D. Month 5

解説: Month 5の4週間をかけてStep-by-Stepで構築する。VPC→SG→RDS→Bastion→EC2→ALB→CloudFront→S3の順で組み立て、AWS ConsoleとAWS CLIを並行させてGUIに頼らない理解も育てる設計になっている。

Q9. ALB（Application Load Balancer）を構成に含める将来的な目的として正しいものはどれか。

正解: ALB配下に複数のEC2を並べることで水平スケールへの布石とするため

解説: 現時点では単一のApp EC2だが、ALBを挟むことで将来的にEC2を増やすだけでスケールアウトできる構成になっている。ヘルスチェックやスティッキーセッション等の機能も利用できる。

Q10. DB接続文字列やJWT secretなどの秘匿情報を管理するコンポーネントはどれか。　A. CloudFront　B. ALB　C. 環境変数 / Secrets Manager　D. GitHub Actions

正解: C. 環境変数 / Secrets Manager

解説: DB接続文字列・JWT secretなどの秘匿情報はコードに直書きせず、環境変数またはAWS Secrets Managerで管理する。関連するdocsはb18（環境変数）で詳しく扱われている。

生きているコード

本ドキュメントで扱ったパターンの完全な動作コードは、メンター側リポジトリの参照ブランチで確認できます。

対応 Week: W4 / W17 / W18 / W19 / W20
参照ブランチ:
W4: reference/week-4
W17: reference/week-17
W18: reference/week-18
W19: reference/week-19
W20: reference/week-20
対応 checklist 項目: M12

ブランチの作り方・見方は b00-curriculum-map を参照してください。