Amazon VPC

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

모든 VPC는 기본적으로 다른 모든 네트워크와 격리돼 있지만. 필요할 때는 인터넷 및 다른 VPC 등 다른 네트워크와 연결할 수 있다.

VPC는 한 AWS리전 안에서만 존재할 수 있으며, 한 리전에서 만든 VPC는 다른 리전에서는 보이지 않는다. 하나의 계정에 여러 VPC를 둘 수 있고 단일 리전에 여러 VPC를 만들 수 있다.

VPC는 전통적인 네트워크 구성 요소인 라우터, 스위치, VLAN등을 사용하지 않으며, 네트워크로서의 확장성을 구현하기 위해 구성 요소를 소프트웨어 기능으로 추상화한 뒤 새로운 명칭으로 부른다.

VPC CIDR블록

VPC는 하나 이상의 연속적 IP 주소 범위인 Classless Inter Domain Routing(CIDR) 블록으로 표시한다. CIDR 블록은 VPC내의 인스턴스 및 리소스에 할당되는 IP 주소를 결정하며, VPC를 만들떄는 기본 CIDR블록을 할덩해야하며 VPC 생성 후에는 기본 VPC CIDR블록을 AWS에 따라 서브넷으로 나눠서 사용하게 된다.

IP 주소 범위를 가장 짧게 표현하는 방법은 빗금 문자 표기법(stash notation)이라고 부르는 CIDR 표기법이다. 예를들어 CIDR 172.16.0.0/16 이라는 표기법은 172.16.0.0~172.16.255.255에 이르는 총 65,536 개의 주소를 포함한다.

위의 /16은 IP의 길이를 나타내는 프리픽스 이며, 이는 서브넷 마스크의 길이를 나타내고 VPC CIDR의 범위는 /16에서 /28까지 가능하다. 길이 프리픽스가 작을수록 CIDR에 존재하는 IP주소의 수는 많아진다.

IP는 Internet protocol 버전 4 또는 IPv4의 축약어이며 유효한 프리픽스 길이는 /0~/32 까지이다. VPC CIDR 지정시 원하는 어떤 IP 범위라도 사용할 수 있지만 다른 퍼블릭 인터넷 주소와 충돌을 피하기 위해 RFC 1918범위를 사용할 것을 권장한다

• 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.169.0.0 - 192.168.255.255(192.168.0.0/16)

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

VPC 생성 후에는 기본 CIDR블록은 변경할 수 없으므로, 신중하게 만들어야한다.

보조 CIDR 블록

VPC를 만든 후에도 보조 CIDR 블록을 지정할 수 있다. 보조 CIDR 블록은 기본 CIDR 주소 범위나 퍼블릭에서 라우팅이 가능한 범위 내에서 생성돼야 하지만 기본 블록 또는 다른 보조 블록과 겹쳐도 무방하다.

IPv6 CIDR 블록

VPC에 IPv6 CIDR을 할당하는 것도 가능하다. 하지만 IP 프리픽스를 지정할 수 있는 기본 CIDR와 달리, IPv6에서는 지정할 수 없다. 대신 사용자가 AWS에 요청을 하면 AWS가 VPC에 IPv6 CIDR을 할당한다.
참고로 IPv6 VPC CIDR의 프리픽스 길이는 항상 /56dlek.

서브넷

서브넷은 VPC에 있는 네트워크 로직 컨테이너이다.

• EC2인스턴스와 같은 VPC리소스를 연결한다.
  - 인스턴스는 서브넷 내에 생성된다.
  • 서브넷에서 인스턴스 생성 이후 다른 서브넷으로 옮길 수 없다.
  • 옮기고 싶은면 기존 인스턴스 종료후 새 서브넷에서 시작해야한다.
• 서브넷은 네트워크상에 존재하는 여러 인스턴스를 서로 격리하는 역할을 한다.
• 인스턴스 간의 트래픽 유입 및 유출을 제어하고, 기능별로 조직화 한다.
  - ex) 인터넷 접속이 가능한 퍼들릭 웹서버용 서브넷 하나만들고, 웹 인스턴스만 접속할 수 있는 데이터 베이스 전용 서브넷을 하나 추가할 수 있다.
• 전통적인 LAN(VLAN)과 유사한 개념의 네트워크 요소

서브넷 CIDR 블록

서브넷의 CIDR은 VPC CIDR 영역 중 일부를 떼서 서브넷의 CIDR로 사용한다.

AWS는 모든 서브넷에서 처음 4개의 IP주소와 마지막 한 개의 IP주소를 예약해서 사용하므로, 이들 주소는 인스턴스에 할당할 수 없다.

하나의 VPC내에 있는 서브넷 CIDR블록은 서로 겹쳐서는 안되고, 서브넷에 CIDR을 할당한 뒤엔 변경할 수 없다.

서브넷과 VPC가 동일한 CIDR를 공유하는것은 가능하다(두개가 똑같게 but 일반적인 케이스는 아님) 하지만 일반적으로 하나의 VPC에 여러개의 서브넷을 둘 수 잇도록 한다.

VPC는 보조 CIDR을 가질 수 있지만 서브넷은 하나의 CIDR만 지닐 수 있다.

가용영역

서브넷은 하나의 가용 영역(Availability Zone) 내에서만 존재할 수 있다.
가용 영역은 리전에 비해 상대적으로 작은 지리적 위치이며, 개별 데이터 센터와 비슷한 개념이다. AWS 리전의 가용 영역은 서로 연결돼 있으며, 하나의 가용 영역에 장애가 발생하더라도 다른 영역에 그 영향이 미치지 않도록 설계 됐다.

서로 다른 가용 영역에 서브넷을 하나씩 만든 뒤 인스턴스를 이들 서브넷에 분산 배치해 애플리케이션의 복원성을 구현할 수 있다.

IPv6 CIDR 블록

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

일래스틱 네트워크 인터페이스

Elasitc Network Interface(ENI)

• 인스턴스가 AWS 서비스, 다른 인스턴스, 온프레미스 서버, 인터넷 등 다른 네트워크 리소스와 통신할 수 있도록 한다.
• Secure Shell(SHH) 또는 Remote Desktop Protocal(RDP)등을 이용해 인스턴스에서 실행되는 OS와도 통신 할 수 있다.
• 물리적 서버의 네트워크 인터페이스와 같은 기능을 제공하되, 환경설정에 따라 통신 대상과 방법 등을 세심하게 관리 가능하다.

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

각 인스턴스는 서브넷으로 지정한 범위 내의 기본 프라이빗 IP주소를 지녀야 하며, 기본 프라이빗 IP주소는 인스턴스의 기본 ENI와 연결된다.

이 주소는 변경 또는 삭제할 수 없지만, 기본 ENI에 보조 프라이빗 IP주소를 할당해서 사용할 수 있다.

보조 프라이빗 IP주소는 ENI가 부착된 서브넷 범위 내에 있어야 한다.
또한 ENI에 할당된 주소는 서브넷에 부착된 프라이빗 IP 주소 범위 내에 있어야 한다.

ENI 부착하기

ENI는 인스턴스와 독립적으로 존재할 수 있으며, ENI를 생성한 뒤 인스턴스에 부착 할 수 있다.
Case 1:
하나의 서브넷에 ENI만든 후 인스턴스를 시작할때 미리 만든 ENI를 기본 ENI로 부착할 수있다. (종료 시 삭제 속성 비활성화시 계속 사용가능)
Case 2:
인스턴스에 부착안된 ENI를 다른 인스턴스의 보조 ENI로 부착할 수 있다.
예를 들어 장애가 있는 인스턴스에서 ENI를 분리한뒤 정상 작동중인 다른 인스턴스에 연결하면 트래픽을 장애 인스턴스에서 정상인스턴스로 전환할 수 있다.

성능강화 네트워크

Enhanced Networking 는 ENI에 비해 고속의 네트워크 처리 속도 및 저지연성을 제공하며, 단일 루트 입출력 가상화(SR-IOV)기법을 사용한다.

SR-IOV 기법은 동일한 물리적 서버에서 호스팅되고 있는 다수의 인스턴스가 하이퍼바이저를 우회할 수 있도록 하므로 좀 더 낮은 CPU 활성화 수준 및 좀 더 높은 네트워크 성능을 제공한다.

성능강화 네트워크를 쓰려면 인스턴스 OS에 해당 네트워크를 지원할 수 있는 드라이버 설치가 필요하다(Amazon Linux 및 Ubuntu HVM AMI에는 ENA 지원이 기본적으로 탑재)

인터넷 게이트웨이

인터넷 게이트웨이는 퍼블릭 IP 주소를 지닌 인스턴스를 인터넷과 연결하며, 인터넷에서 들어오는 요청을 수신할 수 있도록 한다.

기본 VPC는 기본설정으로 인터넷 게이트웨이를 제공하지만, 직접 커스텀 VPC를 생성해서 사용하는 경우 인터넷 게이트웨이도 직접 생성한 뒤 연결해야한다.

하나의 VPC에는 단 하나의 인터넷 게이트웨이만 연결할 수 있다.

인터넷 게이트웨이는 라우터와 유사하지만, AWS에서 제공하는 인터넷 게이트웨이는 기존의 라우터와는 차이점이 있다.

전통적인 네트워크

• 서버가 인터넷과 연결되도록 코어 라우터의 기본 라우트가 인터넷 라우터의 내부 IP주소를 가리키도록 설정해야한다.

AWS I/G

• IP 주소나 네트워크 인터페이스가 없으며, AWS 리소스 ID를 식별용으로 할당한다.
• 이때 리소스 ID는 igw- 로 시작하며 그 뒤에 영문 및 숫자 문자열이 온다.

어쨌든 AWS에서 인터넷 게이트웨이를 사용하려면, 라우트 테이블에 인터넷 게이트웨이를 타겟으로 하는 기본 라우트를 생성해야한다.

라우트 테이블

VPC내에서 트래픽의 유입, 유출, 이동을 제어하려면 라우트 테이블에 저장된 라우트를 이용해야 한다. VPC 아키텍처는 IP라우팅을 소프트웨어 함수로 구현한 내재된 라우터의 특징을 가지기 때문에 사용자는 사용할 라우트 테이블만 관리하면 된다.

하나의 라우트 테이블에는 하나 혹은 그 이상의 라우트와 최소 하나의 서브넷 연결을 지닌다.

VPC를 생성할때 AWS는 메인 라우트 테이블이라 부르는 기본 라우트 테이블을 자동으로 생성한 뒤 이를 VPC의 모든 서브넷에 연결한다. 우리는 기본 라우트 테이블을 사용하거나 필요에 따라 커스텀 라우트 테이블을 직접 생성한 뒤 하나 혹은 그 이상의 서브넷과 연결해서 사용하면 된다.

서브넷은 라우트 테이블 연결없이 존재할 수 없으며, 서브넷을 커스텀 라우트 테이블에 명시적으로 연결하지 않으면, AWS가 암묵적으로 해당 서브넷을 기본 라우트 테이블에 연결한다.

라우트

라우트는 라우트 테이블과 연결된 서브넷 내에서의 트래픽 유입 및 유출을 결정한다. IP 라우팅은 소스 IP주소가 아닌, 대상 주소 IP 프리픽스에 의해서만 라우트 여부를 결정하는 대상 주소 기반 라우팅 기법이다.

라우팅 주소를 생성할때 필 수 요소

• 대상 주소 IP 프리픽스
  - CIDR표기법으로 작성된 IPv4 or IPv6 프리픽스
• 타겟 리소스
  - 인터넷 게이트웨이 또는 ENI등 AWS리소스
  - IP 프리픽스는 타겟으로 사용할 수 없다

모든 라우트 테이블에는 로컬 라우트가 포함돼 있어서 인스턴스가 다른 서브넷으로 이동해 서로 소통할 수 있도록 한다. 즉 동일 VPC내 인스턴스 간의 소통을 허용한다

기본 설정 라우트

인터넷을 통해 인스턴스에 접근하도록 하려면, 기본 라우트를 생성한 뒤 인터넷 게이트웨이로 향하도록 해야한다.

0.0.0.0/0 프리픽스는 인터넷 호스트를 포함 모든 IP주소를 사용한다는 의미이며, 기본라우트는 항상 이 값으로 설정된다.

퍼블릭 서브넷은 인터넷 게이트웨이로 향하는 라우트를 포함한 서브넷이고,
프라이빗 서브넷은 인터넷 게이트웨이를 대상으로 하는 라우트가 하나도 없는 서브넷을 의미한다.

AWS 개발자 문서에는 VPC당 내재된 라우터는 하나가 있다고 설명한다. 내재된 라우터는 실재로 존재하는 개별 리소스가 아니라 IP라우팅 기능을 추상화 한것이며, 라우트 테이블은 하나 이상의 서브넷에 연결된 개별적인 가상 라우터이다.

보안그룹

보안 그룹 (Security group)은 방화벽과 같은 기능을 하며, 인스턴스 ENI에 대한 트래픽의 유입 또는 유출 여부를 허용 또는 거부하는 방식으로 인스턴스의 트래픽을 제어 한다.

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

인바운드 규칙

인바운드 규칙은 인스턴스에 부착된 ENI에 유입되는 트래픽의 허용 여부를 결정하며 다음 세가지 필수 요소를 지닌다.

• 소스
• 프로토콜
• 포트범위

새로 생성한 보안 그룹에는 인바운드 규칙이 존재하지 않는다. 보안 그룹은 기본 거부 방식을 사용하므로, 규칙에 의해 명시적으로 허용되지 않은 모든 트래픽은 거부된다.

아웃바운드 규칙

아웃바운드 규칙은 인스턴스에 부착된 ENI에서 유출되는 트래픽의 허용 여부를 결정하며 다음 세 가지 필수 요소를 지닌다.

• 소스
• 프로토콜
• 포트범위

아웃바운드 규칙은 인바운드 규칙에 비해 트래픽 제약 수준이 좀 더 낮은 경우가 많다. 보안 그룹을 생성하면 AWS는 자동으로 0.0.0.0/0 ALL(프로토콜) ALL(포트범위) 의 규칙을 생성한다.

이 규칙은 인스턴스가 인터넷 및 다른 AWS 리소스에 접속할 수 있도록 하는 것이다.

소스 및 대상 주소

보안 그룹의 규칙에서 소스나 대상 주소는 CIDR 블록 또는 보안 그룹의 리소스 ID가 될 수 있다. 예를 들어 보안 그룹을 인바운드 규칙의 소스로 지정하면 해당 보안 그룹이 부착된 모든 인스턴스의 트래픽을 허용한다.
즉 다수의 인스턴스에 동일한 보안 그룹을 부착해서 인스턴스가 서로 소통하도록 할 수 있다.

소스 보안 그룹은 다른 AWS 계정에 있어도 무방하며, 이 떄 소스 보안 그룹에 해당 계정 소유자 ID를 지정하면 된다.

스테이트풀 방화벽

보안 그룹은 상태 저장 방화벽(stateful firewall)의 기능을 제공한다.
보안 그룹이 트래픽을 한 방향으로 전달하도록 허용한 뒤, 반대 방향의 응답 트래픽을 (상태를 기억했다가) 지능적으로 허용하는 것을 의미한다.

보안그릅은 연결추적 기능을 이용해서 응답 트래픽의 허용 여부를 결정한다. 보안 그룹은 패킷 흐름을 추적해 응답 트래픽이 동일한 플로우에 포함된 것인지 확인해 다른 미분류 트래픽과 구분해낸다.

플로우 정보

• 프로토콜
• 소스 및 대상 주소 IP
• 소스 및 대상 주소 포트 번호

기본 보안 그룹

모든 VPC에는 삭제 불가능한 기본 보안 그룹이 포함돼 있다.
기본 보안 그룹을 사용 할 때는 본인의 필요에 맞춰 규칙을 수정한 뒤 사용하면 된다. 기본 보안 그룹 대신 직접 커스텀 보안 그룹을 만들어 사용해도 된다 .

네트워크 접속 제어 목록(NACL)

Network access control list은 소스 대상 주소 CIDR, 프로토콜, 포트 기반의 인바운드 및 아웃바운드 규칙을 제공한다는 측면에서 보안 그룹과 같은 방화벽 기능을 수행한다.

각 VPC에는 삭제할 수 없는 기본 NACL 이 있다.

보안그룹과 다른점은 NACL은 ENI가 아닌 서브넷에 연결되고, 서브넷과 연결된 NACL은 해당 서브넷으로 유입 및 유출되는 트래픽을 제어한다. 즉 서브넷 내의 인스턴스 간 트래픽을 제어할 때는 NACL을 사용할 수 없으며 보안그룹을 사용해야한다.

서브넷에는 하나의 NACL만 연겨할 수 있다. 사용자는 기본 NACL을 수정하거나 새 NACL을 만들어 서브넷에 연결할 수도 있다.

NACL은 statless 상태 비저장 속성을 지닌다. 즉 NACL을 통과하는 연결 상태를 추적하지 않고 응답 트래픽을 자동으로 허용하지 않는다.
이런 statless 속성으로 인해 모든 인바운드와 아웃바운드 트래픽의 허용 규칙을 별도로 작성해야한다.

인바운드 규칙

인바운드 규칙은 서브넷으로 유입되는 트래픽의 허용 여부를 결정하며, 아래의 내용이 포함된다.

• 규칙 번호
• 프로토콜
• 포트범위
• 소스 CIDR
• 동작(허용 또는 거부)

VPC의 기본 NACL은 IPv6 CIDR가 없다.
NACL 규칙은 규칙 번호가 오름차순으로 처리된다.
가장 작은 번호를 가진 규칙이 가장 먼저 처리된다.

기본 규칙에는 숫자 대신 별표(*) 로 순서를 지정해서 항상 규칙 목록 중 마지막에 적용된다. NACL의 기본 규칙은 삭제하거나 변경할 수 없으며, 선순위 규칙에서 명시적으로 허용하지 않은 모든 트래픽을 거부한다.

아웃바운드 규칙

NACL 아웃바운드 규칙은 앞의 인바운드 규칙과 유사하다

• 규칙번호
• 프로토콜
• 포트범위
• 소스
• 동작
  대상 주소열이 추가되는것 외에는 기본 인바운드 규칙과 동일하다.
  NACL은 statless 속성에 따라 응답 트래픽을 자동으로 허용하지 않는다.
  즉 인바운드 규칙에서 HTTPS트래픽을 허용했다면 아웃바운드 규칙에서 이에 대한 응답 트래픽을 명시적으로 허용해야한다.

NACL과 보안그룹을 함께 사용하기

인스턴스를 시작할때 보안 그룹을 올바르게 지정해야 하는 부담을 줄이기 위해 보안 그룹과 NACL을 함께 사용할 수 있다. NACL은 서브넷에 적용되므로, NACL 규칙은 보안 그룹의 설정 내용과 상관 없이 서브넷의 모든 유입 및 유출 트래픽에 적용된다.

퍼블릭 IP 주소

퍼블릭 IP 주소는 퍼블릭 인터넷으로 접속 가능한 주소이다. 다른 사용자가 인터넷을 통해 우리의 인스턴스에 직접 접속할 수 있도록 하려면 퍼블릭 IP가 필요하다. 이를 위해서는 해당 인스턴스가 포함된 VPC에 인터넷 게이트웨이를 연결해야한다.

VPC 인프라 내부에서 인스턴스 간의 소통을 할 때는 프라이빗 IP주소를 사용함으로 퍼들릭 IP주소를 사용하지 않아도 된다.

서브넷에서 인스턴스를 시작할때 자동으로 IP주소를 할당하게 하면 몇가지 문제 점이 있다.

• 자동으로 할당된 퍼블릭 IP주소는 지속성이 없다.
• 인스턴스 중지 또는 종료 시 해당 퍼블릭 IP주소도 함께 삭제된다.
• 인스턴스 재시작시 새로운 퍼블릭 IP주소가 할당된다.

따라서 애플리케이션 관리의 일관성등을 위해 동일한 주소를 유지해야할 경우 EIP - 일레스틱 IP(탄력적 IP) 를 사용하는 것이 좋다.

탄력적 IP

탄력적 IP(elastic ip address,EIP) 는 사용자 요청에 따라 AWS가 사용자의 계정에 할당하는 퍼블릭 IP 주소이다. 계정에 EIP가 할당되면 사용자가 직접 해제하지 않은 한 해당 주소를 독점적으로 사용할 수 있다.

AWS외부에서보면 EIP와 AWS가 자동으로 할당한 퍼블릭 IP간에는 차이가 없다.

EIP를 처음 생성하면 인스턴스와 연결되지 않은 상태로 만들어지기 때문에 우리가 직접 EIP를 ENI와 연결해야한다. 이때 한번에 하나의 ENI와만 연결 할 수 있다.

이미 퍼블릭IP로 할당된 ENI에 EIP를 연결하면 AWS가 퍼블릭 IP주소를 EIP로 변경한다.

EIP는 AWS리전단위로 제공됨으로 리전을 벗어날 수는 없다.

AWS 글로벌 엑셀러레이터

리소스가 AWS의 여러 리전에 배포되어 있다면 리전 별로 여러 개의 EIP를 관리하는 일이 복잡하기 느껴질 수 있따. AWS 글로벌 엑셀러레이터는 어디에든 연결할 수 있는 두개의 정적 IPv4 주소를 제공하며 이를 통해 어떤 리전에 있는 리소스라도 서로 연결 할 수 있다.

AWS 리전별 서비스인 EIP와 달리 AWS 글로벌 엑셀러레이터는 30여 개국에 퍼져 있는 AWS 접속 포인트(POP)를 연결한 정적 주소 체계이다. 이들 정적 주소는 동시에 다수의 접속 포인트를 연결할 수 있으므로 애니캐스트 주소로도 부른다.

정적 주소로 연결된 사용자는 자동으로 최인접 POP로 라우팅 된다.
리스너는 패킷을 수신한 뒤 미리 지정한 엔드포인트 그룹의 리소스에 전달한다.
엔드포인트 그룹에는 EIP,ELB,EC2 인스턴스를 포함시킬 수 이ㅆ다.

글로벌 엑셀러레이터는 애니케스트 주소를 통해 가장 빠른 엔드포인트로 트래픽을 전송한다.

네트워크 주소 반환

ENI와 퍼블릭 IP주소를 연결한 뒤에도 ENI는 프라이빗 IP주소를 유지하게 되며, ENI와 퍼블릭 IP 주소를 연결하더라도 새로운 주소로 ENI의 환경을 재설정하지 않는다.

대신 인터넷 게이트웨이가 퍼블릭 IP주소를 ENI의 프라이븟 IP주소로 맵핑하게 되며 이러한 프로세스를 네트워크 주소 변환 NAT(natework address treanlation)이라 부른다.

퍼블릭 IP를 지닌 인스턴스를 인터넷 상의 호스트에 연결하면 호스트는 인스턴스의 퍼블릭 IP에서 나온 트래픽을 수신할 수 있다.

Ex)
Private IP -> 퍼블릭 IP -> 타겟 IP
퍼블릭 IP 를 기반으로 해서 IP의 맵핑 처리등이 진행된다.

NAT 작업은 인스턴스가 퍼블릭 IP주소를 지닌 경우 인터넷 게이트웨이에서 자동으로 이뤄진다.

NAT 디바이스

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

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

AWS가 제공하는 NAT디바이스는 인스턴스가 인터넷에 접속할 수 있게 하면서, 인터넷 상의 호스트는 인스턴스에 직접 접속하지 못하게 한다는 데 기본 목적이 있다.

• 인스턴스를 위한 업데이트 또는 데이터 업로드시 인터넷에는 연결하되 클라이언트 요청에 응답할 필요는 없을 때 유용하다.

NAT 디바이스를 사용하면 인스턴스가 인터넷에 접속해야 할 때도 퍼블릭 IP 주소를 할당하지 않으므로, 인터넷 상의 호스트가 직접 인스턴스에 접근할 수 없으며 오직 NAT 디바이스의 퍼블릭 서브넷 내 인터페이스만이 퍼블릭 IP와 연결된다.
(즉 NAT의 퍼블릭 IP 를 기반으로 외부와 통신을 하게 된다)

여러 인스턴스가 같은 NAT디바이스를 사용할 수 있으므로, 동일한 퍼블릭 IP 주소를 공유해서 아웃바운드 연결을 생성 할 수 있다. NAT디바이스의 이와 같은 작업을 포트 주소 변환 PAT(port address translation) 로도 부른다
-> EKS 환경에서 여러 인스턴스가 떠있어도 외부에 방화벽 해제 요청등 할때NAT IP 주소만 전달하면 해결된다.

NAT 디바이스를 위한 라우트 테이블 설정 변경

NAT 디바이스를 사용하는 인스턴스는 인터넷으로 연결된 트래픽을 NAT 디바이스로 보내고 NAT 디바이스는 다시 이 트래픽을 인터넷 게이트웨이로 전송해야 한다.

따라서 NAT 디바이스와 이를 사용하는 인스턴스는의 기본 라우트는 서로 달라야 하고 별도의 서브넷에 존재해야 한다.

NAT 게이트웨이

NAT 게이트웨이는 AWS에서 관리하는 NAT 디바이스로서 인터넷 게이트웨이처럼 하나의 NAT 게이트웨이로 어떠한 형식의 요청도 처리할 수있따.

단일 유형의 NAT 게이트웨이만 제공되지만, 사용자는 별도의 관리 또는 접속작업을 할 필요가 없으며 자동으로 모든 대역ㅂ폭의 요구에 대응하므로 용량 관리 문제를 신경 쓸 필요가 없다.

사용자는 NAT게이트웨이를 생성할 때 EIP를 할당해서 연결해야 하며, 인터넷 접속이 가능하도록 퍼블릭 서브넷에 생성한다. 그러면 AWS가 해당 서브넷에 있는 프라이빗 IP주소를 NAT 게이트웨이에 할당한다. 중복 구현을 위해 다른 AZ에 NAT 게이트웨이를 추가로 생성할 수 있다.

NAT게이트를 만들고 나서는 기본 라우트를 만들어서 인스턴스에서 인터넷으로 향하는 트래픽이 NAT 게이트웨이로 전달 되도록 한다. 기본 라우트 대상은 nat-08419120 등 과 같은 형식의 NAT게이트웨이 ID를 지정한다.

여러 개의 NAT 게이트웨이를 사용하는 경우, 트래픽 타겟 또는 대상으로 각각 NAT게이트웨이를 향하도록 여러 개의 기본 라우트를 생성할 수 있다.

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

NAT게이트웨이는 IPv4 / IPv6 간의 네트워크 주소 변환 지원함

NAT 인스턴스

NAT인스턴스는 Linux 기반 AMI로 생성된 일반적인 EC2 인스턴스의 일종이며, 다른 인스턴스와 동일한 방법으로 생성한다.

기능적으로 NAT게이트웨이와 공통점도 있지만 중요한 차이점도 몇 가지 있다.

• NAT인스턴스는 NAT게이트웨이와 달리 대역폭 요구가 증가하더라도 자동으로 확장되지 않으므로, 처음부터 적절한 성능을 갖춘 인스턴스 유형을 선택하는 것이 중요한다.
• NAT 인스턴스는 ENI를 지니므로 보안 그룹을 적용해야하고, 직접 퍼블릭 IP주소도 할당해야한다.
• NAT인스턴스의 ENI에서 소스/대상주소 옵션을 비활성화 해야한다(이렇게 해야 NAT인스턴스가 자신의 IP로 향하는 트래픽을 수신하고 자신이 보유하지 않은 IP로 트래픽을 송신할 수 있다.)

NAT인스턴스의 장점은 NAT인스턴스를 Bastion Host 또는 Jupm host로 사용해서 퍼블릭 IP가 없는 인스턴스에 연결할 수 있다는 것이다.

사용자는 기본 라우트를 생성한 뒤 인터넷 연결 트래픽을 NAT인스턴스로 보낼 수 있다. 기본 라우트의 타겟은 i-0a1631939139 과 같은 형식의 NAT인스턴스의 ID
이다.

NAT인스턴스는 인스턴스나 AZ의 장애 발생시 다른 NAT 인스턴스로 대체하는 것과 같이 간단하게 문제를 해결할 수 없다는 단점이 있다. 이는 기본라우트를 하나만 정의해서 사용하기 때문에 다른 NAT인스턴스를 가리키도록 하는것이 불가능하기 때문이며 네트워크 복원성이 중요하다면 NAT 게이트웨이를 사용하는 것이좋다.
(현재 NAT인스턴스는 aws의 권장사항이 아니다)

AWS PrivateLink

AWS PrivateLink 는 인터넷을 우회해 VPC 리소스, AWS서비스, 온프레미스 리소스가 서로 통신할 수 있는 방법을 제공한다.
privatelink는 aws리전, 엣지 로케이션등 자체 네트워크와 고객 데이터 센터를 연결하는 전용의 프라이빗 통신선을 이용한다. 퍼블릭 인터넷망을 우회해 통신하기 때문에 저지연성의 신뢰성 높은 연결성을 제공한다.

VPC 피어링

VPC 피어링을 구성하면 프라이빗 AWS네트워크를 통해 하나의 VPC에 포함된 인스턴스가 다른 VPC에 포한된 인스턴스와 소통할 수 있다.
이는 서로 다른 리전에 있는 인스턴스간의 소통이 필요하거나, 본인의 계정과 다른 AWS계정의 인스턴스와 연결할 때 사용할 수 있다.

두 vpc사이에 vpc 피어링 연결을 통해서 피어링을 활성화 해줘야하며 점대점 연결이기 때문에 두 vpc 간에는 하나의 피어링만 설정할 수 있고, 두 vpc의 CIDR블록은 겹치지 않아야 한다.

VPC피어링 연결은 인스턴스 간 통신만 허용한다. VPC 피어링 환경에서 인터넷 게이트웨이나 NAT디바이스는 공유할 수 없지만 NLB(natwork load balancer)는 공유할 수 있다.

2개 이상의 VPC를 연결하려면 하나의 VPC와 다른 모든 VPC 마다 1:1 피어링 연결을 생성해야한다. 즉 하나의 VPC 쌍마다 각각 VPC 피어링을 생성해야한다.

피어링 연결을 사용하려면 트래픽이 양방향으로 소통되도록 두 VPC에 새로운 라우트 규칙을 추가한다.

하이브리드 클라우드 네트워킹

기업 데이터 센터와 관련된 리소스의 경우 프라이빗 속성을 지니고 인터넷과도 연결성이 없더록 설계한다. AWS의 온프레미스와 VPC의 프라이빗 연결 서비스는 아래와 같다.

AWS Site-to-Site VPN

VPN을 이용하면 퍼블릭 인터넷을 이용해 VPC와 데이터 센터 또는 사무실 등 온프레미스 네트워크를 안전하게 연결 할 수 있다.

VPC(virtual private gateway) 리소스를 구성하고, 온프레미스 라우터 또는 방화벽등 고객이 게이트웨이를 구성하면 된다. 이를 통해 VPG로 암호화 VPN터널이 생성된다.

온프레미스 네트워크를 여러 개의 VPC와 연결하려면 각 VPC마다 별도의 VPG및 VPN터널을 생성해야 한다.

대량의 VPC를 온프레미스에 연결할때 혹은 다수의 온프레미스 네트워크를 하나의 VPC에 연결할때는 AWS Transit Gateway를 사용하는게 좋다.

AWS Transit Gateway

Direct Connect 링크와 VPN을 사용해서 다수의 VPC및 다수의 온프레미스 네트워크를 연결할 수 있도록 해주는 고가용성 서비스다. 연결작업을 간소화하고 VPC와 온프레미스에 대한 트래픽은 매우 세밀하게 제어할 수 있도록 돕는다.

Transit Gateway의 부착 리소스는 시간 단위로 과금된다.
또한 아래의 5가지 방법으로 주로 활용된다.

1. 중앙화 라우터
   • 중앙화 라우터로 사용해 우리의 모든 VPC및 온프레미스 트래픽을 제어하는데 활용할 수 있다.
   • 하나의 Transit gateway 라우트 테이블에 다른 모든 리소스를 연결한다.
2. 격리 VPC
   • 하나의 Transit Gateway에 다수의 격리 VPC를 생성할 수 있다.
   • 격리 VPC는 여러개의 VPC를 보유한 상황에서 온프레미스 네트워크와는 연결성을 유지하면서도 VPC간에는 서로 격리성을 유지하려 할 때 유용하다.
3. 공유 서비스에서의 격리 VPC 사용
   • 하나의 VPC에서 Active Directory 또는 LLDP 등의 공유 호스팅을 하는 경우 Transit Gateway를 이용해서 격리 및 보안이 유지된 상태에서 공유 환경을 구성할 수 있다.
4. Transit Gateway 피어링
   • 서로 다른 리전간의 피어링을 할 수도 있다.
5. 멀티 캐스트
   • VPC 간의 멀티캐스트도 지원이 가능하다.
   • 멀티캐스르 그룹 주소 및 인스턴스를 지정해 멀티캐스트 트래픽을 수신할 수 있다.

블랙홀 라우트

특정 라우트를 차단하고 싶으면 Transit Gateway라우트 테이블에 블랙홀 엔트리를 추가하면된다.

• 추가된 블랙홀 라우트는 미리 지정된 라우트의 트래픽을 전부 차단한다.

AWS Direct Connect

AWS Direct Connect 서비스는 우리의 AWS 리소스에 대한 프라이빗, 저지연성 연결을 제공한다. 이를 이용하면 특정 리전에 있는 EC2및 RDS인스턴스 등 모든 AWS리소스에 퍼블릭이 아닌 프라이빗 인터넷 망으로 접속할 수 있다.

주요 장점

• AWS 리소스 접속시 인터넷을 우회해서 접속 할 수 있는 방법 제공
• 광대역 인터넷을 사용할 수 있도록 해준다.
• 대량의 데이터를 전송할때 유용하다.
• 실시간 데이터를 전송할때 유용하다.
• 법규에 의해서 퍼블릭 인터넷으로 데이터를 전송해서 안될 때도 유용하다.

전용 연결 타입

전용(dedicated) 연결 타입은 물리적인 단일 연결로 AWS Direct Connect지점에서 중단된다. 전용 연결을 이용하려면 Direct Connect 지점에 자체 장비를 추가해야한다. 각 연결 지점은 AWS리전과 연결돼 있으며, 연결 지점을 통해 해당 리전에 있는 AWS 리소스에 접속할 수 있다.
(1Gbps or 10Gbps)

호스트 연결 타입

1Gbps 미만의 연결 속도로 충분하거나 Direct Connect 지점에 자체 장비를 추가할 여력이 없다면 50Mbps~10Gbps 연결을 지원하는 호스트 연결 타입을 이용할 수 있다. 호스트 연결 타입은 Direct Connect 연결 지점에서 우리의 데이터 센터 또는 사무실을 이어주는 라스트 마일 연결을 제공한다.

가상 인터페이스

사용자는 Direct Connect 연결 방식에 따라 하나이상의 가상인터페이스를 생성해서 사용하게 되며 AWS가 제공하는 3가지 가상 인터페이스는 아래와 같다

1. 프라이빗 가상 인터페이스
   • 단일 VPC내, EC2 또는 RDS인스턴스 등과 같은 리소스의 프라이빗 IP 주소에 연결할 수 있다.
2. 퍼블릭 가상 인터페이스
   • 퍼블릭 엔드포인트를 지닌 S3 또는 DynamoDB와 같은 AWS 서비스의 퍼블릭 IP 주소에 연결할 수 있다.
   • 온프레미스 애플리케이션을 퍼빌릭 엔드포인트를 이용해서 AWS서비스에 연결하려는 경우 유용하다.
3. 트랜싯 가상 인터페이스
   • 하나 이상의 AWS 트랜싯 게이트웨이에 연결한다.
   • 다수의 VPC에 흩어져 있는 리소스를 연결할 떄 주로 사용한다.
   • 1Gbps 이상의 속도를 제공한다.

고성능 컴퓨팅

고성능 컴퓨팅(High-performance computing,HPC)는 집약적인 워크로드를 다수의 인스턴스를 이용해서 동시에 병렬적으로 처리하는 연산 패러다임이다.
이때 인스턴스는 HPC 클러스터를 이루게 되며, 인스턴스 간의 상호작용 수준에 따라 두 개의 카테고리로 나뉜다.

느슨하게 연결된 클러스터

느슨하게 연결된 워크로드는 개별 인스턴스가 독립적으로 처리할 수 있도록 다시 세분화 되며, 이미지 프로세싱 등의 업무에 주로 활용된다.

느슨하게 연결된 클러스터의 경우, 하나의 인스턴스는 다른 인스턴스와 완전히 별개의 요소로 작동하며, 고속의 통신 등을 필요로 하지 않으므로 별개의 클러스터 플레이스먼트 그룹에 배치할 수 있다.

긴밀하게 연결된 클러스터

긴밀하게 연결된 워크로드는 개별적으로 분리하기도 어렵고, 처리를 위해 상당한 수준의 컴퓨팅 파워가 필요하다.
이런 작업을 위해서는 여러 개의 인스턴스가 단일 슈퍼컴퓨터와 같이 작동할 수 있어야 하므로 인스턴스는 고속의 네트워크로 서로 연결돼 있어야 한다.

즉 여러개의 인스턴스를 긴밀하게 연결해서 동일 클러스터 플레이스먼트 그룹에 배치하는 작업이 필요하다.
(ex, 머신러닝, 기상예측등)

일래스틱 패브릭 어댑터

Elastic Fabric Adapter(EFA)는 전통적인 TCP/IP 네트워크 연결성을 지원하는 특수한 형태의 ENA이며, HPC애플리케이션을 위한 높은 처리량 및 저지연성을 제공한다.

EFA트래픽은 라우팅으로 제어할 수 없으므로, HPC애플리케이션에 EFA를 적용할 때는 모든 인스턴스가 동일 서브넷 내에 있도록 해야한다.
또한 클러스터의 모든 EFA는 동일한 보안 그룹에 부착돼야한다.

AWS ParallelCluster

Linux 기반 HPC 클러스터를 자동으로 관리하며, 클러스터 인스턴스 프로비저닝 작업을 수행하고, 15GB의 공유 파일 시스템을 자동으로 생성한다.

공유 파일 시스템은 마스터 인스턴스에 부착된 EBS 볼륨에 저장되며, NFS를 통해 다른 인스턴스에 저장된 파일을 공유할 수 있따.