Networking - VPC

Understanding CIDR - IPv4

CIDR(Classless Inter-Domain Routing) - IP 주소 할당 방법
Security Groups Rule과 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 (64개의 IP 주소)
CIDR은 두 부분으로 나뉨
- Base IP
  - 범위에 포함될 IP (XX.XX.XX.XX)
  - ex. 10.0.0.0, 192.168.0.0, ...
- Subnet Mask
  - IP 내에서 얼마나 많은 bit가 바뀔 수 있는지를 정의
  - ex. /0, /24, /32
  - 두 가지 형태가 될 수 있음
    - /8 <-> 255.0.0.0
    - /16 <-> `255.255.0.0
    - /24 <-> 255.255.255.0
    - /32 <-> 255.255.255.255
Subnet Mask는 기본적으로 기본 IP로부터 얼마나 추가적인 값들을 허용할지 나타내는 부분이다.
- 예시
  - 192.168.0.0/32 => 1개의 IP 허용 (2^0) => 192.168.0.0
  - 192.168.0.0/31 => 2개의 IP 허용 (2^1) => 192.168.0.0 ~ 192.168.0.1
  - 192.168.0.0/24 => 256개의 IP 허용 (2^8) => 192.168.0.0 ~ 192.168.0.255
  - 0.0.0.0/0 => 모든 IP 허용 (2^32) => 0.0.0.0 ~ 255.255.255.255
주로 사용되는 경우
- /32 - 어떤 octet도 바뀔 수 없음
- /24 - 마지막 octet이 바뀔 수 있음
- /16 - 뒤의 두 octet이 바뀔 수 있음
- /8 - 뒤의 세 octet이 바뀔 수 있음
- /0 - 모든 octet이 바뀔 수 있음

Octet Example

헷갈린다면 CIDR를 IP 주소 범위로 변환해주는 사이트도 있으니 참고

Public vs. Private IP (IPv4)

IANA(Internet Assigned Numbers Authority)가 public / private 주소 사용을 위해 특정 IPv4 주소 블록을 설정해뒀음
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의 범위
- 192.168.0.0 ~ 192.168.255.255 (192.168.0.0/16) -> ex. 홈 네트워크
인터넷 상에서 그 외의 나머지 IP 주소들은 모두 Public IP

Default VPC Walkthrough

모든 새 AWS 계정들은 기본 VPC를 가짐
새로운 EC2 인스턴스들은 별도로 서브넷을 지정하지 않는다면 기본 VPC로 실행됨
기본 VPC는 인터넷 연결이 되어있고, 그 안의 모든 EC2 인스턴스들은 public IPv4 주소를 갖게 됨
public/private IPv4 DNS 네임을 가질 수 있음

VPC in AWS - IPv4

VPC - Virtual Private Cloud
하나의 AWS 리전 내에 여러 VPC들을 둘 수 있음 (리전 별 최대 5개 ~ soft limit)
VPC 별 CIDR은 최대 5개이며, 각 CIDR의 경우:
- 최소 사이즈 /28 (16개의 IP 주소)
- 최대 사이즈 /16 (65536개의 IP 주소)
VPC는 private이기 때문에, 오직 Private 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은 내 다른 네트워크와 겹쳐선 안됨 (ex. 회사의 IP 주소)

VPC - Subnet (IPv4)

AWS 리소스들은 각 서브넷 별로 **5개의 IP 주소 (first 4 & last 1)**를 예약해둠
이 5개의 IP 주소는 사용할 수 없고, EC2 인스턴스에 할당될 수도 없음
예시: 만약 CIDR 블록이 10.0.0.0/24라면, 예약되는 IP 주소들은 다음과 같음
- 10.0.0.0 - Network Address
- 10.0.0.1 - AWS에 의해 예약, VPC 라우터 용도
- 10.0.0.2 - AWS에 의해 예약, Amazon에서 제공하는 DNS에 매핑
- 10.0.0.3 - AWS에 의해 예약, 추후 사용 용도
- 10.0.0.255 - Network Broadcast Address로, AWS에서는 VPC에서 broadcast를 지원하지 않기 때문에, 예약되어 있음
시험 팁: 만약 EC2 인스턴스에 29개의 IP 주소가 필요하다면?
- /27 사이즈의 서브넷을 둘 수 없음 (32개 IP 주소 ~ 32 - 5 = 27 < 29)
- /26 사이즈의 서브넷을 골라야 함 (64개 IP 주소 ~ 64 - 5 = 59 > 29)

Internet Gateway (IGW)

VPC 내에 있는 리소스(e.g., EC2 인스턴스)들의 인터넷 연결을 허용
수평적 확장 & highly available & 중복(redundant)
반드시 VPC와는 별도로 생성되어야 함
하나의 VPC는 오직 하나의 IGW에 연결될 수 있으며, 반대의 경우도 마찬가지
Internet Gateway 그 자체만으로는 인터넷 액세스를 허용하지 않음
- 반드시 Route table도 함께 수정되어야 함!

Internet Gateway Example

Bastion Hosts

private EC2 인스턴스에 SSH 연결을 사용하고 싶을 때 Bastion Host를 사용할 수 있음
bastion은 다른 private 서브넷들에 연결되어 있는 public 서브넷
Bastion Host security group은 반드시 제한된 CIDR의 22번 포트로부터 인바운드만 허용해야 함
- ex. 회사의 public CIDR
EC2 인스턴스의 Security Group은 반드시 Bastion Host의 Security Group을 허용하거나, Bastion host의 private IP를 허용해야 함

Bastion Host

NAT Instance (outdated, but still at the exam)

NAT = Network Address Translation
private 서브넷 내의 EC2 인스턴스들이 인터넷에 연결될 수 있도록 해줌
반드시 public 서브넷 내에서 실행되어야 함
다음 EC2 설정을 반드시 비활성화 해야함: Source / destination Check
연결할 Elastic IP가 반드시 필요함
private 서브넷으로부터의 트래픽을 NAT 인스턴스로 라우팅하도록 Route Table이 반드시 설정되어야 함

NAT Instance Example

NAT Instance - Comments

사전에 설정되어 있는(pre-configured) Amazon Linux AMI를 사용할 수 있음
- 공식 지원은 2020/12/31에 끝났음
기본적으로는 Highly Available 및 resilient setup이 제공되지 않음
- multi-AZ에 ASG를 만들고, resilient user-data script를 생성할 필요가 있음
인터넷 트래픽 대역폭(bandwidth)는 EC2 인스턴스 유형에 따라 다름
반드시 Security group & Rule을 관리해야함:
- 인바운드:
  - private 서브넷으로부터 오는 HTTP/HTTPS 트래픽을 허용
  - 홈 네트워크로부터의 SSH 연결(Internet Gateway를 통한 액세스)을 허용
- 아웃바운드:
  - 인터넷으로의 HTTP/HTTPS 트래픽을 허용

NAT Gateway

AWS가 관리하는 NAT, 높은 대역폭, high availability, 관리 불필요
사용한 시간과 대역폭에 따라 비용 지불
NAT Gateway는 특정 AZ에 생성되며, Elastic IP를 사용
동일한 서브넷 내 EC2 인스턴스에서 사용될 수는 없음 (다른 서브넷을 통해서만 가능)
IGW(Internet Gateway)가 필요함 (Private Subnet => NATGW => IGW)
5Gbps의 대역폭, 최대 45Gbps로 스케일 업
따로 Security Group을 관리해야 하거나 필요하지 않음

NAT Gateway with High Availability

NAT Gateway는 단일 AZ 내에서 resilient함
내결함성(fault-tolerance)를 위해서는 반드시 여러 AZ 내에 여러 NAT Gateway들을 생성해야함
cross-AZ failover가 필요 없음 -> AZ가 다운되면 NAT가 필요하지 않기 때문

NAT Gateway vs. NAT Instance

참고

Network Access Control List (NACL)

NACL은 서브넷 안팎으로 오가는 트래픽을 관리하는 일종의 방화벽
서브넷 별로 하나의 NACL이 있고, 새로운 서브넷에는 Default NACL이 할당됨
NACL Rules를 정의:
- Rule에는 번호가 지정(1~32766), 낮은 번호일 수록 더 높은 우선순위
- 첫번째로 일치하는 규칙을 기반으로 결정을 내림
- ex. 만약 #100번 규칙으로 10.0.0.10/32를 허용했다면, #200번 규칙으로 10.0.0.10/32에 대해 거부했다면, 해당 IP 주소에 대해서는 허용될 것임
- 마지막 Rule은 아스터리스크(*)이며, 아무런 규칙도 매칭되지 않을 경우 요청을 거부
- AWS에서는 100 단위로 규칙을 추가할 것을 추천함
새로 생성된 NACL의 경우 모든 경우에 대해 거부
NACL은 서브넷 레벨에서 특정 IP 주소를 블록하기에 아주 좋은 방법

Default NACL

할당된 서브넷에 대한 모든 인바운드/아웃바운드를 허용함
Default NACL을 수정하지 말 것, 대신에 커스텀 NACL을 새로 생성해야함

Ephemeral Ports (임시 포트)

두 엔드포인트 간에 연결이 이루어지려면, 반드시 포트를 사용해야 함
클라이언트가 defined port(= fixed port)로 연결하고, ephemeral port(임시 포트)에서 응답을 내보냄
운영체제가 다르다면, 포트의 범위도 다르게 사용함
- 예시
  - IANA & MS Windows 10 -> 49152 ~ 65535
  - Many Linux Kernels -. 32768 ~ 60999

NACL with Ephemeral Ports

참고

Securiy Group vs. NACLs

NACL vs SG

VPC Peering

AWS 네트워크를 통해 두 VPC 간에 private하게 연결을 할 수 있게 해줌
마치 두 VPC가 동일한 네트워크에 있는 것처럼 동작하게 만듬
중복되는 CIDR을 가져선 안됨
VPC Peering 연결은 transitive(전이적)하지 않음 (반드시 VPC 간에 서로 직접 연결되어야 함)
EC2 인스턴스들이 서로 상호작용할 수 있도록 하려면 각각의 VPC 서브넷 안에 있는 Route Table을 업데이트 해야만 함

VPC Peering

VPC Peering - Goot to know

서로 다른 AWS 계정/리전 내에서도 VPC 간에 VPC Peering 연결을 생성할 수 있음
피어링된 VPC 내에서는 Security Group을 서로 참조할 수 있음 (동일한 리전 내 cross account 가능)

VPC Endpoints (AWS PrivateLink)

모든 AWS 서비스는 공개적으로 노출 (public URL)
VPC Endpoints (powered by AWS PrivateLink)는 public 인터넷 대신 private network를 사용하여 AWS 서비스들을 연결할 수 있도록 해줌
redundant, 수평적 확장
AWS 서비스들에 액세스 하기 위해 IGW, NATGW 같은 것들을 사용할 필요가 없어짐
문제가 발생했을 경우:
- VPC에서 DNS 설정을 확인
- Route Table을 확인

VPC Endpoints

Types of Endpoints

Interface Endpoints (powered by PrivateLink)
- ENI(private IP 주소)를 엔트리 포인트(반드시 Security Group 연결 필요)로 프로비저닝
- 대부분의 AWS 서비스들을 지원
- 시간 당 비용 + 처리되는 데이터 GB당 비용
Gateway Endpoints
- 게이트웨이를 프로비저닝하며, 반드시 이를 Route Table 내에서 타겟으로 사용해야 함 (Security Group 사용이 필요 없음)
- S3와 DynamoDB를 지원
- 무료

Gateway or Interface Endpoint for S3?

Gateway가 거의 대부분의 경우 더 선호됨
비용 측면: Gateway Interface는 무료인 반면 Interface Endpoint는 비용 필요
Interface Endpoint는 온-프레미스 혹은 다른 VPC/리전으로부터의 액세스가 필요한 경우에 선호됨

VPC Flow Logs

내 인터페이스로 이동하는 IP 트래픽들에 대한 정보를 캡처:
- VPC Flow Logs
- Subnet Flow Logs
- Elastic Network Interface (ENI) Flow Logs
모니터링 & 연결 이슈에 대한 트러블슈팅에 도움
Flow Logs 데이터는 S3, CloudWatch Logs, Kinesis Data Firehose로 보낼 수 있음
AWS에서 관리되는 인터페이스로부터의 네트워크 정보도 캡처:
- ELB, RDS, ElastiCache, Redshift, WorkSpaces, NATGW, Transit Gateway..

VPC Flow Logs Syntax

srcaddr & dstaddr - 문제가 있는 IP를 파악하는 데에 도움
srcport & dstport - 문제가 있는 포트를 파악하는 데에 도움
Action - Security Group / NACL에 따른 요청 성공/실패 여부
사용 패턴 / 악의적 행동에 대한 분석을 위해 사용할 수 있음
S3의 Athena 또는 CloudWatch Log Insights를 통해 VPC Flow Log를 쿼리할 수 있음
Flow Log 예시

VPC Flow Logs - Troubleshoot SG & NACL Issues

ACTION 필드를 확인하자!
- Incoming Request의 경우
  - 인바운드 REJECT => NACL 또는 SG
  - 인바운드 ACCEPT, 아웃바운드 REJECT => NACL
- Outgoing Requests의 경우
  - 아웃바운드 REJECT => NACL 또는 SG
  - 아웃바운드 ACCEPT, 인바운드 REJECT => NACL

VPC Flow Logs - Architectures

VPC Flow Logs -> CloudWatch Logs -> CloudWatch Contributor Insights
VPC Flow Logs -> CloudWatch Logs -> CloudWatch Alarm -> Amazon SNS
VPC Flow Logs -> S3 Bucket -> Amazon Athena -> Amazon QuickSight

AWS Site-to-Site VPN

Virtual Private Gateway (VGW)
- VPN 연결 시 AWS 측의 VPN concentrator
- VGW를 생성 후 Site-to-Site VPN 연결을 생성하고 싶은 VPC에 연결
- ASN(Autonomous System Number)를 커스터마이징 할 수 있음
Customer Gateway (CGW)
- VPN 연결의 customer 측 소프트웨어 애플리케이션 또는 실제 디바이스

Site-to-Site VPN Connections

Customer Gateway Devices (On-Premises)
- 어떤 IP 주소를 사용하는가?
  - Customer Gateway 디바이스에 대한 Public Internet-routable IP 주소를 사용
  - 만약 NAT traversal(NAT-T)가 활성화된 NAT 디바이스라면, NAT 디바이스의 public IP 주소를 사용
중요한 과정: 내 서브넷과 연결된 Route Table 내 Virtual Private Gateway에 대한 Route Propagation을 활성화해야 함
온-프레미스로부터 EC2 인스턴스를 ping해야 한다면, Security Group의 인바운드로 ICMP 프로토콜을 추가하였는지 확인해야 함

Site-to-Site VPN Connection

AWS VPN CloudHub

여러 VPN 연결을 보유한 경우, 여러 사이트 간의 보안 연결을 제공
다른 로케이션 간의 주요 또는 보조 네트워크 연결을 위한 저비용 hub-and-spoke 모델 (VPN Only)
VPN 연결이므로, public 인터넷을 통해 연결됨
설정하려면 동일한 VGW에 여러 VPN을 연결하고, dynamic routing을 설정하고 Route Table을 구성

AWS VPN CloudHub

Direct Connect (DX)

원격 네트워크에서 내 VPC로 전용 private 연결을 할 수 있게 해줌
전용 연결은 반드시 내 Direct Connect와 AWS Direct Connection 로케이션 사이에 구성되어야 함
VPC에 Virtual Private Gateway를 설정해야 함
하나의 연결로 public 리소스(S3)와 private 리소스(EC2)에 액세스할 수 있음
사례:
- 대역폭 처리량 증가 - 거대한 데이터 셋을 다루는 경우 ~ 더 낮은 비용
- 보다 일관적인 네트워크 경험 - 실시간 데이터 피드를 사용하는 애플리케이션
- 하이브리드 환경 (온-프레미스 + 클라우드)
IPv4와 IPv6 모두 지원

Direct Connect Diagram

Direct Connect

Direct Connect Gateway

여러 리전(동일한 계정) 간에 하나 이상의 VPC로 Direct Connect를 설정하고자 한다면 반드시 Direct Connect Gateway를 사용해야 함

Direct Connect Gateway

Direct Connect - Connection Types

Dedicated Connections: 1Gbps, 10Gbps and 100Gbps 가용량
- customer 전용의 물리적 이더넷 포트
- AWS에 먼저 요청을 하고, 이후 AWS Direct Connect Partner로부터 완료됨
Hosted Connections: 50Mbps, 500Mbps, 최대 10Gbps
- AWS Direct Connect Partner를 통해 연결 요청이 이루어짐
- 가용량(capacity)이 on-demand로 추가/삭제될 수 있음
- AWS Direct Connect Partner 선택에 따라 1, 2, 5, 10Gbps
새로운 연결을 구축하는데는 주로 1달 이상 소요됨

Direct Connect - Encryption

데이터는 전송 중(in transit) 암호화 되지 않지만, private함
AWS Direct Connect + VPN은 IPsec-encrypted된 private 연결을 제공함
더 추가적인 보안을 챙길 수 있으나, 구축에 있어 좀 더 복잡함

AWS Direct Connect + VPN

Direct Connect - Resiliency

주요 워크로드에 대한 High Resiliency
- 여러 location들에 대해 하나로 연결

Direct Connect One connection at multi location

주요 워크로드에 대한 Maximum Resiliency
- 하나 이상의 location 내 별도의 장치에서 종료되는 연결들을 분리함으로써 Maximum resilience를 지킬 수 있음

Direct Connect Maximum Resiliency for Critical Workloads

Site-to-Site VPN connection as a backup

Direct Connect가 실패할 경우를 대비하고자 하는 경우
- 백업 Direct Connect 연결을 구축하거나 (비쌈)
- Site-to-Site VPN 연결을 구축할 수 있음

Transit Gateway

수천 개의 VPC와 온-프레미스 사이에 transitive(전이적) peering을 구축함으로써 hub-and-spoke(star) 연결을 만듬
리전 별 리소스, cross-region으로 동작할 수 있음
RAM(Resource Access Manager)를 통해 계정 간에 공유 가능
리전 간에 Transit Gateway들을 피어링할 수 있음
Route Tables: 다른 VPC와 소통할 수 있는 VPC들을 제한할 수 있음
Direct Connect 게이트웨이 및 VPC 연결과 호환 가능
IP Multicast 지원 (다른 어떤 AWS 서비스에서도 지원하지 않음)

Transit Gateway

Transit Gateway - Site-to-Site VPN ECMP

**ECMP = Equal-Cost Multiple-Path routing
여러 최적의 경로를 통해 패킷을 넘기도록 하는 라우팅 전략
사례: AWS로의 연결 대역폭을 상승시키기 위해 여러 개의 Site-to-Site VPN 연결을 구축

Site-to-Site VPN ECMP

Transit Gateway - throughput with ECMP

VPN to Virtual Private Gateway
- 하나의 터널로 하나의 VPC에 연결
- 하나의 터널 -> 1.25Gbps
VPN to Transit Gateway
- 하나의 site-to-site VPN 연결로 여러 개의 VPC에 연결
- 하나의 site-to-site VPN 연결은 2.5Gbps (ECMP ~ 해당 전략에 두개의 터널이 사용됨)
  - 더 많은 site-to-site VPN 연결을 추가할수록 처리량이 증가
    - 2개 ~ 5.0Gbps (ECMP)
    - 3개 ~ 7.5Gbps (ECMP)
- Transit Gateway를 통해 처리되는 데이터 GB 당 비용 지불

Share Direct Connect between multiple accounts

VPC - Traffic Mirroring

내 VPC 내에서의 네트워크 트래픽을 캡처 및 검사하도록 해줌
내가 관리하는 보안 appliance로 트래픽을 라우팅
트래픽 캡처
- From (Source) - 여러 ENI
- To (Targets) - 하나의 ENI 또는 하나의 NLB
모든 패킷을 캡처 또는 내가 관심있는 패킷만 캡처 (선택적으로 패킷 잘라내기 가능 ~ truncate)
Source와 Target은 동일한 VPC에 있을수도, 다른 VPC에 있을 수도 있음 (VPC Peering)
사례: 컨텐츠 검사, 위협 모니터링, 트러블슈팅...

VPC Traffic Mirroring

IPv6 for VPC

IPv4는 4.3 billon(43억)개의 주소를 제공 (곧 소진될 것)
IPv6는 IPv4의 후속
IPv6는 3.4 x 10^38 개의 고유 IP 주소를 제공
모든 IPv6 주소는 public이며, internet-routable함 (= private 범위가 없음)
형태 => x.x.x.x.x.x.x.x (x는 16진수, 범위는 0000 ~ ffff)
예시:
- 2001:db8:3333:4444:5555:6666:7777:8888
- 2001:db8:3333:4444:cccc:dddd:eeee:ffff
- :: => 모든 8 segments가 모두 0
- 2001:db8:: => 뒤의 6 segments가 모두 0
- ::1234:5678 => 첫 6 segments가 모두 0
- 2001:db8::1234:5678 => 가운데 4 segments가 모두 0

IPv6 in VPC

IPv4는 VPC와 서브넷에서 비활성화될 수는 없음
dual-stack 모드로 작동시키기 위해 IPv6를 활성화할 수는 있음 (모두 public IP 주소)
내 EC2 인스턴스들에서는 최소한 내부 private IPv4와 public IPv6를 갖게 됨
Internet Gateway으로 인터넷과 IPv4 또는 IPv6 양측을 통해 소통할 수 있게됨

IPv6 in VPC

IPv6 Troubleshooting

IPv4는 VPC와 서브넷에서 비활성화될 수는 없음
따라서, 내 서브넷에서 EC2 인스턴스를 실행할 수 없다면
- 이는 IPv6를 획득할 수 없기 때문이 아니라 (IPv6 공간은 매우 크기 때문)
- 서브넷 내에서 이용가능한 IPv4이 없기 때문임
해결책: 내 서브넷에서 새로운 IPv4 CIDR을 생성

Egress-only Internet Gateway

IPv6만을 사용하고 하고자 할 때 적용
NAT Gateway와 유사하나, IPv6 전용
내 VPC 안에 있는 인스턴스들이 IPv6로 아웃바운드 연결을 할 수 있도록 해줌
- 반면, 인터넷에서는 인스턴스에 IPv6 연결을 할 수 없도록 차단함
반드시 Route Table을 업데이트 해야함

IPv6 Routing

VPC Section Summary

CIDR - IP 범위
VPC - Virtual Private Cloud => IPv4 & IPv6 CIDR의 목록을 정의
Subnets - 하나의 AZ에 묶임, 하나의 CIDR을 정의
Internet Gateway - VPC 레벨에서 IPv4 & IPv6 인터넷 액세스를 제공
Route Tables - 서브넷에서 IGW, VPC Peering 연결, VPC Endpoint 등으로의 라우트를 추가하기 위해서는 반드시 수정
Bastion Host - private 서브넷 내의 EC2 인스턴스와도 SSH 연결을 수행하기 위해, SSH로 접속할 수 있는 public EC2 인스턴스
NAT Instances - private 서브넷 내의 EC2 인스턴스에 인터넷 액세스를 부여(구식), 반드시 public 서브넷 내에서 설정되어야 하며, Source/Destination 체크 옵션을 반드시 비활성화 해야함
NAT Gateway - private EC2 인스턴스에 scalable한 인터넷 액세스를 제공, AWS에 의해 관리되며, IPv4 전용
Private DNS + Route 53 - DNS Resolution + DNS Hostnames (VPC)를 활성화
NACL - stateless, 인바운드/아웃바운드 서브넷 룰, 임시 포트(Emphemeral Ports)
Security Groups - stateful, EC2 인스턴스 레벨에서 작업
Reachability Analyzer - AWS 리소스 간의 네트워크 연결성 테스트를 수행
VPC Peering - 중복되지 않는 CIDR을 갖는 두 VPC를 연결, 비전이적(non-transitive)
VPC Endpoints - VPC 내에서 AWS 서비스에 대한 private 액세스를 제공 (S3, DynamoDB, CloudFormation, SSM)
VPC Flow Logs - VPC / 서브넷 / ENI 레벨에서 설정될 수 있음, 트래픽의 ACCEPT/REJECT 여부 판단, Athena 또는 CloudWatch Log로 공격을 파악하거나 분석을 수행할 수 있음
Site-to-Site VPN - 데이터센터(DC)에 Customer Gateway, VPC에 Virtual Private Gateway, public 인터넷 간에 Site-to-Site VPN을 설정
AWS VPN CloudHub - 사이트에 연결하기 위한 hub-and-spoke VPN 모델
Direct Connect - VPC에 Virtual Private Gateway 설정, AWS Direct Connection Location에 direct private connection 구성
Direct Connect Gateway - 다른 AWS 리전들 내에 여러 VPC들에 대한 Direct Connect 설정
AWS PrivateLink / VPC Endpoint Services:
- 내 service VPC에서 customer VPC로 private하게 서비스를 연결
- VPC Peering, pulbic Internet, NAT Gateway, Route Table 같은 것이 필요 없음
- Network Load Balancer & ENI를 사용해야 함
ClassicLink - 내 VPC에 EC2와 Classic EC2 인스턴스를 private하게 연결
Transit Gateway - VPC, VPN & DX에 전이적인(transitive) peering 연결
Traffic Mirroring - 자세한 분석을 위해 ENI로부터의 네트워크 트래픽을 복사
Egress-only Internet Gateway - NAT Gateway와 유사하나, IPv6 전용

Networking Costs in AWS per GB - Simplified

비용 절약과 더 좋은 네트워크 성능을 위해서는 Public IP 보다 Private IP를 사용하라
최대의 비용 절약을 위해서는 동일한 AZ를 사용 (대신, High Availability와 트레이드 오프)

Network Costs in VPC

Minimizing egress traffic network cost

Egress traffic(송신 트래픽): 아웃바운드 트래픽 (AWS -> 외부)
Ingress traffic(유입 트래픽): 인바운드 트래픽 (외부 -> AWS, 일반적으로 무료)
비용 절감을 위해서는 가능한 많은 인터넷 트래픽을 AWS 내부에 유지시키는 편이 좋음

S3 Data Transfer Pricing - Analysis for USA

S3 Ingress: 무료
S3 to Internet: GB 당 $0.09 - * * S 3 T r an s f er A cce l er a t i o n * * : - 빠른전송시간 (50500 - 데이터전송에대한추가비용 - GB 당$ 0.04 ~ $0.08 추가 - * * S 3 t o Cl o u d F ro n t * * : GB 당$ 0.00
CloudFront to Internet: GB 당 $0.085 (S 3 보다약간쌈) - 캐싱가능 (낮은레이턴시) - S 3 요청과관련한비용을낮출수있음 (Cl o u d F ro n t 와함께쓰는경우 7 배정도쌈) - * * S 3 C ross R e g i o n R e pl i c a t i o n * * : GB 당$ 0.02

Pricing: NAT Gateway vs. Gateway VPC Endpoint

Gateway VPC Endpoint

NAT Gateway를 이용하여 Private subnet과 소통하는 것보다, VPC Endpoint를 두는 편이 비용이 훨씬 더 절감

Network Protection on AWS

AWS에서의 네트워크를 보호하기 위해 지금껏 아래와 같은 서비스가 있었음
- Network Access Control Lists (NACLs)
- Amazon VPC security groups
- AWS WAF (악성 요청을 보호)
- AWS Shield & AWS Shield Advanced
- AWS Firewall Manager (cross account로 관리)
VPC 전체를 정교한 방식으로 보호하고자 한다면 어떻게 할까?

AWS Network Firewall

Amazon VPC 전체를 보호
layer 3부터 layer 7까지 보호
다음의 어떤 형태의 전송이든 검사 가능
- VPC to VPC 트래픽
- 인터넷으로의 아웃바운드
- 인터넷으로부터의 인바운드
- Direct Connect 또는 Site-to-Site VPN의 인바운드/아웃바운드
내부적으로, AWS Network Firewall은 AWS Gateway Load Balancer를 사용함
Rule들은 여러 VPC에 적용하기 위해 AWS Firewall Manager에 의해 cross-account로 중앙 집중식(centrally) 관리될 수 있음

Network Firewall - Fine Grained Controls

1000개의 Rule 지원
- IP & Port - ex. 10,000개의 IP 필터링
- Protocol - ex. 아웃바운드 커뮤니케이션에 대해 SMB 프로토콜만 블록
- Stateful domain list rule groups: *.mycorp.com 또는 써드파티 소프트웨어 repo로 향하는 아웃바운드 트래픽을 허용
- Regex를 통한 정규표현식 매칭
Traffic Filtering: Rule과 매칭되는 트래픽을 허용/드롭/경고
Active flow inspection: 침입 차단 기능으로 네트워크 위협으로부터 보호 (Gateway Load Balancer와 유사하나, AWS에 의해 완전 관리됨)
Rule과 매치된 로그들을 Amazon S3, CloudWatch Logs, Kinesis Data Firehose로 전송

Shubi Docs