― ついに「仕事をするサーバー」を作る ―
ここまで作ってきたものを、一度振り返ってみよう。
- VPC
- Subnet
- Route Table
- Internet Gateway
- NAT Gateway
- ALB
- Listener
- Target Group
- Target Group Attachment
実は今まで作ってきたものは、ほとんどが
「通信の道」
だった。
これまで
Internet
↓
ALB
↓
Listener
↓
Target Group
↓
？？？
そう。
最後の「？？？」がまだいなかった。
そこで今回は、いよいよ……
EC2を作る！🔥
EC2は今までのような「道」ではなく、
実際にアプリケーションを動かして仕事をするサーバー
だ。
今回、ここが完成する。
Internet
↓
ALB
↓
Listener
↓
Target Group
↓
EC2
ついにAWSの構成図が、かなり「それっぽく」なってきた。
TerraformでEC2を作る
まずは基本形。
resource "aws_instance" "web" {
}
これは、
EC2インスタンスを作成する
というTerraformのコード。
ここからEC2に必要な設定を一つずつ追加していく。
① AMI
ami = "ami-xxxxxxxx"
ここで質問。
AWSコンソールからEC2を作ったことを思い出してみよう。
最初に何を選んでいた？
- Amazon Linux
- Ubuntu
- Windows Server
- その他いろいろ
これらは何だった？
そう。
OSや、そのOSを含んだイメージ。
その正体がAMI。
AMIとは？
AMIは、
EC2を作成するときに使うOSや初期設定などを含んだイメージ
のこと。
イメージとしては、
AMI
↓
EC2を作るためのテンプレート
という感じ。
例えば、
Amazon LinuxのAMI
↓
Amazon LinuxのEC2
UbuntuのAMI
↓
UbuntuのEC2
Windows ServerのAMI
↓
Windows ServerのEC2
という関係。
なので、
ami = "ami-xxxxxxxx"
は、
«「このAMIを元にEC2を作ってください」»
という指定になる。
② instance_type
次はこちら。
instance_type = "t3.micro"
これは何を決めている？
そう。
EC2のスペック。
CPUやメモリなど、どれくらいの性能を持ったEC2にするかを決める。
例えば、
t3.micro
↓
比較的小さなインスタンス
m7i.large
↓
より高いスペックのインスタンス
というイメージ。
AWSコンソールでいうと、
「インスタンスタイプを選択する」
の部分をTerraformで書いている。
③ subnet_id
次はこちら。
subnet_id = aws_subnet.private.id
ここで今日の重要ポイント。
なぜ、
vpc_id
ではなく、
subnet_id
なのか？
ヒントはこれ。
VPC
│
├── Public Subnet
│
└── Private Subnet
│
└── EC2
EC2は、
VPCの中に直接置くのではなく、VPCの中にあるSubnetに配置する。
だから、
subnet_id = ...
になる。
VPCだけ指定しても、
«「そのVPCの中の、どのSubnetに置けばいいの？」»
となってしまう。
TerraformでSubnetを指定することで、
«「このEC2は、このSubnetに配置してね」»
とAWSに伝えている。
④ Security Group
最後はこちら。
vpc_security_group_ids = [
aws_security_group.ec2.id
]
ここではまだSecurity Groupそのものは作っていない。
今は、
「このEC2に、このSecurity Groupを関連付ける」
くらい理解できていればOK。
AWSコンソールでいうと、
EC2作成
↓
Security Groupを選択
の部分。
ここでもTerraformは、
AWSコンソールでやっていた操作をコードにしている
だけ。
完成形
ここまでをまとめると、
resource "aws_instance" "web" {
ami = "ami-xxxxxxxx"
instance_type = "t3.micro"
subnet_id = aws_subnet.private.id
vpc_security_group_ids = [
aws_security_group.ec2.id
]
}
かなりシンプルに見える。
でも、この数行の中には、
- どのOSを使うか
- どのくらいのスペックにするか
- どこに配置するか
- どのSecurity Groupを適用するか
という、EC2を作るための重要な情報が詰まっている。
🔥 今日の問題
ここからは、いつものように自分の言葉で考えてみよう。
Q1
なぜ
subnet_id
なの？
なぜ
vpc_id
じゃない？
Q2
AMIって何？
自分の言葉で説明してみよう。
Q3【今日一番重要】
EC2はPrivate Subnetに置く。
でも、
ブラウザからEC2上のWebアプリへアクセスできる。
なぜ？
今まで勉強したサービスを全部思い出してみよう。
Internet
↓
？
↓
？
↓
EC2
この通信経路を、自分の言葉で説明してみよう。
🎯 今日の目標
今回も暗記する必要はない。
むしろ、
AWSコンソールを思い出してほしい。
EC2を作るとき、
AMIを選ぶ
↓
インスタンスタイプを選ぶ
↓
VPCを選ぶ
↓
Subnetを選ぶ
↓
Security Groupを選ぶ
ってやっていたはず。
Terraformでは、それを
ami = ...
instance_type = ...
subnet_id = ...
vpc_security_group_ids = ...
とコードで書いているだけ。
つまり、
«TerraformはAWSコンソールでクリックしていた操作をコードにしている»
と考えるとかなり分かりやすい。
📝 今回の回答
今回の回答はこちら。
コードの説明
«"resource "aws_instance" "web""
Webサーバーを作る»
«"ami = "ami-xxxxxxxx""
このインスタンスのAMIはami-xxxxxxxx»
«"instance_type = "t3.micro""
インスタンスタイプはt3.microで、小さいやつ»
«"subnet_id = aws_subnet.private.id"
このインスタンスはプライベートサブネットに作る»
«"vpc_security_group_ids"
VPCのセキュリティグループをEC2に作る»
🔎 今回のレビュー
今回かなり良かった。
特にQ3。
通信経路を意識して答えられている。
ここは今までのTerraform学習がちゃんとつながってきている部分。
では、一つずつ見ていこう。
コードの説明
"resource "aws_instance" "web""
«Webサーバーを作る»
これはOK。
100点！💯
厳密には「EC2インスタンスを作る」だけど、今回の構成ではWebサーバーとして使うので、この理解で問題なし。
"ami = "ami-xxxxxxxx""
«このインスタンスのAMIはami-xxxxxxxx»
これも方向性は合っている。
ただ、もう一歩だけ実務っぽくすると、
«このEC2を、指定したAMIを元に作成する。»
と考えるといい。
AMIは単なる「番号」ではなく、
OSや初期状態などを含んだEC2作成用のテンプレート
と考えると分かりやすい。
例えば、
Amazon Linux
Ubuntu
Windows Server
などの環境を作るための元になるもの。
ここは 95点！
"instance_type = "t3.micro""
«インスタンスタイプはt3.microで、小さいやつ»
「小さいやつ」🤣
意味はちゃんと合ってる。
ただブログや実務で説明するなら、
«CPUやメモリなど、EC2のスペックを決める。»
と書けると完璧。
ここは 95点！
"subnet_id = aws_subnet.private.id"
«このインスタンスはプライベートサブネットに作る»
これは完璧。
100点！💯
ちゃんと、
VPC
↓
Subnet
↓
EC2
という階層を理解できている。
"vpc_security_group_ids"
ここは少しだけ修正。
回答では、
«VPCのセキュリティグループをEC2に作る»
となっていた。
ここで重要なのは、
Security GroupをEC2に「作る」のではない
ということ。
正しくは、
«EC2にSecurity Groupを関連付ける（アタッチする）。»
という理解。
Security Group自体は別のAWSリソースとして存在していて、それをEC2に適用するイメージ。
Security Group
↓
EC2に関連付け
↓
EC2の通信を制御
ここは 90点！
Q1レビュー
«EC2はサブネットの中のプライベートサブネットに作るから。
プライベート通信でVPCIDは使えない。»
前半はバッチリ。
95点！
ただし後半の、
«プライベート通信でVPCIDは使えない»
これは違う。
ここ、かなり大事。
VPCはちゃんと使っている。
構造はこう。
VPC
│
├── Public Subnet
│
└── Private Subnet
│
└── EC2
つまり、
EC2はVPCの中に存在して、そのさらに中のSubnetに配置される。
だから、
subnet_id = ...
を指定する。
VPCだけ指定してしまうと、
«「VPCの中のどのSubnetに配置するの？」»
という情報が足りない。
なので、
VPC → Subnet → EC2
という関係を覚えておけばOK。
Q2レビュー
«AMIはEC2をどのような構成で作成するかを定義したもの。»
これもかなり良い。
95点！
さらに分かりやすくするなら、
«AMIはEC2を作成するためのOSや初期状態を含んだテンプレート。»
と考えるといい。
イメージとしては、
AMI
↓
「この状態のサーバーを作って！」
↓
EC2
という感じ。
Q3レビュー🔥
ここは……
めちゃくちゃ良い。
回答は、
«インターネットからEC2へ行くまでに、ALB、listener、ターゲットグループを通りEC2まで行きます。
ALBとlistenerでどう振り分けるかを決め、ターゲットグループでターゲットのEC2ポート転送するからブラウザからアクセスできる。»
だった。
これ、かなり重要なところまで理解できてる。
特に、
ALB
↓
Listener
↓
Target Group
↓
EC2
を自分の言葉で説明できているのがいい。
さらに一つだけ追加するなら、
Internet Gateway（IGW）
も入れよう。
今回の構成なら、
ブラウザ
↓
Internet
↓
Internet Gateway
↓
ALB
↓
Listener
↓
Target Group
↓
EC2
というイメージ。
ここまで言えたらかなり強い。
Q3は100点！💯
🎉 今回の成績
項目| 点数
コードの理解| 95点
Q1| 95点
Q2| 95点
Q3| 100点
総合| 🌟96点🌟
かなり高い。
そして今回の点数以上に大事なのが、
「通信の流れ」で考えられるようになってきたこと。
🚀 今回の一番大きな成長
最初の頃は、
VPC
↓
Subnet
という感じで、一つずつAWSサービスを覚えていた。
でも今は、
Internet
↓
Internet Gateway
↓
ALB
↓
Listener
↓
Target Group
↓
EC2
という一つの通信として考えられるようになっている。
これ、Terraformを勉強するうえでかなり大きい。
なぜならTerraformは、
コードを書くこと自体が目的ではない
から。
AWSの構成を理解して、
「このサーバーをここに置きたい」
「この通信をここに流したい」
「このSecurity Groupを適用したい」
という設計をコードにしていく。
だからAWSの構成が頭の中で動くようになると、Terraformも一気に分かりやすくなる。
💡 そして今回もう一つ大事なこと
ここまで来ると、
AWSの資格勉強とTerraformの勉強がつながってくる。
例えば、
SAPで覚えた
「ALB」
「Target Group」
「Private Subnet」
「NAT Gateway」
「最小権限」
が、
Terraformで実際に
resourceとして作る
↓
関連付ける
↓
通信させる
という形になってくる。
今まで点だったAWS知識が、
「あ、このサービスはここで使うのか」
と線になってくる。
これがTerraformを勉強する面白いところ。
🔒 次回予告
次はいよいよ……
Security Group！
ここから一気に実務っぽくなる。
例えば、
Internet
↓
ALB
80番だけ許可
↓
EC2
ALBからの通信だけ許可
↓
RDS
EC2からの通信だけ許可
というように、
「誰から誰への通信を許可するのか」
をコードで定義していく。
そしてここで、
「最小権限の原則」
という、AWS資格でも何度も出てきた考え方が、実際のTerraformコードにつながってくる。
☁️ 今日のまとめ
今回覚えたことはこの4つ。
AMI
↓
EC2の元になるOS・初期状態のテンプレート
instance_type
↓
EC2のスペック
subnet_id
↓
EC2を配置するSubnet
vpc_security_group_ids
↓
EC2に適用するSecurity Group
そして一番大事なのは、
Internet
↓
IGW
↓
ALB
↓
Listener
↓
Target Group
↓
EC2
という通信の流れ。
ここまで自分の頭で組み立てられるようになってきたら、Terraformはもう「謎のコード」じゃない。
AWSの構成図を、そのままコードに翻訳しているだけ。
この感覚を持ったまま、次はSecurity Groupへ進もう。🔥☁️🚀