VPC

Tue, 20 Aug 2024 04:32:54 GMT

![Image](https://upload.cafenono.com/image/slashpageHome/20240820/134156_SU7N7PAMIMfk03tIAP?q=80&s=1280x180&t=outside&f=webp)

> CIDR, Subnet Mask, 그리고 Public IP, Private IP는 안다는 전제로 진행한다.

# 1. VPC

### VPC

VPC(Virtual Private Cloud)는 각각의 리전에서 고유의 CIDR(IP 범위)를 가지고 있는 가상 클라우드이다. VPC의 CIDR는 다른 VPC와 겹쳐서는 안된다. VPC는 /16 ~ /28 사이의 CIDR를 쓸 수 있다.

### Subnet

Subnet은 VPC 내의 또 다른 격리 구역이라고 생각할 수 있다. 각 서브넷 별로 다른 CIDR를 가지고 있고, 첫 5개의 IP와 마지막 1개는 예약되어 있다.

### Internet Gateway (IGW)

VPC 안의 서비스들이 외부 인터넷과 통신할 수 있도록 해주는 리소스이다. 수평 확장하고 고가용성을 보장하며 한 VPC당 최대 하나씩 가질 수 있다. 또한 라우트 테이블도 꼭 수정해 주어야 한다.

### Route Table

각각의 서브넷 마다 하나씩 할당될 수 있다. 네트워크 트래픽이 어디로 가는지 결정하며 `10.0.0.0/24 → IGW`라고 하면 해당 트래픽은 IGW로 간다. 프라이빗 서브넷과 퍼블릭 서브넷을 구분짓는 것도 IGW를 가리키는 라우팅 테이블이 있냐 없냐이다.

### Bastion Host (밖 → 안)

프라이빗 서브넷은 라우트 테이블에 의해 IGW로 이동할 수 없다. 그래도 외부에서 프라이빗 서브넷 안의 서비스에 접근하고 싶은 상황이 생긴다. 그럴 때는 퍼블릭 서비스에 EC2 같은 서비스를 만들고 해당 서비스로 하여금 프라이빗 서브넷에 접근하도록 한다. 이걸 Bastion Host라고 부른다. 이때 Bastion Host는 22번 SSH 포트만을 허용하여야 한다.

### NAT Instance / NAT Gateway (안 → 밖)

Bastion Host와는 정반대로 프라이빗 서브넷 안의 서비스가 업데이트 등의 이유로 외부와 소통하고 싶을 수도 있다. 그럴 때는 NAT를 퍼블릭 서브넷에 둬서 NAT를 매개로 밖과 소통한다. 물론 라우트 테이블을 구성해야 한다.

NAT Instance는 이제는 쓰지 않는 기술로, EC2 인스턴스를 퍼블릭 서브넷에 생성하는 방법이다. EC2가 할 수 있는 건 다 할 수 있다. 반면, NAT Gateway는 AWS에서 완전 관리해주는 NAT로 별 설정하지 않아도 자동으로 돌아간다.

IPv6 버전은 **외부 전용 인터넷 게이트웨이**가 담당한다.

### DNS 지원

VPC 내에서 리소스에 접근할 때 IP와 DNS 둘 다로 접근이 가능하다. `enableDnsHostnames`와 `enableDnsSupport` 속성을 설정해 DNS를 결정한다.

먼저 `enableDnsSupport`는 AWS에서 자체 지원하는 Route53 Resolver를 사용할 것인지 설정한다. True면 `169.243.169.253`이나 `xx.xx.xx.2`를 통해 Route53 Resolver를 사용할 수 있다. False면 자체 DNS 서버를 사용한다.

`enableDnsHostnames`는 `enableDnsSupport`가 참일때만 동작하며, EC2 인스턴스가 퍼블릭 IPv4를 가지고 있다면 퍼블릭 호스트네임을 할당하는 역할을 한다.

만약 VPC 내에서 프라이빗 호스트네임으로 인스턴스를 사용하고 싶다면 속성 두 개 모두 참이어야 한다.

### Security Group & NACL

**Stateful**: 인바운드로 허용되면 해당 트레픽의 아웃바운드도 허용된다. 반대도 마찬가지. 예를 들어 HTTP request가 들어오면 해당 트레픽의 response는 포트나 설정에 상관없이 임시 허용된다.

**Stateless**: 인바운드, 아웃바운드 따로 따로 검사를 받아야 한다. 인바운드가 허용되었더라도 아웃바운드 규칙이 Deny되면 해당 트래픽은 차단된다.

**NACL**

- Stateless

- Subnet에 하나씩 붙어야 한다.

- 허용, 차단 규칙을 설정할 수 있다.

- 규칙 순서를 설정한다.

- 낮은 순서 정책의 허용/차단 결정을 따른다.

**Security Group**

- Stateful

- EC2 인스턴스에 최소 하나씩 붙어야 한다.

- 허용 규칙밖에 못한다.

- 아무 규칙이나 IP와 포트를 허용하면 허용된다.

# 2. VPC 연결하기

- **VPC Peering** - VPC

- **VPC Endpoint **- AWS Services

- **Site-to-Site VPN **- On-Premise (Logical)

- **Direct Connect **- On-Premise (Physical)

- **Transit Gateway **- Multi VPC

- **VPN CloudHub **- Multi On-Premise

- **PrivateLink **- Expose Service Private

### VPC Peering

VPC 간에 프라이빗 연결을 지원해 하나의 네트워크에 놓여 있는 것처럼 취급할 수 있는 서비스이다. CIDR가 겹치면 안되며, 직접 연결된 네트워크와만 소통이 가능하다. 각각의 라우트 테이블을 설정해 주어야 한다. 다른 계정과도 연동이 가능하다.

다른 계정에 있는 인스턴스더라도 VPC Peering으로 연동이 되어 있으면 해당 인스턴스의 보안 그룹을 허용해줄 수 있다.

### VPC Endpoint ( AWS PrivateLink)

EC2, ELB 같은 서비스 외에는 모두 외부에 공개되어 있으며, 따로 VPC에 둘 수 없다. 그래서 EC2는 해당 서비스에 접근할 때 IGW를 통해 인터넷으로 접근을 하므로 비효율적이게 된다. 이를 해결하기 위해 VPC Endpoint를 만들어 프라이빗하게 접근할 수 있도록 한다. 이렇게 하면 트래픽을 외부에 노출시키지 않고 AWS 망 내에서만 돌아가기 때문에 안전하다.

Gateway Endpoints - S3, DynamoDB만, VPC 내에 Gateway를 두고 라우트 테이블을 통해 연결한다.

Interface Endpoints - 나머지 서비스, 서브넷 내에 ENI를 두고 보안 그룹을 달아서 쓴다.

### Site-to-Site VPN

온프레미스 서버를 VPC에 연결시키는 서비스이다. VPC 단에는 **Viritual Private Gateway(VPG)**를, 온프레미스 단에는 **Customer Gateway(CGW)**를 설치해 연결한다. 이 연결을 위해서는 라우트 전파를 설정해 VPG가 라우트 테이블과 연동될 수 있게 해야 한다. 온프레미스 단에 NAT 장비를 달아 프라이빗 서브넷으로 사용할 수도 있다.

### VPN CloudHub

하나의 VPC, 하나의 VPG에 여러 온프레미스가 Site-to-Site VPN으로 붙으면 어떻게 될까? 온프레미스들끼리도 서로 소통할 수 있다. 이를 hub-and-spoke 모델이라 하며 저비용으로 온프레미스 전부와 VPC를 하나로 묶을 수 있다.

### Direct Connect (DC)

AWS에서 제공하는 장소(DC)와 온프레미스를 물리적 회선으로 연결하는 서비스이다. 이렇게 하면 굉장히 빠른 속도로 AWS 내 다른 서비스들과 소통할 수 있다. VPC에서 사용하려면 VPC에 VPG가 설치되어 있어야 하며 Direct Connect Gateway를 통해 여러 리전, 여러 VPC와도 연결할 수 있다. 연결 방식에는 2가지가 있는데,

- 전용 연결 - AWS DC와 직접 이더넷 연결을 한다

- 호스팅 연결 - 파트너 회사의 노드와 물리적인 연결을 한다.

연결은 암호화되어 있진 않지만 정해진 길만 타고 AWS 망 내로만 연결되므로 안전하다. DC와 VPN을 함께 사용하면 Ipsec-encryped 프라이빗 연결을 할 수 있다.

### PrivateLink

VPC를 노출시키지 않고 특정 서비스만 안전하게 노출시키고 싶을 때 사용한다. 노출시키려는 서비스에는 NLB를 부착해야 하고, 서비스를 제공 받는 서비스는 ENI나 GWLB를 부착해야 한다. 만약 NLB와 ENI가 모두 multi-AZ면 장애 허용 시스템(fault tolerant)이다.

### Transit Gateway

VPC Peering이나 VPN이 계속 복잡해질 수 있다. 이를 해결하기 위해 VPC, Direct Connect Gateway VPN 연결을 한 데 모아 관리하는 서비스이다. hub-and-spoke 방식으로 작동하며 IP 멀티캐스트를 지원한다. 연결은 됬지만 라우트 테이블로 라우팅을 해줘야 실제 소통할 수 있으며 리전에 상관없이 연결할 수 있다. Resource Access Manager(RAM)을 통해 다른 계정에 공유할 수도 있다.

ECMP(Equal-cost multi-path routing) - Transit Gateway에서 같은 서버에 구멍을 여러 개 뚫어 여러 경로로 패킷을 보내서 대역폭을 늘리는 기술

# 3. VPC 모니터링

### VPC Flow Logs

VPC, Subnet, ENI의 IP 트래픽 흐름을 캡쳐하는 서비스이다. 모니터링과 연결 오류 문제를 탐색하는데 도움을 주며, S3나 CloudWatch Logs로 보낼 수 있다. SG나 NACL에서 허용/차단했는지 여부를 확인할 수 있다. 들어r가는 건 허용인데, 나오는 건 거부면 무조건 NACL에서 차단한거다.

### Reachable Analyzer

네크워크 구성을 점검해서 트래픽이 도달하지 못하고 고립된 서비스는 없는지 확인하는 서비스이다. 실제 패킷을 보내지는 않고 구성만 확인한다.

### VPC Mirroring

VPC에서 네트워크 트래픽을 뽑아내는 서비스이다. VPC 내부 서비스의 ENI에서 트래픽을 뽑아 목표 ENI나 NLB로 보낸다.

# 4. 네트워크 비용

### S3

![Image](https://upload.cafenono.com/image/slashpageHome/20240820/134157_ctm9PSnZBj6j6GxgwC?q=80&s=1280x180&t=outside&f=webp)

### EC2

![Image](https://upload.cafenono.com/image/slashpageHome/20240820/134158_hMl2zLYX6JpZya3b5A?q=80&s=1280x180&t=outside&f=webp)