AWS 네트워크

Siyun·2025년 3월 17일
aws

AWS

목록 보기
31/37

CIDR (Classless Inter-Domain Routing)

CIDR는 클래스 없는 도메인 간 라우팅을 의미하며, IP 주소를 효율적으로 할당하고 네트워크를 세분화하는 방식이다. AWS의 보안 그룹 규칙을 설정할 때, 소스 IP를 CIDR 형식으로 입력하는 것을 볼 수 있다. 예를 들어, 0.0.0.0/0은 모든 IP를 의미하며, /32로 끝나는 IP 주소는 단일 IP를 나타낸다.

CIDR의 구성 요소

CIDR는 기본 IP와 서브넷 마스크라는 두 가지 요소로 구성된다.

  • 기본 IP: 네트워크 범위의 시작점이며, 예를 들어 10.0.0.0 또는 192.168.0.0과 같은 주소가 이에 해당한다.

  • 서브넷 마스크: 변경 가능한 비트 수를 나타내며, CIDR 표기법에서 슬래시(/) 뒤의 숫자로 표현된다.
    /8 → 255.0.0.0
    /16 → 255.255.0.0
    /24 → 255.255.255.0

  • CIDR 표기법에서 슬래시(/) 뒤의 숫자는 네트워크에 할당된 비트 수를 의미한다. 나머지 비트는 호스트 IP로 활용할 수 있다.
    예) /32일 경우 단일 IP이다.

공용 IP vs 사설 IP

  • Internet Assigned Numbers Authority(IANA)에서 구축한 특정 IPv4 주소 블록은 사설 LAN 네트워크, 다시 말해 로컬 네트워크나 공용 인터넷 주소이다.

  • 사설 IP는 내부 네트워크에서만 사용된다. 사설 IP 주소 범위는 다음과 같다.

10.0.0.0/8 → 대규모 네트워크에서 사용
172.16.0.0/12 → AWS 기본 VPC에서 사용
192.168.0.0/16 → 가정 및 소규모 네트워크에서 사용
사설 IP는 인터넷 라우터를 통해 공용 IP로 변환되며, NAT(Network Address Translation)를 활용하여 외부와 통신한다

기본 VPC 살펴보기

기본 VPC 개요

새로운 AWS 계정에는 기본적으로 기본 VPC(Default VPC) 가 생성되며, 바로 사용할 수 있다. 새로운 EC2 인스턴스를 생성할 때 서브넷을 지정하지 않으면 기본 VPC에서 실행된다.

기본 VPC는 처음부터 인터넷과 연결되어 있어, EC2 인스턴스가 공용 IPv4 주소를 자동으로 할당받아 인터넷에 액세스할 수 있다. 또한, 공용 및 사설 IPv4 DNS 이름도 제공된다. 이러한 설정 덕분에 EC2 인스턴스를 생성하자마자 즉시 접속할 수 있다.

기본 VPC 확인하기

  1. AWS 콘솔에서 VPC 서비스로 이동

    • "Your VPCs" 메뉴에서 현재 계정에 생성된 VPC를 확인할 수 있다.
    • 기본적으로 하나의 VPC만 생성되며, 일반적으로 별도의 이름이 지정되지 않는다.

  2. 기본 VPC의 주요 설정

    • IPv4 CIDR 블록: 기본 VPC의 CIDR 범위를 확인할 수 있다.
    • 기본 VPC의 IPv4 CIDR은 /16 블록을 사용하며, 이를 통해 총 65,536개의 IP 주소를 생성할 수 있다.
    • IPv6 CIDR은 기본적으로 활성화되지 않으며, 플로우 로그도 비활성화된 상태이다.

서브넷 개요

기본 VPC에는 세 개의 서브넷이 자동으로 생성된다.

  • 각 서브넷은 서로 다른 가용 영역(AZ)에 배치되어 있어 가용성을 높일 수 있다.
  • 서브넷마다 고유한 IPv4 CIDR 블록이 할당되며, 서브넷의 IPv4 CIDR 블록 크기는 /20이다.
  • /20 블록은 총 4,096개의 IP 주소를 제공하지만, 실제로 사용 가능한 IP는 4,091개이다.
    • AWS가 서브넷 내에서 내부적으로 사용하는 5개의 IP 주소(네트워크 주소, 브로드캐스트 주소 등)를 예약하기 때문이다.

기본 서브넷과 네트워크 설정

  • 기본 VPC의 서브넷에는 자동 할당 공용 IPv4 주소 옵션이 활성화되어 있다.
    • 기본 서브넷에서 생성된 EC2 인스턴스는 공용 IPv4 주소를 자동으로 할당받아 인터넷에 연결될 수 있다.
  • 네트워크 ACL(Access Control List)은 기본적으로 모든 트래픽을 허용하는 상태이다.
  • 라우팅 테이블(Route Table)은 기본적으로 하나가 생성되며, 이 라우팅 테이블이 기본적으로 모든 서브넷에 적용된다.

라우팅 테이블과 인터넷 게이트웨이

라우팅 테이블은 VPC 내 트래픽의 경로를 정의하는 역할을 한다.

  • 기본 라우팅 테이블에는 두 개의 규칙이 있다.
    1. VPC 내부 트래픽은 VPC 내에서 라우팅된다.
    2. CIDR 범위 외부 트래픽(인터넷으로 나가는 트래픽)은 인터넷 게이트웨이(Internet Gateway, IGW)를 통해 전송된다.
  • 인터넷 게이트웨이는 기본적으로 VPC에 연결되어 있으며, 이를 통해 EC2 인스턴스가 인터넷에 액세스할 수 있다.

VPC 개요

Virtual Private Cloud(VPC) 는 AWS에서 제공하는 가상 네트워크 환경이다.

  • 단일 AWS 리전에는 최대 5개의 VPC를 생성할 수 있다.
  • 기본 한도는 5개지만, 필요에 따라 한도를 늘릴 수 있다.

VPC의 CIDR 블록

각 VPC에는 최대 5개의 CIDR 블록을 할당할 수 있다.

  • CIDR 최소 크기: /28 (총 16개의 IP 주소 제공)
  • CIDR 최대 크기: /16 (총 65,536개의 IP 주소 제공)
  • VPC는 사설 네트워크이므로 사설 IPv4 범위만 허용된다.

사용할 수 있는 사설 IPv4 범위는 다음과 같다.
1. 10.0.0.0/8
2. 172.16.0.0/12
3. 192.168.0.0/16

VPC의 CIDR 범위 선택

VPC의 CIDR 블록을 선택할 때 고려해야 할 사항은 다음과 같다.

  • IP 주소 크기: 사용하려는 인스턴스 수를 고려하여 CIDR 크기를 설정해야 한다.
  • 네트워크 간 충돌 방지:
    • 다른 VPC 또는 온프레미스 네트워크와 IP 범위가 겹치지 않도록 주의해야 한다.
    • VPC를 피어링하거나 VPN, Direct Connect 등을 통해 연결할 경우 CIDR 블록이 충돌하면 정상적으로 통신할 수 없다.

VPC 생성 실습

  1. AWS 콘솔에 접속한다.
  2. VPC 서비스 메뉴로 이동한다.
  3. 기존 VPC가 있더라도 새 VPC 생성을 선택한다.
  4. 이름 태그를 "DemoVPC"로 지정한다.
  5. IPv4 CIDR 블록은 10.0.0.0/16으로 선택한다.
    • /15 등 너무 큰 범위는 허용되지 않는다. CIDR 제한은 /16 까지다. (aws에서는 /16 ~ /28 서브넷 마스크 허용)
  6. IPv6 CIDR 블록은 이번 실습에서는 할당하지 않는다.
  7. Tenancy 항목에서는 기본(Default, 공유 하드웨어)을 선택한다.
  8. Tags 항목에 이름을 입력한 후 VPC를 생성한다.
  9. 생성 후 VPC 목록에서 DemoVPC의 IPv4 CIDR가 한 개, IPv6 CIDR은 없는 것을 확인한다.
  10. 기본 라우팅 테이블과 기본 네트워크 ACL은 VPC 생성 시 자동으로 생성된다.
  11. 추가적으로 IPv4 CIDR를 할당하고 싶다면, Actions 메뉴에서 Edit CIDRs를 선택한 후 10.1.0.0/16과 같이 추가 CIDR을 입력하고 Save를 클릭한다. 같은 방법으로 IPv6 CIDRs도 추가 가능하다.
  12. IPv4 CIDR는 한 VPC에 최대 다섯 개까지 할당할 수 있으므로 필요에 따라 활용할 수 있다.

VPC 서브넷

서브넷의 개념과 예약된 IP 주소에 대해 정리하면 다음과 같다.

  1. 서브넷이란

    • VPC 내부에서 특정 IPv4 주소 범위를 가지는 네트워크이다.
    • AWS에서는 서브넷마다 IP 주소 다섯 개를 예약한다.

  2. 예약된 IP 주소

    • 서브넷의 첫 번째 네 개와 마지막 한 개의 IP 주소는 예약되어 사용되지 않는다.
    • 예를 들어, CIDR 블록이 10.0.0.0/24인 경우:
      • 10.0.0.0 → 네트워크 주소
      • 10.0.0.1 → VPC 라우터용
      • 10.0.0.2 → Amazon 제공 DNS에 매핑됨
      • 10.0.0.3 → AWS에서 예약 (현재 사용되지 않음)
      • 10.0.0.255 → 네트워크 브로드캐스트 주소 (VPC에서는 브로드캐스트 미지원)

  3. 서브넷 크기 결정

    • 서브넷 크기는 CIDR 블록의 서브넷 마스크 길이로 결정된다.
    • IP 주소 개수에서 예약된 다섯 개를 제외한 후 남은 개수를 고려해야 한다.
    • 예시:
      • /27 서브넷의 경우 총 32개의 IP가 있지만, 5개를 빼면 27개가 남는다.
      • 만약 서브넷에서 29개의 IP가 필요하다면 /27은 부족하므로 /26을 선택해야 한다.

서브넷 생성 실습

서브넷 생성 과정과 개념을 정리하면 다음과 같다.

  1. 서브넷 목록 확인 및 필터링

    서브넷 메뉴 좌측에서 특정 VPC에 속한 서브넷만 보이도록 필터링할 수 있다.

  2. 공용 서브넷(Public Subnet) 생성
    서브넷은 하나 설정하고 Add new subnet 눌러서 한번에 여러개를 만들 수 있다.

    • PublicSubnetA
      • 가용 영역(AZ): eu-central-1a
      • IPv4 CIDR 블록: 10.0.0.0/24
      • 사용 가능한 IP 주소: 10.0.0.1 ~ 10.0.0.254 (예약된 5개 제외)
    • PublicSubnetB
      • 가용 영역(AZ): eu-central-1b
      • IPv4 CIDR 블록: 10.0.1.0/24
      • 사용 가능한 IP 주소: 10.0.1.1 ~ 10.0.1.254

  3. 사설 서브넷(Private Subnet) 생성

    • PrivateSubnetA
      • 가용 영역(AZ): eu-central-1a
      • IPv4 CIDR 블록: 10.0.16.0/20
      • 사용 가능한 IP 주소: 10.0.16.1 ~ 10.0.31.254
    • PrivateSubnetB
      • 가용 영역(AZ): eu-central-1b
      • IPv4 CIDR 블록: 10.0.32.0/20
      • 사용 가능한 IP 주소: 10.0.32.1 ~ 10.0.47.254

  4. 서브넷 생성 결과 확인

    • 총 4개의 서브넷을 생성하였다.
    • 각 서브넷의 사용 가능한 IP 주소 개수는 CIDR 크기에서 5개 예약된 IP를 제외한 값이다.
      • /24 서브넷: 256 - 5 = 251개
      • /20 서브넷: 4,096 - 5 = 4,091개
    • 서브넷을 두 개의 가용 영역(AZ)에 분산하여 고가용성(HA, High Availability)을 고려하였다.

  5. 공용 서브넷과 사설 서브넷의 차이점

    • 현재 생성한 서브넷들은 외부에서 보기에는 동일해 보인다.
    • 공용 서브넷과 사설 서브넷을 구분하는 기준은 이후 강의에서 다룰 예정이다.

인터넷 게이트웨이

  1. 현재 상태

    • 공용 서브넷과 사설 서브넷이 있지만, 아직 인터넷 액세스가 없음.
    • 인터넷 Gateway(IGW)가 없기 때문에 VPC 내의 리소스가 인터넷과 연결되지 않음.

  2. 인터넷 Gateway(IGW)란?

    • VPC 내 리소스를 인터넷에 연결할 수 있도록 허용하는 관리형 서비스.
    • 수평 확장되며 고가용성(HA)과 중복성(Redundancy)을 제공.
    • 별도로 생성해야 하며, VPC 하나는 하나의 IGW에만 연결 가능.
    • IGW 자체만으로는 인터넷 액세스를 제공하지 않으며, 라우팅 테이블 수정이 필요함.

  3. 인터넷 액세스를 제공하는 과정

    • 1단계: VPC에 인터넷 Gateway 생성.
    • 2단계: 인터넷 Gateway를 VPC에 연결.
    • 3단계: 공용 서브넷에서 사용할 라우팅 테이블 수정.
    • 4단계: 공용 서브넷에 EC2 인스턴스 생성.
    • 5단계: EC2 인스턴스의 라우팅을 IGW를 통해 인터넷과 연결.

  4. 결과

    • 공용 서브넷: IGW와 연결되어 외부 인터넷과 통신 가능.
    • 사설 서브넷: 여전히 인터넷 액세스 없음 (추후 NAT Gateway 등을 활용 가능).

퍼블릭 서브넷의 EC2 인스턴스에 인터넷 액세스 연결하기

  1. EC2 인스턴스 인터넷 연결 여부 확인

    • EC2 콘솔 이동 후 인스턴스 생성
    • Amazon Linux 2, t2.micro 선택
    • VPC(DemoVPC) 및 퍼블릭 서브넷(PublicSubnetA) 선택
    • Auto-assign Public IP(자동 퍼블릭 IP 할당) 옵션이 비활성화됨

  2. 퍼블릭 IP 자동 할당 활성화

    • 서브넷 설정 변경 (PublicSubnetA & PublicSubnetB)
    • Actions → Edit subnet settings → 퍼블릭 IPv4 주소 자동 할당 활성화
    • EC2 인스턴스 재생성 후 자동 할당된 퍼블릭 IP 확인

  3. 보안 그룹 설정 및 EC2 인스턴스 실행

    • SSH 접속을 위해 포트 22에 규칙 추가
    • EC2 인스턴스 실행 후 퍼블릭 IPv4 주소 확인
    • 그러나 여전히 인터넷 연결 안 됨. 인터넷 게이트웨이 연결이 안되어있기 때문임.

  4. 인터넷 게이트웨이(IGW) 생성 및 VPC 연결

    • 인터넷 게이트웨이(DemoIGW) 생성
    • Attach to a VPC를 클릭해 IGW를 DemoVPC에 연결

  5. 라우팅 테이블 수정

    • 새로운 라우팅 테이블 2개 생성
      • PublicRouteTable: 퍼블릭 서브넷 연결. PubilcRouteTable의 Subnet Associations에서 Edit로 수정하여 PublicSubnet A와 B를 추가하고 저장한다.
      • PrivateRouteTable: 프라이빗 서브넷 연결. PrivateRouteTable에도 마찬가지로 PrivateSubnet A,B를 추가하고 저장한다.
    • 서브넷이 전부 할당되었기 때문에 기존 기본 라우팅 테이블에는 서브넷이 없다.

  6. 퍼블릭 라우팅 테이블 수정

    • 기존
      • 10.0.0.0/16 → Local (VPC 내부의 모든 IP가 로컬로 라우팅)
    • 경로 추가:
      • 0.0.0.0/0 → Internet Gateway (외부 인터넷 연결)

  7. EC2 인스턴스에서 인터넷 연결 확인

    • EC2 Instance Connect로 접속 시 정상 연결
    • ping google.com 테스트 → 정상 응답

배스천 호스트(Bastion Hosts)

배스천 호스트는 퍼블릭 서브넷에 있는 EC2 인스턴스이다.
배스천 호스트 보안 그룹이라는 자체 보안 그룹이 있다.

  • 프라이빗 서브넷의 EC2 인스턴스는 인터넷에 직접 액세스할 수 없음.
  • 퍼블릭 인터넷에 위치한 사용자가 배스천 호스트(퍼블릭 서브넷에 위치한 EC2)를 통해 프라이빗 EC2에 접근 가능.
  • 접근 방식:
    1. 사용자가 SSH로 배스천 호스트에 접속.
    2. 배스천 호스트가 SSH로 프라이빗 EC2에 접속.
  • 보안 그룹 설정 중요:
    • 배스천 호스트: 인터넷에서 접근 가능하지만 특정 IP(CIDR)만 허용해야 보안 강화됨.
    • 프라이빗 EC2: 배스천 호스트에서의 SSH(포트 22) 접근만 허용해야 함.
  • 보안 미흡 시 공격자가 배스천 호스트를 통해 인프라를 공격할 위험 있음.

배스천 호스트 실습

Bastion Host를 이용해 Private EC2 인스턴스 접속하기

1. Bastion Host 및 Private Instance 생성

  • 퍼블릭 서브넷에 BastionHost(EC2 인스턴스) 생성
  • 프라이빗 서브넷에 PrivateInstance(EC2 인스턴스) 생성
  • SSH로 접속할 것이기 때문에 키 페어(DemoKeyPair.pem) 생성 및 다운로드

2. 보안 그룹 설정

  • Bastion Host 보안 그룹: 인터넷에서 SSH 접속 허용 (보안 위해 특정 IP만 허용 권장)
  • Private Instance 보안 그룹: SSH(포트 22) 허용, Bastion Host 보안 그룹에서만 접속 가능하도록 설정

3. Bastion Host를 통한 Private Instance 접속

그 전에 Bastion Host에 키 페어 파일을 저장해둬야 함.
vi DemoKeyPair.pem 으로 다운받은 키 페어의 내용을 복사 붙여넣는다.
1. Bastion Host에 SSH 접속 

ssh -i DemoKeyPair.pem ec2-user@<BastionHost의 퍼블릭 IP>
  1. Bastion Host에서 Private Instance에 SSH 접속
    • Private Instance의 프라이빗 IP 확인 후 접속 
    ssh -i DemoKeyPair.pem ec2-user@<PrivateInstance의 프라이빗 IP>
  2. 키 페어 설정 오류 시 해결 방법
    • Bastion Host에 키 페어 파일 저장
    • 키 페어 파일 권한 변경 
      chmod 400 DemoKeyPair.pem

4. Private Instance의 인터넷 연결 문제

  • ping google.com이 안 되는 이유
    • Private Instance는 인터넷 게이트웨이 없이 인터넷에 직접 접근 불가
    • 이후 강의에서 NAT 게이트웨이를 사용해 해결 예정

NAT 인스턴스

  • **NAT(Network Address Translation)은 네트워크 주소 변환을 가르킴
  • 프라이빗 서브넷의 EC2 인스턴스가 인터넷에 연결될 수 있도록 함
  • NAT 인스턴스: 공용 서브넷에서 실행되며, 공용 서브넷과 사설 서브넷을 연결. 고정된 탄력적 IP가 연결되어야 한다.

2. NAT 인스턴스 구성 및 설정

  • 공용 서브넷에 NAT 인스턴스 생성
  • 탄력적 IP(Elastic IP) 연결
  • 소스/목적지 확인 비활성화 (NAT 인스턴스가 패킷을 재작성하기 때문)
  • 라우팅 테이블 수정: 프라이빗 서브넷에서 NAT 인스턴스를 통해 인터넷으로 통신하도록 설정

3. NAT 인스턴스의 네트워크 패킷 흐름

  1. 사설 서브넷의 EC2 인스턴스 → NAT 인스턴스로 요청 전송
    • 예: 소스 IP: 10.0.0.20 (사설 IP), 목적지 IP: 50.60.4.10 (외부 서버)
  2. NAT 인스턴스가 패킷 재작성
    • 소스 IP를 NAT 인스턴스의 공용 IP(12.34.56.78)로 변경
  3. 외부 서버가 NAT 인스턴스의 공용 IP로 응답
  4. NAT 인스턴스가 패킷을 다시 원래 EC2 인스턴스로 전달

4. NAT 인스턴스의 단점 및 비추천 이유

  • 2020년 12월 31일 표준 지원 종료 → NAT Gateway 사용 권장
  • 가용성이 낮음 → 단일 인스턴스 장애 시 서비스 중단 위험
  • 자동 복구 불가능 → Auto Scaling Group(ASG) 설정 필요
  • 대역폭 제한 → 인스턴스 크기에 따라 제한됨
  • 보안 관리 필요 → 보안 그룹 및 규칙 설정 필수

5. 보안 그룹 설정

  • 인바운드 규칙: 사설 서브넷의 HTTP/HTTPS 요청 허용, SSH 접속 허용
  • 아웃바운드 규칙: 외부 인터넷으로 트래픽 전송 허용

NAT 인스턴스 실습

NAT 인스턴스를 이용한 프라이빗 서브넷 인터넷 연결

1. NAT 인스턴스 생성

  • Launch instances 클릭 → NAT Instance 검색
  • Community AMIs에서 최신 x86_64 아키텍처 NAT AMI 선택
  • 인스턴스 유형: t2.micro
  • 키 페어: DemoKeyPair
  • 보안 그룹 생성 (nat-instance-sg)
    • SSH: 모든 소스 허용
    • HTTP/HTTPS: VPC CIDR (10.0.0.0/16) 허용
  • VPC: DemoVPC
  • 서브넷: PublicSubnetA
  • Launch instance로 생성

2. NAT 인스턴스 설정

  • Networking → Source/Destination Check 비활성화 (NAT 인스턴스 자체가 소스 및 목
  • 탄력적 IP 할당 및 연결

3. 프라이빗 인스턴스의 NAT 인스턴스 경유 설정

  • Bastion Host 접속 후 프라이빗 인스턴스 SSH 접속 
    ssh -i DemoKeyPair.pem ec2-user@<Private_IP>
  • PrivateRouteTable에서 인터넷으로 트래픽을 보낼 경우 NAT 인스턴스로 트래픽 전달하는 규칙 추가 
    Destination은 0.0.0.0/0 , Target은 NAT 인스턴스 ID

4. 인터넷 액세스 테스트 및 보안 그룹 수정

  • ping google.com → 실패 (ICMP 규칙 필요)
  • NAT 인스턴스의 보안 그룹에 All ICMP - IPv4 규칙 추가
  • ping google.com 및 curl example.com → 성공

NAT Gateway

NAT Gateway는 AWS에서 관리하는 고대역폭의 NAT 서비스로, EC2 인스턴스와는 다르게 관리할 필요 없이 자동으로 확장된다. 이 서비스는 고가용성 및 대역폭 확장성이 뛰어나며, 특정 AZ에서 생성되어 탄력적 IP를 자동으로 할당받는다. EC2 인스턴스와 같은 서브넷에서는 사용할 수 없고 다른 서브넷에 액세스할 때만 도움이 된다.

특징

  • 고대역폭 지원: 기본적으로 초당 5GB 대역폭을 제공하며, 자동으로 최대 45GB까지 확장된다.
  • 관리 불필요: NAT Gateway는 AWS 관리형 서비스로, 사용자가 보안 그룹이나 포트 설정을 관리할 필요가 없다.
  • 특정 AZ에서 작동: NAT Gateway는 특정 AZ에 배포되며, 다른 AZ의 서브넷에서만 사용할 수 있다.
  • 고가용성: 단일 AZ 내에서 복원 가능하며, 다중 AZ에 걸쳐 NAT Gateway를 배치하여 결함 허용을 구현할 수 있다.

구성

  1. NAT Gateway 배포: 공용 서브넷에 NAT Gateway를 배포한다. 이때, 공용 서브넷은 인터넷 게이트웨이에 연결되어 있어 NAT Gateway가 인터넷에 접근할 수 있다.
  2. 사설 서브넷 설정: 사설 서브넷에서 NAT Gateway를 통해 인터넷에 액세스할 수 있도록 라우팅 테이블을 수정한다.

고가용성

  • NAT Gateway는 단일 AZ에서만 가용하지만, 여러 AZ에 배치하여 고가용성을 구현할 수 있다. AZ가 중지되면 다른 AZ에 배치된 NAT Gateway를 통해 트래픽을 처리할 수 있다.

NAT Gateway vs. NAT 인스턴스 비교

  • 가용성: NAT Gateway는 높은 가용성을 제공하며, NAT 인스턴스는 관리자가 장애 조치 스크립트를 통해 관리해야 한다.
  • 대역폭: NAT Gateway는 최대 45GB/초의 대역폭을 제공하며, NAT 인스턴스는 인스턴스 유형에 따라 대역폭이 다르다.
  • 관리: NAT Gateway는 AWS 관리형 서비스로 유지 보수가 필요 없으며, NAT 인스턴스는 사용자가 관리하고 소프트웨어 패치 등도 필요하다.
  • 비용: NAT Gateway는 시간당 요금과 데이터 전송량에 따라 청구되며, NAT 인스턴스는 EC2 인스턴스 요금과 데이터 전송량에 따라 청구된다.
  • 보안 그룹: NAT Gateway는 보안 그룹을 사용하지 않으며, NAT 인스턴스는 보안 그룹을 통해 포트를 설정해야 한다.
  • Bastion 호스트: NAT Gateway는 Bastion 호스트로 사용할 수 없고, NAT 인스턴스는 필요시 Bastion 호스트로 활용할 수 있다.

NAT Gateway 실습

NAT Gateway 설정 및 활성화 과정

  1. 사설 라우팅 테이블 새로고침

    • 기존 경로가 Blackhole로 표시된다. 이는 NAT 인스턴스가 중지되어 해당 경로가 유효하지 않다는 의미이다.
    • NAT Gateway는 관리형 서비스로, NAT 인스턴스처럼 중지 문제를 걱정할 필요가 없다.

  2. NAT Gateway 생성

    • VPC콘솔 > NAT gateways > Create NAT gateway를 선택해서 생성하면 된다.
    • DemoNATGW라는 이름으로 NAT Gateway를 생성한다.
    • 고가용성을 위해 다중 서브넷을 사용할 수 있지만, 이번에는 PublicSubnetA 서브넷을 선택한다.
    • Public 연결 유형을 선택하고, 탄력적 IP를 할당하여 연결을 설정한다.
    • Create NAT Gateway 버튼을 클릭하여 NAT Gateway를 생성한다.

  3. 라우팅 테이블 수정

    • NAT Gateway가 생성되는 동안, 프라이빗 서브넷의 라우팅 테이블을 수정한다.
    • Edit routes 메뉴를 선택하여, 목적지가 0.0.0.0/0 이고 타겟을 DemoNATGW를 선택하여 트래픽을 NAT Gateway로 전송한다.
    • 변경 사항을 저장하면, 이제 더 이상 Blackhole 경로가 없고, 활성화된 NAT Gateway 경로가 표시된다.

  4. NAT Gateway 활성화 및 확인

    • NAT Gateway는 활성화되기까지 시간이 걸리므로 기다린다. 상태가 보류 중에서 활성화됨으로 변경된다.
    • 활성화 후, EC2 인스턴스에서 curl google.com 또는 ping google.com을 실행하면 인터넷 연결이 정상적으로 작동하는 것을 확인할 수 있다.
    • NAT Gateway는 보안 그룹 설정을 필요로 하지 않으며, 라우팅 테이블 수정만으로 인터넷 액세스를 할 수 있다.

  5. 고가용성 설정

    • 단일 AZ에 NAT Gateway를 배치한 경우, 다른 AZ에 두 번째 NAT Gateway를 배치하여 고가용성을 높일 수 있다.
    • 라우팅 테이블을 수정하여 다중 NAT Gateway를 구성하면, AZ 중 하나에 장애가 발생해도 다른 AZ의 NAT Gateway가 트래픽을 처리하여 시스템의 가용성을 유지할 수 있다.

보안그룹과 NACL

NACL -> 보안그룹 -> 인스턴스 식으로 트래픽이 거쳐간다.
따라서 NACL과 보안그룹을 둘 다 통과해야 인스턴스로 트래픽이 도착한다.
나갈 때는 인스턴스 -> 보안그룹 -> NACL 식이다.

  1. 보안 그룹(Security Group)

    • 작동 수준: 인스턴스 수준에서 작동한다.
    • 규칙: 허용 규칙만 지원하며, 트래픽을 허용하는 규칙만 정의된다.
    • 상태: 상태 유지(Stateful)로, 요청이 들어오면 응답도 자동으로 허용된다. 즉, 들어오는 트래픽을 허용하면 나가는 트래픽도 허용된다. 나가는 응답이 허용되면 들어오는 응답도 허용된다.
    • 적용 대상: EC2 인스턴스에 직접 적용된다.
    • 인바운드/아웃바운드 규칙: 아웃바운드 규칙은 자동으로 허용된다.

  2. 네트워크 ACL(NACL)

    • 작동 수준: 서브넷 수준에서 작동한다.
    • 규칙: 허용(Allow)과 거부(Deny) 규칙 모두 지원한다. 특정 IP 주소를 거부하는 규칙도 가능하다.
    • 상태: 무상태(Stateless)로, 들어오는 트래픽과 나가는 트래픽이 독립적으로 평가된다. 즉, 요청이 들어올 때만 평가되며, 응답을 허용하려면 별도로 규칙이 필요하다.
    • 적용 대상: 서브넷에 연결된 모든 EC2 인스턴스에 적용된다.
    • 우선순위: 규칙 번호가 낮을수록 우선순위가 높다. 첫 번째 규칙이 일치하면 그 규칙이 적용된다.

      예시: 특정 CIDR에서 ALLOW를 정의하고 같은 CIDR인 특정 IP를 DENY로 정의하면
      ALLOW는 100이고 DENY가 200이니까 IP 주소는 허용된다.

  3. NACL의 특징

    • 서브넷에 연결된 NACL은 기본적으로 모든 트래픽을 허용하는 설정이 되어 있다.
    • 임시 포트: 클라이언트가 서버에 연결할 때, 서버는 포트를 열어두지만 클라이언트는 열어둔 포트가 없어 서버로부터 응답을 받기 위해 운영 체제에서 임시 포트를 할당하여 연결을 유지한다. 이 포트는 요청/응답을 위해 사용되며, OS에 따라 임시 포트 범위가 다르다.(Windows 10: 49152에서 65,535까지 / Linux: 32768에서 60999까지)

      예시: 클라이언트가 데이터베이스에 연결하는 경우, NACL은 포트 3306에 대한 아웃바운드 및 인바운드 규칙을 정의해야 하며, 데이터베이스가 클라이언트에 응답하려면 임시 포트가 필요하다.
      DB NACL은 포트 및 임시 포트에서 아웃바운드 TCP를 허용하는데 범위는 1,024에서 65,535이다. 웹 서브넷 CIDR로 아웃바운드 되면 웹 NACL은 DB 서브넷 CIDR의 임시 포트 범위에서 인바운드 TCP를 허용해야 한다.

  4. 주요 차이점

    • 보안 그룹: 인스턴스 수준에서 작동하며 상태 유지, 허용 규칙만 정의된다.
    • NACL: 서브넷 수준에서 작동하며, 허용과 거부 규칙을 모두 정의할 수 있고, 무상태이기 때문에 매번 규칙을 평가한다.

NACL 규칙 우선순위

  • 규칙은 숫자로 우선순위가 결정되며, 숫자가 낮을수록 우선순위가 높다. 예를 들어, 100번 규칙이 200번 규칙보다 먼저 평가된다.
  • 별표(*) 규칙은 일치하는 규칙이 없을 경우 기본적으로 모든 트래픽을 거부한다.
  • AWS는 규칙을 100씩 추가하는 것을 권장한다.

NACL 실습

기본 네트워크 ACL 설정

  • VPC 콘솔 > Security > Network ACLs 선택
  • 기본적으로 네트워크 ACL은 모든 서브넷과 연결된다.
  • Inbound rules와 Outbound rules 탭에서 기본적으로 모든 트래픽을 허용한다.
  • 마지막 Deny 규칙은 영향이 없다. 우선적으로 Allow가 먼저 효력을 발생하기 때문이다.
  • 여기에서 새로운 규칙을 추가할 수 있다.

VPC 피어링

VPC 피어링의 기본 개념

  • VPC 피어링은 서로 다른 VPC를 연결하여, 마치 동일한 네트워크에 있는 것처럼 통신할 수 있도록 만든다.
  • 다른 지역(Region), 다른 계정 또는 동일한 계정 내에서 VPC를 연결할 수 있다.
  • 중요한 점은 VPC의 CIDR이 겹치지 않아야 한다는 것이다. CIDR이 겹치면 VPC 간의 통신이 불가능하다.

VPC 피어링 연결의 동작 원리

  • VPC-A와 VPC-B를 피어링하면, 두 VPC는 서로 연결되어 통신할 수 있다.
  • VPC-B와 VPC-C를 또 다른 피어링 연결로 연결할 수 있다.
  • 그러나 A와 B, B와 C가 연결되어 있다고 해서 A와 C가 자동으로 통신할 수 있는 것은 아니다. A와 C도 별도로 피어링 연결을 활성화해야 통신이 가능하다.
  • 각 VPC 서브넷의 라우팅 테이블을 업데이트해야, 다른 VPC의 EC2 인스턴스와 통신할 수 있다.

VPC 피어링의 활용

  • VPC 피어링은 계정 내에서뿐만 아니라 다른 계정 간에도 발생할 수 있다.
  • 예를 들어, 계정 A의 VPC와 계정 B의 VPC를 연결할 수 있다. 또한 지역을 넘나드는 연결도 가능하다.
  • 보안 그룹에서도 다른 VPC의 보안 그룹을 참조할 수 있다. 이는 매우 강력한 기능으로, CIDR이나 IP를 사용하지 않고 다른 VPC의 보안 그룹을 참조하여 접근 제어가 가능하다.

VPC 피어링 연결 설정

  • VPC 피어링을 설정하려면 두 VPC의 라우팅 테이블을 업데이트하고, 보안 그룹과 네트워크 ACL 설정을 적절히 수정해야 한다.
  • 이를 통해 서로 다른 VPC에 있는 EC2 인스턴스들이 원활히 통신할 수 있도록 할 수 있다.

VPC 피어링은 다수의 VPC를 서로 연결하여 확장성과 유연성을 제공하는 중요한 기능이다. 이를 활용하면 여러 계정과 지역에 걸쳐 복잡한 네트워크 구조를 구성할 수 있다.

VPC 피어링 실습

  1. VPC 생성 및 인스턴스 시작

    • DemoVPC와 DefaultVPC를 생성하고, 각각의 VPC에 EC2 인스턴스를 배포하였다.
    • 인스턴스를 생성할 때, DemoKeyPair와 launch-wizard-2 보안 그룹을 사용하여 ssh 규칙을 추가하였다.

  2. 연결 확인

    • 각 VPC의 EC2 인스턴스의 프라이빗 IP 주소가 다르기 때문에, 두 인스턴스가 서로 다른 VPC에 있는 것을 확인하였다.
    • curl 명령어로 DefaultVPC 내 EC2 인스턴스의 IP를 호출하였지만, 시간 초과가 발생하며 연결되지 않았다. 이는 두 VPC가 서로 연결되지 않았기 때문이다.

  3. ⭐VPC 피어링 연결 생성

    • Peering Connections 메뉴에서 DemoPeeringConnection 이름으로 피어링 연결을 생성하였다.
    • Requester VPC를 DemoVPC, Accepter VPC를 DefaultVPC로 설정하였고, CIDR 범위가 겹치지 않아 피어링 연결을 생성할 수 있었다.
    • 피어링 연결은 "승인 보류" 상태인데, Actions > Accept request로 승인을 해줘야 연결이 완료된다.

  4. 라우팅 테이블 수정

    • 피어링 연결 후, VPC 간 트래픽을 전송하기 위해 각 VPC의 라우팅 테이블을 수정하였다.
    • DefaultVPC의 라우팅 테이블에 Destination으로 DemoVPC의 CIDR을 추가하고 Target으로 DemoPeeringConnection을 선택해 피어링 연결을 통해 트래픽을 전송하도록 설정하였다.
    • DemoVPC의 라우팅 테이블에도 DefaultVPC의 CIDR을 추가하고 Target으로 DemoPeeringConnection을 선택해 양방향 통신이 가능하도록 했다.

  5. 연결 확인

    • 라우팅 테이블을 수정한 후, 다시 curl 명령어를 실행하였고, 정상적으로 hello world 메시지가 출력되며 연결이 성공적으로 이루어졌다.

VPC 엔드포인트

AWS 서비스에 퍼블릭 인터넷을 거치지 않고 프라이빗 네트워크를 통해 액세스할 수 있도록 해주는 기능이다. VPC 엔드포인트를 사용하면 NAT Gateway나 인터넷 게이트웨이 없이도 AWS 서비스에 연결할 수 있으며, 네트워크 인프라를 단순화시킬 수 있다. 문제가 발생하면 VPC에서 DNS 설정 해석이나 라우팅 테이블을 확인하면 된다. VPC 엔드포인트에는 두 가지 유형이 있다.

  1. 인터페이스(Interface) 엔드포인트

    • AWS PrivateLink를 사용해 서비스를 프라이빗으로 연결한다.
    • ENI(Elastic Network Interface)를 통해 VPC 내에서 AWS 서비스로의 액세스를 제공한다.

      ENI는 VPC의 프라이빗 IP 주소이자 AWS의 엔트리 포인트이다. ENI가 있으므로 반드시 보안 그룹을 연결해야한다.

    • 보안 그룹을 연결해야 하며, 대부분의 AWS 서비스를 지원한다.
    • 청구는 시간 단위 또는 처리된 데이터의 GB 단위로 이루어진다.

  2. 게이트웨이(Gateway) 엔드포인트

    • Amazon S3와 DynamoDB에만 사용된다.
    • 게이트웨이는 라우팅 테이블에서 목적지로 지정되며, ENI와 같이 IP주소를 사용하지 않고 보안 그룹도 사용하지 않는다.
    • 무료로 제공되며 자동으로 확장된다.

VPC 엔드포인트 사용 시 고려 사항

  • 인터페이스 엔드포인트는 모든 AWS 서비스에 사용할 수 있지만 비용이 발생한다.
  • 게이트웨이 엔드포인트는 Amazon S3와 DynamoDB에만 사용 가능하며, 비용이 발생하지 않고 확장성이 좋다.
  • Amazon S3에 액세스할 때는 게이트웨이 엔드포인트가 유리하며, 인터페이스 엔드포인트는 온프레미스나 다른 VPC에 프라이빗으로 액세스해야 할 때 사용한다.

따라서, 대부분의 경우 Amazon S3에는 게이트웨이 엔드포인트가 유리하다.

VPC 엔드포인트 실습

1. 기본 설정

  • 퍼블릭 인스턴스인 BastionHost를 통해 프라이빗 EC2 인스턴스에 접속함.
  • ssh -i DemoKeyPair.pem ec2-user@<프라이빗EC2-IP> 명령어를 사용하여 SSH 연결함.

2. IAM 역할 부여

  • S3 접근을 위해 프라이빗 EC2 인스턴스에 IAM 역할을 부여해야 함.
  • Security 탭에서 IAM 역할이 없는 것을 확인하고, Modify IAM Role을 선택하여 새로운 역할을 생성함.
  • AmazonS3ReadOnlyAccess 정책을 부여하고, 역할 이름을 DemoRoleEC2-S3ReadOnly로 지정함.
  • 역할 생성 후 EC2 인스턴스에 적용하여 aws s3 ls 명령어 실행 시 S3 버킷 목록이 정상적으로 표시됨.

3. 인터넷 차단 및 VPC 엔드포인트 생성

  • 프라이빗 서브넷의 Route Table에서 NAT 게이트웨이를 통한 인터넷 연결을 제거함.
  • curl google.com 및 aws s3 ls 실행 시 네트워크 접근이 차단됨을 확인함.
  • VPC 콘솔 > Endpoints 에서 VPC 엔드포인트(Endpoints)를 생성하여 프라이빗 네트워크에서 S3에 접근할 수 있도록 설정함.
    • 엔드포인트 유형: Gateway
    • 서비스: Amazon S3
    • VPC: DemoVPC
    • Route Table: PrivateRouteTable을 선택하여 VPC 엔드포인트를 통해 트래픽을 라우팅함.
    • Policy: Full Access로 설정함.

4. 테스트 및 CLI 설정

  • BastionHost를 통해 프라이빗 인스턴스에 SSH로 다시 접속함.
  • curl google.com 실행 시 인터넷 차단으로 인해 동작하지 않음을 확인함.
  • aws s3 ls 실행 시에도 응답이 없었으나, CLI 기본 리전이 us-east-1로 설정되어 있었음.
  • aws s3 ls --region <사용 중인 리전> 명령어를 실행하여 S3 버킷 목록이 정상적으로 표시됨을 확인함.

VPC Flow Logs

VPC Flow Logs는 VPC에서 송수신되는 IP 트래픽 정보를 캡처하는 기능이다. 이 로그는 VPC 수준, 서브넷 수준, 탄력적 네트워크 인터페이스(ENI) 수준에서 생성할 수 있다. 이를 통해 네트워크 연결 문제를 모니터링하고 해결하는 데 유용하다.

VPC Flow Logs의 활용

  • 로그 데이터를 Amazon S3, CloudWatch Logs, Kinesis Data Firehose 등에 전송할 수 있다.
  • AWS 관리형 서비스(ELB, RDS, ElastiCache, Redshift, WorkSpaces, NAT Gateway, Transit Gateway 등)와도 연동할 수 있다.
  • 주요 네트워크 메타데이터(버전, 계정ID, 인터페이스 ID, 소스 주소, 대상 주소, 소스 포트, 대상 포트, 프로토콜, 패킷 수, 바이트 수, 시작 및 종료 시간, 액션, 로그 상태 순으로 구성되어 있음)를 제공한다.

VPC Flow Logs를 활용한 문제 해결

  • 소스 및 대상 주소를 분석하여 특정 IP가 반복적으로 차단되는지 확인할 수 있다.
  • 소스 포트 및 대상 포트를 통해 문제가 발생한 포트를 식별할 수 있다.
  • 액션(Action) 필드를 활용하여 네트워크 트래픽이 보안 그룹(SG) 또는 네트워크 ACL(NACL)에서 허용되었는지 여부를 확인할 수 있다.

보안 그룹과 NACL 문제 해결

  • Inbound REJECT: 외부에서 EC2 인스턴스로 들어오는 요청이 거부된 경우이며, 이는 NACL이나 보안 그룹이 원인일 수 있다.
  • Inbound ACCEPT, Outbound REJECT: 보안 그룹은 상태를 유지하지만 NACL은 그렇지 않기 때문에, 이 경우 NACL이 문제일 가능성이 높다.
  • Outbound REJECT: 나가는 트래픽이 차단된 경우이며, 보안 그룹이나 NACL을 점검해야 한다.
  • Outbound ACCEPT, Inbound REJECT: 반드시 NACL이 문제이며, 인바운드 규칙을 확인해야 한다.

VPC Flow Logs 분석 방법

  • CloudWatch Logs Insights: 실시간 스트리밍 분석을 수행할 수 있다.
  • Athena + S3: 로그 데이터를 SQL로 쿼리하여 분석하는 방법이다.
  • CloudWatch Contributor Insights: 네트워크에서 가장 많은 트래픽을 발생시키는 상위 10개 IP를 확인할 수 있다.
  • CloudWatch 메트릭 필터: SSH(RDP 포함) 트래픽 증가를 감지하여 CloudWatch Alarm과 SNS 경보를 트리거할 수 있다.
  • QuickSight 시각화: Amazon Athena와 연계하여 VPC Flow Logs 데이터를 시각화할 수 있다.

VPC Flow Logs 실습

1. 흐름 로그 생성

1.1. S3로 로그 저장 (DemoS3FlowLog)

  1. 로그 생성: VPC를 선택하고 Flow Logs 탭에서 Create flow log를 눌러DemoS3FlowLog라는 이름으로 흐름 로그를 생성한다.
  2. 필터 선택: ALL(모든 트래픽), ACCEPT(수락된 트래픽), REJECT(거부된 트래픽) 중 선택한다.
    • 거부된 트래픽을 디버깅하려면 REJECT를 선택한다.
    • 모든 트래픽을 모니터링하려면 ALL을 선택한다.
  3. 집계 주기 설정:
    • 기본적으로 10분이 권장되지만, 빠른 결과 확인을 위해 1분으로 설정할 수도 있다.(1분으로 하면 S3,CloudWatch Logs에 기록하는 비용 많이 청구됨)
  4. S3 버킷 생성:
    • S3 콘솔에서 demo-stephane-vpc-flow-logs-v2 버킷을 생성한다.
    • VPC와 동일한 리전에 생성해야 한다.
  5. S3 버킷 ARN 복사:
    • 생성된 S3 버킷의 ARN을 복사하여 흐름 로그 생성 과정에서 설정한다.
  6. 흐름 로그 생성 완료

1.2. CloudWatch Logs로 로그 저장 (DemoFlogLogCWLogs)

  1. 로그 생성: DemoFlogLogCWLogs라는 이름으로 흐름 로그를 생성한다.
  2. 필터 선택: ALL을 선택하여 모든 트래픽을 저장한다.
  3. 집계 주기 설정: 1분으로 설정한다.
  4. CloudWatch Logs 전송 대상 설정:
    • 로그 그룹과 IAM 역할이 필요하다.
  5. IAM 역할 생성:
    • 신뢰 정책: vpc-flow-logs.amazonaws.com을 Principal로 설정한다.
    • 권한 정책: CloudWatchLogsFullAccess를 부여한다.
    • 역할 이름: flowlogsRole로 설정한다.
  6. CloudWatch Logs 그룹 생성:
    • CloudWatch 콘솔의 Log groups에서 VPCFlowLogs 로그 그룹을 생성한다.
    • 보관 기간을 1일로 설정한다.
  7. IAM 역할과 목적지 로그 그룹을 설정 후 흐름 로그 생성 완료

2. 로그 확인

2.1. S3에서 로그 확인

  • Amazon S3 콘솔에서 Objects를 새로고침하면 로그 파일이 저장된 것을 확인할 수 있다.
  • VPC Flow Logs 경로를 따라가면 트래픽 기록이 존재하는 것을 확인할 수 있다.

2.2. CloudWatch Logs에서 로그 확인

  • CloudWatch Logs 콘솔에서 Log streams를 새로고침하면 흐름 로그가 기록된 로그 스트림이 보인다.
  • 특정 ENI ID(Elastic Network Interface)를 검색하여 해당 ENI에서 발생한 네트워크 트래픽을 확인할 수 있다.
  • 로그를 보면 EC2 인스턴스에 대한 접근 시도가 거부된 것을 확인할 수 있으며, 특정 IP에서 반복적으로 접근하는 경우 네트워크 ACL(NACL)에서 차단할 수 있다.

3. Athena를 활용한 로그 분석

  1. Athena 쿼리 결과 저장 위치 설정

    • demo-athena-stephane-v2라는 S3 버킷을 생성한다.
    • s3://demo-athena-stephane-v2/athena/를 결과 저장 위치로 설정한다.

  2. 테이블 생성

    • vpc_flow_logs 테이블을 생성한다.
    • 데이터가 저장된 S3 버킷의 경로를 테이블 생성 쿼리에 입력한다.

  3. 파티션 추가

    • 로그 데이터를 읽기 위해 날짜별 파티션을 추가한다.
    • ALTER TABLE ADD PARTITION 쿼리를 실행하여 특정 날짜의 로그를 쿼리할 수 있도록 설정한다.

  4. 로그 데이터 분석

    • SELECT 문을 사용하여 특정 조건을 만족하는 로그를 조회한다.
    • 예를 들어, 거부된 트래픽(REJECT)만 조회할 수 있다.
    • IP별 공격 시도를 분석하고, 가장 많이 공격하는 IP를 찾아 차단할 수도 있다.

Site-to-Site VPN

Site-to-Site VPN은 기업의 온프레미스 데이터 센터와 AWS VPC를 비공개로 연결하는 네트워크 솔루션이다.
VPN 연결이므로 암호화되지만, 공용 인터넷을 통해 트래픽이 전달된다.

Site-to-Site VPN 구성 요소

  1. 가상 프라이빗 게이트웨이(Virtual Private Gateway, VGW)
    • AWS 측의 VPN 집선기(concentrator) 역할을 한다.
    • 생성 후 VPC에 연결되며, Site-to-Site VPN을 통해 온프레미스와 연결된다.
    • ASN(Autonomous System Number)을 지정할 수 있다.

ASN은 Autonomous System Number(자율 시스템 번호)의 약어이다.
인터넷에서 하나의 네트워크(자율 시스템, AS)를 식별하는 고유한 번호로, BGP(Border Gateway Protocol) 라우팅에서 사용된다.

  1. 고객 게이트웨이(Customer Gateway, CGW)
    • 온프레미스 네트워크 측에서 VPN 연결을 담당하는 소프트웨어 또는 물리적 장치이다.
    • AWS가 테스트한 장비 목록을 확인하여 적절한 장비를 선택할 수 있다.

Site-to-Site VPN 연결 방식

  1. 공용 IP를 사용하는 경우

    • 고객 게이트웨이(CGW)에 공용 인터넷 라우팅이 가능한 IP 주소가 있어야 한다.
    • 이 공용 IP를 사용해 VGW와 CGW를 연결하면 된다.

  2. 사설 IP를 사용하는 경우

    • 고객 게이트웨이가 사설 IP를 가질 수도 있다.
    • 이 경우 NAT-Traversal(NAT-T)를 활성화하고, NAT 장치 뒤에서 공용 IP를 사용하는 방식으로 설정해야 한다.
    • NAT 장치의 공용 IP를 CGW에 설정하면 된다.

VPN 연결 후 설정

  1. 라우트 전파(Route Propagation) 활성화

    • VPC 서브넷의 라우팅 테이블에서 라우트 전파를 활성화해야 VPN 연결이 정상적으로 작동한다.

  2. EC2 인스턴스 네트워크 연결 확인

    • 온프레미스에서 AWS의 EC2 인스턴스에 연결할 때, 보안 그룹의 인바운드 규칙을 확인해야 한다.
    • ICMP 프로토콜이 활성화되지 않으면 핑 테스트가 실패할 수 있다.
    • Site-to-Site VPN 설정 문제와 혼동되지 않도록 주의해야 한다.

AWS VPN CloudHub

  1. CloudHub 개념

    • 여러 고객 네트워크(데이터 센터)를 단일 VGW를 통해 연결하는 방식이다.
    • 허브 앤 스포크(hub & spoke) 모델로 동작하며, 비용이 저렴한 네트워크 연결 방식이다.
    • VPN만을 활용하여 고객 네트워크 간에도 연결되고 VPC로도 연결을 제공한다.
    • VPN 연결이므로 모든 트래픽이 공용 인터넷을 통한다. 프라이빗 네트워크로 연결은 되지 않는다.

  2. CloudHub 설정 방법

    • 하나의 가상 프라이빗 게이트웨이(VGW)를 생성한다.
    • 여러 개의 Site-to-Site VPN 연결을 생성한다.
    • 동적 라우팅을 활성화하고, 라우팅 테이블을 구성한다.

Site to Site VPN 연결 실습

AWS Site-to-Site VPN 연결 생성 과정 정리

  1. 고객 게이트웨이(Customer Gateway) 생성

    • AWS VPC콘솔에서 VPN → 고객 게이트웨이(Customer Gateways) 클릭
    • 온프레미스 게이트웨이 정보 입력
      • IP 주소: 온프레미스 VPN 장비의 외부 인터페이스 IP
      • BGP ASN(선택사항)
      • 인증서 ARN(필요시) :AWS에서 온프레미스 VPN 기기에 접속할 때 보안 연결을 설정하기 위한 것
    • 생성 완료

  2. 가상 프라이빗 게이트웨이(Virtual Private Gateway) 생성

    • AWS 콘솔에서 VPN → 가상 프라이빗 게이트웨이(Virtual Private Gateways) 클릭
    • AWS에서 자동 생성된 ASN 사용
    • 생성 후 VPC에 연결

  3. Site-to-Site VPN 연결 생성

    • VPN 연결(Site-to-Site VPN Connections) → VPN 연결 생성(Create VPN Connection) 클릭
    • 타겟 게이트웨이 유형: 가상 프라이빗 게이트웨이 선택
    • 가상 프라이빗 게이트웨이(Virtual Private Gateway): 생성한 가상 프라이빗 게이트웨이 선택
    • 고객 게이트웨이 ID(Customer Gateway ID): 생성한 고객 게이트웨이 선택
    • 필요하면 라우팅, 터널링 등 추가 설정 후 생성

  4. VPN 연결 확인

    • VPN 상태 확인
    • 온프레미스 장비와의 터널 연결 상태 체크

AWS Direct Connect(DX)

AWS Direct Connect는 원격 네트워크와 VPC 간의 전용 프라이빗 연결을 제공하는 서비스이다. 퍼블릭 인터넷을 거치지 않고 AWS와 온프레미스 데이터 센터 간 안정적이고 빠른 네트워크 연결을 가능하게 한다.

2. 주요 개념

  • Direct Connect 로케이션: Direct Connect가 제공되는 물리적 위치
  • 가상 프라이빗 게이트웨이(Virtual Private Gateway): 온프레미스 네트워크와 VPC를 연결하는 AWS 게이트웨이
  • VIF(Virtual Interface): AWS와의 연결을 위한 가상 인터페이스
    • 프라이빗 VIF: 온프레미스에서 VPC 내 프라이빗 리소스(EC2, RDS 등) 에 접근
    • 퍼블릭 VIF: 온프레미스에서 퍼블릭 AWS 서비스(S3, Glacier 등) 에 접근
  • Direct Connect Gateway: 여러 VPC와 여러 리전 간 Direct Connect 연결을 관리하는 게이트웨이

3. Direct Connect 사용 사례

  • 대역폭 처리량 증가: 퍼블릭 인터넷을 거치지 않아 속도가 빠름
  • 비용 절감: 프라이빗 연결을 통해 데이터 전송 비용 절감
  • 연결 안정성: 퍼블릭 인터넷 장애 발생 시에도 안정적인 연결 유지
  • 하이브리드 환경 지원: 온프레미스 데이터 센터와 AWS 연결
  • IPv4 및 IPv6 지원

4. Direct Connect 연결 과정

  1. Direct Connect 로케이션 선택
  2. Direct Connect 로케이션에 Direct Connect 엔드포인트 생성
  3. Direct Connect 로케이션에 고객/파트너 라우터 설치
  4. 프라이빗 VIF 또는 퍼블릭 VIF 생성
  5. Direct Connect Gateway 설정(필요 시)
  6. 온프레미스와 AWS 네트워크 연결 구성

5. Direct Connect 유형

유형용량특징
전용 연결1Gbps 또는 10GbpsAWS에서 직접 제공하는 물리적 전용 포트
호스팅 연결50Mbps ~ 10GbpsAWS Direct Connect 파트너를 통해 제공, 필요하면 언제든 용량 추가 제거가 가능해 유연한 확장 가능
  • 설치 기간: Direct Connect 연결 설정에는 보통 한 달 이상 소요됨
    → 단기간(예: 1주일) 내 데이터 전송이 필요하면 적절한 솔루션이 아님

6. Direct Connect와 보안

  • Direct Connect 자체는 암호화를 제공하지 않음
  • VPN(IPsec) 을 추가하면 암호화 가능
  • VPN을 통해 Direct Connect 트래픽을 암호화하려면 Direct Connect + VPN 연결 구성

7. Direct Connect 복원력 및 아키텍처 모드

기업 데이터 센터가 2개일 경우

  • 복원력 향상 방법

    • Direct Connect 로케이션을 2개 이상 배포하여 중복 구성
    • Direct Connect 연결을 여러 개 수립하여 장애 발생 시 대체 경로 확보

  • 최대 복원력 구성

    • 각 Direct Connect 로케이션에 독립적인 연결 2개 이상을 설정
    • 최소 2개 이상의 로케이션과 4개의 연결을 사용하여 AWS에 연결

아키텍처: Site-to-Site VPN과 Direct Connect 함께 사용

온프레미스 데이터센터와 VPC를 연결할 때 Direct Connect 하나로 연결하면 가끔 문제가 생길 수 있는데, 하나를 더 Direct Connect로 연결하면 비용이 상당히 많이 든다. 이럴 때는 Site-to-Site VPN을 보조로 연결하여 Direct Connect에 문제가 생겼을 때 퍼블릭 인터넷을 통해 VPN 연결이 가능해 안정성이 높아진다.

AWS Transit Gateway

AWS 네트워크 토폴로지는 매우 복잡할 수 있다. 일반적으로 여러 개의 VPC를 피어링(Peering)으로 연결하고, VPN 및 Direct Connect를 구축하여 Direct Connect Gateway를 통해 여러 VPC를 한 번에 연결하는 방식을 사용한다. 이러한 구조는 네트워크 확장성을 높이는 반면, 관리가 복잡해지는 단점이 있다.

이를 해결하기 위해 AWS Transit Gateway가 도입되었다. Transit Gateway는 여러 VPC 및 온프레미스 네트워크를 전이적으로 연결하는 중앙 허브 역할을 수행한다.

  1. VPC 간 전이적 연결

    • 기존에는 VPC 간 피어링을 직접 설정해야 했지만, Transit Gateway를 사용하면 모든 VPC가 Transit Gateway를 통해 전이적으로 연결된다.
    • VPC 간 직접적인 피어링이 필요하지 않으며, 네트워크 토폴로지가 간결해진다.

  2. Direct Connect 및 VPN 통합

    • Direct Connect Gateway를 Transit Gateway에 연결하면 Direct Connect를 여러 VPC와 공유할 수 있다.
    • Site-to-Site VPN도 Transit Gateway에 연결 가능하며, 고객 게이트웨이를 통해 VPC 여러 개에 액세스할 수 있다.

  3. 리전 간 연결 지원

    • Transit Gateway는 AWS 리소스로 작동하며, 리전 간에도 동작 가능하다.
    • 리전 간 Transit Gateway 피어링을 통해 다른 리전의 네트워크와 연결할 수 있다.

  4. 네트워크 트래픽 제어

    • Transit Gateway 라우팅 테이블을 생성하여 특정 VPC 또는 네트워크만 통신하도록 설정할 수 있다.
    • 이를 통해 네트워크 보안을 강화하고 불필요한 트래픽을 차단할 수 있다.

  5. IP 멀티캐스트 지원

    • AWS에서 유일하게 IP 멀티캐스트를 지원하는 서비스이다.

  6. ECMP(등가 다중 경로) 라우팅 지원

    • ECMP(Equal-Cost Multi-Path) 라우팅을 통해 여러 최적 경로로 패킷을 전달하여 Site-to-Site VPN 연결의 대역폭을 증가시킬 수 있다.
    • 일반적으로 Transit Gateway에 Site-to-Site VPN을 추가하면 터널 개수가 증가하여 연결 처리량이 2배 이상 향상된다.

  7. Direct Connect 계정 간 공유 가능

    • Direct Connect Gateway를 Transit Gateway에 연결하면 Direct Connect를 여러 계정 및 VPC에서 공유할 수 있다.
    • 이를 통해 기업 내 여러 AWS 계정이 동일한 Direct Connect를 활용할 수 있어 비용 절감 효과가 있다.

Transit Gateway를 활용한 네트워크 토폴로지 예시

1. VPC 및 온프레미스 네트워크 연결

  • Transit Gateway를 중심으로 VPC 여러 개와 온프레미스 네트워크를 연결한다.
  • Direct Connect Gateway를 Transit Gateway에 연결하면 Direct Connect를 모든 VPC에서 공유할 수 있다.
  • Site-to-Site VPN을 Transit Gateway에 연결하여 온프레미스 데이터 센터와의 안정적인 통신을 제공한다.

2. Site-to-Site VPN의 ECMP를 활용한 대역폭 증가

  • 기본적으로 VPN 연결을 하면 터널 2개가 생성되며 한 번에 하나의 터널만 활성 상태가 된다. 하나의 터널의 VPN 대역폭은 1.25Gbps를 사용할 수 있다.
  • 하지만 Transit Gateway를 사용하면 두 개의 터널이 동시에 활성화되어 처리량이 2.5Gbps로 증가한다.
  • 여러 Site-to-Site VPN을 Transit Gateway에 추가하면 ECMP 덕분에 대역폭이 2~3배 증가한다.

3. Direct Connect 공유 아키텍처

  • 기업 데이터 센터에서 Direct Connect를 생성하고, Transit Gateway를 사용하여 여러 계정 및 VPC에서 공유할 수 있다.
  • 이를 통해 여러 계정의 AWS 리소스가 하나의 Direct Connect를 통해 온프레미스와 연결된다.

Transit Gateway 사용 시 고려할 점

  • Transit Gateway를 통과하는 데이터는 1GB당 요금이 부과되므로, 비용 최적화를 고려해야 한다.
  • 각 VPC 및 온프레미스 네트워크 간 라우팅 테이블을 적절히 구성하여 보안을 강화해야 한다.
  • 리전 간 트래픽을 고려할 경우 Transit Gateway 피어링을 설정하여 최적의 경로를 구성하는 것이 중요하다.

VPC 트래픽 미러링

VPC 트래픽 미러링은 VPC에서 네트워크 트래픽을 수집하고 분석하는 기능이다.
트래픽을 관리 중인 특정 보안 어플라이언스로 전송하여 위협 탐지, 문제 해결, 성능 모니터링 등을 수행할 수 있다.
기존 트래픽 흐름을 방해하지 않으면서 트래픽을 복제하여 분석할 수 있도록 지원한다.

1. 트래픽 미러링 구성 요소

① 소스(Source)

  • 트래픽을 미러링할 탄력적 네트워크 인터페이스(ENI).
  • 일반적으로 EC2 인스턴스에 연결된 ENI를 사용한다.

② 대상(Destination)

  • 미러링된 트래픽을 받을 위치.
  • 대상은 ENI 또는 네트워크 로드 밸런서(NLB)가 될 수 있다.
  • 일반적으로 보안 소프트웨어가 설치된 EC2 인스턴스의 오토 스케일링 그룹을 사용한다.

③ 필터(Filters)

  • 미러링할 트래픽을 선택적으로 조정하는 기능.
  • 전체 트래픽을 미러링할 수도 있고, 특정 프로토콜이나 포트의 트래픽만 선택할 수도 있다.

2. VPC 트래픽 미러링 동작 방식

  1. EC2 인스턴스(소스 A)가 인터넷과 통신하고 있으며, 트래픽이 ENI를 통해 흐른다.
  2. VPC 트래픽 미러링을 설정하면 ENI를 통해 흐르는 트래픽이 네트워크 로드 밸런서(NLB)로 복제된다.
  3. NLB 뒤에는 보안 소프트웨어가 설치된 EC2 인스턴스 오토 스케일링 그룹이 존재하며, 복제된 트래픽을 분석한다.
  4. 소스 A는 트래픽 미러링이 적용되었음을 인지하지 못하며, 기존과 동일하게 동작한다.

3. VPC 트래픽 미러링의 특징

  • VPC 내에서 소스와 대상이 동일한 VPC에 있어야 한다.
  • VPC 피어링이 활성화된 경우, 다른 VPC에도 적용할 수 있다.
  • 트래픽 미러링은 실시간으로 트래픽을 복제하며, 원본 트래픽의 흐름에 영향을 주지 않는다.

4. VPC 트래픽 미러링 사용 사례

  • 보안 및 위협 모니터링
    • 네트워크 트래픽을 분석하여 DDoS 공격, 악성 트래픽, 데이터 유출 감지에 활용한다.
  • 콘텐츠 검사
    • 특정 트래픽을 필터링하여 애플리케이션 트래픽 패턴 분석 및 규정 준수 확인에 사용한다.
  • 네트워크 문제 해결
    • 트래픽 흐름을 모니터링하여 지연 문제, 네트워크 장애, 패킷 손실 분석에 활용한다.

IPv6

IPv6는 IPv4의 한계를 해결하기 위해 도입된 새로운 인터넷 프로토콜이다.
IPv4는 약 43억 개의 주소를 제공하도록 설계되었지만, 인터넷 기기의 폭발적인 증가로 인해 빠르게 고갈되었다.
이를 해결하기 위해 IPv6가 등장했으며, 약 3.4×10³⁸개의 고유 IP 주소를 제공한다.

IPv6의 특징**

  • IPv6 주소 형식: x:x:x:x:x:x:x:x (각 x는 16진수, 0000~FFFF)
  • AWS의 IPv6 주소:
    • 모든 IPv6 주소는 공용(public) IP이며 인터넷 라우팅이 가능하다.
    • IPv4처럼 사설(private) IPv6은 제공되지 않는다.
  • IPv6 지원 방식:
    • AWS VPC에서 듀얼 스택 모드(Dual Stack Mode)로 IPv6을 활성화할 수 있다.
    • 즉, 하나의 EC2 인스턴스가 사설 IPv4 + 공용 IPv6 주소를 가질 수 있다.
    • 인터넷 게이트웨이를 통해 IPv4와 IPv6로 인터넷에 연결할 수 있다.

IPv6 지원을 활성화하는 방법

  • VPC와 서브넷에서 IPv6을 활성화한다.
  • IPv6 CIDR 블록을 할당하고, 인스턴스에 IPv6 주소를 자동 할당할 수 있도록 설정한다.
  • 인터넷 게이트웨이 또는 NAT 게이트웨이를 통해 외부와의 연결을 설정한다.

VPC가 IPv4와 IPv6를 지원할 때 EC2 인스턴스가 생성되지 않는 문제

  • 원인: VPC와 서브넷에서 IPv4를 비활성화 할 수 없다. 따라서 IPv6의 주소공간은 충분한데 서브넷에 사용 가능한 IPv4 주소가 부족하여 인스턴스 생성이 불가능한 경우가 생긴다.
  • 해결책: VPC 또는 서브넷에 새로운 IPv4 CIDR 블록을 추가하여 사용 가능한 IPv4 주소를 확보한다.

IPv6 활성화 및 설정 실습

1. VPC에서 IPv6 활성화

  1. VPC(DemoVPC)에서 IPv6 CIDR 블록 추가

    • Edit CIDRs 클릭 → Amazon 제공 CIDR 블록 선택
    • Select CIDR 버튼 클릭 → IPv6 CIDR 할당 완료

  2. 서브넷(PublicSubnetA)에 IPv6 CIDR 할당

    • Subnets → PublicSubnetA 선택
    • Action → Edit IPv6 CIDRs 선택
    • IPv6 CIDR 입력 후 저장

  3. IPv6 자동 할당 활성화

    • Edit subnet settings → IPv6 자동 할당 옵션 활성화

2. EC2 인스턴스에 IPv6 주소 추가

  1. Bastion Host에서 IPv6 주소 부여

    • EC2 인스턴스 → BastionHost 선택
    • Networking → Manage IP addresses 클릭
    • 자동 할당 IPv6 주소 추가 후 Save 및 Confirm

  2. 보안 그룹에서 IPv6 접근 허용

    • Edit inbound rules → SSH 규칙 추가
    • Anywhere-IPv6 선택 (IPv6 트래픽 허용)

3. IPv6 연결 테스트 및 접속

  1. IPv6 지원 여부 확인

    • Test your IPv6 웹사이트에서 현재 네트워크가 IPv6을 지원하는지 확인

  2. IPv6 주소를 통한 SSH 접속

    • IPv6 주소를 사용하여 SSH로 BastionHost에 연결
    • 단, 사용자의 인터넷 서비스 제공업체(ISP)가 IPv6를 지원해야 함

4. 라우팅 테이블 설정 확인

  1. PublicRouteTable에서 IPv6 라우팅 확인

    • Route 탭에서 IPv6 CIDR 규칙 확인
    • IPv6 주소 간의 통신은 로컬(Local)에서 이루어짐
    • 즉, 같은 VPC 내의 IPv6 주소는 인터넷을 거치지 않고 직접 통신 가능

5. IPv4 주소 부족 문제 해결 방법

  • 서브넷에 IPv4 주소가 남아 있어야 새로운 EC2 인스턴스를 생성할 수 있음
  • IPv6 주소가 많아도 IPv4 주소가 부족하면 인스턴스 생성 불가능
  • 해결책:
    • VPC 및 서브넷에 새로운 IPv4 CIDR 블록 추가
    • 추가된 IPv4 주소를 사용하여 EC2 인스턴스를 계속 생성

송신 전용 인터넷 게이트웨이(Egress-Only Internet Gateway)

송신 전용 인터넷 게이트웨이(Egress-Only Internet Gateway, EIGW)는 IPv6 트래픽 전용으로,
사설 서브넷 내 EC2 인스턴스가 인터넷으로 아웃바운드 연결은 가능하지만, 외부에서 해당 인스턴스로의 인바운드 연결은 차단되도록 설정하는 데 사용된다.

라우팅 테이블 설정

공용 서브넷 (Public Subnet)

  • 라우팅 테이블 항목

    대상대상 게이트웨이
    로컬 IPv4 (VPC CIDR)로컬
    로컬 IPv6 (VPC CIDR)로컬
    0.0.0.0/0 (IPv4 모든 트래픽)인터넷 게이트웨이 (IGW)
    ::/0 (IPv6 모든 트래픽)인터넷 게이트웨이 (IGW)

  • 설명:
    공용 서브넷의 EC2 인스턴스는 IPv4 및 IPv6를 통해 인터넷과 양방향 통신 가능

사설 서브넷 (Private Subnet)

  • 라우팅 테이블 항목

    대상대상 게이트웨이
    로컬 IPv4 (VPC CIDR)로컬
    로컬 IPv6 (VPC CIDR)로컬
    0.0.0.0/0 (IPv4 모든 트래픽)NAT Gateway
    ::/0 (IPv6 모든 트래픽)송신 전용 인터넷 게이트웨이 (EIGW)

  • 설명:
    사설 서브넷의 EC2 인스턴스는 IPv4 NAT Gateway를 통해 인터넷에 나갈 수 있음
    IPv6의 경우 송신 전용 인터넷 게이트웨이를 사용하여 인터넷에 나갈 수 있지만, 외부에서 접근할 수 없음

실습

  1. EIGW는 VPC 콘솔 > Egress Only Internet Gateways 메뉴에서 생성
  2. VPC를 EIGW에 연결
  3. 프라이빗 서브넷의 라우팅 테이블을 편집해서 ::/0이 EIGW로 향하도록 수정

AWS GB당 네트워킹 비용

  1. EC2 인스턴스 간 트래픽

    • 기본적으로 EC2 인스턴스로 향하는 트래픽은 무료
    • 같은 가용 영역(AZ)에 있는 EC2 인스턴스 간에 사설 IP로 통신할 경우 트래픽은 무료이다.
    • 다른 AZ에 있는 EC2 인스턴스 간 트래픽은 사설 IP를 사용하면 비용이 0.01달러로 절감된다. 공용 IP를 사용할 경우 GB당 0.02달러의 비용이 발생한다.

  2. 리전 간 트래픽

    • 다른 리전으로 트래픽이 이동하면 GB당 0.02달러의 비용이 발생한다. 이는 비용이 상당히 비쌀 수 있다.

  3. RDS 복제본

    • 같은 AZ에 읽기 전용 복제본을 생성하면 트래픽에 대한 비용이 없다.
    • 다른 AZ에 복제본을 생성하면, 트래픽 비용으로 GB당 0.01달러가 발생한다.

  4. 송신 트래픽 (아웃바운드 트래픽)

    • 외부로 나가는 트래픽은 비용이 발생한다. 반면, 수신 트래픽 (인바운드)은 대부분 무료이다.
    • 따라서 최대한 인터넷 트래픽을 AWS 내부에 두고 비용을 최소화한다.
      • 예시) 온프레미스에서 RDS에 100MB의 데이터를 받고 정제해서 최종 사용자에게 50KB를 전송하는 것과 RDS와 EC2를 AWS에 두고 최종 사용자에게 50KB를 전송하는 것은 송신 트래픽이 100MB vs 50KB로 비용 차이가 있다.
      • Direct Connect를 사용할 경우 Direct Connect Location을 동일한 AWS 리전으로 설정해 비용을 아낀다.
    • S3 버킷으로 들어가는 데이터는 수신트래픽이므로 전부 무료다. 하지만 데이터를 내려받을 때는 1GB당 0.09달러가 청구된다. S3 전송 가속화를 사용하면 전송 속도가 50~500% 정도 빨라지는데 추가 비용으로 GB당 4~8센트가 청구된다.

  5. S3 및 CloudFront

    • S3와 CloudFront 사이에서의 트래픽은 무료이다.
    • CloudFront에서 인터넷으로 트래픽을 보내면 GB당 0.085달러가 청구된다. S3에서 바로 트래픽이 나가는 것보다 약간 저렴하다. 캐싱 기능도 얻고 데이터 액세스 지연 시간도 짧아진다.
    • S3 리전 간 복제를 사용할 경우 GB당 0.02달러의 비용이 발생한다.

  6. NAT Gateway

    • NAT Gateway 사용 시 시간당 0.045달러와 1GB당 0.045달러의 비용이 발생한다.

  7. VPC 엔드포인트

    • VPC 엔드포인트는 S3와 같은 서비스를 사설 네트워크에서 안전하게 연결할 수 있으며, 비용이 더 저렴하다.
    • S3와 같은 서비스를 VPC 엔드포인트를 통해 사용할 경우 GB당 1센트의 비용이 발생한다.
      • VPC 엔드포인트를 사용하지 않고 프라이빗 EC2에서 NAT Gateway -> Internet Gateway -> Internet -> S3로 데이터를 요청할 때는 NAT gateway 비용과 만약 다른 리전이라면 리전간 송신비용 시간당 0.09달러가 청구된다. 동일한 리전이라면 비용이 발생하지 않는다. 따라서 VPC 엔드포인트가 훨씬 저렴하다.

사설 IP와 VPC 엔드포인트를 활용하면 비용 절감이 가능하고, 공용 IP나 NAT Gateway를 사용할 경우 더 많은 비용이 발생할 수 있다.

AWS Network Firewall

AWS Network Firewall은 전체 VPC를 보호하는 방화벽 서비스이다. VPC를 둘러싸는 형태로 작동하며, 계층 3부터 계층 7까지 보호한다. 모든 방향에서 들어오는 트래픽을 검사하며, 다음과 같은 트래픽을 보호할 수 있다.

  • VPC 간 트래픽
  • 인터넷 아웃바운드 및 인바운드 트래픽
  • Direct Connect 및 Site-to-Site VPN 연결

주요 기능

  1. 트래픽 보호 범위

    • 인터넷과의 모든 트래픽 보호
    • 피어링된 VPC 간 트래픽 보호
    • Direct Connect 및 Site-to-Site VPN 트래픽 보호

  2. 중앙 집중식 규칙 관리

    • AWS 자체 어플라이언스를 통해 트래픽을 관리
    • AWS Firewall Manager를 통해 여러 계정과 VPC에 동일한 규칙 적용 가능

  3. 세부적인 네트워크 트래픽 관리

    • VPC 수준에서 수천 개의 규칙 지원
    • 수만 개의 IP를 대상으로 필터링 가능 (IP 및 포트별 필터링 포함)
    • 프로토콜별 필터링 가능 (예: SMB 프로토콜 차단)
    • 도메인별 필터링 가능 (예: 특정 기업 도메인 및 타사 소프트웨어 리포지토리만 허용)
    • 정규 표현식(Regex)을 활용한 패턴 매칭 가능

  4. 침입 방지 및 로깅 기능

    • 활성 플로우 검사를 통해 침입 방지 기능 제공
    • 모든 규칙 일치 로그를 Amazon S3, CloudWatch Logs, Kinesis Data Firehose로 전송하여 분석 가능
profile
Siyun
공부 기록
이전 포스트

AWS 암호화

다음 포스트

AWS 재해복구

0개의 댓글