VPC 이론
VPC의 구성요소
-
VPC : 사용자의 AWS 계정 전용의 가상 네트워크
: (Virtual Private Cloud)
-
서브넷 : VPC의 IP 주소 범위
-
라우팅 테이블 : 네트워크 트래픽을 전달할 위치를 결정하는데 사용되는 라우팅이라는 규칙 집합
-
인터넷 게이트웨이 : vpc 리소스와 인터넷간의 통신을 활성화하기 위해 vpc에 연결하는 게이트웨이
-
NAT 게이트웨이 : 네트워크 주소 변환을 통해 프라이빗 서브넷에서 인터넷 또는 기타 AWS 서비스에 연결하는 게이트웨이
-
Security Group : 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 하는 규칙 집합
-
VPC 엔드포인트 : 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 AWS Direct Connect 연결을 필요로 하지 않고 PrivateLink 구동 지원 AWS 서비스 및 VPC 엔드포인트 서비스에 VPC를 비공개 연결 가능. vpc의 인스턴스는 서비스의 리소스와 통신하는데 퍼블릭 IP 주소를 필요로 하지 않음. vpc와 기타 서비스간의 트래픽은 아마존 네트워크를 벗어나지 않음
-
NACL : 서브넷 단위로 적용
: NACL이 설정된 서브넷 안의 모든 인스턴스에 적용
: NACL은 여러개의 서브넷에 적용 가능
: 서브넷은 하나의 NACL만 적용 가능
비슷해보이는 요소간 차이
-
NACL과 보안그룹의 차이점
- 보안그룹 : 인스턴스 단위로 적용, 상태 저장 방화벽 (stateful),포트 및 IP Deny 불가능
- NACL : 서브넷 단위로 적용, 상태 저장하지 않는 방화벽(stateless), 포트 및 IP Deny 가능
=> 같은 서브넷끼리 통신 할 때 : 보안그룹 정책을 거치면서 통신
다른 서브넷끼리 통신 : NACL 정책을 거친 후 보안그룹 정책 거침 -
Internet 게이트웨이 와 NAT 게이트웨이 차이점
ec2에 공인ip가 붙여져있으면 public subnet.
공인ip가 없지만 nat 게이트웨이를 통해 인터넷으로 갈 수 있으면 prvate subnet
NAT 게이트웨이와 연결된 라우팅 테이블 => Private 서브넷
인터넷 게이트웨이와 연결된 라우팅 테이블 => Public 서브넷
VPC를 AWS 콘솔에서 만들지 않고 IaC로 하는 이유
콘솔에서 만들면 히스토리를 추적하기 어려움
IaC로 만들면 히스토리를 알고 변경 내용을 알 수 있음
VPC는 서비스의 특성과 크기에 따라 vpc 구성이 복잡해질 수 있음 => 코드를 통해 원하는 모양으로 만들 수 있어야함
VPC 실습
코드로 vpc 생성
-
provider.tf 생성
-
vpc.tf 생성
- cidr_block은 필수 인자값
- 코드
-
terraform init
-
terraform plan
-
terraform apply
-
AWS 콘솔에 들어가서 생성된 VPC 확인하기
코드로 서브넷 생성
서브넷 특징 : availability zone에 속한 네트워크 그룹으로
aws_subnet이라는 리소스 사용하면 됨
vpc 내부에 있어야함
cidr_block 필수 인자값
가용영역 지정해줄 수도 있고 안해줄 수도 있음
1. vpc.tf 파일에 추가해줌
resource "aws_subnet" "public_subnet" {
vpc_id = aws_vpc.main.id
cidr_block = "10.0.0.0/24"
tags = {
Name = "terraform-101-public-subnet"
}
}
resource "aws_subnet" "private_subnet" {
vpc_id = aws_vpc.main.id
cidr_block = "10.0.1.0/24"
tags = {
Name = "terraform-101-private-subnet"
}
}- terraform plan
- terraform apply
코드로 IGW와 NAT Gateway 생성
- IGW와 연결 = public subnet
- NAT Gateway = private subnet
- private 서브넷 안에 있는 인스턴스들은 외부에 나갈 때 NAT Gateway에 갔다가 IGW를 통해서 나감 => private 서브넷 안의 인스턴스들은 나갈 때 같은 아웃바운드 IP를 갖게됨
IGW 생성
- vpc.tf에 코드 추가 작성
resource "aws_internet_gateway" "igw" {
vpc_id = aws_vpc.main.id
tags = {
Name = "main"
}
}- terraform plan
- terraform apply
NAT Gateway
Nat Gateway는 반드시 고정 IP(Elastic IP)를 가지고 있어야 하고, private subnet에서 보내는 모든 요청이 외부로 나갈 때는 내부IP가 아닌 고정 IP를 사용함
1. vpc.tf에 eip와 nat_gateway 코드 추가
- terraform apply
Route Table 생성
Route Talbe : 룰들의 집합. 내부에서 트래픽이 어떤 경로로 가게할지.
: Route Table은 트래픽을 규칙에 맞게 전달해주기 위해 필요한 일종의 테이블
: 여러 서브넷에서 동시에 사용할 수 있음
1. vpc.tf에 aws_route_table 코드 추가, aws_route_table_association 코드 추가
resource "aws_route_table" "public" {
vpc_id = aws_vpc.main.id
tags = {
Name = "terraform-rt-public"
}
}
resource "aws_route_table" "private" {
vpc_id = aws_vpc.main.id
tags = {
Name = "terraform-rt-private"
}
}
resource "aws_route_table_association" "route_table_association_public" {
subnet_id = aws_subnet.public_subnet.id
route_table_id = aws_route_table.public.id
}
resource "aws_route_table_association" "route_table_association_private" {
subnet_id = aws_subnet.private_subnet.id
route_table_id = aws_route_table.private.id
}-
terraform paln
assocition으로 서브넷과 라우트테이블이 연결된거 확인
-
룰 연결하기 ( 방법 2가지 )
3-a. 어떤 라우트테이블의 룰 지정해주기 ( inner rule보다 확장성이 좋음 )
resource "aws_route" "private_nat_1" {
route_table_id = aws_route_table.route_table_private_1.id
destination_cidr_block = "0.0.0.0/0"
nat_gateway_id = aws_nat_gateway.nat_gateway_1.id
}
resource "aws_route" "private_nat_2" {
route_table_id = aws_route_table.route_table_private_2.id
destination_cidr_block = "0.0.0.0/0"
nat_gateway_id = aws_nat_gateway.nat_gateway_2.id
}3-b. innter rule : route_table 리소스 코드 안에 인그레스 형태로 넣어주는 방법
resource "aws_route_table" "public" {
vpc_id = aws_vpc.main.id
route {
cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.igw.id
# 이 라우트 룰이 igw로 나가게된는 의미
# 0.0.0.0/0 : 외부 아웃바운드
}
tags = {
Name = "terraform-rt-public"
}
}- terraform paln -> terraform apply -> 라우팅 규칙 생성됬는지 확인
