AWS 16：総まとめ ― 3層の Web 構成を組み上げる

まず要件：フォトログに求めること

構成を考えるとき、いきなり部品から選んではいけません。まず要件、つまり「このサービスに何が起きたら困るのか」を言葉にします。部品は、その困りごとへの答えとして後から決まります。

フォトログ（写真を投稿して、一覧を見て、いいねする SNS）の要件を並べます。

逆に言えば、要件が違えば構成も変わります。たとえば「社内の10人だけが使う」「止まっても翌朝直せばよい」なら、AZ を2つにする必要はないかもしれません（この章の最後で触れます）。

この本のフォトログは、一般公開のサービスとして、1つの故障では止まらないことを目標にします。これが、多くの会社で「本番」と呼べる最低限の水準です。

3層構成：入口・計算・データを分ける

要件を満たす形として、3層構成を採ります。第13章で出てきた形です。

層に分けると、次のことができます。

写真のような大きなファイルは、3層の流れに乗せず、横に置き場を作る（S3＋CloudFront）のが定石です。第15章で見たとおり、大きなものを層の中で運ぶと、計算の層が配送係になって重くなるからです。

3層の形は、この本の後半で部品が増えても、ほとんどの構成の背骨として残ります。

組み立て ①：VPC を1つ、2つの AZ にまたがって作る

ここから、構成図を土台から順に描き足していきます。

最初は VPC（第5章）です。AWS の中に作る、自分専用のネットワークでした。

/16 は、アドレスの先頭16ビット（10.0）が固定で、残りを自由に使える、という意味でした（第5章）。将来、別の VPC や会社のネットワークとつなぐ可能性があるなら、他と重ならない範囲を選んでおくことも大事です。

図では、VPC（青）の中に AZ-a と AZ-c（灰）を上下に並べています。この先、ほとんどすべての部品を、上の段と下の段に1つずつ置いていきます。「2つの AZ に1つずつ」が、この構成でいちばん大事な原則です。

VPC は、それ自体には料金がかかりません。料金がかかるのは、中に置く部品です。

組み立て ②：AZ ごとに3種類、合わせて6つのサブネット

次に、VPC をサブネット（第6章）に区切ります。3つの層に合わせて3種類、それを2つの AZ に作るので、合わせて6つです。

/24 は、1つのサブネットに約250個のアドレスです（AWS が予約する5個を除く）。

番号の付け方に注目してください。パブリックは 0 番台、アプリは 10 番台、DB は 20 番台と、層ごとに番号の帯を分けています。こうしておくと、アドレスを見ただけでどの層かがわかり、後で AZ を3つに増やすときも 10.0.2.0/24、10.0.12.0/24 と足すだけで済みます。

図では、パブリックを青、プライベートを白で描いています。ただし第6章で見たとおり、パブリックかプライベートかは名前や色ではなく、ルートテーブルで決まります。次で、その「道」を引きます。

組み立て ③：IGW・NAT・ルートテーブルで「道」を引く

サブネットに道を引きます。

そして、サブネットの種類ごとにルートテーブルを作ります。

NAT を AZ ごとに置き、アプリのサブネットは同じ AZ の NAT を使うのがポイントです。NAT が1つだけだと、その AZ が止まったとき、もう片方の AZ の EC2 も外へ出られなくなります（NAT が単一障害点になる）。

なお、2025年からは、1つ作るだけで複数の AZ に自動で広がるリージョン型の NAT ゲートウェイも選べるようになりました。仕組みは同じで、置き方の手間が減る選択肢です。

DB のサブネットには外への道を一切引きません。DB は VPC の中の EC2 とだけ話せればよいからです。

組み立て ④：セキュリティグループを「鎖」にする

道を引いたら、次は扉です。セキュリティグループ（SG、第8章）を層ごとに3つ作ります。

許可の相手に IP アドレスではなく別の SG を書いているのが要です。こうすると、次の図のような鎖になります。

プライベートサブネット（道が無い）と SG（扉が無い）の二重の守りになっている点にも注目してください。どちらか一方の設定を間違えても、もう一方が止めてくれます。これを多層防御と呼びます（第27章）。

EC2 にログインして調べたいときも、SSH の扉（22番）は開けません。Session Manager（第7章）を使えば、扉を開けずに中に入れます。

完成図：一般的な3層の Web 構成

残りの部品を置くと、構成図が完成します。

図を上下に見比べてください。AZ-a の段にあるものは、ほぼすべて AZ-c の段にもあります。どちらか一方の段が丸ごと消えても、もう一方の段だけで動けるように置いてあるのです。

例外に見えるのは RDS ですが、待機系が控えているので、本体が消えても待機系が本体になります（第13章）。ALB は1つに見えますが、実際には2つの AZ のパブリックサブネットに足を持っていて、AWS が両方を面倒見ています。

VPC の外にある Route 53・CloudFront・S3・ACM は、もともと AWS が複数の AZ や拠点で動かしているサービスです。あなたが AZ を気にする必要はありません。

これで、00章の「この本で作るもの ②」で見た形が、中身の理由まで含めて完成しました。次から、この図の上で、利用者のリクエストを1つ追いかけます。

リクエストの一生 ①：名前を調べる（Route 53）

利用者がスマートフォンで https://example.com を開いたとします。そのリクエストが、構成図のどこをどう通るのかを、小包で追います。

最初の一歩は、名前を IP アドレスに直すことです（第14章）。

図の青い小包がこの問い合わせです。答えはリゾルバーとブラウザが TTL の間だけ覚えておくので、2回目からはこの一歩はほとんど一瞬です。

ここで ALB の IP が返ってくるのは、第14章で example.com の A レコードをエイリアスで ALB に向けておいたからです。ALB の IP は AWS の都合で変わりますが、エイリアスなら Route 53 がいつも今の IP を答えてくれます。

リクエストの一生 ②：ALB と鍵をかけて話す（HTTPS）

IP アドレスがわかったので、ブラウザは ALB につなぎます。

図の緑の小包が、GET /（トップ画面をください）というリクエストです。ここから ALB までは暗号化されているので、途中のカフェの Wi-Fi でも中身は読めません。

もし利用者が http:// で来ていたら、ALB の80番のリスナーが「301：https へどうぞ」と返し、ブラウザがもう一度443番に来ます（第14章）。

ブラウザは証明書を確かめます。名前が example.com で、信頼できる認証局の発行で、期限内です。ACM が自動で更新しているので、期限切れの心配もありません。

リクエストの一生 ③：ALB が元気な EC2 を選んで渡す

ALB は受け取ったリクエストを、ターゲットグループ（第11章）の中の EC2 に渡します。

図では AZ-a の EC2 が選ばれました。次のリクエストは AZ-c の EC2 に行くかもしれません。利用者は、自分がどちらの AZ のどの EC2 に当たったかを知りませんし、知る必要もありません。

これが成り立つのは、第12章で EC2 をステートレスにしたからです。どの EC2 も同じアプリで、ログイン状態や写真を自分の中に持っていません。だから、どの EC2 に振られても同じ答えが返ります。

Auto Scaling グループの EC2 は、起動テンプレート（第12章）から作られています。AMI・インスタンスタイプ・app-sg・IAM ロール・起動時の準備（ユーザーデータ）がすべてそこに書いてあるので、新しい EC2 も最初から同じ状態で生まれます。

リクエストの一生 ④：EC2 が RDS にたずねる

トップ画面には、新しい写真の一覧を出します。EC2 のアプリは、RDS に問い合わせます。

図の小包「SQL」が、この問い合わせです。

もし、いいねを押すような書き込みなら、RDS 本体は待機系（AZ-c）にも同期で写してから「完了」を返します。本体の AZ が突然止まっても、完了と返した書き込みは待機系に残っています。

ここで、AZ-c の EC2 が AZ-a の RDS 本体に話しかけることもある点に気づいたでしょうか。RDS の本体はいつも1つなので、半分の EC2 は別の AZ の DB と話します。AZ をまたぐ通信は少しだけ遅く、わずかに料金もかかりますが、1つのエンドポイントで済むという単純さのほうが大事です。

読み取りが増えて本体が忙しくなったら、リードレプリカ（第13章）やキャッシュ（第25章）を足します。

リクエストの一生 ⑤：来た道を戻って、HTML が届く

EC2 は、RDS から受け取った一覧を使って、トップ画面の HTML（画面の設計図）を作ります。そして、来た道を逆にたどって返します。

SG は「状態を覚える」門番（第8章）なので、行きに通したリクエストへの返事は、改めて許可を書かなくても通ります。

ここで大事なのは、返した HTML の中身です。HTML には写真そのものは入っていません。入っているのは、写真のURL だけです。

<img src="https://img.example.com/thumbs/u123/a1b2.webp" alt="夕焼けの海">

EC2 は、RDS から受け取った s3_key の頭に https://img.example.com/ を付けただけです。数 MB の写真を、EC2 は1バイトも運んでいません。

ブラウザは HTML を読み、<img> を見つけるたびに、その URL を取りに行きます。つまり、写真は別のリクエストとして、別の道を通ります。次にそれを追います。

リクエストの一生 ⑥：写真は CloudFront から（2回目以降）

ブラウザは https://img.example.com/… を開きます。この名前も Route 53 にあり、エイリアスで CloudFront を指しています（第14・15章）。

図の小包は、利用者のいちばん近くのエッジから写真が届くところです。

この道には、VPC も ALB も EC2 も出てきません。写真の配信は、フォトログの通信量の大部分を占めます。その大部分を CloudFront が引き受けているので、EC2 は少ない台数で済み、ALB の処理量も NAT の通信量も増えません。

CloudFront 用の証明書は、ACM のバージニア北部（us-east-1）で作ったものです（第14章）。ALB 用とは別の証明書である点に注意してください。

リクエストの一生 ⑦：エッジに無ければ S3 から（初回だけ）

投稿されたばかりの写真は、まだどのエッジも覚えていません（キャッシュミス）。そのときだけ、エッジは本体（オリジン）の S3 へ取りに行きます。

S3 は、ブロックパブリックアクセスをオンにしたままです。S3 の URL を直接叩いても読めません。写真を見る道は、CloudFront を通る1本だけです。

S3 から CloudFront への転送は無料で、写真の保存は複数の AZ に分けて保管されています（第15章）。AZ が1つ止まっても写真は消えず、配信も止まりません。

リクエストの一生 ⑧：投稿は署名付き URL で S3 へ直接

今度は、利用者が写真を投稿するときの道です（第15章）。

重い写真は、ALB も EC2 も通りません。EC2 が扱うのは、許可証とキーという小さな文字だけです。

EC2 がアクセスキーを持たずに署名できるのは、起動テンプレートで IAM ロールを付けておいたからです（第3・15章）。ロールの権限は「このバケットに置く・読む」だけに絞ってあります。

大きな写真の縮小画像（thumbs/…）は、この時点ではまだありません。第24章では、S3 に写真が置かれたことをきっかけに、縮小画像を後から自動で作る仕組みを足します。

リクエストの一生 ⑨：EC2 が外へ出るときは NAT を通る

最後は、利用者からではなく、EC2 から外へ向かう通信です。

EC2 はプライベートサブネットにいるので、IGW へ直接の道はありません。アプリのルートテーブルに従って、同じ AZ の NAT へ行き、NAT が IGW を通って外へ出ます（第7章）。返事は NAT を通って戻ってきます。

外から EC2 へ入る道は、どこにもありません。NAT は「中から出て、その返事が戻る」だけを通すからです。

1つ気をつけたいのは、S3 への通信です。何もしないと、EC2 から S3 への通信も NAT を通り、NAT の処理量の料金がかかります。VPC に S3 用のゲートウェイエンドポイント（第7章）を付けると、S3 への通信は NAT を通らずに直接届き、エンドポイント自体の料金もかかりません。付けておいて損のない部品です。

これで、リクエストの一生を全部たどりました。

各部品が防いでいる困りごと ①：つなぐ・守る

構成図の部品が、それぞれ何を防いでいるのかを表にまとめます。「その部品を外したら、何が起きるか」を言えることが、構成を理解しているということです。

この表は、構成を人に説明するときにもそのまま使えます。「なぜ NAT が2つあるの？」と聞かれたら、「1つだと、その AZ が止まったとき、もう一方の AZ のサーバーも外へ出られなくなるから」と答えられます。

各部品が防いでいる困りごと ②：計算・しまう・配る

続きです。

2つの表を通して見ると、1つの原則が浮かび上がります。「1つだけ」のものが、構成の弱点になるということです。

構成図を見たら、まず「1つしか無いものはどれか」を探す。これが、後の第29章（可用性と災害対策）につながる考え方です。

壊れたら ①：EC2 が1台倒れる

構成が本当に「止まらない」のかを、壊れた場面で確かめます。まず、AZ-a の EC2 が1台、突然応答しなくなった場合です。

図では、倒れた EC2 が赤くなり、ALB からの線が消えています。利用者から見ると、その間も AZ-c の EC2 が答え続けているので、何も起きていないように見えます。

1つ設定を確かめておくことがあります。Auto Scaling グループのヘルスチェックの種類を ELB にしておくことです。既定の EC2 のチェックだけだと、「機械は動いているが、アプリが固まっている」状態を見逃し、入れ替えてくれません。

また、倒れた EC2 の中に何かを置いていたら、それは消えます。ステートレスにしてあるので、失うものは何もありません。

壊れたら ②：AZ-a が丸ごと止まる

次は、もっと大きな障害です。AZ-a が丸ごと使えなくなったとします。図の上の段が赤くなりました。

RDS の切り替わりの1〜2分の間は、DB を使う画面がエラーになることがあります。ただし、アプリがつなぎ直す作りになっていれば、その後は自動で戻ります。人が夜中に起きて作業をしなくても、サービスは AZ-c だけで動き続けます。

ここで、NAT を1つにしていたらどうなったかを考えてみてください。NAT が AZ-a にあれば、AZ-c の EC2 は外へ出られず、外部の API を使う機能が止まっていたはずです。1つだけのものが弱点になる、の実例です。

AZ-a が戻ると、RDS は AZ-a に新しい待機系を作り直し、Auto Scaling も台数を2つの AZ に均し直します。

混んだら：Auto Scaling が EC2 を足す

最後は、壊れたのではなく混んだ場合です。フォトログがテレビで紹介され、利用者が急に増えたとします。

図では、各 AZ に1台ずつ増えて、2台から4台になりました。Auto Scaling は増やすときも2つの AZ に均等に置きます。

混雑が去れば、Auto Scaling は台数を減らします。空いている時間のぶんは払わない。00章で見た「クラウド」の良さが、ここで実際に効いています。

ただし、DB は自動では増えません。3層のうち、いちばん増やしにくいのがデータの層です。そのため、写真は CloudFront に、よく読むものはキャッシュ（第25章）に、重い処理は後回し（第24章）に、と、DB に届く仕事そのものを減らす工夫を後半の章で重ねていきます。

作る順番 ①：土台（道・扉・データの置き場）から

構成がわかったら、実際に作ります。順番を間違えると、「この部品を作るには、あの部品が先に要る」と行ったり来たりすることになります。

ここまでが土台です。まだ利用者は1人もつなげません。

土台ができたら、1台の EC2 を手で立てて、プライベートサブネットから NAT 経由で更新が取れるか、RDS に接続できるか、S3 に置けるかを確かめておくと、後で問題が起きたときに切り分けが楽になります（確かめたら、その EC2 は消します）。

作る順番 ②：計算と入口、最後に名前と配り口

続きです。

EC2 は手で立てず、Auto Scaling に作らせるのが大事です。手で立てた EC2 は、壊れても誰も入れ替えてくれません。

9〜10で「ALB の長い名前で、HTTP で動く」ことを確かめてから、11〜12で HTTPS と名前を足します。一度に全部を足さず、1段ずつ動くことを確かめると、動かなかったときに、原因が最後に足した部品にあるとすぐわかります。

同じ構成をコードで書くと（第18章の予告）

ここまでの手順を画面で1つずつやると、慣れても1〜2時間はかかります。しかも、同じものをもう1つ作る（開発用と本番用など）ときに、同じ手順を間違えずに繰り返すのは大変です。

第18章で学ぶ IaC（構成をコードにする）を使うと、この章の構成の骨組みは、図のような数十行で書けます。AWS CDK（TypeScript）の例です。

const vpc = new ec2.Vpc(this, "Vpc", {
  ipAddresses: ec2.IpAddresses.cidr("10.0.0.0/16"),
  maxAzs: 2, natGateways: 2,
  subnetConfiguration: [
    { name: "public", subnetType: ec2.SubnetType.PUBLIC, cidrMask: 24 },
    { name: "app", subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS, cidrMask: 24 },
    { name: "db", subnetType: ec2.SubnetType.PRIVATE_ISOLATED, cidrMask: 24 },
  ],
});
const db = new rds.DatabaseInstance(this, "Db", {
  engine: rds.DatabaseInstanceEngine.postgres({ version: rds.PostgresEngineVersion.VER_16 }),
  vpc, vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED }, multiAz: true,
});
const asg = new autoscaling.AutoScalingGroup(this, "Web", {
  vpc, instanceType: new ec2.InstanceType("t4g.small"),
  machineImage: ec2.MachineImage.latestAmazonLinux2023({ cpuType: ec2.AmazonLinuxCpuType.ARM_64 }),
  minCapacity: 2, maxCapacity: 6,
});
asg.scaleOnCpuUtilization("Cpu", { targetUtilizationPercent: 50 });
db.connections.allowDefaultPortFrom(asg); // db-sg ← app-sg の鎖
const alb = new elbv2.ApplicationLoadBalancer(this, "Alb", { vpc, internetFacing: true });
alb.addListener("Https", { port: 443, certificates: [cert] })
  .addTargets("Web", { port: 80, targets: [asg], healthCheck: { path: "/health" } });
alb.addRedirect(); // 80 → 443

subnetConfiguration の3行が6つのサブネットに、natGateways: 2 が AZ ごとの NAT に、allowDefaultPortFrom が SG の鎖になっています。この章で1つずつ理由を知った部品が、1行ずつに対応しているのがわかるはずです。

まずは画面で作って仕組みを体で覚え、それからコードにする。これがいちばんの近道です。

できたら、壊して確かめる

構成が完成しても、「止まらないはず」「守れているはず」は、試すまでは仮説です。本番の利用者を迎える前に、わざと壊して動きを見ておきます。

特に、RDS のフェイルオーバーでアプリがちゃんとつなぎ直すかは、試さないとわかりません。切り替わった後もエラーが続くなら、アプリの接続の作りを直します。

これらを定期的に試す習慣は、第29章の「復旧の練習」につながります。

月額の目安の考え方：「ずっと動くもの」と「使った量」に分ける

この構成の料金を見積もるときは、2つに分けて考えます。

公開 IPv4 アドレスは、2024年から、使っているかどうかに関係なく1つごとに時間で課金されるようになりました。ALB や NAT も内部で公開 IPv4 アドレスを使うので、その分も数に入ります。

小さなサービスでは、利用者が少ないうちは「使った量」はわずかで、「ずっと動くもの」がほぼすべてになります。その中でも大きくなりやすいのは、Multi-AZ の RDS（2台分）と、AZ ごとの NAT です。

見積もりは、第4章の Pricing Calculator に部品を1つずつ並べて行います。

単価はリージョンや時期で変わるので、この本には書きません。必ず料金ページと Pricing Calculator で確かめてください。

お金の調整つまみ：安くすると、何を手放すか

料金を下げる方法はいくつもありますが、どれも何かを手放します。つまみと、手放すものを並べます。

考え方は、要件と照らし合わせることです。

「本番は止まらないこと」が要件なら、NAT や Multi-AZ は削ってはいけない部分です。逆に、止まってもよい開発用なら、削っても困りません。同じ構成でも、要件によって正解の設定が違うのです。

片付け：作った順の逆から消す

練習で作った構成は、その日のうちに消します。使われているものは消せないので、作った順の逆、つまり外側（入口）から内側（土台）へ消していきます。

図の右は、消し忘れやすいものです。

最後に、翌日の Cost Explorer（第4章）で、この構成の料金が止まったかを確かめます。

この形は、ほかの Web サービスにもそのまま使える

この章の構成は、フォトログのためだけのものではありません。3層＋ファイル置き場は、多くの Web サービスの出発点になる形です。

変えるのは主に中身（アプリ）と数（台数・大きさ・AZ の数）で、形はほとんど変わりません。

自分で構成を考えるときは、この章と同じ手順を踏みます。

この問いの型は、第30章の設計演習でもう一度、何度も使います。