Understanding CIDR - IPV4

class 없는 도메인 간 routing

보안 그룹 규칙 및 AWS 네트워킹에서 일반적으로 사용된다.
IP 주소 범위를 정의하는 데 도움을 준다.

BASE IP, Subnet Mask 두가지 구성 요소를 가지고 있다.
subnet Mask 는 IP 에서 변경 가능한 Bit의 개수를 뜻한다.

Subnet Mask

Public vs Private IP(IPv4)

인터넷 할당 번호 관리 기관 (Internet Assigned Numbers Authority, IANA)에서 구축한 특정 IPv4 주소 블록은 사설 (LAN) 및 공용 (인터넷) 주소로 사용하기 위해 설정되었다.
사설 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 범위
192.168.0.0 – 192.168.255.255 (192.168.0.0/16): ex. 홈 네트워크에서 사용
이외의 나머지 모든 IP 주소는 공용 IP 주소이다.

Default VPC Walkthrough

모든 새로운 AWS 계정은 모두 기본 VPC를 가지고 있음
서브넷이 지정되지 않은 경우 새로운 EC2는 기본 VPC에서 실행
기본 VPC는 인터넷 연결이 가능하며, 그 안에 있는 모든 EC2 인스턴스는 공개 IPv4 주소를 가지고 있다.
또한 EC2 인스턴스를 위한 퍼블릭 및 프라이빗 IPv4 DNS 이름도 가지고 있다.

VPC in AWS - IPv4

VPC = Virtual Private Cloud
단일 AWS 리전에 여러 개의 VPC를 생성할 수 있다. (리전당 최대 5개 - 소프트 리밋)
VPC다 최대 CIDR은 5개이며, 각 CIDR에 대해서는:
최소 크기는 /28 (16개의 IP 주소)
최대 크기는 /16 (65,536개의 IP 주소)
VPC는 사설 리소스이기 때문에 프라이빗 IPv4 주소 범위만 허용된다.
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 CIDR은 다른 VPC나 네트워크, 혹은 기업 네트워크와 겹치지 않도록 주의해야한다.

State of Hands on

VPC - Subnet(IPv4)

VPC 내부에 있는 IPv4 나 주소의 부분 범위 이다.
각 서브넷 마다 5개의 주소를 예약해서 /27 이라면 32-5=27 개의 주소를 사용할수있는것.

Adding Subnets

Internet Gateway(IGW)

subnet 에 인터넷 엑세스를 연결하는 방법이다.
VPC의 resource를 인터넷에 연결하도록 허용하는 resource 이다.

Adding Internet Gateway

Editing Route Tables

Bastion Hosts

배스천 호스트는 프라이빗 EC2 인스턴스에 SSH로 액세스하기 위해 사용할 수 있다.
BastionHost는 Public 에 있고 BastionHost 보안 그룹이라는 자체 보안 그룹이 있다.

NAT Instance

NAT = Network Address Translation 네트워크 주소 변환
NAT 인스턴스는 프라이빗 서브넷에 있는 EC2 인스턴스가 인터넷에 연결되도록 하용한다.
퍼블릭 서브넷에서 실행되어야 하고, 퍼블릭 및 프라이빗 서브넷을 연결한다.
EC2 설정에서 소스/목적지(source/destination) 확인을 해야 한다.
Elastic IP가 연결되어야 한다.
라우팅 테이블을 수정하여 프라이빗 서브넷에서 NAT 인스턴스로 트래픽을 라우팅하도록 구성되어야 한다.

퍼블릭 서브넷에 NAT 인스턴스를 생성하고
라우팅 테이블을 통해 프라이빗 인스턴스가 NAT 인스턴스에서 인터넷 Gateway까지 통신하도록 한다.

NAT Gateway

AWS의 관리형 NAT 인스턴스, 높은 대역폭과 고가용성을 제공하며 관리할 필요가 없음
사용량 및 NAT Gateway의 대역폭에 따라 비용 지불
NAT Gateway는 특정 가용 영역에서 생성되고 탄력적 IP를 이어 받음
동일 서브넷의 EC2 인스턴스에서는 사용할 수 없으며 다른 서브넷에서 액세스할 때만 NAT Gateway가 도움됨
NAT Gateway는 인터넷 Gateway가 필요함 (프라이빗 서브넷 → NAT Gateway → 인터넷 Gateway)
초당 5 Gbps의 대역폭을 제공하며 최대 45 Gbps까지 자동으로 확장 가능
보안 그룹을 관리할 필요가 없음
연결을 하기 위해 어떤 포트를 활성화할지 생각할 필요가 없음

프라이빗 인스턴스와 서브넷이 있고, 인터넷에 액세스할 수 없었다.
따라서 NAT Gateway를 퍼블릭 서브넷에 배포한다.

NAT Gateway with High Availability

NAT Gateway vs NAT Instance

Network Access Control List(NACL)

subnet을 오가는 traffic 을 제어하는 방화벽과 비슷하다.

Default NACL

연결된 subnet을 가지고 In/Out 의 모든 요청을 허용한다.

기본 NACL 을 수정하는것이 아닌 사용자 정의 NACL 을 생성해야한다.

Ephemeral Ports

Client/Server 연결되면 port 사용해야한다.

클라이언트는 규정된 포트의 서버에 연결하고 휘발성 포트에서 응답을 기대한다.
클라이언트가 서버에서 회신을 받기 위해서는 서버에서도 클라이언트에 연결해야 하지만, 클라이언트는 기본적으로 개방된 포트가 없어서 클라이언트가 서버에 접속할 때 자체적으로 특정한 포트를 열게 된다.
이 포트는 임시라서 클라이언트와 서버간 연결이 유지되는 동안에만 열려있다.

NACL with Ephemeral Ports

Create NACL rules for each target subnets CIDR

Security Group vs NACLs

VPC peering

다양한 리전,계정에서 VPC 생성 가능하다.
하지만 AWS Network 를 통해 연결하고 싶을때 사용한다.
VPC 가 모두 같은 network 에서 작동하도록 만들기 위해.

다른 AWS 계정/리전에 있는 VPC 간에 VPC 피어링 연결을 생성할 수 있다.
피어링된 VPC에서 보안 그룹을 참조할 수 있다. (동일 리전의 계정 간 VPC에서도 보안 그룹 참조 가능)

VPC Endpoints

WS에서 DynamoDB와 같은 서비스를 이용한다고 하면 퍼블릭 액세스가 가능하다.
이것은 NAT Gateway나 인터넷 Gateway를 통해 DynamoDB에 액세스할 수 있다는 것이다.
이 모든 트래픽은 퍼블릭 인터넷을 거쳐서 온다.
CloudWatch나 Amazon S3 등의 서비스를 이용할 때는 인터넷을 경유하지 않고 프라이빗 액세스를 원할 수도 있다.
이때 VPC 엔드포인트를 사용하면 퍼블릭 인터넷을 거치지 않고도 인스턴스에 액세스할 수 있다.
프라이빗 AWS 네트워크만 거쳐서 바로 해당 서비스에 액세스할 수 있음!

모든 AWS 서비스는 퍼블릭에 노출되어 있고 퍼블릭 URL을 가지고 있다.
VPC 엔드포인트 (AWS PrivateLink를 통해 구현)를 사용하면 퍼블릭 인터넷을 거치지 않고도 프라이빗 네트워크를 사용하여 AWS 서비스에 연결할 수 있다.
이들은 중복성을 가지며 수평으로 확장된다.
인터넷 Gateway나 NAT Gateway 없이도 AWS 서비스에 액세스할 수 있게 해준다.
문제가 발생하는 경우:
VPD의 DNS 설정 해석 (DNS Setting Resolution)을 확인
라우팅 테이블 확인

Types of Endpoints

인터페이스 엔드포인트 (Interface Endpoints - PrivateLink를 통해 구현)
ENI (VPC의 프라이빗 엔드포인트)를 AWS의 엔트리 포인트로 프로비저닝함 (반드시 보안 그룹을 연결해야 함)
대부분의 AWS 서비스를 지원함
시간당 + 처리된 데이터의 GB당 비용이 발생
Gateway 엔드포인트
게이트웨이를 프로비저닝하며 이 게이트웨이는 반드시 라우팅 테이블의 대상이 되어야 한다. (보안 그룹을 사용하지 않음)
게이트웨이 엔드포인트 대상으로는 S3 및 DynamoDB가 있음
무료

Gateway or Interface Endpoint for S3?

VPC Flow Logs

인터페이스로 들어오는 IP 트래픽에서 정보 포착 기능이다.

흐름 로그는 연결 문제를 모니터링하고 트러블 슈팅하는데 유용하다.
흐름 로그 데이터는 S3, CloudWatch Logs로 전송할 수 있다.

srcaddr & dstaddr: 문제가 있는 IP를 식별
srcport & dstport: 문자게 있는 포트를 식별
action: 보안 그룹 또는 NACL 계층에서 요청이 성공했는지 실패했는지 알려줌
사용 패턴 분석이나 악성 행동 감지 포트 스캔 등에 사용될 수 있음
VPC 흐름 로그를 S3 또는 CloudWatch Logs Insights를 사용하여 쿼리할 수 있다.

Troubleshoot SG & NACL issues

Incoming Request

NACL은 stateless, 보안 그룹은 stateful이라는 점에 주목할 것
인바운드 REJECT: NACL이나 보안 그룹 중 하나가 요청을 거부하고 있다는 것
인바운드 ACCEPT, 아웃바운드 REJECT: NACL 문제
Outgoing Request

아웃바운드 REJECT: NACL이나 보안 그룹 문제
아웃바운드 ACCEPT, 인바운드 REJECT: NACL 문제

Architectures

CloudWatch Logs로 전송된 흐름 로그
CloudWatch Contributor Insights라는 기능을 사용하여 상위 10위에 해당하는 VPC 네트워크에 가장 많이 기여하는 IP 주소 식별 가능
SSH, RDP 프로토콜에 관하여 지표 필터를 설정하고, 평소보다 SSH나 RDP 프로토콜이 너무 많은 경우 경보를 트리거하여 SNS 주제로 경보를 전송할 수 있음
S3 버킷에 전송된 흐름 로그
Athena를 이용하여 SQL로 VPC 흐름로그 분석 가능
QuickSight를 이용하면 시각화 가능

AWS Site to Site VPN

VPC는 구축했으나 특정 구조가 있는 기업 데이터 센터를 AWS와 비공개로 연결하려면 기업은 고객 게이트웨이를, VPC는 VPN 게이트웨이를 갖춰야 한다.
퍼블릭 인터넷을 통해 프라이빗 Site-to-Site VPN을 연결해야 한다.
퍼블릿 인터넷을 거치긴 하지만 VPN 연결이기 때문에 암호화되어 있다.

가상 프라이빗 게이트웨이 (Virtual Private Gateway, VGW)
VPN 연결에서 AWS 측에 있는 VPN 접선기 (concentrator)
VWG는 Site-to-Site VPN 연결을 생성하려는 VPC에 연결되고 생성된다.
ASN (Autonomous System Number, 자율 시스템 번호)를 지정할 수 있다.
고객 게이트웨이 (Customer Gateway, CGW)
VPN 연결의 고객 측에 위치한 소프트웨어 또는 물리적 장치

Site to Site VPN Connections

고객 게이트웨이 장치 (온프레미스) - 어떤 IP 주소를 사용해야 할까?
고객 게이트웨이가 공용이라면, 인터넷 라우팅이 가능한 IP 주소를 사용해야 한다.
NAT 탐색(NAT-T)이 활성화된 NAT 장치 뒤에 있는 경우, NAT 장치의 퍼블릭 IP 주소를 사용
Important step: 서브넷과 연관된 라우팅 테이블에서 가상 프라이빗 게이트웨이의 라우트 전파 (Route Propagation)를 활성화해야 한다.
온프레미스에서 EC2 인스턴스에 핑을 보내려면 보안 그룹의 인바운드에 ICMP 프로토콜을 추가해야 합니다.

AWS VPN CloudHub

CloudHub는 여러 VPN 연결을 통해 모든 사이트 간의 안전한 통신을 보장하고, 여러 VPN 연결이 있는 경우에 적합하다.
다양한 위치 간의 주요 또는 보조 네트워크 연결을 위한 저비용 허브 앤 스포크(hub-and-spoke) 모델을 제공한다. (VPN only)
VPN 연결이므로 모든 트래픽이 공용 인터넷을 통해 이루어진다.
CloudHub를 설정하기 위해 동일한 가상 프라이빗 게이트웨이(VGW) 하나에 여러 Site-to-Site VPN 연결을 여러 개 만들고, 동적 라우팅을 설정하고, 라우트 테이블을 구성하면 된다.

Direct Connect(DX)

VPC 로의 전용 Private 연결을 제공한다.

원격 네트워크와 VPC간의 전용 프라이빗 연결을 제공한다.
Direct Connect를 사용할 때는 전용 연결을 생성해야 하고, AWS Direct Connect 로케이션을 사용한다.
VPC에 가상 프라이빗 게이트웨이(VPW)를 설정해야 함
AWS Direct Connect를 사용하면 동일한 연결을 통해 퍼블릭 리소스(ex. S3)와 프라이빗 리소스(ex. EC2)에 접근 가능
사용 사례:
대역폭 처리량이 증가할 때 (대용량 데이터 세트 작업 시) 비용 절감 가능
퍼블릭 인터넷을 거치지 않기 떄문
실시간 데이터 피드를 사용하는 애플리케이션에서 더 일관된 네트워크를 경험할 수 있게 함
하이브리드 환경 지원 (온프레미스 + 클라우드)
IPv4와 IPv6 모두 지원

Direct Connect Gateway는 하나 이상의 VPC를 여러 다른 리전에 설정하려는 경우 (동일한 계정 내에서) Direct Connect 연결을 사용해야할 때 사용된다.

Connection Types

Dedicated Connections: 초당 1Gbps, 10 Gbps 혹은 100 Gbps 의 전용 연결 용량
고객은 물리적 전용 이더넷 포트를 할당받음
요청은 먼저 AWS에 보내지며, 그후 AWS Direct Connect 파트너가 처리를 완료함
Hosted Connections: 초당 50Mbps, 500 Mbps에서 10 Gbps까지
연결 요청은 AWS Direct Connect 파트너를 통해 이루어짐
용량은 필요에 따라 추가하거나 제거할 수 있음
일부 AWS Direct Connect 파트너에서는 1, 2, 5, 10 Gbps 용량이 제공
새로운 연결을 설정하는 데에는 1개월 이상이 걸린다.
예를 들어 일주일 안에 빠르게 데이터를 전송하고 싶을 때에는 Direct Connect는 답이 될 수 없다.

Encryption

전송중인 데이터는 암호화되지 않지만 프라이빗 연결이므로 보안을 유지할 수 있다.
AWS Direct Connect와 VPN을 함께 설치해서 IPsec으로 암호화된 프라이빗 연결이 가능하다.
보안 수준을 높이기 위한 좋은 방법이지만 구현이 복잡하다는 단점이 있다.

Resiliency

핵심 워크로드의 복원력 높이기 - 여러 Direct Connect를 설치하는 것이 좋음

햇김 워크로드 복원력을 최대로 끌어올리기 - 각 Direct Connect 로케이션에 독립적인 연결을 두 개씩 수립하면 복원력을 최대로 만들 수 있음

Site to Site VPN connection as a backup

Direct Connect 연결에 문제가 발생했을 때 Direct Connect로 보조 연결을 할 수 있다. 하지만 이는 비용이 상당히 많이 든다.
Site-to-Site VPN을 백업 연결로 두어 기본 연결에 문제가 발생했을 때, S2S VPN을 통해 퍼블릭 인터넷에 연결할 수 있으므로 안정성이 높아진다. (퍼블릭 인터넷에 언제나 연결되어있을 것이기 때문)

Transit Gateway

일반적인 AWS 네트워크 토폴로지는 꽤 복잡하게 보인다.

예를 들어 VPC 여러 개를 피어링으로 전부 연결하고
VPN 연결과 Direct Connect를 구축해서
Direct Connect Gateway로 여러 VPC를 한 번에 연결하는 식이기 때문이다

수천 개의 VPC와 온프레미스 간에 전이적 연결을 제공하기 위한 허브 앤 스포크 (스타) 연결
리전별 자원으로 크로스 리전 작업 가능
Resource Access Manager (RAM)을 사용하면 계정 간 Transit Gateway 공유 가능
리전 간 Transit Gateway를 피어링할 수 있음
라우팅 테이블: VPC간의 통신 제한 가능
Direct Connect Gateway, VPN 연결과 함께 작동함
AWS에서 유일하게 IP 멀티캐스트를 지원함

Site to Site VPN ECMP

Site-to-Site VPN 연결 대역폭을 ECMP를 사용해 늘리는 경우 Transit Gateway를 사용할 수 있다.

ECMP = Equal-cost multi-path routing, 등가 다중 경로 라우팅

패킷을 여러 최적 경로로 전송하기 위한 라우팅 전략

여러 Site-to-Site VPN 연결을 생성하여 AWS와의 연결 대역폭을 증가시키는 사용 사례에 적합

throughput with ECMP

가상 프라이빗 게이트웨이에 VPN을 연결한 경우

VPC마다 터널 하나 (연결 하나) 씩 생김
연결 하나당 1.25 Gbps를 제공하며 최대 처리량으로 제한됨
이때 VPN 연결은 터널 두 개로 구성됨

Transit Gateway에 VPN을 연결한 경우

Site-to-Site VPN 하나가 여러 VPC에 생성됨
동일한 Transit Gateway에 모두 전이적으로 연결되기 때문
한 개의 Site-to-Site VPN 연결은 ECMP 덕에 최대 처리량이 2.5 Gbps가 됨 - 해당 전략을 통해 두 터널이 사용되기 때문
Transit Gateway에 Site-to-Site VPN 연결을 두세 개 정도 더 추가할 수 도 있다. - ECMP를 사용하면 처리량이 두세 배가 됨
데이터가 Transit Gateway를 통과할 때 1 GB마다 요금이 청구됨

Share Direct Connect between multiple accounts

Direct Connect 연결을 여러 계정에서 공유할 때도 Transit Gateway를 사용한다.
기업 데이터 센터와 Direct Connect 로케이션 간에 Direct Connect 연결을 생성한다.
Transit Gateway를 서로 다른 계정의 VPC 두 개 모두에 생성한다.
Direct Connect 로케이션에 연결한 Direct Connect Gateway를 Transit Gateway에 연결하면 여러 계정과 VPC 사이에 Direct Connect 연결을 공유할 수 있게 된다.

VPC - Traffic Mirroring

VPC 에서 네트워크 Traffic 수집,검사 방해하지 않는다.

What is Ipv6?

IPv4는 약 43억 개의 IP 주소를 제공하기 위해 설계되었으며, 이 주소들은 곧 소진될 예정
IPv6는 3.4 × 10^38 개의 고유한 IP 주소를 제공하기 위해 설계됨
모든 IPv6 주소는 공용이고 인터넷 라우팅이 가능함 (사설 범위가 없음)

IPv6 in VPC

VPC 및 서브넷에서 IPv4는 비활성화할 수 없다.
IPv6는 활성화할 수 있고 (퍼블릭 IP 주소이기 때문) 듀얼 스택 모드로 작동한다.
EC2 인스턴스가 VPC 내에서 실행되면 최소 사설 내부 IPv4 하나와 공용 IPv6 하나를 얻게 된다.
인스턴스는 인터넷 게이트웨이를 통해 IPv4 또는 IPv6를 사용하여 인터넷과 통신할 수 있다.

IPv6 Troubleshooting

VPC 및 서브넷에서는 IPv4를 비활성화할 수 없다.
만약 IPv6가 활성화된 VPC가 있는데 서브넷에서 EC2 인스턴스를 실행할 수 없는 경우
인스턴스가 IPv6를 받지 못해서가 아니라 (실제로는 공간이 아주 크고 EC2 인스턴스를 위한 IPv6도 충분하기 때문)
해당 서브넷에서 사용 가능한 IPv4 주소가 없기 때문이다.
Solution: 서브넷에서 새로운 IPv4 CIDR을 생성

Egress-only internet Gateway

송신 전용 인터넷 게이트웨이는 IPv6 트래픽에만 사용됨 (NAT Gateway와 비슷하지만 IPv6 전용임)
VPC 내의 인스턴스가 IPv6를 통해 아웃바운드 연결을 할 수 있게 하면서도 동시에 인터넷이 인스턴스로의 IPv6 연결을 시작하는 것을 방지한다.
라우팅 테이블을 업데이트해야 함

IPv6 Routing

VPC Section Summary

CIDR: IP 범위
VPC: 가상 사설 클라우드 → IPv4와 IPv6용으로 작동
서브넷: CIDR이 정의된 AZ에 연결되며 공용 및 사설 서브넷이 있음
인터넷 게이트웨이: VPC 수준에서 IPv4 및 IPv6 인터넷 액세스를 제공
라우팅 테이블: 서브넷에서 IGW, VPC Peering 연결, VPC 엔드포인트 등으로의 라우트를 갖도록 편집해야 함. 네트워크가 VPC 내부에서 흐르도록 돕는 중요한 기능
배스천 호스트 (Bastion Host): 사설 서브넷의 EC2 인스턴스와 SSH 연결을 제공하는 공개 EC2 인스턴스
NAT 인스턴스: 사설 서브넷의 EC2 인스턴스에 인터넷 액세스를 제공. Outdated. 퍼블릭 서브넷에 설정해야 하며, 소스/대상 확인 플래그를 비활성화해야 함.
NAT 게이트웨이: AWS에서 관리되며, 사설 EC2 인스턴스에 확장 가능한 인터넷 액세스를 제공 - IPv4에서만 작동
프라이빗 DNS + Route 53: DNS Resolution 및 DNS 호스트 이름 설정을 VPC에서 활성화해야 함
NACL: stateless, 인바운드 및 아웃바운드 액세스를 서브넷 레벨에서 정의, stateless이기 때문에 인바운다와 아웃바운드 규칙이 항상 평가됨, 휘발성 포트 기억하기
보안 그룹: stateful - 인바운드 허용시 아웃바운드도 허용 (vice versa), EC2 인스턴스 레벨에서 적용
Reachability Analyzer: AWS 리소스 간의 네트워크 연결성 테스트를 수행
VPC 피어링: CIDR이 겹치지 않는 두 개의 VPC를 연결, 비전이적 (Not transitive)
VPC 엔드포인트: VPC 내에서 AWS 서비스(S3, DynamoDB, CloudFormation, SSM 등)에 대한 사설 액세스 제공, Amazon S3와 DynamoDB는 게이트웨이 엔드포인트, 나머지는 모두 인터페이스 엔드포인트
VPC 흐름 로그 (VPC Flow Logs): VPC / 서브넷 / ENI 레벨에서 생성 가능, ACCEPT 및 REJECT 트래픽을 기록하여 공격을 식별하는 데 도움, Athena 또는 CloudWatch Logs Insights를 사용하여 분석 가능
Site-to-Site VPN: (VPC를 데이터 센터에 연결하는 첫 번째 옵션) 공용 인터넷을 지나는 VPN 연결 - 데이터 센터에 고객 게이트웨이, VPC에 가상 사설 게이트웨이를 생성하고 VPN 연결 구축
AWS VPN CloudHub: 가상 프라이빗 게이트웨이를 사용해 VPC 연결을 여러 개 생성하려면 CloudHub를 활용하여 허브-앤-스포크 VPN 모델로 사이트에 연결
Direct Connect: (VPC를 데이터센터에 연결하는 또다른 옵션 - 완전 비공개로 연결함) 공용 인터넷을 통과하지 않고 구축하는데 시간이 걸림, 데이터 센터를 Direct Connect 로케이션과 연결해야 작동함
Direct Connect Gateway: 다양한 AWS 리전의 수많은 VPC에 Direct Connect를 설정함
AWS PrivateLink / VPC Endpoint Services:
고객 VPC에 만든 자체 VPC 내부 서비스에 비공개로 연결
VPC Peering, 공용 인터넷, NAT Gateway, 라우트 테이블이 필요하지 않음
Network Load Balancer 및 ENI와 함께 사용
VPC가 있는 서비스를 수백, 수천 고객 VPC에 네트워크를 드러내지 않은 채 노출할 수 있음
Transit Gateway: VPC, VPN 및 DX를 위한 전이적 피어링 연결
Traffic Mirroring: ENI의 네트워크 트래픽을 복사하여 추가 분석을 위해 사용
송신 전용 인터넷 게이트웨이 (Egress-only Internet Gateway): IPv6를 위한 NAT Gateway와 유사한 기능

Network Protection on AWS

AWS에서 네트워크를 보호하기 위해 다음과 같은 기능을 사용할 수 있다.

네트워크 액세스 제어 목록 (NACL)
Amazon VPC 보안 그룹
AWS WAF (악성 요청으로부터 보호)
AWS Shield 및 AWS Shield Advanced
AWS Firewall Manager (다중 계정에서 관리)

AWS Network Firewall

정교하게 보호하기 위함. VPC 를

전체 VPC를 방화벽으로 보호하는 서비스
계층 3에서 계층 7까지 보호
모든 방향에서 들어오는 트래픽 검사
VPC 간 트래픽
인터넷으로의 아웃바운드
인터넷으로부터의 인바운드
Direct Connect 및 Site-to-Site VPN 연결
내부적으로 Network Firewall은 AWS Gateway Load Balancer를 사용
AWS에서 자체 어플라이언스를 통해 트래픽을 관리하므로 Network Firewall에 자체 규칙을 갖추고 있음
AWS Firewall Manager를 통해 중앙에서 관리되는 규칙은 여러 VPC에 적용될 수 있음

Fine Grained Controls

VPC 수준에서 수천 개의 규칙 지원
IP & 포트: ex. 수만 개의 IP 필터링
프로토콜: ex. 아웃바운드 통신에서는 SMB 프로토콜 차단
상태 기반 도메인 목록 규칙 그룹: ex. *.mycorp.com 또는 타사 소프트웨어 저장소로의 아웃바운드 트래픽만 허용
정규식을 사용한 일반 패턴 매칭
트래픽 필터링: 설정한 규칙과 일치하는 트래픽의 허용, 차단, 경고 등 설정
침입 방지 기능을 갖춘 네트워크 위협에 대한 활성 플로우 검사 (게이트웨이 로드 밸런서와 유사, AWS에서 모두 관리)
규칙 일치 로그를 Amazon S3, CloudWatch Logs, Kinesis Data Firehose로 전송하여 분석 가능