[AWS SAA] Virtual Private Cloud (VPC)

VPC Components Diagram

Understanding CIDR

CIDR 이해 – IPv4

CIDR(Classless Inter-Domain Routing, 사이더)는 클래스 없는 도메인 간 라우팅 기법으로 1993년 도입되기 시작한, 최신의 IP 주소 할당 방법입니다. CIDR는 기존의 IP 주소 할당 방식이었던 네트워크 클래스를 대체하였습니다.

• Classless Inter-Domain Routing – 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 주소)

Understanding CIDR – IPv4

• CIDR은 두 가지 구성 요소로 구성됩니다.
• 기본 IP
  • 범위(XX.XX.XX.XX)에 포함된 IP를 나타냅니다.
  • 예:10.0.0.0,192.168.0.0,...
• 서브넷 마스크
  • IP에서 변경할 수 있는 비트 수를 정의합니다.
  • 예:/0,/24,/32
  • 두 가지 형식을 취할 수 있습니다.
    • /8-255.0.0.0
    • /16~255.255.0.0
    • /24~255.255.255.0
    • /32~255.255.255.255

Understanding CIDR – Subnet Mask

• 서브넷 마스크는 기본적으로 기본 IP의 일부가 기본 IP에서 추가 다음 값을 얻을 수 있도록 허용합니다.

Understanding CIDR – Little Exercise

• 192.168.0.0/24 = ... ?
  • 192.168.0.0 – 192.168.0.255(256 IP)
• 192.168.0.0/16 = ... ?
  • 192.168.0.0 – 192.168.255.255(65,536 IP)
• 134.56.78.123/32 = ... ?
  • 그냥 134.56.78.123 - 0.0.0.0/0
• 모든 IP!

• 의심스러운 경우 이 웹사이트 https://www.ipaddressguide.com/cidr를 사용하십시오.

Public vs. Private IP (IPv4)

• IANA(Internet Assigned Numbers Authority)는 개인(LAN) 및 공용(인터넷) 주소 사용을 위해 특정 IPv4 주소 블록을 설정했습니다.
  .
• 개인 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 defaultVPC
  • 192.168.0.0 – 192.168.255.255(192.168.0.0/16) ç 예: 홈 네트워크
• 인터넷의 나머지 IP 주소는 모두 공용입니다.

---

기본 VPC 둘러보기

Amazon Virtual Private Cloud(Amazon VPC)를 이용하면 사용자가 정의한 가상 네트워크로 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 매우 유사합니다.

• 모든 새 AWS 계정에는 기본 VPC가 있습니다.
• 서브넷이 지정되지 않은 경우 새 EC2 인스턴스가 기본 VPC로 시작됩니다.
• 기본 VPC에는 인터넷 연결이 있으며 내부의 모든 EC2 인스턴스에는 퍼블릭 IPv4 주소가 있습니다.
• 공개 및 비공개 IPv4 DNS 이름도 얻습니다.

VPC in AWS – IPv4

• VPC = 가상 사설 클라우드
• AWS 지역에 여러 VPC가 있을 수 있습니다(지역당 최대 5개 – 소프트 제한).
• 최대. VPC당 CIDR은 5개입니다.
  • Min. 크기는 /28(IP 주소 16개)
  • Max. 크기는 /16(65536개의 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 – Subnet (IPv4)

• AWS는 각 서브넷에 5개의 IP 주소(처음 4개 및 마지막 1개)를 예약합니다.
• 이 5개의 IP 주소는 사용할 수 없으며 EC2 인스턴스에 할당할 수 없습니다.
• 예: 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는 aVPC에서 브로드캐스트를 지원하지 않으므로 주소가 예약되어 있습니다.
• 시험 팁, EC2 인스턴스에 대해 29개의 IP 주소가 필요한 경우:
• 크기가 /27인 서브넷은 선택할 수 없습니다(IP 주소 32개, 32 – 5 = 27 < 29).
• 크기가 /26인 서브넷을 선택해야 합니다(IP 주소 64개, 64 – 5 = 59 > 29).

실습 상태 State of Hands-on

• VPC 생성

Adding Subnets

• VPC에 해당하는 public, private subnet추가
  AZ에 소속하는 서브넷을 만들는데, 서브넷 중 5개는 기본할당됨.

Internet Gateway (IGW)

인터넷 게이트웨이는 수평 확장되고 가용성이 높은 중복 VPC 구성 요소로, VPC와 인터넷 간에 통신할 수 있게 해줍니다.

• VPC의 리소스(예: EC2 인스턴스)를 인터넷에 연결할 수 있습니다.
• 수평으로 확장되며 가용성이 높고 중복됩니다.
• VPC와 별도로 생성해야 함
• One VPC는 하나의 IGW에만 연결할 수 있으며 그 반대의 경우도 마찬가지입니다.
• 인터넷 게이트웨이 자체는 인터넷 액세스를 허용하지 않습니다...
• 경로 테이블도 편집해야 합니다!

인터넷 게이트웨이 추가

• VPC에 인터넷 Gateway를 만들었습니다.
  • 하지만 인터넷과 연결하려면 아래의 설정을 더 해야합니다.
    
    

라우팅 테이블 편집

• 공용 서브넷에 공용 EC2 인스턴스를 만들고 라우팅 테이블을 수정해서 EC2 인스턴스를 라우터에 연결하고 인터넷 Gateway에 연결합니다.
• 인터넷 게이트 웨이를 위한 0.0.0.0/0 추가
• 그러면 인터넷 Gateway가 인터넷과 연결될 수 있습니다

https://serverfault.com/questions/526857/use-of-0-0-0-0-as-default-gateway

Bastion Hosts

배스천 호스트(Bastion Host)란 침입 차단 소프트웨어가 설치되어 내부와 외부 네트워크 사이에서 일종의 게이트 역할을 수행하는 호스트입니다.

• 배스천 호스트를 사용하여 프라이빗 EC2 인스턴스에 SSH로 연결할 수 있습니다.
• 배스천은 퍼블릭 서브넷에 있으며 다른 모든 프라이빗 서브넷에 연결됩니다.
• 배스천 호스트 보안 그룹은 제한된 CIDR(예: 회사의 공용 CIDR)에서 포트 22의 인터넷으로부터의 인바운드를 허용₩해야 합니다.
• EC2 Instances의 보안 그룹은 Bastion Host의 Security Group 또는 Bastion 호스트의 사설 IP를 허용해야 합니다.

NAT Instance (outdated, but still at the exam)

네트워크 주소 변환을 제공하는 고유한 AMI를 생성하고 자신의 AMI를 사용하여 EC2 인스턴스를 NAT 인스턴스로 시작할 수 있습니다. 퍼블릭 서브넷에 있는 NAT 인스턴스를 시작하여 프라이빗 서브넷에 있는 인스턴스가 인터넷 또는 다른 AWS 서비스로의 아웃바운드 IPv4 트래픽을 시작하되, 인터넷에서 시작된 인바운드 트래픽은 인스턴스가 수신하지 못하게 막을 수 있습니다.

• NAT = 네트워크 주소 변환
• 프라이빗 서브넷의 EC2 인스턴스가 인터넷에 연결할 수 있도록 도와줍니다.
• 퍼블릭 서브넷에서 구동해야 합니다.
• EC2 설정을 비활성화해야 함: 소스/목적지 확인
• Elastic IP가 연결되어 있어야 합니다.
• 전용 서브넷에서 NAT 인스턴스로 트래픽을 라우팅하도록 RouteTable을 구성해야 합니다.

NAT Instance

• 공용 서브넷에 NAT 인스턴스를 생성하고 거기에 Elastic IP를 연결합니다
• 그리고 라우팅 테이블을 통해 사설 인스턴스가 NAT 인스턴스에서 인터넷 Gateway까지 통신하도록 합니다

NAT Instance – Comments

• 사전 구성된 Amazon Linux AMI 사용 가능
• 2020년 12월 31일에 표준 지원이 종료되었습니다.
• 즉시 사용 가능/복원력이 높지 않은 설정
• 다중 AZ + 탄력적인 사용자 데이터 스크립트에서 ASG를 생성해야 합니다.
• 인터넷 트래픽 대역폭은 EC2 인스턴스 유형에 따라 다름
• 보안 그룹 및 규칙을 관리해야 합니다.
  • 인바운드:
    • 프라이빗 서브넷에서 오는 HTTP/HTTPS 트래픽 허용
    • 홈 네트워크에서 SSH 허용(인터넷 게이트웨이를 통해 액세스 제공)
  • 아웃바운드:
    • 인터넷에 대한 HTTP/HTTPS 트래픽 허용

NAT Gateway

• AWS 관리형 NAT, 더 높은 대역폭, 고가용성, 관리 불필요
• 사용량 및 대역폭에 대해 시간당 지불
• NATGW는 특정 가용영역에 생성되며 Elastic IP를 사용
• 동일한 서브넷의 EC2 인스턴스에서 사용할 수 없음(다른 서브넷에서만 사용 가능)
• IGW 필요(Private Subnet => NATGW => IGW)
• 최대 45Gbps까지 자동 확장되는 5Gbps 대역폭
• 관리할 보안 그룹 없음/필수

NAT Gateway

NAT Gateway with High Availability

• NAT 게이트웨이는 단일 가용 영역 내에서 복원 가능합니다.
• 내결함성을 위해 여러 AZ에서 여러 NAT 게이트웨이를 만들어야 합니다.
• AZ가 다운되면 NAT가 필요하지 않기 때문에 교차 AZ 장애 조치가 필요하지 않습니다.

NAT Gateway vs. NAT Instance

---

Security Groups & NACLs

• NACL은 무상태 (인, 아웃 바운드 별개검사)
• Security Groups은 상태 유지 (특정 요청의 인 이나 아웃이 통과되면 통과)

Network Access Control List (NACL)

네트워크 액세스 제어 목록(ACL)은 서브넷 수준에서 특정 인바운드 또는 아웃바운드 트래픽을 허용하거나 거부합니다.

• NACL은 서브넷과 주고받는 트래픽을 제어하는 방화벽과 같습니다.
• 서브넷당 하나의 NACL, 새 서브넷에 기본 NACL이 할당됨
• NACL 규칙을 정의합니다.
  • 규칙에는 숫자(1~32766)가 있으며 숫자가 낮을수록 우선 순위가 높습니다.
  • 첫 번째 규칙 일치가 결정을 주도합니다.
  • 예: #100 ALLOW 10.0.0.10/32 및 #200 DENY 10.0.0.10/32를 정의하면 100이 200보다 우선 순위가 높기 때문에 IP 주소가 허용됩니다.
  • 마지막 규칙은 별표(*)이며 일치하는 규칙이 없을 경우 요청을 거부합니다.
  • AWS는 규칙을 100씩 추가할 것을 권장합니다.
• 새로 생성된 NACL은 모든 것을 거부합니다.
• NACL은 서브넷 수준에서 특정 IP 주소를 차단하는 좋은 방법입니다.

NACLs

• NACL은 서브넷 레벨이므로 서브넷마다 한개씩 있습니다.

Default NACL

• 기본 NACL은 연결된 서브넷으로 모든 인바운드/아웃바운드 허용하는 특수성을 가집니다.
• 기본 NACL을 수정하지 말고 대신 사용자 정의 NACL을 만드십시오.

Ephemeral Ports

• 두 엔드포인트(서버/클라이언트)가 연결을 설정하려면 포트를 사용해야 합니다.
• 클라이언트는 정의된 포트에 연결하고 임시 포트에서 응답을 기대합니다.
• 서로 다른 운영 체제는 서로 다른 포트 범위를 사용합니다.
  예:
• IANA&MSWindows10 49152–65535
• 많은 Linux 커널 32768 – 60999

• 클라이언트에 이렇게 IP가 있고 한 번의 요청 또는 연결에만 임시 포트 50105를 개방하려고 합니다
• 클라이언트에서 서버로 전송된 요청에는 목적지 IP 정보와 서버가 연결할 목적지 포트 그리고 요청과 관련된 페이로드가 있습니다
• 그런데 src IP는 응답을 위한 것이고 src port가 응답을 위한 소스 임시 포트입니다
• 포트인 50105입니다 그리고 웹 서버가 다시 회신을 위해서 클라이언트와 연결될 때 이런 응답을 보냅니다
• 소스 IP와 소스 포트 정보 그리고 서버 포트 정보가 있고 목적지 IP는 11.22.33.44입니다
• 임시 포트라고 불리는 것은 연결 수명을 위해서만 할당되는 무작위 포트이기 때문입니다

NACL with Ephemeral Ports

• 클라이언트가 데이터베이스에 연결된다고 생각하겠습니다
• 여기 사설 및 공용 서브넷이 있고 각 서브넷에 연결된 NACL이 하나 있습니다
• 바로 웹 NACL과 DB NACL입니다 클라이언트가 데이터베이스 인스턴스에 연결을 시작하면
• 허용되어야 하는 규칙은 무엇이 있을까요?
• 첫 번째 NACL은 포트 3306를 통해 TCP부터 데이터베이스의 서브넷 CIDR까지 아웃바운드를 허용해야 합니다
• 그렇지 않으면 요청이 서브넷을 떠나지 않을 겁니다 데이터베이스 측에서는 DB NACL가 웹 서브넷 CIDR에서 포트 3306으로
• TCP를 인바운드할 것입니다 이해가 되셨을까요? 여기가 복잡한 부분입니다
• 데이터베이스가 클라이언트로 요청에 회신을 할 때 무슨 일이 생길까요?
• 클라이언트에게는 임시 포트가 있습니다 그래서 이 요청에 대해 무작위 포트가 할당됩니다 그러면 DB NACL은 포트 및 임시 포트에서 아웃바운드 TCP를 허용하는데 범위는 1,024에서 65,535입니다
• 웹 서브넷 CIDR로 아웃바운드 되면 웹 NACL은 DB 서브넷 CIDR의 임시 포트 범위에서 인바운드 TCP를 허용해야 합니다 그래서 임시 포트를 제대로 구성하는 것이 정말 중요합니다.

Create NACL rules for each target subnets CIDR

NACL의 또 다른 특징은 다중 NACL 및 서브넷이 있다면 각 NACL 조합이 NACL 내에서 허용되어야 한다는 것입니다

• CIDR 사용 시, 서브넷이 고유의 CIDR을 갖기 때문이죠
• 그리고 이 부분을 꼭 이해해야합니다.
• NACL에 서브넷을 추가하면 NACL 규칙도 업데이트해서 연결 조합이 가능한지 확인해야만 합니다

Security Group vs. NACLs

---

VPC Peering

• AWS 네트워크를 사용하여 두 개의 VPC를 비공개로 연결
• 동일한 네트워크에 있는 것처럼 작동하도록 합니다.
• 겹치는 CIDR이 없어야 합니다.
• VPC 피어링 연결은 전환되지 않습니다.
  (서로 통신해야 하는 각 VPC에 대해 설정해야 함)
• EC2 인스턴스가 서로 통신할 수 있도록 각 VPC의 서브넷에서 라우팅 테이블을 업데이트해야 합니다.

VPC Peering – Good to know

• 여러분의 계정에서 할 수 있지만 다른 계정 간에도 가능합니다.
• 서로 다른 AWS에 있는 VPC 간에 VPC 피어링 연결을 생성할 수 있습니다.
  계정/지역
• 피어링된 VPC에서 보안 그룹을 참조할 수 있습니다(여러 계정에서 작동 - 동일한 지역).

VPC Peering

---

VPC Endpoints

AWS에서 DynamoDB와 같은 서비스를 이용한다고 하면 퍼블릭 액세스가 가능한데, 이것은 NAT Gateway나 인터넷 게이트웨이 또는 인터넷 게이트웨이를 통해 DynamoDB에 액세스할 수 있다는 겁니다.

• 하지만 이 모든 트래픽은 퍼블릭 인터넷을 거쳐서 오죠
• 그리고 CloudWatch와 Amazon S3 등의 서비스를 이용할 때는 인터넷을 경유하지 않고 프라이빗 액세스를 원할 수도 있을 텐데, 이때 VPC 엔드포인트를 사용하면 퍼블릭 인터넷을 거치지 않고도 인스턴스에 액세스할 수 있습니다

VPC Endpoints (AWS PrivateLink)

• 모든 AWS 서비스는 공개적으로 노출됩니다(공용 URL).
• VPC endpoint(AWS PrivateLink 제공)을 사용하면 공용 인터넷 대신 사설 네트워크를 사용하여 AWS 서비스에 연결할 수 있습니다.
• 중복되고 수평으로 확장됩니다.
• 그들은 IGW, NATGW, ...의 필요성을 제거합니다.
  AWS 서비스에 액세스하기 위해
• 문제가 있는 경우:
  • VPC에서 DNS 설정 확인 확인
  • CheckRouteTables

Types of Endpoints

• 인터페이스 엔드포인트(PrivateLink 제공)
  • ENI(사설 IP 주소)를 항목으로 프로비저닝(보안 그룹을 연결해야 함
  • 대부분의 AWS 서비스 지원
  • 시간당 $ + 처리된 데이터 GB당 $
• 게이트웨이 엔드포인트
  • 게이트웨이를 프로비저닝하고 라우트 테이블에서 대상으로 사용해야 합니다(보안 그룹을 사용하지 않음).
  • S3 및 DynamoDB 모두 지원
  • 무료

Gateway or Interface Endpoint for S3?

• 게이트웨이는 보통의 아키텍쳐에서 선호될 가능성이 높습니다.
• 비용: 게이트웨이는 무료, 인터페이스 엔드포인트는 $
• 인터페이스 엔드포인트는 온프레미스(사이트 간 VPN 또는 직접 연결), 다른 VPC 또는 다른 지역에서 기본 액세스가 필요합니다.

Lambda in VPC accessing DynamoDB

• DynamoDB는 AWS의 공용 서비스입니다.
• 옵션 1: 공용 인터넷에서 액세스
  • LambdaisinaVPC이므로 퍼블릭 서브넷의 NAT 게이트웨이와 인터넷 게이트웨이가 필요합니다.
• 옵션 2(더 좋고 무료): 비공개 VPC 네트워크에서 액세스
  • DynamoDB용 DeployaVPCGatewayendpoint
  • 경로 테이블 변경

---

VPC Flow Logs

VPC Flow Logs는 VPC의 네트워크 인터페이스에서 전송되고 수신되는 IP 트래픽에 대한 정보를 수집할 수 있는 기능입니다.

• 인터페이스로 들어가는 IP 트래픽에 대한 정보를 캡처합니다.
  • VPC 흐름 로그
  • 서브넷 흐름 로그
  • 탄력적 네트워크 인터페이스(ENI) 흐름 로그
• 연결 문제 모니터링 및 문제 해결 지원
• 흐름 로그 데이터는 S3/CloudWatch Logs로 이동할 수 있습니다.
• ELB, RDS, ElastiCache, Redshift,WorkSpaces, NATGW,Transit Gateway...와 같은 AWS 관리형 인터페이스에서도 네트워크 정보를 캡처합니다.

VPC Flow Logs

VPC Flow Logs Syntax

• srcaddr & dstaddr – 문제가 있는 IP 식별에 도움
• srcport 및 dstport – 문제가 있는 포트 식별 지원
• action - 보안 그룹/NACL로 인한 요청의 성공 또는 실패
• 사용 패턴 또는 악의적인 행동에 대한 분석에 사용할 수 있습니다.
• S3 Athena를 사용하여 VPC 흐름 로그 쿼리 또는 CloudWatch Logs Insights에서
• 흐름 로그 예: https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples.html

VPC Flow Logs – Troubleshoot SG & NACL issues

들어오는 요청

• 인바운드 REJECT => NACL 또는 SG 문제
• 인바운드 ACCEPT,아웃바운드REJECT=> NACL 문제

발신 요청

• 아웃바운드 거부 => NACL 또는 SG 문제
• 아웃바운드 ACCEPT,InboundREJECT=> NACL 문제

VPC Flow Logs – Architectures

• CloudWatch Logs로 전송된 흐름 로그는 CloudWatch Contributor Insights라는 기능을 사용하여 상위 10위에 해당하는 VPC 네트워크에 가장 많이 기여하는 IP 주소를 식별할 수 있습니다. ENI 등도 마찬가지고요

• CloudWatch Logs에 흐름 로그를 보내고 SSH나 RDP 프로토콜에 관하여 지표 필터를 설정할 수도 있습니다 평소보다 SSH나 RDP 프로토콜이 너무 많은 경우 CloudWatch 경보를 트리거하여 Amazon SNS 주제로 경보를 전송할 수 있습니다 네트워크에 수상한 행동이 발생했을 수 있으니까요

• VPC 흐름 로그를 모두 S3 버킷에 전송 및 저장해서 Amazon Athena를 이용하여 SQL로 VPC 흐름 로그를 분석할 수도 있습니다 Amazon QuickSight를 이용하면 시각화도 할 수 있죠

---

AWS Site-to-Site VPN

WS Site-to-Site VPN(Site-to-Site VPN) 연결을 생성하고 연결을 통해 트래픽을 전달하도록 라우팅을 구성하여 VPC에서 원격 네트워크에 대한 액세스를 활성화할 수 있습니다.

특정 구조가 있는 기업 데이터 센터를 AWS와 비공개로 연결하려면 기업은 고객 게이트웨이를 VPC는 VPN 게이트웨이를 갖춰야 합니다

• 공용 인터넷을 통해 사설 Site-to-Site VPN을 연결해야겠죠
• VPN 연결이라서 암호화돼 있습니다 공용 인터넷을 거치긴 하지만요

AWS Site-to-Site VPN

• 가상 프라이빗 게이트웨이(VGW)
  • VPN 연결의 AWS 측 VPN 집중 장치
  • VGW가 생성되어 Site-to-Site VPN 연결을 생성하려는 VPC에 연결됩니다.
  • ASN(Autonomous System Number) 커스터마이즈 가능
  • 자율 시스템(AS)은 명확하게 정의된 단일 라우팅 정책을 유지 관리하는 하나 이상의 네트워크 운영자가 실행하는 하나 이상의 IP 접두사(네트워크에서 액세스할 수 있는 IP 주소 목록) 그룹입니다.
• 고객 게이트웨이(CGW)
  • VPN 연결의 고객 측에 있는 소프트웨어 애플리케이션 또는 물리적 장치
  • https://docs.aws.amazon.com/vpn/latest/s2svpn/your-cgw.html#DevicesTested

Site-to-Site VPN Connections

• 고객 게이트웨이 장치(온프레미스)
  • 사용할 IP 주소는 무엇입니까?
    • cg가 public ip면 고객 게이트웨이 장치에 대한 공용 인터넷 라우팅 가능 IP 주소
    • cg가 private ip면 NAT 통과(NAT-T)가 활성화된 NAT 장치 뒤에 있는 경우 NAT 장치의 공용 IP 주소를 사용합니다.
• 중요한 단계: 서브넷과 연결된 라우팅 테이블에서 가상 프라이빗 게이트웨이에 대한 라우팅 전파를 활성화합니다.
• 온프레미스에서 EC2 인스턴스를 ping해야 하는 경우 보안 그룹의 인바운드에 ICMP 프로토콜을 추가해야 합니다.

AWS VPN CloudHub

• 여러 VPN 연결이 있는 경우 여러 사이트 간에 보안 통신 제공
• 서로 다른 위치 간의 기본 또는 보조 네트워크 연결을 위한 저비용 허브 앤 스포크 모델(VPN 전용)
• VPN 연결이므로 공용 인터넷을 통과합니다.

  • 설치 방법은 아주 간단합니다. 가상 프라이빗 게이트웨이 하나에 Site-to-Site VPN 연결을 여러 개 만들어 동적 라우팅을 활성화하고 라우팅 테이블을 구성하면 됩니다

---

Direct Connect (DX)

• 원격 네트워크에서 VPC로의 전용 비공개 연결을 제공합니다.
• DC와 AWS Direct Connect 위치 간에 전용 연결을 설정해야 합니다.
• VPC에 가상 프라이빗 게이트웨이를 설정해야 합니다.
• 동일한 연결에서 퍼블릭 리소스(S3) 및 프라이빗(EC2)에 액세스
• 사용 사례:
  • 대역폭 처리량 증가 - 대용량 데이터 세트 작업 - 비용 절감
  • 보다 일관된 네트워크 경험 - 실시간 데이터 피드를 사용하는 애플리케이션
  • 하이브리드 환경(온프레미스 + 클라우드)
• IPv4 및 IPv6 모두 지원

Direct Connect Diagram

리전을 기업 데이터 센터에 연결하려면 AWS Direct Connect 로케이션을 요청합니다 물리적인 위치 말이에요 AWS 웹사이트에 전부 나와 있습니다.

• Direct Connect 엔드포인트가 있습니다
• 고객이나 파트너 케이지(Cage)에서 빌려 와야 하는 고객 혹은 파트너 라우터도 이렇게 있고요
• Direct Connect 로케이션에 케이지 두 개가 있고 온프레미스 데이터 센터에는 방화벽이 있는 고객 라우터를 설치할 겁니다
• 먼저 프라이빗 가상 인터페이스 즉 프라이빗 VIF를 생성하여 VPC로 프라이빗 리소스에 액세스합니다 그러려면 모든 로케이션을 연결하는 프라이빗 VIF를 생성하여 가상 프라이빗 게이트웨이에 연결해야 합니다 가상 프라이빗 게이트웨이는 VPC에 연결되어 있죠
• 프라이빗 VIF를 통해서 EC2 인스턴스가 있는 프라이빗 서브넷에 액세스할 수 있습니다 보시다시피 모든 과정이 비공개로 처리되니까 수동으로 연결해야 하므로 설치만 한 달이 걸릴 수도 있습니다. 하지만 퍼블릭 인터넷을 전혀 지나지 않고 전부 비공개로 연결됩니다
• 그 대신 AWS 내 퍼블릭 서비스 가령 Amazon Glacier 또는 Amazon S3에 연결할 수도 있는데 이때는 퍼블릭 가상 인터페이스 즉 퍼블릭 VIF를 설치해야 합니다 결국 같은 경로를 지나가지만 가상 프라이빗 게이트웨이로 연결되지 않고 AWS로 직접 연결되는 겁니다.

Direct Connect Gateway

• 서로 다른 여러 지역(동일한 계정)에 있는 하나 이상의 VPC에 Direct Connect를 설정하려면 Direct Connect 게이트웨이를 사용해야 합니다.

Direct Connect – Connection Types

• 전용 연결: 1Gbps, 10Gbps 및 100Gbps 용량
  • 고객 전용 물리적 이더넷 포트
  • 먼저 AWS에 요청한 다음 AWS Direct Connect 파트너가 완료
• 호스팅 연결: 50Mbps, 500Mbps~10Gbps
  • 연결 요청은 AWS Direct Connect 파트너를 통해 이루어집니다.
  • 필요에 따라 용량을 추가하거나 제거할 수 있습니다.
  • 일부 AWS Direct Connect 파트너에서 1, 2, 5, 10Gbps 사용 가능
• 새로운 연결을 설정하는 데 소요되는 리드 타임은 종종 1개월 이상입니다.

Direct Connect – Encryption

• 전송 중인 데이터는 암호화되지 않지만 비공개입니다.
• AWS Direct Connect + VPN은 IPsec 암호화 프라이빗 연결을 제공합니다.
• 추가 보안 수준에 적합하지만 적용하기가 약간 더 복잡함

Direct Connect - Resiliency

• 핵심 워크로드의 복원력을 높이기 위해서는 여러 Direct Connect를 설치하는 것이 좋습니다
• 최대의 복원력을 달성하려면 여러 독립적인 연결을 하나 이상의 로케이션에서 각기 다른 장치에 도달하도록 구성하면 됩니다

Site-to-Site VPN connection as a backup

• Direct Connect가 실패하는 경우 백업 Direct Connect 연결(고가) 또는 Site-to-Site VPN 연결을 설정할 수 있습니다.

가령 회사 데이터 센터가 Direct Connect를 통해 VPC에 연결한다고 해 봅시다

• 이것이 기본 연결이죠 비용도 많이 들고 가끔은 Direct Connect 연결에 문제가 발생할 수도 있습니다
• 당연하게도 VPC에서 인터넷 연결이 없는 경우는 피하고 싶겠죠 이런 경우 또 다른 Direct Connect로 보조 연결을 할 수 있지만 비용이 상당히 많이 들겠죠
• 또는 Site to Site VPN을 백업 연결을 두어 기본 연결에 문제가 발생했을 때 이 연결을 사용하면 Site to Site VPN을 통해 퍼블릭 인터넷에 연결할 수 있으므로 안정성이 높아집니다 퍼블릭 인터넷에 언제나 연결되어 있을 테니까요

---

Network topologies can become complicated

• 너무 복잡..

---

Transit Gateway

그래서 이게 탄생!

• 수천 개의 VPC와 온프레미스 간 전환 피어링, 허브 앤 스포크(스타) 연결
• 지역 리소스, 지역 간 작업 가능
• RAM(Resource Access Manager)을 사용하여 교차 계정 공유
• 여러 지역에서 Transit Gateway를 피어링할 수 있습니다.
• 경로 테이블: VPC가 다른 VPC와 통신할 수 있는 제한
• Direct Connect 게이트웨이, VPN 연결과 함께 작동
• IP 멀티캐스트 지원(다른 AWS 서비스에서는 지원하지 않음)

Transit Gateway: Site-to-Site VPN ECMP

• ECMP = 동일 비용 다중 경로 라우팅
• 여러 최상의 경로를 통해 패킷을 전달할 수 있는 라우팅 전략
• 사용 사례: 여러 Site-to-Site VPN 연결을 생성하여 AWS 연결 대역폭 증가

Transit Gateway: ECMP를 사용한 처리량

Transit Gateway – 여러 계정 간에 Direct Connect 공유

• Transit Gateway를 서로 다른 계정의 VPC 두 개 모두에 생성합니다
• Transit Gateway로 이런 작업이 가능해요 Direct Connect 로케이션에 연결한 Direct Connect Gateway를 Transit Gateway에 연결하면 여러 계정과 VPC 사이에 Direct Connect 연결을 공유할 수 있게 됩니다

---

VPC – Traffic Mirroring

트래픽 미러링은 유형의 탄력적 네트워크 인터페이스에서 네트워크 트래픽을 복사하는 데 사용할 수 있는 Amazon VPC 기능입니다 interface. 그런 다음 다음을 위해 트래픽을 대역 외 보안 및 모니터링 어플라이언스로 보낼 수 있습니다.

• VPC에서 네트워크 트래픽을 캡처하고 검사할 수 있습니다.
• 관리하는 보안 어플라이언스로 트래픽 라우팅
• 트래픽 캡처
  • From(소스) – ENI
  • 대상(대상) – ENI 또는 Network Load Balancer
• 모든 패킷을 캡처하거나 원하는 패킷을 캡처합니다(선택적으로 패킷 자르기).
• 원본과 대상은 동일한 VPC 또는 다른 VPC(VPC 피어링)에 있을 수 있습니다.
• 사용 사례: 콘텐츠 검사, 위협 모니터링, 문제 해결 등

---

What is IPv6?

• 43억 개의 주소를 제공하도록 설계된 IPv4(곧 고갈됨)
• IPv6는 IPv4의 후속 제품입니다.
• IPv6은 3.4 × 10+의 고유한 IP 주소를 제공하도록 설계되었습니다.
• 모든 IPv6 주소는 공용이며 인터넷 라우팅이 가능합니다(개인 범위 없음).
• 형식 è 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 세그먼트는 0입니다.
  • 2001:db8:: -> 마지막 6개 세그먼트는 0입니다.
  • ::1234:5678 -> 처음 6개 세그먼트는 0입니다.
  • 2001:db8::1234:5678 -> 중간 4개 세그먼트는 0입니다.

IPv6 in VPC

• VPC 및 서브넷에 대해 IPv4를 비활성화할 수 없습니다.
• 이중 스택 모드에서 작동하도록 IPv6(공개 IP 주소임)를 활성화할 수 있습니다.
• EC2 인스턴스는 최소한 프라이빗 내부 IPv4 및 퍼블릭 IPv6을 갖게 됩니다.
• IPv4 또는 IPv6를 사용하여 인터넷 게이트웨이를 통해 인터넷과 통신할 수 있습니다.

IPv6 Troubleshooting

• VPC 및 서브넷에 대해 IPv4를 비활성화할 수 없습니다.
• 따라서 서브넷에서 EC2 인스턴스를 시작할 수 없는 경우
• IPv6를 획득하지 못해서가 아님(공간이 매우 넓음)
• 서브넷에 사용 가능한 IPv4가 없기 때문입니다.
• 솔루션: 서브넷에 새 IPv4 CIDR 생성

Egress-only Internet Gateway

• IPv6에만 사용됨
• (NAT 게이트웨이와 유사하지만 IPv6용)
• 인터넷이 인스턴스에 대한 IPv6 연결을 시작하는 것을 방지하면서 IPv6을 통한 VPC 아웃바운드 연결의 인스턴스를 허용합니다.
• 경로 테이블을 업데이트해야 합니다.

IPv6 Routing

---

VPC Section Summary (1/3)

• CIDR – IP 범위
• VPC – Virtual Private Cloud => IPv4 및 IPv6 CIDR 목록을 정의합니다.
• 서브넷 – AZ에 연결되어 CIDR을 정의합니다.
• 인터넷 게이트웨이 – VPC 수준에서 IPv4 및 IPv6 인터넷 액세스 제공
• RouteTables – 서브넷에서 IGW,VPC 피어링 연결,VPC 끝점, ...에 대한 경로를 추가하려면 편집해야 합니다.
• 배스천 호스트 – 프라이빗 서브넷의 EC2 인스턴스에 대한 SSH 연결이 있는 SSH에 대한 퍼블릭 EC2 인스턴스
• NAT 인스턴스 – 프라이빗 서브넷의 EC2 인스턴스에 대한 인터넷 액세스를 제공합니다. 이전, 퍼블릭 서브넷에서 설정해야 함, 소스/대상 체크 플래그 비활성화
• NAT 게이트웨이 – AWS에서 관리하며 프라이빗 EC2 인스턴스(IPv4 전용)에 대한 확장 가능한 인터넷 액세스를 제공합니다.
• 프라이빗 DNS + Route 53 – DNS 확인 활성화 + DNS 호스트 이름(VPC)

VPC Section Summary (2/3)

• NACL – 인바운드 및 아웃바운드에 대한 상태 비저장 서브넷 규칙, 임시 포트를 잊지 마십시오.
• 보안 그룹 – 상태 저장, EC2 인스턴스 수준에서 작동
• 도달 가능성 분석기 – AWS 리소스 간의 네트워크 연결 테스트 수행
• VPC 피어링 – 겹치지 않는 CIDR, 비전이성을 사용하여 두 개의 VPC를 연결합니다.
• VPC 엔드포인트 – VPC 내에서 AWS 서비스(S3, DynamoDB, CloudFormation, SSM)에 대한 비공개 액세스를 제공합니다.
  • Amazon S3와 DynamoDB는 게이트웨이 엔드 포인트로 사용
  • 나머지 인터페이스
• VPC 흐름 로그 – ACCEPT 및 REJECT 트래픽에 대해 VPC/서브넷/ENI 수준에서 설정할 수 있으며, 공격을 식별하고 Athena 또는 CloudWatch Logs Insights를 사용하여 분석하는 데 도움이 됩니다.
• Site-to-SiteVPN – DC의 고객 게이트웨이, VPC의 가상 프라이빗 게이트웨이 및 공용 인터넷을 통한 사이트 간 VPN 설정, VPG를 통해 연결을 여러개 생성하려면 cloudHub를 활용해서 허브와 스포크 간 VPN모델로 사이트 연결
• AWS VPN CloudHub – 사이트 연결을 위한 허브 앤 스포크 VPN 모델

VPC Section Summary (3/3)

• Direct Connect – VPC에서 가상 프라이빗 게이트웨이를 설정하고 AWS Direct Connect 위치에 직접 프라이빗 연결을 설정합니다.
• Direct Connect 게이트웨이 – 서로 다른 AWS 지역의 여러 VPC에 대한 Direct Connect 설정
• AWS PrivateLink/VPC 엔드포인트 서비스:
  • 서비스 VPC에서 고객 VPC로 비공개로 서비스 연결
  • VPC 피어링, 공용 인터넷, NAT 게이트웨이, 라우팅 테이블이 필요하지 않습니다.
  • Network Load Balancer 및 ENI와 함께 사용해야 합니다.
  • VPC가 있는 서비스를 수백, 수천 고객 VPC에 노출할 수 있습니다 네트워크를 드러내지 않은 채로요
• ClassicLink – EC2-Classic EC2 인스턴스를 VPC에 비공개로 연결
• Transit Gateway – VPC, VPN 및 DX를 위한 전이적 피어링 연결
• 트래픽 미러링 – 추가 분석을 위해 ENI에서 네트워크 트래픽 복사
• 외부 전용 인터넷 게이트웨이 – NAT 게이트웨이와 비슷하지만 IPv6용

---

GB당 AWS의 네트워킹 비용 - 단순화됨

• 비용 절감 및 네트워크 성능 향상을 위해 공용 IP 대신 사설 IP 사용
• 최대 절약을 위해 동일한 AZ 사용(고가용성을 희생)

---

송신 트래픽 네트워크 비용 최소화

• 엔그레스 트래픽: 아웃바운드 트래픽(AWS에서 외부로)
• 인그레스 트래픽: 인바운드 트래픽 - 외부에서 AWS로(일반적으로 무료)
• 비용을 최소화하기 위해 AWS 내에서 최대한 많은 인터넷 트래픽을 유지하려고 합니다.
• 동일한 AWS 지역에 있는 Direct Connect 위치로 인해 송신 네트워크 비용이 절감됩니다.

S3 Data Transfer Pricing – Analysis for USA

• S3 ingress: 무료
• S3에서 인터넷으로: GB당 $0.09
• S3 Transfer Acceleration:
  • 빠른 전송 시간(50~500% 향상)
  • 데이터 전송 시 추가 비용: GB당 +$0.04 ~ $0.08
• S3에서 CloudFront로: GB당 $0.00
• CloudFront에서 인터넷으로: GB당 $0.085
  (S3보다 약간 저렴)
  • 캐싱 기능(낮은 대기 시간)
  • S3 요청 요금과 관련된 비용 절감(CloudFront로 7배 저렴)
• S3 교차 지역 복제: GB당 $0.02

---

Pricing: NAT Gateway vs Gateway VPC Endpoint

Network Protection on AWS

• AWS에서 네트워크를 보호하기 위해 우리는
  • 네트워크 액세스 제어 목록(NACL)을 확인했습니다.
  • Amazon VPC 보안 그룹
  • AWS WAF(악의적인 요청으로부터 보호)
    • HTTP를 통하여 특정 서비스에 유입되는 악성 요청을 막는 방화벽
  • AWS 실드 및 AWS 실드 어드밴스드
    • ddos
  • AWS Firewall Manager(계정 전체에서 관리)
• 그러나 전체 VPC를 정교한 방식으로 보호하려면 어떻게 해야 합니까?

AWS Network Firewall

• 전체 Amazon VPC 보호
• 레이어 3에서 레이어 7 보호
• 모든 방향에서 검사 가능
  • VPC to VPC traffic
  • 인터넷으로 아웃바운드
  • 인터넷에서 인바운드
  • Direct Connect & Site-to-Site VPN으로/에서
• 내부적으로 내부적으로 Network Firewall은 AWS Gateway Load Balancer를 사용합니다
• 여러 VPC에 적용할 수 있도록 AWS Firewall Manager에서 교차 계정으로 규칙을 중앙에서 관리할 수 있습니다.

Network Firewall – Fine Grained Controls

• 1000가지 규칙 지원
  • IP 및 포트 - 예: 10,000개의 IP 필터링
  • 프로토콜 – 예: 아웃바운드 통신을 위한 SMB 프로토콜 차단
  • 상태 저장 도메인 목록 규칙 그룹: *.mycorp.com 또는 타사 소프트웨어 저장소에 대한 아웃바운드 트래픽만 허용
  • regex를 사용한 일반 패턴 매칭
• 트래픽 필터링: 규칙과 일치하는 트래픽을 허용, 삭제 또는 경고합니다.
• 침입 방지 기능(Gateway Load Balancer와 같지만 모두 AWS에서 관리)으로 네트워크 위협으로부터 보호하기 위한 활성 흐름 검사
• 규칙 일치 로그를 Amazon S3, CloudWatch Logs, Kinesis Data Firehose로 전송

---

AWS Certified Solutions Architect Associate 시험합격!