ここから、いよいよ実務編スタート。
初級編では、
«「このAWSサービスは何をするもの？」»
というところから始めて、
VPC、Subnet、ALB、EC2、Security Group、RDSなど、一つずつAWSの部品を学んできた。
そして今までは、
AWSのサービスを知る
↓
Terraformのコードを書く
という流れだった。
でも、ここからは違う。
今日からは、
要件
↓
AWSの構成を考える
↓
必要なリソースを考える
↓
通信経路を考える
↓
Security Groupを考える
↓
Terraformを書く
という、実務に近い考え方で進めていく。
🧪 第17回：実務演習①
📋 要件
会社のWebサービスをAWS上に構築する。
今回の条件はこれ。
- VPCを作る
- Public Subnetを1つ作る
- Private Subnetを1つ作る
- ALBをPublic Subnetへ配置する
- EC2をPrivate Subnetへ配置する
- インターネットからWebページへアクセスできるようにする
- EC2へはALB経由だけでアクセスさせる
🗺️ 今回の構成イメージ
今回、目指す構成はシンプル。
Internet
│
▼
ALB
│
▼
EC2
Subnetまで含めると、
VPC
│
├── Public Subnet
│ │
│ └── ALB
│
└── Private Subnet
│
└── EC2
という構成になる。
🎯 今日のミッション
今日は、
コードを書かなくていい。
まずは設計だけ。
やってほしいのは、この4つ。
① 必要なTerraformリソースを全部挙げる
例えば、
aws_vpc
aws_subnet
のように、
今回の構成に必要だと思うTerraformリソースを全部挙げる。
② Public SubnetとPrivate SubnetのCIDRを決める
VPCは、
10.0.0.0/16
を使う。
では、
Public Subnet
Private Subnet
のCIDRは何にする？
そして、
なぜそのCIDRにしたのか？
理由も考える。
③ ALB Security Group
ALBはインターネットからアクセスされる。
では、
何番ポートを世界中に許可する？
④ EC2 Security Group ⭐
今回一番重要。
EC2は、
誰からの通信だけを許可する？
そして、
なぜCIDRではなくSecurity Group参照を使う？
💡 先生からヒント
これは、ここまで学んできた内容だけで解ける。
つまり今日の授業は、
«「覚えているか」ではなく「組み立てられるか」»
を見るテスト。
コードは次回。
まずは、
AWSの設計図を頭の中で完成させる。
ここから実務エンジニアモードでいこう。💪☁️
✍️ 実際に設計してみる
今回、自分で考えた回答はこちら。
① 必要なTerraformリソース
回答：
aws_vpc.main.id
aws_internet_gateway.igw.id
aws_subnet.public.id
aws_subnet.private
aws_lb_alb.id
aws_listner
aws_targetgroup
aws_securitygroup
② Public SubnetとPrivate SubnetのCIDR
VPC：
10.0.0.0/16
回答：
Public : 10.0.1.0/24
Private : 10.0.2.0/24
理由：
«パブリックとプライベートで通信できる範囲を変えたいから。»
③ ALB Security Group
回答：
80
④ EC2 Security Group
回答：
«EC2はALBからだけ許可する。
CIDRを指定しない理由は、特定の通信を許可したいわけじゃないから。»
🔍 今回のレビュー
今回はコードの正確さではなく、
「要件からAWS構成を組み立てられているか」
を中心にレビューする。
① 必要なTerraformリソース
ここは少し惜しい！
今回求めていたのは、
「必要なリソースの種類」
だった。
例えば、
aws_vpc
や、
aws_subnet
のように答える。
今回の回答では、
aws_vpc.main.id
となっている。
これは、
Terraformリソースそのものではなく、リソースのIDを参照している式。
例えば、
aws_vpc.main.id
を分解すると、
aws_vpc
↓
リソースタイプ
main
↓
リソース名
id
↓
そのリソースのID属性
となる。
だから、
«「必要なリソースは？」»
と聞かれたら、
aws_vpc
と答える。
今回必要になるリソース
今回の要件なら、例えば以下。
aws_vpc
aws_subnet
aws_internet_gateway
aws_route_table
aws_route_table_association
aws_lb
aws_lb_listener
aws_lb_target_group
aws_lb_target_group_attachment
aws_instance
aws_security_group
こうやって、
「何を作らないとこの構成が完成しないか」
を考える。
これは実務でもかなり重要。
例えば先輩から、
«「この構成に必要なTerraformリソースを洗い出して」»
と言われたとき、
aws_vpc.main.id
ではなく、
aws_vpc
aws_subnet
aws_lb
aws_instance
...
と答えられるようにする。
② CIDR設計
ここは、
💯 完璧！
回答：
VPC
10.0.0.0/16
Public
10.0.1.0/24
Private
10.0.2.0/24
この分割で問題ない。
10.0.0.0/16
│
├── 10.0.1.0/24
│ └── Public Subnet
│
└── 10.0.2.0/24
└── Private Subnet
という形。
今回の理由、
«パブリックとプライベートで通信できる範囲を変えたい»
も方向性としてOK。
さらに実務的にするなら、
«将来的にSubnetを追加できるよう、VPC内に余裕を残してCIDRを分割している»
と説明できるとさらに良い。
今回、
10.0.0.0/16
という大きなネットワークの中から、
10.0.1.0/24
10.0.2.0/24
というSubnetを切り出している。
この感覚は今後かなり重要になる。
③ ALB Security Group
回答：
80
💯 正解！
HTTPでWebページへアクセスするため、
Internet
│
│ TCP :80
▼
ALB
となる。
HTTPSを使う構成なら、
443
が基本。
今回はHTTPなので、
80
でOK。
⭐ ④ EC2 Security Group
ここが今回一番重要。
まず、
«EC2はALBからだけ許可する。»
これは、
💯 完璧！
今回の要件、
«EC2へはALB経由だけでアクセスさせる»
を正しく読み取れている。
構成としては、
Internet
│
▼
ALB
│
▼
EC2
なので、
EC2側では、
ALB → EC2
だけを許可する。
ただし、理由は少し修正
回答では、
«CIDRを指定しない理由は特定の通信を許可したいわけじゃないから。»
となっていた。
ここは実は逆。
今回、
「ALBという特定の相手だけを許可したい」
から、Security Group参照を使う。
つまり、
Internet
│
▼
ALB
│
│ ← ここだけ許可
▼
EC2
という関係を、
security_groups = [
aws_security_group.alb.id
]
で表現する。
CIDRではなくSecurity Group参照を使う理由
例えば、
0.0.0.0/0
をEC2に許可したら、
Internet
│
├────────→ EC2
│
▼
ALB
│
└────────→ EC2
となってしまう。
これでは、
ALBを経由せずにEC2へ直接アクセスできる可能性
が出てしまう。
だから、
EC2 Security Group
│
│
▼
「ALB Security Groupを持つ相手だけ許可」
とする。
これなら、
Internet
│
▼
ALB
│
▼
EC2
という経路に限定できる。
⭐ 先生から逆質問
ここから、もう一段実務っぽい問題。
もし、
ALBを2台
作ったとする。
ALB①
│
▼
EC2
ALB②
│
▼
EC2
そして、
ALB①とALB②の両方に同じSecurity Groupを付けている。
ALB①
SG: alb-sg
ALB②
SG: alb-sg
EC2側では、
security_groups = [
aws_security_group.alb.id
]
としている。
🔥 問題
この場合、
EC2はALB①・ALB②の両方から通信を受けられる？
理由も考えてみよう。
💡 ヒント
EC2側が許可しているのは、
「ALB①」
という個別のALBではない。
許可しているのは、
「alb-sgを持っているリソース」
という条件。
ここを考えてみよう。
✍️ 逆質問への回答
回答：
«同じSecurity Groupを使っているから、EC2はALB①・ALB②の両方から通信を受けられる。»
🎉 正解！
その通り。
ここは実務でもかなり重要な考え方。
Security Group参照では、
IPアドレスそのものではなく、Security Groupを持つリソースを通信元として指定できる。
例えば、
ALB①
│
│ SG: alb-sg
│
├─────────┐
│
ALB② │
│ │
│ SG: alb-sg
│ │
└────┬────┘
│
▼
EC2
ec2-sg
EC2側が、
security_groups = [
aws_security_group.alb.id
]
を許可しているなら、
alb-sgを持っているALB
からの通信を許可できる。
つまり、
ALB① → OK
ALB② → OK
となる。
これがSecurity Group参照の強さ
もしIPアドレスで、
ALBのIP
を直接指定していたら、ALBの構成変更やIPアドレス変更などに応じてルールの見直しが必要になる。
一方、
ALB
↓
alb-sg
↓
EC2
という関係で設計しておけば、
「ALBという役割を持つリソースからの通信を許可する」
という意図をコードに表現できる。
これは、
IPアドレスを許可する
よりも、
役割・関係を許可する
というAWSらしい設計。
📝 今回のレビューまとめ
項目| 評価
必要なリソースの洗い出し| 90点
CIDR設計| 100点
ALB Security Group| 100点
EC2 Security Group| 100点
Security Group参照の理解| 100点
総合| 🌟98点🌟
今回の一番大きな学び
今回、一番大事なのは、
Terraformのコードを書かなかったこと。
むしろ、コードを書く前に、
要件
↓
必要なAWSサービス
↓
ネットワーク構成
↓
通信経路
↓
Security Group
を考えた。
これが実務では重要。
「Terraformを書く人」から「設計してTerraformを書く人」へ
今までの授業では、
このコードを書いてください
↓
なぜこう書く？
という順番だった。
でも今回は、
会社のWebサービスを作ってください
↓
何が必要？
↓
どういうネットワークにする？
↓
誰から誰へ通信させる？
↓
どこまで許可する？
↓
Terraformでは何を書く？
という順番。
この違いはかなり大きい。
今日の理解度
⭐⭐⭐⭐⭐ 5 / 5
今回、特に良かったのは、
「ALBからだけEC2へ通信させる」
という要件を見て、
EC2 Security Group
↓
ALB Security Groupを参照
という設計まで持っていけたこと。
さらに逆質問では、
«同じSecurity Groupを付けているなら、ALB①とALB②の両方から許可される»
というところまで理解できた。
これは単なるTerraformの文法ではなく、
AWSの通信制御そのものを理解できている
ということ。
🚀 次回
今回、設計図は完成した。
次はいよいよ、
第18回：この設計をTerraformでコード化する
今回考えた、
VPC
↓
Public Subnet
↓
Private Subnet
↓
IGW
↓
Route Table
↓
ALB
↓
Listener
↓
Target Group
↓
EC2
↓
Security Group
を、
自分でTerraformコードに落としていく。
今度は最初から完成コードを渡すのではなく、
設計を見ながら、自分でコードを書く。
分からないところはレビューで修正する。
つまり、
要件
↓
設計
↓
コード
↓
レビュー
↓
修正
という、かなり実務に近い流れになる。
🔥 実務編、スタート
初級編では、
AWSの部品を覚えた。
第17回では、
要件からAWS構成を考えた。
そして次は、
その設計をTerraformに変換する。
ここから、
«「Terraformを書ける」»
から、
«「AWSを考えて、Terraformで作れる」»
へ進んでいこう。
実務エンジニアモード、ここから本番。💪☁️🚀