[클라우드] VPC (Virtual Private Cloud)

CIDR (Classless Inter-Domain Routing)

• IP 주소를 할당을 위한 방법
  

  

• We’ve seen WW.XX.YY.ZZ/32 → 하나의 IP
• We’ve seen 0.0.0.0/0 → 모든 IP
• But we can define: 192.168.0.0/26 → 192.168.0.0 - 192.168.0.63 (64 개의 IP 주소)
• 두 가지 구성 요소
  • Base IP (기본 IP)
    • 범위 내에 포함된 IP를 나타냄 (XX.XX.XX.XX)
    • ex. 10.0.0.0, 192.168.0.0 등
  • Subnet Mask (서브넷 마스크)
    • IP에서 변경 가능한 비트의 개수 정의
    • ex. /0, /24, /32 등
    • 두 가지 형식으로 표현할 수 있다.
      • /8 ↔️ 255.0.0.0
      • /16 ↔️ 255.255.0.0
      • /24 ↔️ 255.255.255.0
      • /32 ↔️ 255.255.255.255
• Quick Memo: IP는 옥텟 네 개로 구성

  

---

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 CIDR은 다른 VPC나 네트워크, 혹은 기업 네트워크와 겹치지 않도록 주의 !

---

Subnet (IPv4)

• AWS는 각 서브넷마다 5개의 IP 주소 (처음 4개와 마지막 1개)를 예약
• 이 5개의 IP 주소는 사용할 수 없으며 EC2 인스턴스에 IP로 할당 X
• ex. CIDR 블록이 10.0.0.0/24인 경우, 예약된 IP 주소
  • 10.0.0.0 - 네트워크 주소
  • 10.0.0.1 - VPC 라우터 용으로 AWS가 예약한 주소
  • 10.0.0.2 - Amazon 제공 DNS에 매핑하기 위해 AWS가 예약한 주소
  • 10.0.0.3 - 미래 사용을 위해 AWS가 예약한 주소
  • 10.0.0.255 - 네트워크 브로드캐스트 주소. AWS는 VPC에서 브로드캐스트를 지원하지 않기 때문에 예약은 되지만 사용은 할 수 없음
• 시험 팁: EC2 인스턴스에 29개의 IP 주소가 필요한 경우
  
  • /26 크기의 서브넷을 선택 (64개의 IP 주소, 64 - 5 = 59 > 29)

공용 서브넷과 사설 서브넷을 VPC에 추가

---

Internet Gateway (IGW)

• VPC 내의 리소스 (ex. EC2 인스턴스)를 인터넷에 연결하도록 허용
• 수평으로 확장 가능하며 가용성과 중복성이 높다.
• VPC와는 별도로 생성
• 하나의 VPC에는 하나의 인터넷 Gateway만 연결
• ✅ 인터넷 Gateway 자체만으로는 인터넷 액세스를 허용 X > 라우팅 테이블도 수정 필수

---

Bastion Hosts

• 배스천 호스트는 프라이빗 EC2 인스턴스에 SSH로 액세스하기 위해 사용
• 배스천 호스트는 퍼블릭 서브넷에 위치하며, 다른 모든 프라이빗 서브넷에 연결
• ✅ 배스천 호스트의 보안 그룹은 인터넷에서 제한된 CIDR(예: 회사의 공용 CIDR)로부터 포트 22로의 인바운드 연결을 허용할 것
• ❓❓ 배스천 호스트의 보안 그룹은 반드시 인터넷 액세스를 허용해야 한다. 하지만 모든 인터넷 액세스를 허용하면 보안상 위험이 크기 때문에 기업의 퍼블릭 CIDR 액세스만 허용하거나 사용자의 인터넷 액세스만 허용하는 등 이를 제한하는 것이 좋다.
• EC2 인스턴스의 보안 그룹은 배스천 호스트의 보안 그룹 또는 배스천 호스트의 프라이빗 IP를 허용

---

NAT Instance

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

 

NAT Instance 

• 미리 구성된 Amazon Linux AMI 사용 가능
• 표준 지원은 2020년 12월 31일에 종료
• 기본적으로 고가용성/신뢰성 설정이 제공 X
• 멀티-AZ 및 신뢰성 있는 사용자 데이터 스크립트로 ASG(Auto Scaling Group)를 생성해야 함
• 인터넷 트래픽 대역폭은 EC2 인스턴스 유형에 따라 다름
• 보안 그룹과 규칙을 관리해야 함
• 인바운드
  • 프라이빗 서브넷에서 오는 HTTP/HTTPS 트래픽 허용
  • 홈 네트워크에서 SSH 허용 (인터넷 게이트웨이를 통해 접속 가능)
• 아웃바운드
  • 인터넷으로의 HTTP/HTTPS 트래픽 허용

NAT Gateway

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

NAT Gateway with High Availability

• NAT Gateway는 단일 AZ에서 복원 가능
• ✅ 내결함성(fault-tolerance)을 위해 다중 NAT Gateway를 여러 AZ에 생성
• 라우팅 테이블을 통해 AZ를 서로 연결할 필요 X

---

Security Groups & NACLs

Network Access Control List (NACL)

• 네트워크 액세스 제어 목록인 NACL은 서브넷을 오가는 트래픽을 제어하는 방화벽과 유사
• ✅ 하나의 서브넷당 하나의 NACL을 가지며, 새로운 서브넷은 기본 NACL이 할당
• NACL은 규칙을 정의한다.
  • 규칙은 번호(1-32,766)를 가지며, 번호가 낮을수록 우선순위가 높다.
  • 첫 번째 규칙 비교가 결정을 이끈다.
    • 예를 들어, #100 ALLOW 10.0.0.10/32 & #200 DENY 10.0.0.10/32를 정의한 경우
    • IP 주소는 100이 200보다 우선순위가 높기 때문에 허용 > 모든 규칙 평가 X
  • 마지막 규칙은 별표(*)로, 일치하는 규칙이 없으면 모든 요청을 거부
  • AWS는 규칙을 100씩 추가하는 것을 권장
• ✅ 새로 생성된 NACL은 기본적으로 모든 것을 거부
• NACL은 서브넷 수준에서 특정 IP 주소를 차단하는 효과적인 방법

Default NACL

• 기본 NACL은 해당하는 서브넷과 관련된 모든 인바운드/아웃바운드의 요청을 허용
• 기본 NACL을 수정하지 말고, 사용자 정의 NACL를 생성할 것

Ephemeral Ports (휘발성 포트)

연결 수명을 위해서만 활당되는 무작위 포트

•  두 엔드포인트가 연결되기 위해서는 포트를 사용
• 클라이언트는 규정된 포트의 서버에 연결하고 휘발성 포트에서 응답을 기다림
• 운영 체제에 따라 포트 범위가 달라진다.
  • IANA 및 MS Windows 10: 49,152 – 65,535
  • Linux: 32,768 – 60,999
• 다중 NACL 및 다중 서브넷이 있다면 각 NACL 조합이 NACL 내에서 허용

---

VPC Peering

• AWS의 네트워크를 사용하여 두 개의 VPC를 프라이빗하게 연결
• ✅ 다른 AWS 계정/리전에 있는 VPC 간 연결 가능
• 피어링된 VPC에서 보안 그룹을 참조 가능
• CIDR이 겹치면 X
• VPC 피어링은 두 VPC 간에 발생하며 전이(transitive)되지 않는다. (서로 통신해야하는 각 VPC에 대해 별도의 피어링 연결을 활성화해야 함)

---

VPC Endpoints

• AWS에서 DynamoDB와 같은 서비스를 이용한다고 하면 퍼블릭 액세스가 가능
• 이것은 NAT Gateway나 인터넷 Gateway를 통해 DynamoDB에 액세스할 수 있다는 것
• CloudWatch나 Amazon S3 등의 서비스를 이용할 때는 인터넷을 경유하지 않는 프라이빗 액세스를 원할 수도 있다.
• ✅ 이때 VPC 엔드포인트를 사용하면 퍼블릭 인터넷을 거치지 않고도 인스턴스에 액세스

Types of Endpoints

• 인터페이스 엔드포인트 (Interface Endpoints - PrivateLink를 통해 구현)
  • ENI (VPC의 프라이빗 엔드포인트)를 AWS의 엔트리 포인트로 프로비저닝 (반드시 보안 그룹을 연결해야 함)
  • 대부분의 AWS 서비스를 지원
  • 시간당 + 처리된 데이터의 GB당 비용이 발생
  • 프레미스(Site to Site VPN 또는 Direct Connect), 다른 VPC 또는 다른 리전에서 액세스가 필요한 경우에 선호
• Gateway 엔드포인트
  • ✅ 게이트웨이를 프로비저닝하며 이 게이트웨이는 반드시 라우팅 테이블의 대상이 되어야 한다. (보안 그룹을 사용하지 않음) > 라우팅 테이블만 수정하면 끝 !
  • 게이트웨이 엔드포인트 대상으로는 S3 및 DynamoDB가 있음
  • 무료

---

VPC Flow Logs

• 인터페이스로 들어오는 IP 트래픽에 대한 정보를 포착하는 기능
  • VPC 플로우 로그
  • 서브넷 플로우 로그
  • Elastic Network Interface (ENI) 플로우 로그
• 흐름 로그는 연결 문제를 모니터링하고 트러블 슈팅하는데 유용
• 흐름 로그 데이터는 S3, CloudWatch Logs로 전송
• AWS에서 관리하는 인터페이스에서도 네트워크 정보를 포착한다: ELB, RDS, ElastiCache, Redshift, WorkSpaces, NATGW, Transit Gateway 등

---

Troubleshoot SG & NACL issues

Incoming Request

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

Outgoing Request

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

---

AWS Site-to-Site VPN

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

AWS Site-to-Site VPN

AWS Site-to-Site VPN (AWS 사이트 간 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

 

• 고객 게이트웨이 장치 (온프레미스) 
  • CGW가 퍼블릭이면 CGV의 퍼블릭 IP를 사용하여 VGW와 연결
  • CGV가 프라이빗이면 NAT 장치의 공용 IP를 사용하여 CGW와 VGW를 연결
• Important step: 서브넷과 연관된 라우팅 테이블에서 가상 프라이빗 게이트웨이의 라우트 전파 (Route Propagation)를 활성화해야 site-to-site VPN 연결 가능
• 온프레미스에서 EC2 인스턴스에 핑을 보내려면 보안 그룹의 인바운드에 ICMP 프로토콜을 추가해야 함

---

AWS VPN CloudHub

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

---

Direct Connect (DX)

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

Direct Connect Gateway

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

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는 답이 될 수 없다.

 

---

Direct Connect – Encryption

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

Direct Connect - Resiliency

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

  

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

  

---

Site-to-Site VPN connection as a backup

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

  

---

Transit Gateway

네트워크 토폴로지는 정말 복잡해질 수 있다. AWS는 이런 문제를 해결하고자 Transit Gateway를 만들었다.

• 수천 개의 VPC와 온프레미스 간에 전이적 연결을 제공하기 위한 허브 앤 스포크 (스타) 연결
• ✅ AWS에서 유일하게 IP 멀티캐스트를 지원함

---

VPC – Traffic Mirroring

• VPC 내에서 네트워크 트래픽을 수집하고 분석
• 관리 중인 보안 어플라이언스로 트래픽을 라우팅하여 검사
• Capture the traffic
  • From (Soruce): ENIs
  • To (Targets): ENI 또는 네트워크 로드 밸런서
• 모든 패킷을 캡처하거나 관심있는 패킷을 캡처할 수 있으며 필요한 경우 패킷을 줄일 수 있다.
• 소스와 대상은 동일한 VPC 내에 있거나 VPC 피어링이 활성화된 경우 다른 VPC에 위치할 수 있다.
• 사용 사례: 콘텐츠 검사, 위협 모니터링, 네트워킹 문제 해결

---

IPv6 in VPC

What is IPv6?

• IPv4는곧 소진될 예정
• IPv6는 3.4 × 10^38 개의 고유한 IP 주소를 제공하기 위해 설계
• 모든 IPv6 주소는 공용이고 인터넷 라우팅이 가능함 (사설 범위가 없음)
• 형식: x.x.x.x.x.x.x.x (x는 16진수, 범위는 0000부터 ffff까지)
• examples:
  • 2001:db8:3333:4444:5555:6666:7777:8888
  • 2001:db8:3333:4444:cccc:dddd:eeee:ffff
  • :: → 8개 세그먼트가 모두 0
  • 2001:db8:: → 마지막 6개 세그먼트가 0
  • ::1234:5678 → 처음 6개 세그먼트가 0
  • 2001:db8::1234:5678 → 중간 4개 세그먼트가 0

IPv6 in VPC

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

  

IPv6 Troubleshooting

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

---

Egress-only Internet Gateway

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

IPv6 Routing

• 사설 서브넷: 서버에 IPv4와 IPv6가 있음. 서버가 인터넷에 액세스하되 액세스받지는 못하게하려면 어떻게 해야할까?
  • IPv4의 경우 NAT Gateway를 사용한다. 서버는 NAT Gateway에 연결되고 NAT Gateway는 인터넷 Gateway에 연결되며 IPv4로 인터넷에 액세스하게 된다.
  • IPv6는 송신 전용 인터넷 게이트웨이(Egress-only Internet Gateway)를 사용
    • 송신 전용 인터넷 게이트웨이에 서버가 연결되고 IPv4로 인터넷에 액세스
  • 사설 서브넷 라우팅 테이블

---

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 인스턴스. 사설 서브넷의 EC2 인스턴스에 인터넷 액세스를 제공. 퍼블릭 서브넷에 설정해야 하며, 소스/대상 확인 플래그를 비활성화해야 함.
• 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를 사용하여 분석 후 S3으로 전송
• Site-to-Site VPN: (VPC를 데이터 센터에 연결하는 첫 번째 옵션 1) 공용 인터넷을 지나는 VPN 연결 - 데이터 센터에 고객 게이트웨이, VPC에 가상 사설 게이트웨이를 생성하고 VPN 연결 구축
• AWS VPN CloudHub: 가상 프라이빗 게이트웨이를 사용해 VPC 연결을 여러 개 생성하려면 CloudHub를 활용하여 허브-앤-스포크 VPN 모델로 사이트에 연결
• Direct Connect: (VPC를 데이터센터에 연결하는 또다른 옵션 2 - 완전 비공개로 연결함) 공용 인터넷을 통과하지 않고 구축하는데 시간이 걸림, 데이터 센터를 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와 유사한 기능

---

 

Networking Costs in AWS - Simplified

• 공용 IP보다는 사설 IP 사용: 공용 IP를 사용하면 추가 비용이 발생할 수 있다. 사설 IP를 사용하면 비용이 절약될 뿐만 아니라 네트워크 성능도 더 좋다.
• 동일한 가용 영역(AZ) 사용: 최대한 비용을 절감하도록 같은 가용 영역을 사용하는 것이 좋다. 하지만 비용이 절감되는 만큼 가용성이 떨어지기도 한다. (AZ가 다운되는 경우 장애 조치 불가)

---

Network Protection on AWS

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

• 네트워크 액세스 제어 목록 (NACL)
• Amazon VPC 보안 그룹
• AWS WAF (악성 요청으로부터 보호)
• AWS Shield 및 AWS Shield Advanced
• AWS Firewall Manager (다중 계정에서 관리)
  하지만 VPC 전체를 정교하게 보호하고 싶다면 어떻게 해야 할까?

AWS Network Firewall

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

Network Firewall – Fine Grained Controls

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

---

 

참고) 강의 내용이 너무 많아 아래 블로그를 참고해 중요한 부분 위주로 보충했습니다. 추후 비공개로 돌릴 예정입니다.

[SAA-C03] 네트워킹 - VPC

 

[AWS] Virtual Private Cloud (VPC)