[SAA] Virtual Private Cloud(VPC)

1. CIDR(Classless Inter-Domain Routing)

• IP 주소 할당을 위한 방법
• 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(64개의 IP 주소)
• 구성 요소
  • Base IP(기본 IP)
    
    • 범위내에 포함된 IP를  나타냄
    • 10.0.0.0, 192.168.0.0 등
  • Subnet Mask(서브넷 마스크)
    
    
    
    • IP에서 변경 가능한 비트의 개수 정의
    • /0, /24, /32  등
    • 두가지 형식으로 표현 가능
      • /8 = 255.0.0.0
      • /16 = 255.255.0.0
      • /24 = 255.255.255.0
      • /32 = 255.255.255.255
  • Quck Memo: IP는 옥텟 네 개로 구성
    
    
    
    • /32: 옥텟 변경 불가
    • /24: 마지막 옥텟 변경 가능
    • /16: 마지막 두개 옥텟 변경 가능
    • /8: 마지막 세개 옥텟 변경 가능
    • /0: 옥텟 전체  변경 가능
• examples
  • 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: 134.56.78.123 (1 IP)
  • 0.0.0.0: All IPs
• Pulbic IP VS Private IP (IPv4)
  • 인터넷 할당 번호 관리 기관(Internet Assigned Numbers Authority, IANA)에서 구축한 특정 IPv4 주소 블럭은 사설 (LAN) 및 공용 (Internet) 주소로 사용하기 위하여 설정됨
  • 사설 IP는 특정 값만 허용
    • 10.0.0.0 ~ 10.255.255.255(10.0.0.0/8): 대규모 네트워크에 사용
    • 172.16.0.0 ~ 172.16.255.255(172.16.0.0/12): AWS의 기본 VPC 범위
    • 192.168.0.0 ~ 192.168.255.255(192.168.0.0/16): 홈 네트워크 
• Default VPC 
  • 모든 새로운 AWS계정은 모두 기본 VPC를 가지고 있음
  • 서브넷이 지정되지 않은 경우 새로운 EC2는 기본 VPC에서 실행
  • 기본 VPC는 인터넷 연결이 가능하며, 그 안에 있는 모든 EC2 인스턴스는 공개 IPv4 주소를 가짐
  • 또한 EC2  인스턴스를 위한 퍼블릭 및 프라이빗 IPv4 DNS 이름도 가짐
• VPC in AWS (IPv4)
  • VPC = Virtual Private Cloud
  • 단일 AWS 리전에 여러개의 VPC 생성 가능(리전당 최대 5개, soft limit)
  • VPC당 최대 CIDR은 5개, 각 CIDR에 대해 최소 크기는 /28(16개의 IP), 최대 크기는 /16 (65,536개의 IP)
  • VPC CIDR은 다른 VPC나 네트워크와 겹치지 않도록 주의해야 함
  • VPC는 사설 리소스이기 때문에 프라이빗 IPv4 주소 범위만 허용됨
    • 10.0.0.0 ~ 10.255.255.255(10.0.0.0/8)
    • 172.16.0.0 ~ 172.16.255.255(172.16.0.0/12)
    • 192.168.0.0 ~ 192.168.255.255(192.168.0.0/16)
• Subnet (IPv4)
  • AWS는 각 서브넷마닫 5개의 IP주소(처음 4개와 마지막 1개)를 예약
  • 이 5개의 IP 주소는 사용 불가, EC2 인스턴스에 할당 불가
  • ex) CIDR 블록이 10.0.0.0/24인 경우
    • 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)
    • /26 크기의 서브넷 선택(64 - 5)

2. Internet Gateway(IGW)

• VPC 내의 리소스(ex.EC2 Instance)를 인터넷에 연결하도록 허용하는 EC2 인스턴스나 람다 함수 등
• 수평으로 확장 가능, 가용성과 중복성이 높음
• VPC는 별도 생성 필요
• 하나의 VPC에는 하나의 Internet Gateway만 연결 가능
• Internet Gateway 자체만으로는 인터넷  액세스 허용 X, 라우팅 테이블도 수정해야 함
• 인터넷 액세스 적용 방법
  
  
  
  • 공용 서브넷에 공용 EC2 인스턴스 생성
  • 라우팅 테이블 수정
  • EC2 인스턴스를 라우터에 연결
  • 인터넷 게이트웨이에 연결
• Bastion Hosts
  • 배스천 호스트는 프라이빗 EC2 인스턴스에 SSH로 액세스 하기 위해 사용할 수 있음
  • 배스천 호스트는 퍼블릭 서브넷에  위치하며, 다른 모든 프라이빗 서브넷에  연결됨
  • 배스천 호스트의 보안 그룹은 인터넷에서 제한된 CIDR(ex.회사의 공용 CIDR)로 부터 포트 22로의 인바운드 연결을 허용해야 함
    • 배스천 호스트의 보안 그룹은 반드시 인터넷 액세스를 허용해야  함.
    • 모든 인터넷 액세스 허용 시 보안상 위험이크기 때문에 기업의 Public  CIDR 액세스만 허용하거나 사용자의 인터넷 액세스만  허용하는 등 이를 제한하는 것이 좋음
  • EC2 인스턴스의 보안 그룹은 배스천 호스트의 보안 그룹 또는 배스천 호스트의 프라이빗 IP를 허용해야 함

3. NAT Instance

• NAT  = Network Address  Translation: 네트워크  주소 변환
• NAT 인스턴스는 프라이빗 서브넷에 있는 EC2 인스턴스가 인터넷에 연결되도록 허용한다
• 퍼블릭 서브넷에서 실행되어야 하고 퍼블릭 및 프라이빗 서브넷을 연결한다
• EC2 설정에서 소스/목적지 확인을  해야한다
• Elastic IP가 연결되어야 한다
• 라우팅 테이블을 수정하여 프라이빗 서브넷에서 NAT 인스턴스로 트래픽을 라우팅하도록 구성 되어야 한다.
• 퍼블릭 서브넷에 NAT 인스턴스를 연결하고 라우팅 테이블을 통해 인스턴스가 NAT 인스턴스에서 인터넷 Gateway까지 통신하도록 한다.
• 참고
  • 미리 구성된  Amazon Linux AMI 사용 가능
  • 표준 지원은 2020년  12월 31일에 종료
  • 기본적으로  고가용성/신뢰성 설정 제공 x
  • 멀티 az 및 신뢰성 있는 사용자 데이터 스크립트로 ASG(Auto-Scaling Group)를 생성해야 함
  • 인터넷 트래픽 대역폭은 EC2 인스턴스 유형에 따라 다름
  • 보안 그룹과 규칙을 관리해야 함
  • 인바운드
    • 프라이빗 서브넷에서 오는 http/https 트래픽 허용
    • 홈 네트워크에서 ssh 허용(인터넷 게이트웨이를 통해 접속 가능)
  • 아웃바운드
    • 인터넷으로의 http/https  트래픽 허용

4.  NAT Gateway

• AWS의 관리형 NAT 인스턴스, 높은  대역폭, 고가용성 제공, 관리 필요 X
• 사용량 및 NAT Gateway의 대역폭에 따라 비용 지불
• NAT Gateway는 특정 가용 영역에서 생성되고 탄력적 IP를 이어받음
• 동일 서브넷의 EC2 인스턴스에는 사용 불가, 다른 서브넷에서 액세스 할때만 NAT Gateway가 도움 됨
• NAT Gateway는 인터넷 Gateway 필요(프라이빗 서브넷 -> NAT Gateway -> Internet Gateway)
• 초당 5gbps의 대역폭 제공, 최대 45gbps까지 자동 확장
• 보안 그룹 관리 필요 X
• NAT Gateway를 퍼블릭 서브넷에 배포하면, 퍼블릭 서브넷은  이미 인터넷 게이트웨이에 연결되어있기 때문에 NAT Gateway에 인터넷 연결이 생성됨
• 프라이빗 서브넷의 루트를 수정하여 EC2 인스턴스를 NAT Gateway에 연결할 수 있음
• NAT Gateway with High Availabilty
  • NAT Gateway는  단일 AZ에서 복원 가능
  • 내결함성(fault-tolerance)를 위해 다중 NAT Gateway를 여러 AZ에 생성해야 함
  • 라우팅 테이블을 통해 AZ를 서로 연결할 필요 X
    • 가용 영역이 다운되는 경우에도 NAT가 필요하지 않으므로 가용 영역 간 장애 조치 필요 X
• **NAT Gateway VS NAT Instance
• https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-nat-comparison.html

	NAT Gateway	NAT Instance
가용성	- 특정 AZ에서 가용성이 높음 - AZ 전체에서 고가용성을 필요로 하는 경우 다른 AZ에 더 만들어야 함	스크립트를  사용하여 인스턴스 간의 장애 조치 관리
대역폭	최대 100gbps 까지 확장	인스턴스 유형의 대역폭에 따라 다름
유지 관리	AWS에서 관리	사용자가 관리 (ex. 인스턴스에 소프트웨어 업데이트, 운영체제 패치 설치 등)
비용	시간당 & 데이터가 전송되는 양	시간당, EC2 유형과 크기, 네트워크
Public IPv4	O	O
Private IPv4	O	O
보안 그룹	X	O
Bastion 서버	X	O

 

5.  Security Groups & NACLs

• NACL(Network Access Control List)
  • 네트워크 액세스 제어 목록인 NACL은 서브넷을 오가는 트래픽을 제어하는 방화벽과 유사
  • 하나의 서브넷당 하나의 NACL을 가지며, 새로운 서브넷은 기본 NACL을 할당
  • NACL은 규칙을 정의
    • 규칙은 번호(1 ~ 32,766)을 가지며, 번호가 낮을 수록 우선순위 높음
    • 첫번째 규칙 비교가 결정을 이끈다
      • #100 ALLOW 10.0.0.10/32 & #200 DENY 10.0.0.10/32 정의한 경우, IP 주소는 100이 우선순위가 높기 때문에 허용됨
    • 마지막 규칙은 별표(*)로 일치하는 규칙이 없을 경우 모든 요청 거부
    • AWS는 규칙을 100씩 추가하는것을 권장
  • 새로 생성된 NACL은 기본적으로 모든 것을  거부
  • NACL은 서브넷 수준에서 특정 IP 주소를 차단하는 효과적인 방법
  • 서브넷 수준에 있기 때문에, 퍼블릭 서브넷과 프라이빗 서브넷에 위치
  • Default NACL
    • 해당하는 서브넷과 관련된 모든 인바운드/아웃바운드의 요청을 허용
    • 기본 NACL을 수정하지 말고 사용자 정의 NACL을 생성해야 함
  • 휘발성 포트(Ephemeral Ports)
    • 어떤 두 엔드포인트가 연결되기 위해서는 포트를 사용해야 함
    • 연결 수명을 위해서만 할당되는 무작위 포트이기 때문에 휘발성 포트라고 불림
    • 클라이언트는 규정된 포트의 서버에 연결하고 휘발성 포트에서 응답을 기대함
      • 클라이언트가 서버에서 회신을 받기 위해서는 서버에서도 클라이언트에 연결해야 하지만,  클라이언트는 기본적으로 개방된 포트가 없어서 클라이언트가 서버에 접속할 때  자체적으로 특정 포트를 열게 됨
      • 이 포트는 임시라서 클라이언트와 서버간 연결이 유지되는 동안에만 열려있음
    • 운영체제에 따라 포트 범위가 달라짐
      • IANA 및 MS Windows 10: 49,152 ~  65,535
      • Linux: 32, 768 ~ 60,999
  • Security Group VS NACLs
    

    보안 그룹	NACL
    인스턴스 수준에서 작동	서브넷 수준에서 작동
    허용 규칙 지원	허용과 거부 규칙 지원 (특정 IP 거부 가능)
    Stateful: 규칙과 무관하게 트래픽 허용	Stateless: 인바운드와 아웃바운드 규칙이 매번 평가됨(휘발성 포트)
    모든 규칙이 평가되고 트래픽 허용 여부 결정	가장 높은 우선 순위를 가진 것이 가장 먼저 평가, 첫번째 비교로 결정
    누군가 지정할 때 EC2 인스턴스에 적용	연결된 서브넷의 모든 EC2 인스턴스에 적용됨

• VPC Peering
  • AWS의  네트워크를 사용하여 두개의 VPC를 프라이빗 하게 연결, 두 VPC가 동일한 네트워크에 있는 것처럼 동작 가능
  • CIDR이 겹치지 않아야함: 연결했을 때 CIDR이 겹치면 통신 불가
  • VPC 피어링은 두 VPC 간에 발생, 전이되지 않음
  • 각 VPC 서브넷 상의 루트 테이블을 업데이트 하여 EC2 인스턴스들이 서로 통신할 수 있도록 해야 함
  • 다른 AWS 계정/리전에 있는 VPC 간에 VPC 피어링 연결을 생성할 수 있음
  • 피어링된 VPC에서 보안 그룹 참조 가능 (동일 리전의 계정간 VPC에서도 보안 그룹 참조 가능)
• VPC EndPoints
  • AWS에서 DynamoDB와 같은 서비스를 이용한다고 하면 퍼블릭 액세스 가능
  • NAT Gateway나 Internet Gateway를 통해 DynamoDB에 액세스 할 수 있음
  • 모든 트래픽은 퍼블릭 인터넷을 거침
  • CloudWatch나 Amazon S3 등의 서비스를 이용할 때는 인터넷을 경유하지 않고 프라이빗 액세스를 원할 수도 있음
  • VPC 엔드포인트 사용 시 퍼블릭 인터넷을 거치지 않곡 인스턴스에 액세스 가능
  • 프라이빗 AWS 네트워크만 거쳐서 바로 액세스 가능
  • 중복성을 가지고 수평으로 확장
  • 문제 발생 경우
    • VPD의  DNS 설정 해석(DNS Setting Resolution)을 확인
    • 라우팅 테이블 확인
  • 종류
    • Interface Endpoints - PrivateLink를 통해 구현
      • 온프레미스, 다른 VPC 또는 다른 리전에서 액세스가 필요한 경우에 선호 
      • ENI(VPC의 Private Endpoints)를 AWS의 엔트리 포인트로 프로비저닝(반드시 보안 그룹 연결)
      • 대부분의 AWS 서비스 지원
      • 시간당  + 처리된 데이터의 gb당 비용 발생
    • Gateway Endpoints
      • 라우팅 테이블만 수정하면 됨, 애플리케이션에서 S3에 무료로 액세스 가능 
      • 게이트웨이를 프로비저닝, 이 게이트웨이는 반드시 라우팅 테이블의 대상이 되어야함(보안 그룹 사용X)
      • 게이트웨이 엔드포인트 대상으로는 S3, DynamoDB
      • 무료
• VPC Flow Logs
  • 인터페이스로 들어오는 IP 트래픽에 대한 정보 포착 기능
    • VPC Flow Logs
    • Subneet Flow Logs
    • Elastic network Interface(ENI) Flow Logs
  • 연결 문제를 모니터링하고 트러블 슈팅하는 데 유용
  • S3, CloudWatch Logs로 전송 각능
  • AWS에서 관리하는 인터페이스에서도 네트워크 정보 포착
    • ELB, RDS, ElastiCache, Redshift, WorkSpaces, NATGW, Transit Gateways
  • Syntax
    
    
    
    • srcaddrr & dstaddrr: 문제가 있는 IP 식별
    • srrcport & 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 or 보안그룹 중 하나가 요청을 거부하고 있다는 것
    • 인바운드 ACCEPT, 아웃바운드 REJECT: NACL 문제
  • Outgoing Request
    • 아웃바운드 REJECT: NACL이나 보안그룹 문제
    • 아웃바운드 ACCEPT, 인바운드 REJECT: NACL 문제

 

6.  AWS Site-to-Site VPN

• VPC를 구축했으나 특정 구조가 있는 기업 데이터 센터를 AWS와 비공개로 연결하려면 기업은 고객 게이트웨이를, VPC는 VPN게이트웨이를 갖춰야 함
• 퍼블릭 인터넷을 통해 Private 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  연결의 고객 측에 위치한 소프트웨어 또는 물리적 장치
    • 고객 게이트웨이각 공용이라면 인터넷 라우팅이 가능한 IP 주소를 사용해야 함
    • NAT 탐색이 활성화된 NAT 장치 뒤에 있는 경우, NAT 장치의 Public IP 주소 사용
• 연결 방법
  • 서브넷과 연관된 라우팅 테이블에서 가상 프라이빗 게이트웨이의 라우트 전파(Route Propagation)을 활성화 해야 ㅇ함
  • 온프레미스에서 EC2 인스턴스에 핑을 보내려면 보안 그룹의 인바운드에 ICMP 프로토콜을 추가해야 함
• AWS VPN CloudHub
  • CloudHub는 여러 VPN 연결을 통해 모든 사이트 간의 안전한 통신을 보장하고 여러 VPN 연결이 있는 경우에 적합함
  • 다양한 위치간의 주요 또는 보조 네트워크 연결을 위한 저비용 hub-and-spoke 모델 제공(vpn only)
  • VPN 연결이므로  모든 트래픽이 공용 인터넷을 통해  이루어짐
  • CloudHub를 설정하기 위해 동일한 가상 프라이빗 게이트웨이(VGW) 하나에 여러 Site-to-Site VPN 연결을 여러개 만들고, 동적 라우팅을 설정하고, 라우트 테이블을 구성하면 됨

7.  Direct Connect(DX)

• 원격 네트워크와 VPC간의 전용 프라이빗 연결을 제공
• Direct Conneect를 사용할 때는 전용 연결을 생성해야 하고, AWS Direct Connect 로케이션을 사용
• VPC에 가상 프라이빗 게이트웨이를 설정해야 함
• 동일한 연결을 통해 퍼블릭 리소스(S3)와 프라이빗 리소스(EC2)에 접근 가능
• example
  • 대역폭 처리량이 증가할 때(대용량 데이터 세트 작업 시) 비용 절감 가능 -> 퍼블릭 인터넷을 거치지 않기 때문에
  • 실시간 데이터 피드를 사용하는 애플리케이션에서 더  일관된 네트워크 경험 가능
  • 하이브리드 환경 지원(온프레미스 + 클라우드)
• IPv4, IPv6 모두 지원
• Direct Connet Gateway
  • 하나 이상의 VPC를 여러 다른 리전에 설정하려는 경우(동일한 계정 내에서) Direct Connect 연결을 사용해야 할 때 사용됨
• 연결 종류
  • Dedicateed Connections: 초당 1gbps, 10gbps, 100gbps의 전용 연결 용량
    • 고객은 물리적 전용 이더넷 포트 할당
    • 요청은 먼저 AWS에 보내지며, 그 후 AWS Direct Connect 파트너가 처리를 완료
  • Hosted  Connections: 초당 50mbps, 500mbps, 10 gbps까지
    • 연결 요청은  AWS Direct Connect 파트너를 통해 이루어짐
    • 용량은  필요에 따라 추가/제거 가능
    • 일부 AWS Direct Connect 파트너에서는 1, 2, 5, 10 gbps 용량 제공
  • 새로운 연결 설정 시 1개월 이상 걸리기 때문에 Direct Connect는 답이 아님
• 암호화
  • 전송중인 데이터는 암호화되지 않지만 프라이빗 연결이므로 보안 유지 가능
  • AWS Dirct Connect와 VPN을 함께 설치하여 IPsec으로 암호화된 프라이빗 연결 가능
  • 보안 수준을 높이기 위한 좋은 방법이지만 구현이 복잡
• 복원력
  • 핵심 워크로드의 복원력 높이기: 여러 Direct Connect 설치
  • 핵심 워크로드의 복원력을 최대로 끌어올리기: 각 Direct Connection 로케이션에 독립적인 연결을 두개씩 수립
• Site-to-Site VPN Connection as a backup
  • Direct Connection 연결에 문제 발생 시, Direct Connect로 보조 연결 가능, BUT 비용이 많이 듦
  • Site-to-Site VPN을 백업 연결로 두어 기본 연결에 문제  발생 시 S2S VPN을 통해 퍼블릭 인터넷에 연결할 수 있으므로 안정성이  높아짐(퍼블릭 인터넷은 언제나 연결되어 있기 때문에)

 

8.  Transit Gateway

• 네트워크 토폴로지가 복잡해질 수 있기 때문에  이를 해결하고자 Transit Gateway를 만듦
• 수천개의 VPC와 온프레미스간에 전이적 연결을 제공하기 위한 허브앤스포크(스타형) 연결
• 리전별 자원으로 크로스 리전  작업 가능
• Resource Access Manager(RAM)을 사용하면 계정 간 Transit Gateway 공유 가능
• 리전 간 Transit Gateway 피어링 가능
• 라우팅 테이블: VPC간의 통신 제한 가능
• Direct  Connect Gateway, VPN 연결과 함께 작동
• AWS에서 유일하게 Multicast 지원
• 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에 연결한 경우에는 사용할 수 없다.
• throughput with ECMP
  • 가상 프라이빗 게이트웨이에 VPN  연결
    • VPC마다 터널 하나(연결 하나)씩
    • 연결 하나당 1.25gbps 제공, 최대 처리량으로 제한
    • 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 연결을 공유할 수 있게 된다.

9.  VPC -  Traffic Mirroring

• VPC 내에서 네트워크 트래픽을 수집하고 분석할 수 있게 해줌
• 관리중인 보안 어플라이언스로 트래픽을 라우팅하여 검사
• Capture  the Traffic
  • From (Source): ENIs
  • TO (Targetes): ENI or Network Load Balancer
• 모든 패킷을 캡처하거나 관심있는 패킷을 캡처할 수 있으며 필요한 경우 패킷을 줄일 수 있음
• 소스와 대상은 동일한 VPC 내에 있거나 VPC 피어링이 활성화된 경우 다른 VPC에 위치할 수 있음
• ex) 콘텐츠 검사, 위협 모니터링, 네트워킹 문제 해결 등
• IPv6 in VPC
  • IPv6
    • IPv4는 약 43억 개의 IP 주소를 제공하기 위해 설계되었으며, 이 주소들은 곧 소진될 예정
    • IPv6는 3.4 × 10^38 개의 고유한 IP 주소를 제공하기 위해 설계됨
    • 모든 IPv6 주소는 공용이고 인터넷 라우팅이 가능함 (사설 범위가 없음)
    • 형식: x.x.x.x.x.x.x.x (x는 16진수, 범위는 0000부터 ffff까지)
    • examplee
      • 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

 

10.  Networking Costs in AWS

• 공용 IP 보다는 사설 IP 사용: 공용 IP 사용 시 추가 비용 발생, 사설 IP 사용 시 비용 절약 뿐만 아니라 네트워크 성능도  좋음
• 동일한 가용영역(AZ) 사용: 비용절약을 위해 같은 가용 영역 사용이 좋음, but 가용성이 떨어지기도 함, 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
  
  • 공용 인터넷 사용
    
    • 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 엔드포인트를 쓰는 게 훨씬 저렴함

11.  Network Protection on 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에 적용될 수 있음
    • VPC 수준에서 수천 개의 규칙 지원: IP, port, protocal, 상태 기반 도메인 목록 규칙 그룹, 정규식 매칭
    • 트래픽 필터링: 설정한 규칙과 일치하는 트래픽의 허용, 차단, 경고 등 설정
    • 침입 방지 기능을 갖춘 네트워크 위협에 대한 활성 플로우 검사 (게이트웨이 로드 밸런서와 유사, AWS에서 모두 관리)
      
    • 규칙 일치 로그를 Amazon S3, CloudWatch Logs, Kinesis Data Firehose로 전송하여 분석 가능