AWS 네트워킹 - VPC

2023년 6월 17일

CIDR(Classless Inter-Domain Routing)

클래스 없는 도메인간 라우팅으로 IP 주소를 할당하는 메소드
보안 그룹 규칙과 AWS 네트워킹 다룰 때 사용
단순한 IP 범위를 정의하는데 도움울 준다
- WW.XX.YY.ZZ/32 ⇒ 하나의 IP를 의미
- 0.0.0.0/0 ⇒ 모든 IP를 의미
- 192.168.0.0/26 ⇒ 192.168.0.0 - 192.168.0.63 (IP주소 64개)

CIDR 구성 요소

Base IP : 범위에 포함된 IP
- XX.XX.XX.XX처럼 구성됨
- 10.0.0.0 , 192.168.0.0
Subnet Mask: IP에서 변경 가능한 비트의 개수를 정의
- /0, /24, /32
- 두 가지 형식이 있다
  - /8 ←→ 255.0.0.0과 같다
  - /16 ←→ 255.255.0.0
  - /32 ←→ 255.255.255.255

Subnet Mask란?

기본 IP에서 변경할 수 있는 값을 정의하는 방법을 정의한 것이다

/32에서 하나씩 줄어들 수록 사용할 수 있는 IP가 2배씩 늘어난다

IPv4는 32비트이기 때문에 /32는 변경을 하나도 허용하지 않고 하나씩 줄어들 수록 한 비트씩 변경을 허용한다고 생각하면 된다

Public vs Private IP (IPv4)

Internet Assigned Numbers Authority(IANA)에서 구축한 특정 IPv4 주소 블록은 사설 LAN 네트워크(로컬 네트워크) 혹은 공용 인터넷 주소이다
Private IP는 특정 값만 허용한다(이것 뿐만 아니라 많이 있다)
- 10.0.0.0 - 10.255.255.255 (10.0.0.0/8) ← 대형 네트워크에서 사용
- 172.16.0.0 - 172.31.255.255 (172.16.0.0/12) ← AWS 기본 VPC 범위이다
  - AWS내 최대 CIDR의 크기는 /16
- 192.168.0.0 - 192.168.255.255 (192.168.0.0/16) ← 홈 네트워크를 나타낸다
  - 인터넷 라우터가 있다면 흔히 사용
이 외 전 세계에 있는 IP주소는 모두 Public IP가 된다.

기본 VPC

새로운 AWS 계정은 기본 VPC가 있으며 바로 사용 가능
새로운 ec2 인스턴스는 서브셋을 지정하지 않으면 기본 VPC에 실행된다
기본 VPC는 처음부터 인터넷에 견결되어 있어, 인스턴스가 인터넷에 엑세스하고 또 내부의 ec2 인스턴스는 공용 IPv4 외부 주소를 갖는다
공용 및 사설 IPv4 DNS 이름도 얻는다

VPC 살펴보기

각각의 서브넷은 자신만의 IPv4 CIDR을 가진다
서브넷마다 다른 AZ에 위치한다
사용하는 IP가 있다면 주소가 하나씩 줄어든다
라우팅 테이블은 트래픽이 VPC를 통해 경로를 선택하도록 돕는다
- CIDR 모든 트래픽은 인터넷 게이트웨이로 이동한다
- 인터넷 게이트웨이는 VPC에 연결되어 있고 VPC에 위치한 EC2 인스턴스에 인터넷 엑세스를 제공한다
기본 라우팅 테이블은 할당되기 때문에 설정 없이 인스턴스 연결 가능

VPC in AWS - IPv4

Virtual Private Cloud - VPC는 클라우드 컴퓨팅 환경에서 네트워크를 가상화하는 기술
단일 리전에 여러 개의 VPC를 생성할 수 있다(최대 5개지만 엄격한 제한은 아니라 늘릴 수 있다)
VPC마다 할당된 CIDR은 다섯 개이다
- 최소 /28(16개 IP)
- 최대 /16(65536개 IP)
VPC는 사설 IP이기 때문에 Pivate IP 주소만 허용한다
- 10.0.0.0 - 10.255.255.255 (10.0.0.0/8)
- 172.16.0.0 - 172.31.255.255 (172.16.0.0/12)
- 192.168.0.0 - 192.168.255.255 (192.168.0.0/16)

원하는 대로 설정할 수 있지만 다른 VPC나 네트워크 혹은 기업 네트워크와 겹치지 않도록 주의해야한다 → 만약 두개를 연결하려면 VPC 혹은 CIDR IP주소가 다른 네트워크의 IP 주소 범위와 연결해야한다.

Subnet

VPC 내부에 있는 IPv4 주소의 부분 범위 - 이 범위 내에서 AWS가 IP 주소 다섯개를 예약
- ip주소 처음 네 개, 마지막 한 개를 서브넷마다 예약
- 이런 ip주소는 사용할 수 없고 인스턴스에 ip로 할당되지도 못한다
CIDR 10.0.0.0/24 일부는 예약된 ip주소
- 10.0.0.0 - 네트워크 주소
- 10.0.0.1 - AWS가 VPC 라우터를 위해 예약해놓음
- 10.0.0.2 - AWS에서 제공하는 DNS에 매핑
- 10.0.0.3 - 나중에 사용할지도 몰라서 예약
- 10.0.0.255 - 네트워크 브로드캐스트 주소 .255
  - 네트워크 브로드캐스트는 지원하지 않아 예약되어있지만 사용은 불가
IP주소가 29개 필요할 때 /27 서브냇은 사용할 수 없다(32 - 5 = 27) 29 불가능

IP주소 5개는 서브넷에 예약된거다. 사용 가능한 갯수도 5개를 빼고 계산된 것임

Internet Gateway(IGW)

서브넷에 인터넷 엑세스를 연결하는 방법

VPC의 리소스를 인터넷에 견결하도록 허용하는 인스턴스나 람다함수
수평으로 확장되고 가용성과 중복성이 높다 → 관리형 리소스
VPC와는 별개로 생성해야하며 VPC는 하나의 IGW에 연결되며 반대도 마찬가지
IGW 자체는 인터넷 엑세스를 허용하지 않는다. 또한 작동을 위해 라우팅 테이블을 수정해야한다

Route tables에서 0.0.0.0/0을 목적지로 설정하고, IGW를 타겟으로 잡는다는 것은 VPC내 모든 트래픽을 IGW로 보내 인터넷으로 향하도록 설정
이때 VPC와 라우터 테이블은 연결되어 있다. 따라서 VPC와 인스턴스만 잘 연결해서 설정해주면 인터넷연결이 가능함

Bastion Hosts

ec2 인스턴스가 자체 보안그룹(Bastion Host)를 가지고 public subnet에 있다
프라이빗 서브넷에도 보안그룹을 가지고 ec2 인스턴스가 있다
Bastion Host를 사용해 프라이빗 서브넷에 있는 인스턴스에 엑세스 가능
SSH를 Bastion Host에 연결해야한다. 또 Bastion Host가 사설 서브넷이 인스턴스로 SSH 연결해야한다

요약

Bastion Host를 통해 사용자가 사설 서브넷으로 연결 가능
Bastion Host는 반드시 공용 서브넷에 위치해야한다
Bastion Host를 위해서는 보안 그룹이 반드시 인터넷 엑세스를 허용해야한다
- 모든 인터넷 엑세스를 허용하는 것은 보안이 매우 취약해지기 때문에 어느정도 제한을 걸어야한다
- 보안그룹을 최대한 제어할 수록 안전해진다
사설 서브넷의 보안그룹은 Bastion Host의 프라이빗 IP와 SSH를 위한 22번 포트를 허용해야한다

네트워크 보안과 접근 제어를 위해 사용되며 주로 중앙 집중식 관리를 위해 사용된다고 한다

구형 NAT 인스턴스(시험엔 출제됨)

Network Address Translation → 네트워크 주소 변환
NAT 인스턴스는 사설 서브넷 ec2 인스턴스가 인터넷에 연결하도록 허용
공용 서브넷에서 실행되어야 하고 공용, 사설 서브넷을 연결한다
Source/destination 확인은 비활성화해야한다
NAT 인스턴스에는 고정된 탄력적 IP가 필요하다
Route tables를 수정하여 사설 서브넷이 NAT 인스턴스로 트래픽을 전송하도록 해야한다
NAT를 통과해서 요청을 하는데 네트워크 패킷의 소스가 NAT 인스턴스로 재작성된다
- 프록시를 해주는 것과 비슷함
- 일부 IP가 재작성되기 때문에 소스/목적지 확인 설정은 비활성화가 필요함

NAT Comments

사전 구성된 Amazon Linux AMI를 사용 가능
- 표준 지원이 종료되었기 때문에 NAT Gateway 권장(커뮤니티엔 있다)
가용성이 높지 않고 초기화 설정으로 복원 불가
여러 AZ에 ASG가 필요하며 복원되는 사용자 데이터 스크립트가 필요하기때문에 꽤나 복잡하다
작은 인스턴스는 큰 인스턴스와 비교해서 대역폭이 작다
보안그룹과 규칙을 관리해야한다
- 인바운드/아웃바운드

NAT Gateway

고가용성 높은 대역폭, AWS에서 관리하므로 관리가 필요 없다
사용량, 대역폭에 따라 청구
특정 AZ에서 생성되고 탄력적 IP를 이어받는다
인스턴스와 같은 서브넷에서 사용할 수 없어서 다른 서브넷에서 엑세스할 때만 NAT Gateway가 도움이 된다
IGW가 필요하다 (사설 서브넷 → NAT GW → IGW)
초당 5GB로 45GB까지 확장 가능
보안그룹을 고민할 필요가 없다 → 포트 설정 불필요

NAT GW의 고가용성

단일 AZ에서 복원 가능
- Fault Tolerant (시스템이 일부 구성 요소의 장애나 오류에도 정상적으로 작동하거나 서비스를 제공할 수 있는 능력을 가지는 것)을 위해 다중 AZ로 다중 NAT Gateway를 설정해야한다
Route tables를 통해 AZ끼리 연결할 필요는 없다
- AZ가 중지되면 AZ의 인스턴스가 엑세스 불가 상태가 되기 때문이다

NAT instance → 모든걸 너가 설정하는데 설정 잘못하면 성능도 구지고 복구도 어려움

NAT Gateway → 모든걸 AWS가 관리하고 성능도 좋음

NACL과 보안그룹

네트워크 엑세스 컨트롤 리스트(NACL)
Incoming Request
- NACL 인바운드 규칙, 요청이 허가되지 않으면 못들어감
- NACL을 통과하면 보안그룹 인바운드 규칙을 거침
- NACL은 Stateless, 보안그룹은 Stateful
- 만약 요청이 보안그룹의 인바운드 규칙을 통과하면 응답을 보내는데 아웃바운드 규칙은 보안 그룹 수준에서 모두 허용된다 → 평가되는 규칙이 없음
  - 보안그룹이 상태 유지이기 때문 → 들어간 것은 전부 나올 수 있음
- NACL은 아웃바운드 규칙이 무상태이기 때문에 모든 것이 평가받는다.
  - 규칙이 통과하지 못하면 응답도 통과되지 못한다
- 들어오고 나가는게 하나의 상태라고 가정
  - 보안그룹은 들어올 수만 있으면(한번 평가되면 상태가 유지되어) 나가는건 자유
  - NACL은 들어올 때 나갈 때(상태가 없기 때문에) 모두 평가
Outgoing Request(인스턴스 → google.com)
- 보안그룹 아웃바운드 규칙을 통해 나갈지 말지 평가
- NACL을 통해 나갈지 말지 평가
- google.com에 도달하고 다시 돌아올 때
- NACL을 통해 들어올지 말지 평가
- 보안그룹은 상태가 이어지기 때문에 그냥 통과 된다

NACL

서브넷을 오가는 트래픽을 제어하는 방화벽
서브넷마다 하나의 NACL이 있고 새로운 서브넷은 기본 NACL이 할당
NACL 규칙
- 숫자가 있고 (1-32766) 숫자가 낮을 수록 우선 순위가 높다
- 첫 번째 규칙 비교로 결정이 난다
  - Allow 10.0.0.10/32 #100과 Deny 10.0.0.10/32의 특정 범위 IP #200으로 설정해놓으면 Deny IP가 요청이 와도 통과된다
- asterisk(*) → 일치하는 규칙이 없으면 모든 요청을 거부한다
- 규칙을 100씩 추가하는 것을 권장
새로 만들어진 NACL은 모든 것을 거부한다
서브넷 수준에서 특정한 IP주소를 차단하는데 적합하다

Default NACL(시험에서 정말 중요)

기본 NACL은 연결된 서브넷을 가지고 인바운드/아웃바운드의 모든 요청을 허용하는 특수성을 가진다
모든 것이 나가고 모든 것이 들어온다
기본 NACL은 매우 개방적이고 수정하는 것을 권하지 않는다. 대신 커스텀 NACL을 만들어 사용

Ephemeral Ports(임시 포트)

클라이언트와 서버의 연결에선 포트와 엔드포인트가 필요하다
클라이언트는 규정된 포트로 연결하는데, 클라이언트가 서버에서 회신을 받을 때를 고려해야함
- 클라이언트는 기본적으로 개방된 포트가 없어서 클라이언트가 서버에 접속할 때 자체적으로 특정한 포트를 열게 된다
- 임시라서 클라와 서버 간 연결이 유지되는 동안만 열려 있다
OS에 따라 포트 범위가 달라진다(무작위 임시 포트)
전송시 포트를 열고 헤더에 넣어준다

NACL with 임시 포트

클라이언트가 DB와 연결되었을 때 각 서브넷 NACL이 있다
허용되어야하는 규칙들(3,4번 리스트에 집중해야함)
- 클라이언트 NACL은 포트 3306을 통해 TCP와 데이터베이스의 서브넷 CIDR까지 아웃바운드를 허용해야한다
- 데이터베이스 NACL은 클라이언트 서브넷 CIDR과 포트 3306 TCP 인바운드를 허용해야한다
- 데이터베이스 NACL은 아웃바운드를 위해 임시 포트의 범위(1024-65535)와 클라 서브넷의 CIDR까지 포함해야한다
- 클라 NACL은 인바운드를 위해 임시포트의 범위와 DB 서브넷의 CIDR까지 포함해야한다

임시포트를 잘 설정하는 것이 중요하다

각 타겟 서브넷 별 NACL 규칙을 만들 수 있다

다중 NACL 다중 서브넷이 있다면 각 NACL 조합이 NACL 내에서 다중 서브넷을 허용해야한다
CIDR 사용시 서브넷이 고유의 CIDR을 갖고 있기 때문임

NACL에 서브넷을 추가하면 NACL 규칙도 업데이트해서 연결 조합이 가능한지 확인해야만한다

보안그룹 NACL

인스턴스	서브넷
허용 규칙만 지원	허용, 거부 규칙 지원
Stateful	Stateless
모든 규칙을 평가하여 트래픽 허용	우선 순위에 따라 평가하며 첫 번째 비교로 결정
인스턴스에 적용	NACL과 연결된 서브넷의 모든 인스턴스와 연관

명시적인 거부 규칙이 있더라도 더 우선순위가 높은 규칙이 있다면 해당 규칙은 허용된다.

네트워크 문제가 생기면 보안그룹 외에도 NACL도 살펴봐야한다

VPC 피어링

다양한 리전에서 VPC를 만들 때 AWS 네트워크를 통해 연결하고 싶을 때 사용
VPC가 모두 같은 네트워크에서 동작하도록 만들기 위해서 사용한다
CIDR이 서로 명확히 떨어지거나 구분되어야한다
VPC는 전이되지 않으며 다른 VPC가 추가되면 해당 VPC끼리 피어링을 지정해야한다
VPC 서브넷 상의 라우터 테이블 또한 업데이트해서 인스턴스가 서로 통신할 수 있게 한다

VPC 피어링에 대해 알아두어야 할 점

다른 계정 간 피어링이 가능하다
리전간 VPC또한 가능
동일 리전의 계정 간 VPC에서도 보안 그룹을 참조할 수 있다.
- CIDR이나 IP를 소스로 가질 필요가 없으며 보안그룹을 참조할 수 있다

VPC Endpoints

AWS에서 DynamoDB같은 서비스를 사용하면서 퍼블릭 엑세스가 가능한데 NAT Gateway나 IGW를 통해 연결이 가능하다
- 모든 트래픽은 퍼블릭 인터넷을 거쳐서 옴
CloudWatch나 S3를 사용할 땐 인터넷을 거치지 않고 사설 엑세스를 원할 수 있다
이때 VPC 엔드포인트를 사용하면 사설 AWS 네트워크만 거쳐서 바로 엑세스가 가능

VPC 엔드포인트(AWS PrivateLink)

Option 1

비용이 많이든다(NAT Gateway, Internet Gateway는 비용이 없지만 허브와 공용 인터넷을 경유하며 지연 비용이 발생)

Option 2

VPC 엔드포인트는 VPC내에 배포된다
네트워킹을 구성해서 사설 서브넷에 있는 인스턴스를 VPC 엔드포인트를 거쳐 AWS 서비스에 직접 연결이 가능하며 네트워크는 AWS 내에서만 이루어진다.
모든 AWS 서비스는 공용 URL로 접속이 가능하다
VPC 엔드포인트를 사용하면 AWS PrivateLink를 통해 사설 엑세스하므로 모든 서비스에 엑세스할 때 공용 인터넷을 거치지 않고도 접속이 가능
엔드포인트는 중복과 수평 확장이 가능
IGW, NATGW없이도 엑세스 가능하게 한다.
문제가 발생하면 DNS 설정 해석이나 라우팅 테이블을 확인하면 된다.

Types of Endpoints

Interface Endpoints(Private Link)

ENI(VPC의 프라이빗 IP 주소이자 AWS의 엔트리 포인트)를 프로비저닝하며 보안그룹과의 연결이 필요
대부분의 AWS 서비스 지원
시간당 + 처리량으로 요금 계산

Gateway Endpoints

게이트웨이를 프로비저닝하며 반드시 라우팅 테이블의 대싱이 되어야함
IP 주소를 사용하거나 보안 그룹을 사용하지 않고 라우팅 테이블의 대상으로만 지정하면 됨
- 보안그룹이 필요 없음
대상으로는 S3와 DynamoDB 두 가지만 지원하고 있고 요금이 무료
라우팅 테이블 엑세스 뿐이므로 자동으로 확장된다

s3를 위한 게이트웨이 혹은 인터페이스 엔드포인트 선택하는 방법

시험에서는 Gateway를 선택하는 것이 좋음
- 비용이 들지 않고 확장성이 높음
인터페이스 엔드포인트가 권장되는 경우는 온프레미스에서 엑세스 해야할 필요가 있을 때
- 온프레미스에 있는 데이터 센터에 프라이빗으로 엑세스해야하는 경우
- 다른 VPC에 연결할 때도 사용할 수 있다.

VPC Flow Logs

인터페이스로 향하는 IP 트래픽 정보를 포착하는 것
- VPC 계층, 서브넷 계층, ENI 계층 세 가지 Flow log가 있다
flow log는 연결 문제를 모니터링하고 트러블 슈팅하는데 유용
S3 혹은 CloudWatch Logs로 전송 가능
AWS 관리형 서비스 ELB, RDS,ElastiCache, Redshift, NATGW의 정보를 포착

Flow logs Syntax

→ VPC를 통과하는 네트워크 패킷의 메타데이터이다

어떤 정보를 얻을 수 있는지

srcaddr & dstaddr: 문제가 있는 IP 식별(한 IP가 지속적으로 거부되는 경우, IP에 문제가 있거나 특정 IP가 공격받았을 때)
srcport & dstport
Action : 보안그룹이나 NACL 계층에서 요청이 성공했는지 실패했는지를 알려준다
사용량 패턴이나 악성행동감지 포트 스캔 등에 사용될 수 있다
Athena S3 혹은 스트리밍 분석을 위한 CloudWatch Logs Insight

VPC Flow Logs - 트러블 슈팅 보안그룹 & NACL 이슈

Action 필드를 보면 된다

이때 NACL은 Stateless, 보안 그룹은 Stateful을 주의

Incoming Requests

인바운드 거부 ⇒ NACL 혹은 보안그룹
인바운드 허용/아웃바운드 거부 ⇒ NACL

Outgoing Requests

아웃바운드 거부 ⇒ NACL 혹은 보안그룹
아웃바운드 허용/인바운드 거부 ⇒ NACL

아키텍쳐

AWS Site-to-Site VPN

VPC는 구축했지만 특정 구조가 있는 기업에 데이터 센터와 비공개 연결하고자 할 때
기업은 고객 게이트웨이를 VPC는 VPN 게이트웨이를 놓고 공용 인터넷을 통해 사설 Site-to-Site VPN을 연결해야한다 → VPN 연결은 암호화 되어있다

Virtual Private Gateway(VGW)

VPN 연결에서 AWS측에 있는 VPN 접선기
VGW는 생성되면 Site-to-Site VPN 연결을 생성하려는 VPC와 연결된다.
ANS(Autonomous System Number)을 지정할 수도 있다(참고)

Customer Gateway(CGW)

기업이 갖춰야할 소프트웨어 혹은 물리적인 장치로 VPN 연결에서 데이터 센터측에 위치

Site-to-Site VPN Connections

고객 게이트웨이(CGW)가 퍼블릭이라면 → 인터넷 라우팅 가능한 IP주소가 CGW에 있다.
- 해당 IP주소를 통해 연결하면 됨
CGW를 비공개로 남겨 Private IP를 가질 수 있다
- 대부분 NAT-T를 활성화하는 장치 뒤에 있다
- NAT 장치에 퍼블릭 IP가 있을 때 공용 IP를 CGW에 사용해야한다
서브넷의 VPC에서 라우트 전파(Route Propagation)를 활성화해야만 Site-to-Site가 정상적으로 동작한다
온프레미스에서 aws로 ec2 인스턴스 상태를 진단할 때 보안그룹 인바운드 ICMP 프로토콜이 활성화되었는지 확인해야함 → 그렇지 않으면 연결이 되지 않는다

AWS VPN CloudHub

VGW를 갖춘 VPC가 있고 고객 네트워크와 데이터센터마다 고객 게이트웨이 설정 가능
여러 VPN 연결을 통해 모든 사이트간 안전한 소통 보장
비용이 적게드는 Hub&Spoke 모델
VPN만을 활용해 서로 다른 지역 사이 기본 및 보조 네트워크에 활용된다
- 고객 네트워크는 VPN 연결을 통해 서로 소통이 가능
VPN 연결이므로 모든 트래픽이 공용 인터넷을 통한다 → 프라이빗은 불가능
가상 프라이빗 게이트웨이 하나에 Site-to-Site VPN 연결을 여러 개 만들어 동적 라우팅을 활성화하고 라우팅 테이블을 구성하면 됨

Direct Connect(DX)

VPC 전용 프라이빗 연결을 제공한다.
사용할 때 전용 연결을 생성하고 AWS Direct Connect 로케이션을 사용
VPC에는 가상 프라이빗 게이트웨이를 설치해둬야한다.
- 이를 통해 온프레미스와 AWS간 연결을 지원
s3 퍼블릭 리소스와 인스턴스 등의 프라이빗 리소스에 VIF(가상 인터페이스)를 사용해 콘솔과 똑같이 엑세스가 가능
사용 사례
- 대역폭 처리량 증가 → 퍼블릭 인터넷을 거치지않기 때문에 큰 데이터 셋과 적은 비용으로 가능
- 퍼블릭 인터넷 연결에 문제가 발생해도 Direct Connect를 사용하면 지속적인 연결이 가능
- 하이브리드 환경 지원(온프레미스 + 클라우드)

전부 비공개 연결이 가능하다
Private VIF, Public VIF 설치가 필요함

Direct Connect Gateway

다른 리전에 있느 하나 이상의 VPC와 연결하고 싶다면 Direct Connect Gateway를 써야한다

Direct Connect – Connection Types

Dedicated Connections

1Gbp ~ 10Gbp
물리적 전용 이더넷 포트를 받는다(요청시 AWS Direct connect파트너가 처리)

Hosted Connections

50MbP, 500Mbp, 100Gbp
파트너를 통해 연결하고 필요하면 언제든지 용량을 추가하거나 제거할 수 있다

어떤 연결 타입이든 리드 타임(설치하는 시간)이 한 달이상으로 길어질 때도 있다

⇒ 일주일 안에 빠르게 데이터를 전송하고 싶다면 Direct Connect는 해결책이 아니다

Direct Connect - Encryption

암호화기능은 없지만 사설 연결을 통해 비공개할 수 있다
암호화를 원한다면 Direct Connect + VPN을 통해 IPsec으로 암호화된 프라이빗 연결이 가능하다
보안을 높일 수 있지만 구현이 복잡하다

Direct Connect - Resiliency(복원력)

복원력 및 아키텍쳐 모드 두 가지를 기억할 것

핵심 워크로드의 복원력 높일려면

여러 DX를 설치하는게 좋다
하나의 연결을 여러 로케이션으로 만듬 → 하나가 망가져도 다른 하나가 있다

핵심 워크로드 복원력을 최대로 끌어 올리고 싶다면

DX 로케이션에 독립적인 연결을 두 개씩 수립한다

백업으로 활용한 Site-to-Site VPN 연결

DX를 통해 연결에 문제가 발생할 수 있고 비용도 많이 든다.
Site-to-Site VPN 연결을 백업으로 두어 기본 연결에 문제가 발생시 해당 백업 연결을 사용하면 퍼블릭 인터넷으로 연결을 전환하여 안정성이 높아진다 (언제나 연결되어있기 때문)

Transit Gateway

VPN 연결과 DX를 구축해서 여러 개의 VPC를 연결하다보면 매우 복잡해질 수 있다.
VPC 수천개와 온프레미스 데이터센터, Site-to-Site VPN, DX, 허브앤스포크 연결을 통해 과도한 피어링이 발생한다
Transit Gateway를 통해 피어 없이 전이적인 연결이 가능해진다
모든 VPC가 서로 통신할 수 있는데 DX Gateway를 Transit Gateway에 연결하면 DX 연결이 각기 다른 VPC와 연결된다
Site-to-Site VPN 연결을 한다면 고객 게이트웨이와 VPN 연결을 Transit Gateway가 해결
리전간 작동
계정간 공유를 위해 Resource Access Manager(RAM) 사용가능
리전간 Transit Gateway를 피어링할 수 도 있다
Transit Gateway에 라우팅 테이블을 생성해서 어느 VPC가 누구와 연결할 지 Gateway 내 모든 트래픽 경로를 제어해서 네트워크 보안 제공
AWS에서 유일하게 IP 멀티캐스트를 지원한다

Site-to-Site VPN 연결 대역폭을 ECMP를 통해 늘리기

ECMP = Equal-cost multi-path routing (등가 다중 경로 라우팅)
여러 최적 경로를 통해 패킷을 전달하는 라우팅 전략
Site-to-Site VPN연결을 많이 사용해서 AWS로의 대역폭을 늘릴 때 사용

Site-to-Site VPN을 VPC에 직접 연결하면 두 터널 모두 연결 하나로 사용하지만 Transit Gateway를 사용할 때는 두 터널이 동시에 사용된다
Site-to-Site VPN 터널을 2배로 더 사용할 수 있게 해준다
데이터 센터를 직접 VPC 연결한 경우에는 사용 불가능

가상 프라이빗 게이트웨이에 VPN을 하나 연결하면 VPC마다 연결이 하나 생긴다
하나당 1.25Gbps가 최대
이때 VPN 연결은 터널이 두 개로 구성된다

VPN을 Transit gateway에 연결하면 Site-to-Site VPN 하나가 여러 VPC에 생성
모두 전이적으로 연결이 되기 때문
ECMP때문에 최대 처리량이 2.5Gbps → 터널이 2개이지만 더 추가가 가능
하지만 성능 최적화 비용이 추가됨

다중 계정간 DX 연결

Transit gateway에 연결만 하면 구조는 동일하다

VPC 트래픽 미러링

VPC에서 네트워크 트래픽을 수집하고 검사하되 방해되지 않는 방식으로 실행
관리 중인 보안 어플라이언스로 트래픽을 라우팅
- 수집하려는 트래픽이 있는 소스 ENI를 정의
- 어디로 트래픽을 보낼지 대상을 정의
일부 정보만 얻고싶다면 선택적으로 필터를 적용할 수 있다
동일한 VPC에 소스와 대상이 있어야하며 다른 VPC에 걸쳐 있을 수 있다.(피어링 활성화시)
컨텐츠 검사, 위협 모니터링, 트러블 슈팅이 가능하다

VPC용 IPv6

주소 43억 개가 전부 소진될 예정이기 때문에 새로운 체계가 만들어짐
모든 주소는 공용이다(사설 범위는 없음)

VPC와 서브넷에서 IPv4 비활성은 불가능하지만 IPv6를 활성화 가능(듀얼 스택 모드)
해당 모드가 활성화된 VPC에서 인스턴스가 동작하면 최소 사설 내부 IPv4 하나와 공용 IPv6 하나를 얻게 된다
인터넷 게이트웨이를 통해 통신 가능

IPv6 Troubleshooting

IPv4는 VPC 및 서브넷에서 비활성화가 불가능
IPv6가 활성화된 VPC 서브넷에서 ec2 인스턴스를 실행할 수 없다고 하면 IPv6를 받지 못해서가 아니라 서브넷에 현재 이용 가능한 IPv4가 없기 때문이다
서브넷에 새로운 IPv4 CIDR을 활성화해야함

Egress(송신) 전용 Internet Gateway

IPv6 트래픽에만 사용되며 NAT Gateway와 비슷하지만 IPv6 전용이다
VPC 인스턴스에서 IPv6상 아웃바운드 연결을 허용하고 동시에 인스턴스로 IPv6 연결을 시작하지 못하게 막는다 → 인터넷에 엑세스는 가능하지만 연결은 막음
라우팅 테이블 업데이트가 필요

IPv6 라우팅

라우터 테이블에 주목하면 된다

VPC 요약

CIDR - IP 범위
VPC - 가상 사설 클라우드 → IPv4 & IPv6 CIDR의 목록을 정의
서브넷 - CIDR이 정의된 VPC와 AZ 단위로 묶이며 공용,사설 서브넷이 있다
IGW - 공용 서브넷에서 IGW와 연결 경로를 만들면 공용 인터넷 접근이 가능
라우트 테이블 - 게이트웨이나 VPC 피어링,VPC 엔드포인트 라우트를 갖도록 편집되고 네트워크가 VPC 내부에서 흐르도록 돕는다
Bastion Host - 사설 서브넷의 다른 EC2로 SSH 연결이 가능
NAT Instance - 사설 및 공용 서브넷에 배포되어 사설 서브넷의 ec2 인스턴스에 인터넷 엑세스를 제공 ⇒ 사용하지 않는다
NAT Gateway - 성능이 훨씬 좋고 AWS에서 관리, 사설 서브넷 인터넷 연결, IPv4에서만 작동
Private DNS + Route 53 - 사설 DNS를 사용하려면 DNS 변환과 DNS 호스트이름 설정을 VPC에서 설정해야함
NACL - 방화벽 규칙으로 인바운드와 아웃바운드 엑세스를 서브넷 레벨에서 정의. 임시 포트 NACL이 무상태이므로 인바운드와 아웃바운드 규칙이 항상 평가되기 때문에 규칙을 잘 허용해야함
보안그룹 규칙 - 상태가 유지되어 인바운드가 허용되면 아웃바운드까지 허용 그 반대도 성립
Reachability Analyzer - 여러 AWS 리소스 사이에 네트워크 연결을 시험하고 디버깅을 수행
VPC 피어링 - 두 VPC 연결시 유용 CIDR이 겹치지 않고 전이적이지 않기 때문에 3개의 VPC 연결이 필요하다면 VPC 연결도 3개가 있어야한다
VPC Endpoints - 사설 엑세스를 제공하여 S3, DynamoDB 등 VPC 내 모든 서비스에서 가능하며 S3와 DynamoDB 게이트웨이 엔드포인트로 사용되고 나머지는 모두 인터페이스 엔드포인트
VPC Flow Logs - VPC 모든 패킷과 관련해 일정 레벨의 메타데이터를 얻는다. ACCEPT or REJECT 트래픽 정보도 있음. 서브넷이나 ENI 레벨에서 생성 가능하며 분석 과정 후 s3로 이동. 이후 다른 곳으로 보내 분서곧 함
Site-to-Site VPN - VPC를 온프레미스 데이터 센터에 연결하기 위한 방법 중 하나로 공용 인터넷을 지나는 VPN 연결로 AWS에는 가상 프라이빗 게이트웨이를 설치하고 데이터센터에는 고객 게이트웨이를 생성하고 나서 VPN 연결을 구축해야한다
AWS VPN CloudHub - 가상 프라이빗 게이트웨이를 사용해 여러 VPN을 연결하려면 허브앤스포크 모델로 VPN을 연결
Direct Connect (DX) - 온프레미스 데이터 센터에 연결하는 또 다른 방법으로 완전히 비공개 연결을 지원하지만 구축하는데 시간이 걸린다. 훨씬 빠르고 안정적
Direct Connect Gateway - 다양한 AWS 리전의 수많은 VPC에 DX를 생성할 수 있다
AWS PrivateLink / VPC Endpoint Services - 고객 VPC에 만든 자체 VPC에서 AWS 내부 서비스에 직통으로 비공개 연결되며 VPC 피어링 NAT Gateway가 필요 없고 NLB와 ENI가 주로 사용. VPC가 있는 서비스를 네트워크를 공개하지 않고도 직접 노출할 수 있다
ClassicLink - 인스턴스를 VPC에 비공개 연결하지만 곧 사라짐
Transit Gateway - 전이적(VPC간 직접 연결이 필요 없다) 피어링
트래픽 미러링 - 패킷 추가 분석을 위해 ENI 등에서 네트워크 트래픽을 복사해 써드파티 어플라이언스로 전송할 수도 있다
Engress 전용 Internet Gateway - IPv6 전용으로 송신만 가능

AWS에서 네트워킹 비용 per GB

ec2로 들어오는 트래픽은 무료
같은 가용영역에서 인스턴스간 트래픽은 전부 무료
다른 리전간 네트워킹할 때 사설 IP를 활용한 연결이 훨씬 싸다
- 트래픽이 밖으로 나가지만 않는다면 비용이 절감됨
공용 보다는 사설 IP → 성능도 좋고 비용도 절감 설정도 적다
최대한 비용을 절감하도록 같은 가용영역을사용해야함 하지만 가용성이 낮다
- 장애조치가 필요(균형을 맞춰야한다)
예시로써 RDB를 읽기 전용 복제본을 만들어 사용할 때 같은 AZ에 있다면 읽기 전용 복제본으로 만들 때 비용이 들지 않는다. 다만 가용성이 낮아짐. 만약 다른 AZ로 복사한다면 비용은 조금 발생할지언정 가용성을 높일 수 있다

네트워킹 비용 최적화

Egress(송신) 트래픽(AWS → 밖으로)
- 아웃바운드 트래픽
- 대부분 비용이 청구됨
Ingress(수신) 트래픽(밖 → AWS)
- 인바운드 트래픽
- 대부분 무료

따라서 인터넷 트래픽을 최대한 AWS 내부에 두고 비용을 최소화 해야한다.

송신 데이터 사이즈를 줄여서 최소만 보낸다
Direct Connect를 사용할 경우 DX의 로케이션을 같은 AWS 리전으로 활성화해 비용을 아낀다

s3 데이터 전송 비용

요청이 들어오면 비용이 발생하는데 CloudFront는 훨씬 저렴하고 캐싱 기능같은 여러 기능도 지원해준다

NAT Gateway vs Gateway VPC Endpoint

VPC 엔드포인트가 훨씬 저렴하다

Network Protection on AWS

NACL, VPC 보안그룹, WAF(Web application firewall), AWS Shield, Shield Advanced, Firewall manager 등등
VPC 보안을 높이기 위한 더 높은 방법

AWS Network Firewall

VPC 전체를 보호한다
네트워크 3~7계층까지 보호
모든 방향의 트래픽을 검사한다
- VPC간 트래픽
- 인터넷 아웃바운드,인바운드
- DX 혹은 Site-to-Site VPN 연결까지 포함
규칙을 정의하기만 하면 모든 동작을 제어 가능
내부적으로 AWS Gateway Load Balancer를 사용한다 타사 어플라이언스가 아닌 AWS 자체 어플라이언스로 트래픽을 관리하므로 자체 규칙을 갖고 있다
중앙 집중식 관리가 이루어지며 여러 계정과 VPC에 적용된다

Fine Grained Controls(세분화된 컨트롤)

수천 개의 규칙 지원
- 수만 IP와 포트별로 필터링 가능
- 프로토콜 별로 필터링 가능
- 도메인별로 필터링 가능
- 정규식을 통한 일반 패턴 필터링 가능
트래픽 허용, 차단, 알림등을 설정해서 규칙에 맞는 트래픽만 허용 가능
Active flow inspection(활성 플로우 검사): 침입 방지 능력을 갖출 수 있다 Gateway Load Balacner의 역할임
모든 규칙 확인 여부는 s3, CloudWatch Logs, Kinesis Data Firehose로 전송해 분석할 수 있다