VPC의 IP 주소를 나누어 리소스가 배치되는 물리적인 주소 범위를 뜻한다.
VPC가 논리적인 범위를 의미한다면, 서브넷은 VPC안에서 실제로 리소스가 생성될 수 있는 네트워크 영역이라고 생각하면 되며 EC2, RDS같은 리소스를 생성 할 수 있다.
하나의 VPC에 N개의 서브넷을 가질 수 있으며 하나의 AZ에만 생성이 가능하다.
CIDR 10.0.0.0/24 인 경우
10.0.0.0 네트워크 주소 (Network ID)
10.0.0.1 AWS에서 VPC 라우터용으로 예약 (Default Gateway)
10.0.0.2 DNS 서버 주소 DNS 서버의 IP 주소는 기본 VPC 네트워크 범위에 2를 더한 주소이다.CIDR 블록이 여러 개인 VPC의 경우, DNS 서버의 IP 주소가 기본 CIDR에 위치하게 된다.
10.0.0.3 AWS에서 앞으로 사용하려고 예약한 주소
10.0.0.255 네트워크 브로드캐스트 주소
서브넷은 다시 Public Subnet과 Private Subnet으로 나뉠 수 있다.
Private Subnet : 인터넷에 접근 불가능한 subnet (VPC 내부에서만 통신)
Public Subnet : 인터넷에 접근 가능한 Subnet (VPC 외부/내부와 통신)
public subnet에 존재하는 인스턴스는 Public IP와 Elastic IP를 보유하여 인터넷에 연결되어 아웃바운드, 인바운드 트래픽을 주고받을 수 있는 반면, private subnet은 외부에 노출이 되어 있지 않기 때문에 접근할 수 없다.
이처럼 Private 서브넷 내부의 인스턴스들은 오직 다른 서브넷과만 연결이 가능한데
인터넷 연결이 필요할 경우 NAT instance를 통해서 인터넷 연결이 가능하다.
VPC 내 Resource들이 VPC 외부의 서비스(S3, Dynamo DB, Cloudwatch) 등에 접근할 때 Internet Gateway, NAT Gateway 등의 외부 인터넷 전송 서비스를 타지 않고 내부 네트워크를 통해 접근할 수 있도록 지원하는 서비스이다.
VPC 내부에 EC2, RDS, ELB 등을 탑재하고 ENI(Elastic Network Interface)에 사설 IP 혹은 공인 IP를 부여하여 사용한다.
그러면 다른 서비스는 어떨까? S3, Cloudwatch, Cloudfront, Dynamo DB, API Gateway ..등은 설정한 AWS의 Region 내에 존재하지만, VPC 내부에 설치하는 서비스들이 아니고 따로 공인 IP를 가지고 외부에서 접근하는 서비스들이다.
그렇다면 VPC 내의 Private Subnet에 위치한 EC2 인스턴스에서 S3에 대한 api를 호출하게 될 경우 흐름은 EC2(Private Subnet) → NAT Gateway → Router → Internet Gateway → 외부 인터넷 → S3 이와 같을 것이다.
통신에는 문제가 없어 보이지만 결국 VPC 내부 Resource와 기타 AWS Service Endpoint(EC2 API 호출, S3 접속 등)와 통신 시 외부 인터넷에 공개적으로 연결되며 트래픽이 노출된다.
즉 VPC Endpoint는 AWS 여러 서비스들과 VPC를 연결시켜주는 중간 매개체로서, AWS에서 VPC 바깥으로 트래픽이 나가지않고 AWS의 여러 서비스들을 사용할수있게 만들어주는 서비스 이다.
VPC 엔드포인트는 Interface Endpoint와 라우팅 테이블 기반의 Gateway Endpoint 두가지 종류로 나뉜다.
2개 유형의 차이점은 Interface Endpoint가 ENI(Elastic Network Interface)를 이용하여 IP가 할당되고 해당 IP로 Access를 하는 방식이라면, Gateway Endpoint는 Route Table을 이용하여 Endpoint에 Access한다는 점이다.
ENI(Elastic Network Interface)을 기반으로 하여, private ip를 만들어 서비스를 연결한다.
프라이빗 서브넷 내부에 위치한다. SQS, SNS, Kinesis, Sagemaker, Athena등의 다양한 서비스를 지원한다.
Route Table을 이용하여 Endpoint에 Access한다.
라우팅 테이블에서 경로의 대상으로 지정하여 사용하고 VPC 내부에 위치한다.
S3, DynamoDB 만 지원한다.
통신과정 : Private Subnet에 위치한 EC2에서 만일 S3에 대한 api 호출 -> 라우팅 테이블을 보고 라우터로 가서 Gateway Endpoints 쪽으로 전송 -> Gateway Endpoints는 트래픽을 받고 S3로 전송
인스턴스에 대한 인바운드(외부 - > 인스턴스) & 아웃바운드(인스턴스 - > 외부) 트래픽을 제어하는 가상 방화벽 역할을 한다.
인스턴스는 EC2 인스턴스뿐만 아니라 VPC 내에 탑재될 수 있는 수많은 가상 컴퓨터를 의미하는데 정확히는 VPC 내에서 Elastic Network Inteface(ENI)를 갖는 모든 서비스에 탑재될 수 있다. Security Group은 인스턴스의 ENI에 적용되는 것이기 때문이다. RDS, ELB, VPC Interface Endpoint 등도 포함 가능
마지막 두 부분이 Securiy Group의 가장 큰 특징이라고 할 수 있는데
즉, 인바운드를 통해 온 트래픽이라는 소리는 문제없는 허용된 트래픽이라는 것이고 이를 보안 그룹에서 기억하고 있다가, 트래픽이 빠져 나갈때 이 트래픽은 문제없는 놈인걸 기억하기 때문에 아웃바운드 규칙에 구애 받지않고 나가는 것이다.
Subnet 수준에서 특정 인바운드 또는 아웃바운드 트래픽을 허용하거나 거부하여 트래픽을 제어하는 역할을 한다.
Subnet 단위로 적용되기 때문에 Subnet 내의 모든 트래픽은 Network ACL의 규칙 적용을 받게 된다.
Security Group처럼 마지막 두가지 특징이 중요한데 인바운드 규칙을 적용받아 유입된 패킷이 다시 밖으로 나가기 위해서는 아웃바운드 규칙의 적용을 받아야 한다.
규칙 순서의 경우 예를들어 100번 규칙은 80번 포트를 Allow하고 101번 규칙은 Deny 했을 경우 숫자가 작은 100번 규칙에서 80번 포트를 Allow 했기 때문에 101번 규칙 80번 포트를 Deny 는 무시된다.
하나 이상의 CIDR 블록 세트이다. 접두사 목록을 사용하면 보안 그룹과 라우팅 테이블을 보다 쉽게 구성하고 유지 관리할 수 있다.
두 가지 유형이 존재한다.