참고 자료

https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/

VPC

CIDR (Classless Inter-Domain Routing)

• CIDR은 IP 주소를 할당을 위한 방법으로 사용된다.
• 보안 그룹 규칙 및 AWS 네트워킹에서 일반적으로 사용된다.
  
• 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 주소)

Understanding CIDR – IPv4

• CIDR은 두 가지 구성 요소를 가지고 있다.
  • 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

Subnet Mask

• 서브넷 마스크는 기본 IP에서 추가적인 다음 값들을 가져올 수 있도록 하는 역할을 한다.
  

• Quick Memo: IP는 옥텟 네 개로 구성된다.

  • /32: 옥텟 변경 불가
  • /24: 마지막 옥텟 변경 가능
  • /16: 마지막 옥텟 두 개 변경 가능
  • /8: 마지막 옥텟 세 개 변경 가능
  • /0: 옥텟 전체 변경

Little Exercise

https://www.ipaddressguide.com/cidr

• 192.168.0.0/24 = ... ?
  • 192.168.0.0 – 192.168.0.255 (256 IPs)
• 192.168.0.0/16 = ... ?
  • 192.168.0.0 – 192.168.255.255 (65,536 IPs)
• 134.56.78.123/32 = ... ?
  • Just 134.56.78.123
• 0.0.0.0/0
  • All IPs!

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

Subnet (IPv4)

• AWS는 각 서브넷마다 5개의 IP 주소 (처음 4개와 마지막 1개)를 예약한다.
• 이 5개의 IP 주소는 사용할 수 없으며 EC2 인스턴스에 IP로 할당할 수 없다.
• 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 주소가 필요한 경우,
  • /27 크기의 서브넷을 선택할 수 없다. (32개의 IP 주소, 32 - 5 = 27 < 29)
  • /26 크기의 서브넷을 선택해야 한다. (64개의 IP 주소, 64 - 5 = 59 > 29)

🧩 Adding Subnets

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

Internet Gateway (IGW)

• VPC 내의 리소스 (ex. EC2 인스턴스)를 인터넷에 연결하도록 허용하는 EC2 인스턴스나 람다 함수 등
• 수평으로 확장 가능하며 가용성과 중복성이 높다.
• VPC와는 별도로 생성해야 한다.
• 하나의 VPC에는 하나의 인터넷 Gateway만 연결할 수 있으며, 그 반대의 경우에도 마찬가지이다.
• 인터넷 Gateway 자체만으로는 인터넷 액세스를 허용하지 않는다.
• 라우팅 테이블도 수정해야만 한다!

🧩 Adding Internet Gateway

• 이정도로는 서브넷에 인터넷 액세스를 제공하지 못한다. 따라서 라우팅 테이블도 수정해야 한다.

🧩 Editing Route Tables

• 공용 서브넷에 공용 EC2 인스턴스를 만들고
• 라우팅 테이블을 수정해서
• EC2 인스턴스를 라우터에 연결하고
• 인터넷 Gateway에 연결한다. 그러면 인터넷 Gateway가 인터넷과 연결될 수 있다!

Bastion Hosts

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

NAT Instance (outdated, but still at the exam)

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

🧩 NAT Instance

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

NAT Instance – Comments

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

시험에는 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를 퍼블릭 서브넷에 배포한다.
• NAT Gateway가 퍼블릭 서브넷에 있으므로 퍼블릭 서브넷은 이미 인터넷 게이트웨이에 연결됐고 NAT Gateway에 인터넷 연결이 생긴다.
• 이후에 프라이빗 서브넷의 루트를 수정하여 EC2 인스턴스를 NAT Gateway에 연결할 수 있다.

NAT Gateway with High Availability

• NAT Gateway는 단일 AZ에서 복원 가능하다.
• 내결함성(fault-tolerance)을 위해 다중 NAT Gateway를 여러 AZ에 생성해야 한다.
• 라우팅 테이블을 통해 AZ를 서로 연결할 필요는 없다.
  • 가용 영역이 다운되는 경우에도 NAT가 필요하지 않으므로 가용 영역 간 장애 조치(Cross-AZ failover)가 필요하지 않다.

NAT Gateway vs. NAT Instance

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-nat-comparison.html

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보다 우선순위가 높기 때문에 허용된다.
  • 마지막 규칙은 별표(*)로, 일치하는 규칙이 없으면 모든 요청을 거부한다.
  • AWS는 규칙을 100씩 추가하는 것을 권장한다.
• 새로 생성된 NACL은 기본적으로 모든 것을 거부한다.
• NACL은 서브넷 수준에서 특정 IP 주소를 차단하는 효과적인 방법이다.

🧩 NACLs

• NACL은 서브넷 수준에 있기 때문에, 위 도면에서는 퍼블릭 서브넷과 프라이빗 서브넷에 위치해있다.

Default NACL

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

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-network-acls.html

Ephemeral Ports (휘발성 포트)

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-network-acls.html#nacl-ephemeral-ports

• 어떤 두 엔드포인트가 연결되기 위해서는 포트를 사용해야 한다.
• 클라이언트는 규정된 포트의 서버에 연결하고 휘발성 포트에서 응답을 기대한다.
  • 클라이언트가 서버에서 회신을 받기 위해서는 서버에서도 클라이언트에 연결해야 하지만, 클라이언트는 기본적으로 개방된 포트가 없어서 클라이언트가 서버에 접속할 때 자체적으로 특정한 포트를 열게 된다.
  • 이 포트는 임시라서 클라이언트와 서버간 연결이 유지되는 동안에만 열려있다.
• 운영 체제에 따라 포트 범위가 달라진다.
  • IANA 및 MS Windows 10: 49,152 – 65,535
  • Linux: 32,768 – 60,999
    
    휘발성 포트라고 불리는 이유는 연결 수명을 위해서만 활당되는 무작위 포트이기 때문이다.

NACL with Ephemeral Ports

휘발성 포트를 제대로 구성하는 것이 중요하다!

Create NACL rules for each target subnets CIDR

다중 NACL 및 다중 서브넷이 있다면 각 NACL 조합이 NACL 내에서 허용되어야 한다.

Security Group vs. NACLs

VPC Peering

• AWS의 네트워크를 사용하여 두 개의 VPC를 프라이빗하게 연결한다.
• 두 VPC가 동일한 네트워크에 있는 것처럼 동작할 수 있다.
• CIDR이 겹치지 않아야한다.
  • 연결했을 때 CIDR이 겹치면 통신을 할 수 없기 때문
• VPC 피어링은 두 VPC 간에 발생하며 전이(transitive)되지 않는다. (서로 통신해야하는 각 VPC에 대해 별도의 피어링 연결을 활성화해야 함)
• 각 VPC의 서브넷 상의 루트 테이블을 업데이트하여 EC2 인스턴스들이 서로 통신할 수 있도록 해야한다.

VPC Peering – Good to know

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

🧩 VPC Peering

• VPC 피어링 연결을 추가해서 서로 다른 VPC를 연결

VPC Endpoints

🧩 VPC Endpoints

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

VPC Endpoints (AWS PrivateLink)

• 모든 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?

Amazon S3에 액세스하는 방법은 두 가지 방법이 있다.

• 게이트웨이 엔드포인트와 인터페이스 엔드포인트
• 시험에서는 게이트웨이 엔드포인트를 선택하는 것이 유리하다.
  • 라우팅 테이블만 수정하면 되기 때문
  • 애플리케이션에서 S3에 무료로 액세스할 수도 있음
• 인터페이스 엔드포인트는 온프레미스(Site to Site VPN 또는 Direct Connect), 다른 VPC 또는 다른 리전에서 액세스가 필요한 경우에 선호된다.

VPC Flow Logs

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

🧩 VPC Flow Logs

• 도식에는 VPC 계층이 있지만 서브넷이나 ENI 계층일 수도 있다.
• 이 로그는 CloudWatch와 S3에 전송된다.

VPC Flow Logs Syntax

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/flow-logs.html#flow-log-records

version, account-id, interface-id, srcaddr(소스 주소), dstaddr(대상 주소), 소스 포트(scrpor), 대상 포트(dstport), protocl, 패킷 수(packets), 바이트 수(bytes), 시작 동작(start action), 로그 상태(log-status) 등이 있다.

• srcaddr & dstaddr: 문제가 있는 IP를 식별
• srcport & dstport: 문자게 있는 포트를 식별
• action: 보안 그룹 또는 NACL 계층에서 요청이 성공했는지 실패했는지 알려줌
• 사용 패턴 분석이나 악성 행동 감지 포트 스캔 등에 사용될 수 있음
• VPC 흐름 로그를 S3 또는 CloudWatch Logs Insights를 사용하여 쿼리할 수 있다.
• 흐름 로그 레코드 예: https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/flow-logs-records-examples.html

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

🧩 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 연결의 고객 측에 위치한 소프트웨어 또는 물리적 장치
  • https://docs.aws.amazon.com/ko_kr/vpn/latest/s2svpn/your-cgw.html

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간의 전용 프라이빗 연결을 제공한다.
• 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

• 핵심 워크로드의 복원력 높이기 - 여러 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를 한 번에 연결하는 식이기 때문이다.
  
  네트워크 토폴로지는 정말 복잡해질 수 있다. AWS는 이런 문제를 해결하고자 Transit Gateway를 만들었다.
  

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

Transit Gateway: Site-to-Site VPN ECMP

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

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

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

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

• Site-to-Site VPN을 VPC에 직접 연결하면 두 터널 모두 하나로 사용되지만 Transit Gateway를 사용할 떄는 두 터널이 동시에 사용된다.

• 두 번째 Site-to-Site VPN을 생성해 Transit Gateway를 사용하면 총 터널 네 개가 생겨 연결 처리량이 증가한다.

• 기업 데이터 센터를 직접 VPC에 연결한 경우에는 사용할 수 없다.

Transit Gateway: 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마다 요금이 청구됨

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

IPv6 in VPC

What is IPv6?

• IPv4는 약 43억 개의 IP 주소를 제공하기 위해 설계되었으며, 이 주소들은 곧 소진될 예정
• 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

• 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

• IPv6가 있는 VPC이다. 공용 및 사설 서브넷이 있는데 둘 다 IPv4와 IPv6를 가진다.
• 인터넷에 액세스하는 웹 서버는 인터넷 게이트웨이를 통해 IPv4와 IPv6로 액세스한다.
• 공용 서브넷의 라우팅 테이블
  • 첫 두 줄: 로컬
  • 0.0.0.0/0: 모든 IPv4
  • ::/0: 모든 IPv6
    • 인터넷 게이트웨이를 통해 웹 서버가 인터넷에 액세스하도록 허용
• 사설 서브넷: 서버에 IPv4와 IPv6가 있음. 서버가 인터넷에 액세스하되 액세스받지는 못하게하려면 어떻게 해야할까?
  • IPv4의 경우 NAT Gateway를 사용한다. 서버는 NAT Gateway에 연결되고 NAT Gateway는 인터넷 Gateway에 연결되며 IPv4로 인터넷에 액세스하게 된다.
  • IPv6는 송신 전용 인터넷 게이트웨이(Egress-only Internet Gateway)를 사용해야 한다.
    • 송신 전용 인터넷 게이트웨이에 서버가 연결되고 IPv로 인터넷에 액세스한다.
  • 사설 서브넷 라우팅 테이블
  • NAT Gateway ID는 0.0.0.0/0의 대상
  • 송신 전용 인터넷 게이트웨이 ID는 ::/0

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와 유사한 기능

Networking Costs in AWS - Simplified

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

Minimizing egress traffic network cost

• Egress traffic (송신 트래픽): 아웃바운드 트래픽 - AWS에서 밖으로 나가는 트래픽
• Ingress traffict (수신 트래픽): 인바운드 트래픽 - 외부에서 AWS로 들어오는 트래픽은 대부분 무료
• 가능한 인터넷 트래픽을 최대한 AWS 내부에 두고 비용을 최소화
• 동일한 AWS 리전에 위치한 Direct Connect 로케이션을 활용하면 송신 네트워크 비용을 낮출 수 있음

S3 Data Transfer Pricing – Analysis for USA

• S3 ingress: 무료
• S3 to Internet: $0.09 / GB
• S3 Transfer Acceleration:
  • 더 빠른 전송 시간 (50% - 500% 향상)
  • 데이터 전송 비용에 추가 비용 발생: 1GB당 0.04달러에서 0.08달러 추가
• S3 to CloudFront: 무료
• CloudFront to Internet: $0.085 / GB (S3 to Internet보다 약간 더 저렴함)
  • 캐싱 기능으로 지연 시간을 줄일 수 있음
  • S3 요청에 연결된 비용을 줄일 수 있음 (CloudFront로 사용 시 7배 저렴)
• S3 Cross Region Replication: $0.02 / GB

NAT Gateway vs Gateway VPC Endpoint

리전에 VPC가 있고, 프라이빗 서브넷 두 개는 각기 다른 유형의 EC2 인스턴스 사용. 둘 다 S3 버킷으로 데이터를 액세스하고자 함.

• 공용 인터넷 사용:
  • NAT Gateway가 있는 퍼블릭 서브넷 생성, 이때 인터넷 게이트웨이로 향하는 라우트 필요함
  • 라우팅 테이블을 사용하여 라우트 구축
  • EC2 인스턴스에서 NAT Gateway와 인터넷 게이트웨이를 지나 인터넷과 직접 연결됨
  • NAT Gateway: $0.045 / h + $0.045 / GB
  • S3 리전간 데이터 송신 비용: $0.09 / h (동일 리전의 경우엔 비용 X)
• VPC 엔드포인트 사용:
  • S3 버킷에 비공개로 데이터를 액세스할 수 있고, 다른 라우팅 테이블을 생성함
  • VPC 엔드포인트에 액세스하기 위해서는 여기로 연결되는 라우트만 설정하면 됨
  • 데이터는 사설 서브넷에서 VPC 엔드포인트와 S3 버킷으로 직접 흐르게 됨
  • 게이트웨이 엔드포인트: 비용 X
  • 동일 리전에서 S3로 데이터 주고 받을 때: $0.01 / GB
• NAT Gateway보다 VPC 엔드포인트를 쓰는 게 훨씬 저렴함

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로 전송하여 분석 가능