System
Amazon Web Services
AWS SAA 시험정리
4장 VPC

4장 VPC

4장 Amazon Virtual Private Cloud

4장의 목표

  • 복원력을 갖춘 아키텍처 설계
    • 어떻게 멀티 티어 아키텍처 솔루션을 설계할지 결정한다.

  • 안전한 어플리케이션 및 아키텍처 설계
    • 단일 VPC 어플리케이션을 위한 네트워킹 인프라르 정의한다.
    • 단일 VPC 애플리케이션을 위한 네트워킹 인프라르 정의한다.

 

Virtual Private Cloud ( 이하 VPC )

  • VPC란 EC2의 네트워크 계층으로, EC2 인스턴스를 비롯한 여러 AWS 서비스에 네트워크 리소스를 담을 수 있는 가상의 네트워크를 의미한다.

  • 모든 VPC는 기본적으로 다른 모든 네트워크와 격리되어 있지만, 필요할 때는 인터넷 및 다른 VPC와 연결이 가능하다.

  • VPC는 한 리전안에서만 존재할 수 있으며, 한 리전에 만든 VPC는 다른 리전에서는 볼 수 없다.

  • VPC에는 라우터, 스위치, VLAN과 같은 기존 네트워크 구성 요소들이 존재하지 않으며, 확장성을 실현하기 위해 소프트웨어 기능으로 추상화하였다.

 

VPC CIDR 블록

  • 기존 네트워크와 동일하게 VPC는 하나 이상의 연속적인 IP 주소 범위로 구성되며, CIDR ( Classless Inter Domain Routing ) 블록으로 표시된다.

  • VPC 내 인스턴스를 비롯한 리소스에 해당되는 IP 주소는 CIDR 블록으로 결정되며, VPC를 만들 때는 기본 CIDR 블록 주소의 할당이 필수이다.

  • 간략한 CIDR 설명

    • IP 접두사라는 CIDR 블록의 /16 부분은 접두사의 길이를 의미하며, VPC CIDR 접두사의 길이는 /16부터 /28까지를 의미한다..
    • CIDR과 IP 주소는 반비레 관계이며 접두사의 길이가 작을 수록 CIDR의 IP 주소는 많아진다.
    • 예를 드면 /28 접두사의 길이는 16개의 IP 주소만이 사용 가능하다.
주소 대역 할당 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 )
192.168.0.0 192.168.255.255 ( 192.168.0.0/16 )

  • VPC는 온 프레미스 네트워크나 다른 VPC 등 다른 네트워크에 연결하려면 사용할 VPC CIDR과 다른 네트워크에 연결하려면 주소와 중복되지 않도록 해야 한다.

  • 기본 CIDR 블록은 변경할 수 없으므로 VPC를 만들기 전에 주소 요구 사항을 신중히 검토해야 한다.

 

보조 CIDR 블록

  • VPC를 만든 후에도 보조 CIDR 블록을 지정할 수 있다.

  • 보조 CIDR 블록은 기본 CIDR 주소 범위나 퍼블릭 라우팅이 가능한 범위 내에서 생성돼야 하며, 기본 블록 또는 다른 보조 블록과 겹치지 않아야 한다.

  • VPC가 172.16.0.0/16일 경우 172.17.0.0/16으로 지정할 수 있지만, 192.168.0.0/16으로는 지정할 수 없다.

 

IPv6 CIDR 블록

  • VPC에 IPv6 CIDR을 할당 할 수 있으나, IP 접두사를 지정할 수 있는 기본 CIDR과는 달리 IPv6에서는 CIDR을 지정할 수 없다.

  • AWS에 요청을 하면, AWS가 VPC에 IPv6을 할당한다.

  • IPv6의 VPC CIDR의 접두사의 길이는 항상 /56이다.

 

서브넷

  • 서브넷은 VPC 내 논리 컨테이너로 EC2 인스턴스를 배치하는 장소이다.

  • 서브넷으르 통해 인스턴스를 서로 격리하고, 인스턴스 간 트래픽 흐름을 제어하고, 인스턴스를 기능별로 모을 수 있다.

  • 인스턴스는 서브넷 안에 있어야 하며, 한 서브넷에 생성된 인스턴스는 다른 서브넷으로 이동이 불가능하다.

 

서브넷 CIDR 블록

  • 서브넷의 CIDR은 VPC CIDR의 일부이면서, VPC 내에서 고유해야 한다.

  • 서브넷의 모든 IP의 첫 4개, 끝 1개는 사용할 수 없다.

    • 172.16.100.0 ~ 172.16.100.3
    • 127.16.100.255

  • 서브넷 CIDR 접두사의 길이 제한은 VPC CIDR과 동일할 수 있지만, 이리하면 공간이 남지 않기에 보통 서브넷의 CIDR은 VPC보다 길다.

  • VPC는 보조 CIDR을 가질 수 있지만, 서브넷에는 하나의 CIDR만이 사용 가능하다.

  • 만약 VPC가 보조 CIDR을 가지고 있을 경우, 서브넷은 적합한 CIDR을 선택해 생성할 수 있다.

 

가용 영역

  • 서브넷은 하나의 가용영역 ( Availability Zone 이하 AZ ) 내에서만 존재할 수 있으며, 가용 영역은 상대적으로 작은 지리적 위치, 데이터 센터의 개념이다.

  • AWS 리전의 가용영역들은 서로 연결되어 있으며, 한 가용 영역에 잘애가 발생하더라도 다른 영역에 장애의 영향이 미치지 않도록 설게되어있다.

  • 즉, 서로 다른 가용영역에 서브넷은 만든 후, 인스턴스를 각각 생성하면 애플리케이션은 복원성을 사용가능하다.

Subnet AZ Instance
web-subnet1 us-east-1a web1
web-subnet2 us-east-1b web2
  • 위와 같이 만약 us-east-1a의 생성된 web1의 인스턴스의 문제가 발생하더라도, web2 인스턴스의 서브넷은 다른 AZ에 속해있기 때문에 무중단 서비스가 가능하다.

 

IPv6 CIDR 블록

  • VPC에 IPv6 CIDR을 할당하면 해당 VPC 내 서브넷에 IPv6 CIDR을 할당할 수 있다. IPv6 서브넷의 접두사 길이는 /64로 고정되어있다.

 

탄력적 네트워크 인터페이스

  • 탄력적 네트워크 인터페이스 ( Elastic Network Interface 이하 ENI )를 사용하면 인스턴스가 AWS 서비스, 다른 인스턴스, 온 프레미스 서버, 인터넷 등 다른 네트워크의 리소스와 통신할 수 있다.

  • 기본적으로 물리 서버의 네트워크 인터페이스와 동일한 기능을 수행한다.

 

기본 프라이빗 주소와 보조 프라이빗 IP 주소

  • 각 인스턴스는 기본 프라이빗 주소를 가지고 있어야 하는 데, 그 주소는 서브넷 CIDR에서 지정한 범위 내 주소여야 한다.

  • 기본 프라이빗 IP 주소는 인스턴스의 기본 ENI에 연결되며 이 주소는 변경하거나 삭제가 불가능하다.

  • 보조 프라이빗 IP 주소에는 ENI를 할당할 수 있으며, 보조 주소는 ENI가 연결된 서브넷의 주소 내에서 할당된다.

  • ENI를 인스턴스에 추가해서 연결할 수 있고, 이 ENI를 다른 서브넷에 둘 수도 있지만, 해당 인스턴스와 같은 가용 영역에 있어야하며, ENI와 연결된 주소는 ENI가 있는 서브넷에서 가져와야 한다.

 

탄력적 네트워크 인터페이스 연결

  • ENI는 인스턴스와 독립적으로 존재가 가능하며, 먼저 ENI를 생성한 후 인스턴스를 생성하고 할당할 수 있다.

 

인터넷 게이트웨이

  • 인터넷 게이트웨이는 퍼블릭 IP 주소를 할당받은 인스턴스가 인터넷과 연결돼서 인터넷으로부터 요청을 수신하는 기능을 수행한다.

  • 처음 VPC를 생성하고, VPC에는 인터넷 게이트웨이가 연결되어 있지 않으므로, 직접 인터넷 게이트웨이를 만들어 VPC와 연결해야한다.

  • 인터넷 게이트웨이는 인터넷 서비스를 제공하는 업체의 온 프레미스에 설치하는 인터넷 라우터와 유사하지만, AWS에서 인터넷 게이트웨이는 라우터와 동일하게 동작하지는 않는다.

  • 기존 네트워크에서는 핵심 라우터의 주소를 인터넷으로 향하는 기본 게이트웨이 IP 주소로 구성해서 각 서버가 인터넷에 엑세스 할 수 있도록 한다.

  • 인터넷 게이트 웨이는 관리형 IP나 네트워크 인터페이스가 없는 대신, 식별을 위해 AWS 리소스 ID가 할당된다.

  • 인터넷 게이트 웨이는 igw-로 시작하며 그 뒤에는 영 숫자나 문자열이 온다.

  • 인터넷 게이트웨이를 사용하려면 인터넷 게이트웨이를 대상으로 하는 기본 라우팅을 라우팅 테이블에 만들어야 한다.

 

라우팅 테이블

  • VPC는 리소스 형태로 가상 라우터를 구성하지 않음, 소프트웨어 함수로 IP 라우팅을 구현한 내재된 라우터를 제공한다.

  • 사용자는 가상 라우터에서 인터페이스 IP 주소나 동적 라우팅 프로토콜을 구성하지 않고 내재된 라우터에서 라우팅 테이블만 관리하면 된다.

  • 각 라우팅 테이블은 하나 이상의 라우팅과 하나 이상의 서브넷의 연결로 구성되며, 기존의 라우터와 거의 동일한 방식으로 여러 서브넷에 연결되어 있다.

  • 라우팅 테이블과 서브넷은명시적으로 직접 연결하지 않더라도 서브넷에 암시적으로 기본 라우팅 테이블이 연결되므로, 모든 서브넷은 라우팅 테이블으로 연결된다.

 

라우팅

  • 라우팅은 라우팅 테이블과 연결된 서브넷 내 인스턴스에서 트래픽을 저달하는 방법을 결정한다.

  • IP라우팅은 원본 IP 주소가 아닌 대상 IP주소를 기반으로 작동하므로, 하위의 요소는 제공해야 한다.

    • 대상 주소
    • 대상

  • IP 주소는 CIDR 표기법의 IP 접두사여야 하며, 대상에는 CIDR은 사용할 수 없고, 인터넷 게이트웨이, ENI 등의 AWS 리소스가 지정되어야한다.

  • 모든 라우팅 테이블에는 각각 다른 서브넷에 있는 인스턴스들이 서로 통신할 수 있게 하는로컬 라우팅이 포함되어 있다.

 

기본 라우팅

  • 인스턴스가 인터넷에 액세스하게 하려면 인터넷 게이트웨이를 가리키는 기본 라우팅을 생성해야 한다.
대상 주소 대상
172.31.0.0/16 LOCAL
0.0.0.0/0 igw-xxxxxxxxx

  • 인터넷 상의 모든 호스트 IP 주소를 표기할 때는 0.0.0.0/0 접두사를 사용하므로, 기본 라우팅 대상 주소로 0.0.0.0/0의 접두사를 등록해야 한다.

  • 인터넷 게이트웨이를 가리키는 기본 라우팅이 포함된 라우팅 테이블과 연결된 서브넷을 퍼블릭 서브넷이라 한다.

  • 이와 반해서 프라이빗 서브넷은 기본 라우팅을 포함하지 않는다. 0.0.0.0/0과 172.31.0.0/16이 증복되어 있을 때, 트래픽을 라우팅할 위치를 결정할 때 내재된 라우터는 가장 근접하게 일치된 항목을 기반으로 라우팅 한다.

  • AWS docs에서는 VPC 당 내재된 라우터가 하나 존재한다고 기술되어 있으며, 이 라우터란 실제 개별 리소스가 아닌 IP 라우팅 기능을 추상화한 것으로 이해하면 된다.

 

보안 그룹

  • 보안 그룹은 방화벽과 같은 기능을 제공하며, 인스턴스의 ENI의 송수신되는 트래픽을 허가해서 인스턴스를 오가는 트래픽을 제어해야 한다.

  • 모든 ENI에는 최소한 하나의 보안 그룹이 연결되어야 하고, 한 ENI에 여러 개의 보안 그룹을 연결할 수 있으며, 한 보안 그룹을 여러 개의 ENI에 연결할 수도 있다.

  • 실제 인스턴스는 ENI를 하나만 연결해서 사용하기 땜누에 하나의 인스턴스에 하나의 보안 그룹만이 연결되어 있다고 생각하기 쉬운데, 인스턴스에 ENI가 여러 개 있는 경우에는 반드시 확인이 필요하다.

 

보안 그룹 인바운드 규칙

  • 인바운드 규칙은 연결된 ENI에 허용할 트래픽을 정의하는 것으로 아래의 3 가지의 필수 요소를 포함한다.

    • 출발 주소 ( source address )
    • 프로토콜
    • 포트 범위

  • 새로 생성한 보안 그룹에는 인바운드 규칙이 없으며, 연결한 인스턴스의 모든 트래픽을 차단한다.

  • 필요에 따라 특정 트래픽을 허용하려면 그 때마다 인바운드 규칙을 만들어야 하고, 이러한 이유로 보안 그룹에서 규칙의 순서는 중요하지 않다.

  • 아래의 항목은 HTTP와 SSH의 예시이다.

    원본 프로토콜 포트 범위
    151.123.231.2 ( 자기자신이 사용하고 있는 특정 IP ) TCP ( SSH ) 22
    0.0.0.0/0 ( 모두 접속할 수 있어야 하므로 ) HTTP 80

 

보안 그룹 아웃바운드 규칙

  • 아웃바운드 규칙은 인스턴스에 연결된 ENI르 통해 송수힐 수 있는 트래픽을 정의한 것으로, 아래의 세가 요소를 포함한다.

    • 목적지 주소
    • 프로토콜
    • 포트 범위

  • 보안 그룹의 아웃바운드 규칙은 인바운드 규칙보다 제한이 적으며, 보안 그룹을 생성할 때, AWS는 기본적으로 하단의 표로 모든 프로토콜과 포트가 열려 있는 아웃 바운드 규칙을 생성한다.

목적지 주소 프로토콜 포트 범위
0.0.0.0/0 모두 모두

 

원본과 대상 주소

  • 규칙의 원본이나 대상 주소에 CIDR 또는 보안 그룹의 리소스 ID를 지정할 수 있고, 보안 그룹에 연결된 모든 인스턴스 규칙이 적용된다.

 

상태 저장 방화벽

  • 보안 그룹은 상태 저장 방화벽 역할을 수행한다.

  • 상태 저장이란 보안 그룹이 트래픽을 한 방향으로 전달되도록 허용할 때, 반대 방향의 응답 트래픽을 지능적으로 허용하는 것을 의미한다.

 

기본 보안 그룹

  • 각 VPC엔느 삭제할 수 없는 기본 보안 그룹이 있으며, 필요하면 규칙을 수정할 수 있다.

  • 사용자 지정 봉나 그룹을 만들어 대신 사용하는 것도 가능하다.

 

네트워크 엑세스 제어 목록 ( Network Access Contol List : 이하 NACL )

  • NACL은 원본 또는 대상 주소 CIDR, 프로토콜, 포트를 기반으로 트래픅을 허용하는 인바운드와 아웃바운드 규칙을 포함한다.

  • NACL은 보안 그롭, 방화벽의 기능을 수행하며, 각 VPC에는 삭제할 수 없는 NACL이 있다는 점도 보안 그룹과 유사하다.

  • 하지만 NACL은 보안그룹과 달리, ECI가 아닌 서브넷에 연결되며, 서브넷과 연결된 NACL은 해당 서브넷과 송수신되는 트래픽을 제어한다.

  • 즉, 서브넷 내의 인스턴스간 트래픽을 제어할 때는 NACL을 사용할 수 없으며, 보안 그룹을 사용해야한다.

  • 서브넷은 하나의 NACL만 연결할 수 있으며, VPC에 서브넷을 만들면 기본적으로 VPC의 기본 NACL이 연결된다.

  • 서브넷과 NACL이 같은 VPC에 있다면 하나의 NACL을 여러 서브넷에 연결하는 것이 가능하다.

 

NACL 인바운드 규칙

  • 인바운드 규칙은 서브넷에 진입할 수 있는 트래픽을 정의하며, 다음 요소들을 포함한다.

    • 규칙 번호
    • 프로토콜
    • 포트 범위
    • 출발 주소
    • 동작 ( 허용/ 거부 )

  • IPv6 CIDR이 없는 VPC는 기본 NACL에는 표 4.5에 나열된 두 가지 인바운드 규칙이 포함되어있다.

규칙번호 프로토콜 포트 범위 출발 주소 허용/ 거부
100 모두 모두 0.0.0.0/0 ALLOW
* 모두 모두 0.0.0.0/0 DENY
  • NACL 규칙은 규칙 번호의 오름차순으로 처리된다.

 

NACL 아웃바운드 규칙

  • 아웃바운드 또한 인바운드 규칙과 거의 같은 형식을 따르며, 아래의 요소들을 포함한다.

    • 규칙 번호
    • 프로토콜
    • 포트 범위
    • 대상 주소
    • 동작 ( 허용/ 거부 )

  • 각 기본 NACL은 하단에 나열된 아웃바운드 규칙으로 제공되며, 아웃바운드 규칙은 대상 주소를 제외하고는 기본 인바운드 규칙과 동일하다.

규칙번호 프로토콜 포트 범위 도착 주소 허용/ 거부
100 모두 모두 0.0.0.0/0 ALLOW
* 모두 모두 0.0.0.0/0 DENY
  • NACL은 상태 비저장이므로 응답 트래픽을 자동으로 허용하지 않기 때문에, 만약 인바운드에서 HTTPS의 트래픽을 허용한다면, 아웃바운드 규칙에서도 응답 트래픽을 명시적으로 허용해야한다.
  • 기본적으로 최신 운영 체제에서는 49125-65535 범위의 임시 포트를 허용하지만, 이 범위는 충분하지않을 수 있다.

 

네트워크 엑세스 제어 목록과 보안 그룹을 같이 사용

  • 사용자가 인스턴스를 시작할 때, 보안 그룹을 올바르게 지정해야 하는 부담을 줄이기 위해 보안 그룹과 NACL을 함께 사용할 수 있다.

  • NACL은 서브넷에 적용되므로 NACL 규칙은 보안 그룹 구성 방법과 관계없이 서브넷에서 송수신하는 모든 트래픽에 적용된다.

  • NACL이나 보안 그룹은 규칙을 변경하면 해당 변경 사항이 즉시 적용 ( 실제로는 몇 초 의 시간이 소요 )

  • NACL에서는 원본 또는 대상 주소를 지정해야 CIDR을 사용할 수 있으며, 이는 보안 그룹의 원본이나 대상 주소를 다른 보안 그룹을 지정할 수 있는 보안 그룹 규칙과는 다른 점이다.

 

퍼블릭 IP 주소

  • 퍼블릭 IP주소는 퍼블릭 인터넷으로부터 인스턴스에 엑세스하는 데 필수 요소로 인터넷이 아닌 프라이빗 네트워크 내에서만 통신할 수 있는 RFC 1918 주소와는 다르다 할 수 있다.

  • AWS 외부에서 직접 인터넷을 통해 연결하려면 인스턴스에 퍼블릭 IP 주소가 필요하다.

  • 인스턴스에서 인터넷으로 전송만 하는 용도의 퍼블릭 IP 주소를 연결하는 방법도 있지만, 인스턴스 간에는 프라이빗 IP 주소로 통신하기 때문에, VPC 인프라 내에서 인스턴스 간 통신에는 퍼블릭 IP 주소가 필요하지 않다.

  • 퍼블릭 주소는 처음에만 할당이 가능하고, 생성 후에는 할당이 불가능하다.

  • 사용자가 재시작 하지 않았더라도, AWS 자체 유지보수 기능의 이해 변동 될 수 있다.

  • IP 주소가 바뀌어도 무방한 인스턴스에는 퍼블릭 IP를 사용해도 되지만, 장기간 같은 IP 주소를 유지해야하는 인스턴스에는 탄력적 IP 주소를 사용하는 것이 좋다.

 

탄력적 IP 주소 ( Elastic IP Address : 이하 EIP )

  • EIP는 AWS에서 사용자의 요청하면 계정에 할당되는 퍼블릭 IP 주소로 계정에 EIP가 할당되면 사용자가 직접 해제하지 않는 한 해당 주소를 독점적으로 사용할 수 있다.

  • AWS 외부에서 보면 EIP와 자동 할당된 퍼블릭 IP 간에는 차이점이 없다.

  • EIP는 인스턴스에 연결되지 않은 상태로 할당된다.

 

네트워크 주소 변환

  • ENI를 퍼블릭 IP 주소와 연결할 때는 ENI는 프라이빗 IP 주소를 그대로 유지한다.

  • 퍼블릭 IP를 ENI와 연결하더라도 ENI가 새로운 주소로 재구성되는 것이 아니며, 인터넷 게이트웨이는 네트워크 주소 변환이라는 프로세스를 활용해 퍼블릭 IP 주소와 ENI 프라이빗 주소를 연결한다.

  • 퍼블릭 IP가 있는 인스턴스에서 인터넷의 호스트로 연결하면 그 호스트는 인스턴스의 퍼블릭 IP에 있는 트래픽이 발생한 것으로 간주한다.

  • 예를 들면, 퍼블릭 IP가 있는 호스트에 프라이빗 IP 주소에 보내었다 해도 게이트 웨이를 지나 퍼블릭 IP를 통해 접속하게 된다.

  • 이 때 게이트웨이는 자동적으로 주소를 변화시키며, 사용자는 개입이 불가능하다.

 

네트워크 주소 변환 장치

  • 네트워크 주소 변환은 인터넷 게이트웨이에서 이루어지지만, 다음 두 가지 서비스도 네트워크 주소변환을 수행한다.

    • NAT 게이트웨이
    • NAT 인스턴스

  • AWS 서비스 속에서 이는 NAT 디바이스라 하며, 인스턴스가 인터넷에 액세스할 수 있게 되면서 인터넷상의 호스트에서는 인스턴스에 직접 도달하지 못하게 할 때 사용한다.

  • 이 기능은 이느턴스가 업데이트 패치를 받거나 데이터를 업로드할 때 인터넷에 연결할 필요는 있지만, 클라이언트 요청에 응답할 필요는 없을 때 유용하다.

  • NAT 디바이스를 사용하면 인스턴스가 액세스 할 필요가 있더라도 퍼블릭 IP 주소를 할당하지 않으므로, 인터넷 상의 호스트가 인스턴스에 직접 액세스하는 것은 불가능하다.

  • NAT 디바이스의 인터페이스는 퍼블릿 서브넷에 위치하면서 퍼블릭 IP가 연결된다.

  • 하단은 NAT 디바이스를 사용할 때의 IP 주소 구성이다.

이름 서브넷 프라이빗 IP 퍼블릭 IP
EC2-1 Private 10.0.0.10  
EC2-2 Private 10.0.0.11  
NAT 디바이스 Public 10.0.1.10 18.212.132.21

 

  • EC2-1, 2의 외부주소의 인터넷 호스트로 패킷을 전송하면 그 패킷은 먼저 NAT 디바이스로전달되고, NAT 디바이스에서는 아래와 같이 패킷을 변환한다.
원본 패킷의 원본 IP 주소 원본 패킷의 대상 IP 주소 –> 변환 –> 변환 패킷의 원본 IP 주소 변환 패킷의 대상 IP 주소
EC2-1 ( 10.0.0.10 ) 외부 주소 –> 변환 –> NAT 디바이스 ( 10.0.1.10 ) 외부 주소

 

  • 내부 대역에서 NAT 디바이스와의 변환을 마치게 되면 하단과 같이 NAT 디바이스와 인터넷 게이트웨이로의 변환이 다시 한번 이루어진다.
원본 패킷의 원본 IP 주소 원본 패킷의 대상 IP 주소 –> 변환 –> 변환 패킷의 원본 IP 주소 변환 패킷의 대상 IP 주소
NAT 디바이스 ( 10.0.1.10 ) 외부 주소 –> 변환 –> NAT 디바이스 ( 18.212.132.21 ) 외부 주소
  • 이와 같이 여러 인스턴스가 같은 NAT 디바이스를 사용할 수 있으므로 같은 퍼블릭 IP 주소를 공유해서 아웃 바운드에 연결할 수 있다.
  • NAT 디바이스가 수행하는 기능을 포트 주소 변환 ( Port Address Translation : 이하 PAT )이라고 한다.

 

NAT 디바이스를 사용한 라우팅 테이블 구성

  • 프라이빗 서브넷에서 트래픽이 인터넷으로 전송돼야 하는 경우, 트래픽이 NAT 디바이스를 향하도록 경로가 설정되어 있어야 한다.

  • NAT 디바이스에서 트래픽이 인터넷으로 전송되야 할 경우, 트래픽은 인터넷 게이트웨이로 향하도록 경로가 설정되어야 한다.

  • 따라서 NAT 디바이스와 라우팅가 인스턴스의 기본 라우팅은 다르게 구성되어야 하며, 복수의 라우팅 테이블을 사용해야 하므로 이에 따라 서브넷도 분리되어야 한다.

서브넷 대상 주소 대상
프라이빗 0.0.0.0/0 NAT 디바이스
퍼블릭 0.0.0.0/0 igw-0e538022a0fddc318
  • 위의 표는 프라이빗과 퍼블릿의 기본 라우팅을 나타낸다.

 

NAT 게이트웨이

  • NAT 게이트웨이는 AWS에서 관리하는 NAT 디바이스이며, 인터넷 게이트웨이처럼 하나의 NAT 게이트웨이로 어떠한 용량의 요청도 수행할 수 있다.

  • 한 종류의 NAT 게이트웨아만 제공되고, 자동 확장해서 모든 대역폭 요구에 대응하므로 용량 관리를 위한 디바이스에 엑세스할 필요가 없다.

  • NAT 게이트웨이를 생성할 때, EIP도 함께 할당해서 연결해야하고, 퍼블릭 서브넷 한 곳에 배포해서 인터넷에 엑세스할 수 있게 해야 한다.

  • NAT 게이트웨이는 포함되어 있는 서브넷에서 프라이빗 IP주소를 할당받는다.

  • NAT 게이트웨이를 생성 후에는 기본 라우팅을 만들어야 인스턴스의 인터넷 연결 트래픽이 NAT 게이트웨이로 전달된다.

  • NAT 게이트웨이의 명칭은 nat-xxxxxxxxx… 이며 기본 라우팅을 여러 개 만들 수 있다.

  • NAT 게이트웨이는 ENI를 사용하지 않으므로 보안 그룹을 적용할 수는 없지만, 서브넷에 NACL을 적용해서 트래픽을 제어할 수 있다.

 

NAT 인스턴스

  • NAT 인스턴스는 사전 구성된 Linux 기반 AMI를 사용하는 일반적인 EC2 인스턴스로, 만들 때도 동일한 단게를 가진다.

  • NAT 게이트웨이와 다방면에서 동일하다 할 수 있지만, 몇 가지 다른 점이 존재한다.

  • NAT 인스턴스는 대역폭 요구가 증가하더라도 자동으로 확장되지 않는다. 즉, 적절한 성능을 갖춘 인스턴스를 초기에 맞게 생성해야한다.

  • NAT 인스턴스는 ENI가 있으므로 보안 그룹을 적용해야 하며, 퍼블릭 IP주소를 할당해야 한다.

  • NAT 인스턴스의 한 가지 이점은 배스천 호스트 ( Bastion Host : 점프 호스트 )로 사용해서 퍼블릭 IP가 없는 인스턴스에 연결할 수 있다는 것이며, NAT 게이트웨이로는 이 작업을 수행할 수 없다.

  • 인스턴스나 가용 영역에 장애가 발생하면 다른 NAT 인스턴스로 확장하는 정도로는 간단한 대처가 불가능하며, 이는 기본 라우팅에 여러 NAT 인스턴스를 대상으로 경로를 지정할 수 없기 때문이다.

  • 즉, 높은 탄력성이 요구되면 NAT 게이트웨이를 사용하는 것이 현명하다.

 

VPC 피어링

  • VPC 피어링을 구성하면 VPC의 인스턴스가 프라이빗 AWS 네트워크를 통해 다른 VPC와 통신하게 할 수 있다.

  • 다른 리전에 있는 인스턴스와 통신이 필요할 때에도 이와 같은 작업을 수행할 수 있으며, 한 계정의 인스턴스를 다른 계정의 인스턴스와 연결할 수 있다.

  • VPC 피어링을 활성화하려면 두 VPC 사이에 VPC 피어링 연결을 설정해야 하며, VPC 피어링 연결은 아래와 같은 특징이 있다.

    • 두 VPC 사이의 지점간의 연결이다.
    • 두 VPC 간에는 단 하나의 피어링만 설정할 수 있다.
    • 두 VPC 간에는 서로 다른 CIDR을 사용해야 한다.

  • VPC 피어링 연결은 인스턴스 간 통신만 허용된다. 즉, 한 VPC 인스턴스에서 피어링 된 다른 VPC사이의 지점간 연결이며, 두 VPC 간에는 단 하나의 피어링만 설정할 수 있고, 두 VPC의 CIDR 블록은 겹치지 않아야 한다.

  • 인터넷 게이트웨이나 NAT 디바이스는 VPC 피어링으로 공유해서 사용할 수 없지만, Networkk Load Balancer만은 예외적으로 공유할 수 있다.

  • 2개 이상의 VPC를 연결하려면 한 VPC와 다른 모든 VPC 각각 1:1 피어링 연결을 생성해야 하며, 데이지 체인 방식 ( 전이전 구성 )으로 라우팅은 불가능하다.

  • 피어링 연결을 사용할면 트래픽이 양방향으로 오가도록 두 VPC에 새로운 라우팅을 만들어야 하고, 각 라우팅의 대상이 될 접두사는 대상 VPC 범위 내에 있어야 한다.

  • 각 경로의 대상은 pcx-xxxxxxx로 시작되는 피어링 연결 식별자로 존재한다.

원본 VPC CIDR 대상 VPC CIDR 대상
10.0.0.0/16 172.31.0.0/16 pcx-xxxxxxxxxxx
172.31.0.0/16 10.0.0.0/16 pcx-xxxxxxxxxxx
  • 위에 표는 라우팅이 서로 반대로 설정된 것은 양방향으로 트래픽을 허용한다는 의미이다.
  • 대상 CIDR은 대상 VPC CIDR과 정확히 일치할 필요는 없으며, 특정 서브넷 사이에서 피어링을 사용하려면 서브넷 CIDR을 대신 지정할 수 있다.

 

요약

  • VPC 서비스는 EC2 및 다른 AWS 서비스의 네트워크 인프라를 제공하는 서비스이다.

  • AWS는 기존 네트워크보다 구성하기 쉽도록 일부 네트워크 구성 요소를 추상화했지만, 여전히 VPC를 설계하기 위해서는 네트워크 기초 지식이 필요하다.

  • AWS 각 리전의 기본 VPC에 자동으로 기본 서브넷, 기본 라우팅 테이블, 기본 보안 그룹, 기본 NACL을 제공한다. 많은 이들이 기반부터 VPC를 구성하지 않고 기본 VPC를 장기간으로 사용하고 있다.

  • AWS 아키텍트라면 가상 네트워크 인프라를 기반부터 구성하는 방법을 이해하는 것이 중요하다.

  • 기본 VPC에서 구축한 인프라를 수정할 수 없을 때가 많지만, 대신 VPC를 기초부터 구성해서 인프라를 복제해야 하는 임무를 받을 수도 있다.

  • 이 과정에서 여러 트러블을 해결하고 기초를 공부할 수 있고, 기능에 대한 이해의 학습을 도와준다.

  • 기존의 네트워크에서는 서버 IP주소를 자유롭게 구성하고, 다른 서브넷으로 이동하며, 다른 물리적 위치로 이동시킬 수도 있다. 즉, 중간에 네트워크 계획을 변경할 수 있는 유연성이 존재하지만, VPC 생성 시에는 불가능하며, 이를 위해 사전에 인프라를 신중하게 계획해야 하므로, 전체 VPC와 EC2 구성 요소를 맞추는 방법을 이해하는 것이 중요하다.

  • CIDR로 표현되는 연속적 IP 주소 범위를 정하는 것으로 VPC를 생성하기 한다. 즉, CIDR의 범위를 사전에 모든 인스턴스들을 수용할 수 있을만큼 충분한 여유 주소를 넣어 두고 생성한다.

  • VPC CIDR을 서브넷으로 나눌 때는, 한 가용 영역에만 있는 컨테이너이기 때문에 인스턴스를 어디에 배치할지 사전에 결정해둬야 한다.

  • 서브넷에 인스턴스를 만들고 난 인스턴스를 다른 서브넷으로 옮길 수 없다.

  • 인스턴스를 시작하기 전에 보안 그룹을 구성할 필요가 있으며, 모든 인스턴스의 ENI에 보안 그룹을 하나 이상 연결해야 하며, 네트워크 엑세스 제어 목록은 상대적으로 변경이 가능해 유연성을 가지고 있으며, NACL은 언제든지 서브넷에 연결할 수 있고 제거가 가능하다.

  • 인터넷에서 인스턴스에 엑세스할 수 있게 하려면 기본적으로 인터넷 게이트웨이를 프로비저닝하고 기본 라우팅과 퍼블릭 IP 주소를 할당시켜야 한다.

  • NAT 게이트웨이나 인스턴스 혹은 VPC 피어링 연결을 사용하기로 했다면 여러 라우팅 테이블을 수정해야 한다.

 

시험 핵심

  • VPC나 서브넷에 필요한 IP 주소의 수를 기반으로 올바른 CIDR 블록 접두사 길이를 결정할 수 있어야 한다.
    • 접수다의 길이는 /16- /28까지 허용되며, 접두사의 길이가 길수록 사용할 수 있는 IP 주소 수는 줄어든다.

  • 서브넷의 중요성을 이해한다.

    • 서브넷은 EC2 인스턴스가 있는 논리적 컨테이너이다.

    • 각 서브넷의 CIDR 블록은 그 서브넷에 속해 있는 VPC CIDR의 일부다.

    • 한 서브넷에 속한 인스턴스는 그 서브넷의 CIDR 범위 내에서 프라이빗 IP주소를 가져온다.

    • 모든 서브넷에 처음 4개의 IP 주소와 마지막 IP 주소는 AWS에서 예약하기 때문에 인스턴스에 할당이 불가능하다.

  • 가용 영역 장애가 미치는 영향을 파악한다.

    • 한 영역에 장애가 발생하면 해당 영역의 모든 서브넷과 해당 서브넷의 모든 인스턴스가 함께 중단된다.

    • 한 영역에 장애가 일어나더라도 서비스의 중단을 피하려면 인스턴스를 여러 영역에 배포해 중복해서 구축한다.

  • 탄력적 네트워크 인터페이스(ENI)를 생성하고 사용하기 위한 규칙을 이해한다.
    • 모든 인스턴스에는 기본 프라이빗 IP 주소를 사용하는 기본 네트워크 인터페이스가 존재하야 하며, 인스턴스에 연결하는 추가 ENI는 기본 ENI와 같은 서브넷에 존재해야한다.

  • 라우팅 테이블을 생성, 수정, 사용할 수 있어야 한다.
    • VPC의 기본 라우팅 테이블의 목적과 VPC의 서브넷의 관계를 알아야 한다.
    • 인터넷 게이트웨이와 기본 라우팅 테이블을 사용해 퍼블릭 서브넷을 만드는 방법 또한 이해해야 한다.

  • 보안 그룹과 네트워크 엑세스 제어 목록 간의 차이점을 파악한다.
    • 상태 저장 보안 그룹과 상태비저장 NACL이 같은 결과를 얻기 위해서 각각 다르느 규칙을 사용해야 하는 이유를 이해한다.

  • 네트워크 주소 변환이 어떻게 작동되는 지 이해한다.
    • 인터넷 게이트웨이에서의 네트워크 주소 변환과 NAT 디바이스에서의 네트어크 주소 변환의 차이점을 이해한다.
    • NAT 디바이스에서의 네트워크 주소 변환은 포트 주소변환(PAT)라 하며, 여러 인스턴스가 한 NAT 디바이스의 단일 퍼블릭 IP 주소를 공유할 수 있다.

  • 여러 VPC 간에 VPC 피어링을 만들고 구성할 수 있어야 한다.
    • VPC 피어링 연결의 제한을 파악한다.
    • VPC 피어링 연결은 전이 라우팅과 IPv6를 지원하지 않는다. 일부 리전에서는 리전 간에도 피어링할 수 있다.

 

RSS Feed
마지막 수정일자
3장 S3와 Glacier5장 데이터베이스