AWS를 사용하면서 알아야 할 VPC에 대해 적어보려고 한다.

VPC (Virtual Private Cloud)

VPC는 사용자가 정의하는 가상의 네트워크다. VPC를 통해 인스턴스가 속하는 네트워크를 구분하여 각 네트워크에 맞는 설정을 부여할 수 있다. AWS에서 VPC에 대한 설정을 따로 하지 않아도 기본 VPC로 설정 되지만, 예를 들어 VPC 없이 인스턴스를 생성한다면 아래와 같이 인스턴스끼리 구분 없이 복잡하게 연결되어 있어 시스템의 복잡도를 높이고 하나의 인스턴스만 추가 되어도 모든 인스턴스를 수정해야 할 것이다.


VPC가 없는 구조

VPC를 적용한 구조

VPC의 핵심 개념

Virtual Private Cloud(VPC) — 사용자의 AWS 계정 전용 가상 네트워크

서브넷 — VPC의 IP 주소 범위

라우팅 테이블 — 네트워크 트래픽을 전달할 위치를 결정하는 데 사용하는 라우팅이라는 이름의 규칙 집합

인터넷 게이트웨이 — VPC의 리소스와 인터넷 간의 통신을 활성화하기 위해 VPC에 연결하는 게이트웨이

VPC 엔드포인트 - 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 AWS Direct Connect 연결을 필요로 하지 않고 AWS PrivateLink 및 VPC 엔드포인트 서비스에 VPC를 비공개로 연결할 수 있다. VPC의 인스턴스는 서비스의 리소스와 통신하는 데 퍼블릭 IP 주소를 필요로 하지 않는다. VPC와 기타 서비스 간의 트래픽은 Amazon 네트워크를 벗어나지 않는다.

CIDR 블록 — 클래스 없는 도메인 간 라우팅이다. 인터넷 프로토콜 주소 할당 및 라우팅 집계 방법이다. 자세한 내용은 이곳에서 확인하기.


VPC는 사용자의 AWS 계정 전용 가상 네트워크다. VPC는 AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리되어 있다. EC2 인스턴스 같은 AWS 리소스를 VPC에서 실행할 수 있다. IP 주소 범위와 VPC 범위를 설정하고 서브넷을 추가하고 보안 그룹을 연결한 다음 라우팅 테이블을 구성한다.

서브넷은 VPC의 IP 주소 범위다. 지정된 서브넷으로 AWS 리소스를 시작할 수 있다. 인터넷에 연결되어야 하는 리소스에는 퍼블릭 서브넷을 사용하고, 인터넷에 연결되지 않는 리소스에는 프라이빗 서브넷을 사용하는 것이 좋다.

각 서브넷에서 AWS 리소스를 보호하기 위해 보안 그룹 및 네트워크 액세스 제어 목록(ACL, Access Control List)을 포함한 다중 보안 계층을 사용할 수 있다.

VPC를 구축하기 위해서는 VPC의 IP 범위를 RFC1918이라는 사설 IP 대역에 맞추어 구축해야 한다. 사설 IP는 인터넷에서 공인된 IP 주소를 사용하지 않고, 사적인 용도로 임의 사용하는 IP 주소다.

VPC에서 사용하는 사설 IP 대역
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

참고
Amazon VPC 작동 방식 - Amazon Virtual Private Cloud
Great, Harry The. “[AWS] 가장쉽게 VPC 개념잡기.” Medium, 해리의 유목코딩, 14 Feb. 2020


서브넷 (Subnet)

서브넷이란 하나의 IP 네트워크 주소를 지역적으로 나누어 여러 개의 서로 연결된 지역 네트워크로 사용할 수 있도록 하는 방법이다. (네트워크의 논리적인 분할)

A Class

A클래스의 첫번째 옥텟의 비트가 0으로 고정된다.

0xxx xxxx. xxxx xxxx. xxxx xxxx. xxxx xxxx

그렇기 때문에 표현할 수 있는 범위는 아래와 같다.

0000 0000.0000 0000.0000 0000.0000 0000 ~ 0111 1110.1111 1111.1111 1111.1111 1111

그래서 십진수로 표현하면 0.0.0.0 ~ 127.255.255.255이다. 이 IP 클래스는 대규모 네트워크에 적합하다. 네트워크 주소는 처음 8비트까지이고, 나머지 24비트는 호스트 주소를 의미한다.

B Class

B클래스는 첫번째 옥텟의 두번째 비트까지 10으로 고정된다.

10xx xxxx. xxxx xxxx. xxxx xxxx. xxxx xxxx

그래서 표현할 수 있는 범위는 아래와 같다.

1000 0000. 0000 0000. 0000 0000. 0000 0000 ~ 1011 1111. 1111 1111. 1111 1111

그래서 십진수로 표현하면 128.0.0.0 ~ 191.255.255.255이다. 네트워크 주소는 처음 16비트까지이고, 나머지 16비트는 호스트 주소를 의미한다.

C Class

C클래스는 첫번째 옥텟의 세번째 비트까지 110으로 고정된다.

110x xxxx. xxxx xxxx. xxxx xxxx. xxxx xxxx

그래서 표현할 수 있는 범위는 아래와 같다.

1100 0000. 0000 0000. 0000 0000. 0000 0000 ~ 1101 1111. 1111 1111. 1111 1111. 1111 1111

그래서 십진수로 표현하면 192.0.0.0 ~ 223.255.255.255이다. 네트워크 주소는 처음 24비트까지이고, 나머지 8비트는 호스트 주소를 의미한다.

D Class

D클래스는 첫번째 옥텟의 네번째 비트가 1110으로 고정된다.

1110 xxxx. xxxx xxxx. xxxx xxxx. xxxx xxxx

그래서 표현할 수 있는 범위는 아래와 같다.

1110 0000. 0000 0000. 0000 0000. 0000 0000 ~ 1110 1111. 1111 1111. 1111 1111. 1111 1111

그래서 십진수로 표현하면 224.0.0.0 ~ 239.255.255.255이다. 멀티캐스트용 대역으로 IP주소에 할당되지 않는다.

E Class

E클래스는 첫번째 옥텟의 네번째 비트까지 1111으로 고정된다.

1111 xxxx. xxxx xxxx. xxxx xxxx. xxxx xxxx

그래서 표현할 수 있는 범위는 아래와 같다.

1111 0000. 0000 0000. 0000 0000. 0000 0000 ~ 1111 1111. 1111 1111. 1111 1111. 1111 1111

그래서 십진수로 표현하면 240.0.0.0 ~ 255.255.255.255이다. 예약된 주소 대역으로 IP주소에 할당되지 않는다.

D클래스와 E클래스는 특정 용도로 사용하기 때문에 실제 IP주소에 할당되지 않는다.

클래스 등급이 낮아지면서 호스트 주소 부분이 점점 줄어들고 있는것을 알 수 있다.

이 중 특정 주소 대역은 사설 IP로 사용된다.

VPC에서 사용하는 사설 IP 대역
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

(아까 위에서 설명한 사설 IP 대역이랑 같다.)

각 클래스로 나눠진 네트워크를 운영중인 서비스의 규모에 맞게 분할하여 사용하기 위한 기술이다. 따라서 이런 기술을 통해서 A Class 네트워크와 같은 매우 큰 네트워크를 작게 나눠서 사용하면서, 낭비되는 IP주소 자원을 최소화하려는 것이 주된 목적이다.

참고
Heyhyo. “[Network]서브넷(Subnet).” Hyo Note, TISTORY, 31 Aug. 2018,
heyoon2j. “Subnet 이란?” { BLog: “heyoon2j” }, TISTORY, 7 Dec. 2019
Reakwon. “[네트워크] IP 클래스와 서브넷마스크, 서브넷마스크 계산방법.” REAKWON, TISTORY, 19 May 2020


서브넷 마스크 (Subnet Mask)

네트워크 범위를 제한하거나 네트워크 범위를 알기 위한 마스크다. IP 주소에 대한 네트워크 아이디와 호스트 아이디를 구분하기 위해서 사용된다.

C클래스 대역을 사용해서 호스트를 255개를 수용할 수 있는 것도 너무 많이 남을 때가 있다. 또는 B클래스 대역을 C클래스 대역으로 쓰고 싶을 때가 있다. 네트워크 주소를 조금 더 효율적으로 할당하고자 나온 것이 서브넷 마스크다. 서브넷 마스크로 만들어진 네트워크를 서브넷이라고 한다.

128.255.11.11는 B클래스 주소다. 128.255까지가 네트워크 주소이고 나머지 2옥텟이 호스트 주소다.

💡 128.255.11.11을 255.255.255.0이라는 서브넷 마스크를 씌우면 어떻게 될까 🤔

서브넷 마스크는 비트로 보는 것이 편하다.

255.255.255.0 ➡️ 1111 1111.1111 1111.1111 1111.0000 0000

여기서 서브넷 마스크 비트가 1인 것은 전부 네트워크 주소가 되고, 반대로 서브넷마스크 비트가 0인 것은 호스트 주소가 된다.

⏬ 서브넷 마스크 적용 ⏬

128.255.11.11 ➡️ 1000 0000.1111 1111.0000 1011.0000 1011

따라서 255.255.255.0이라는 서브넷 마스크를 씌우면 128.255.11이 네트워크 주소가 되고 나머지 11이 호스트 주소가 된다. 네트워크 주소: 128.255.11.0, 호스트 주소: 0.0.0.11

서브넷마스크의 표기방식은 주소/서브넷마스크 주소 또는 주소/비트수로 표현할 수 있다. 128.255.11.11/255.255.255.0 또는 128.255.11.11/24로 표현이 가능하다.

💡 128.255.11.11을 255.255.255.224의 서브넷마스크를 적용하면 어떻게 될까 🤔

비트로 풀어보면

255.255.255.224 ➡️ 1111 1111.1111 1111.1111 1111.1110 0000

⏬ 서브넷 마스크 적용 ⏬

128.255.11.11 ➡️ 1000 0000.1111 1111.0000 1011.0000 1011

하위 5비트 0 0000을 호스트 주소로 적용시킬 수 있으니까(서브넷마스크 비트가 0인 것이 호스트 주소) 128.255.11.0 ~ 128.255.11.31 까지가 같은 네트워크고, 128.255.11.11은 이 네트워크에 속하는 것을 알 수 있다. 128.255.11.0은 네트워크 주소, 128.255.11.31은 브로드캐스트 주소기 때문에 실제 사용 가능한 호스트 개수는 2^5-2 = 30개다.

  • 네트워크 주소: 해당 네트워크의 첫번째 IP주소로, 하나의 네트워크를 통칭한다. IP주소와 서브넷마스크의 AND 연산을 통해 구할 수 있다.
  • 호스트 주소: 특정한 하나의 네트워크 내에서 서로를 구분하기 위한 주소다.
  • 브로드캐스트 주소: 해당 네트워크에 속하는 모든 IP 주소 가운데 맨 마지막 IP주소로, 네트워크에 있는 모든 클라이언트들에게 데이터를 보내기 위함이다.

사실 A, B, C클래스 대역은 각각 255.0.0.0, 255.255.0.0, 255.255.255.0의 서브넷마스크가 적용되었다. 이것을 default subnet mask라고 한다.

참고
Reakwon. “[네트워크] IP 클래스와 서브넷마스크, 서브넷마스크 계산방법.” REAKWON, TISTORY, 19 May 2020


라우팅 테이블

라우팅 테이블(Routing Table)은 컴퓨터 네트워크에서 목적지 주소를 목적지에 도달하기 위한 네트워크 노선으로 변환시키는 목적으로 사용된다. 각 라우터의 라우팅 테이블은 모든 목적지 정보에 대해 해당 목적지에 도달하기 위해서 거쳐야 할 다음 라우터의 정보를 가지고 있다.

VPC 내에는 서브넷이 있으며 각 서브넷은 각각 다른 네트워크 대역을 가지고 있다. 각각의 서브넷은 서로 다른 네트워크 영역이기 때문에 하나의 서브넷이 다른 서브넷으로 가기 위해서는 라우팅(Routing)이 필요하다.

이미지 출처
VPC의 라우팅 테이블 - Amazon Virtual Private Cloud

모든 라우팅 테이블에는 VPC 내부 통신을 위한 로컬 라우팅이 포함되어 있다. 이 라우팅은 기본적으로 모든 라우팅 테이블에 추가된다. VPC에 하나 이상의 IPv4 CIDR블록이 연결되어 있는 경우, 라우팅 테이블에 각 IPv4 CIDR 블록의 로컬 경로가 포함된다. IPv6 CIDR 블록을 VPC와 연결한 경우, 라우팅 테이블에 IPv6 CIDR 블록의 로컬 경로가 포함된다. 서브넷 라우팅 테이블이나 기본 라우팅 테이블에서 이러한 라우팅을 수정하거나 삭제할 수 없다.

VPC 내부(모든 서브넷)에 대해서는 라우팅이 자동으로 생성된다. 별도의 설정 없이 하나의 서브넷에서 다른 서브넷으로 통신이 가능하다는 말이다. 이는 사용자가 따로 설정할 필요가 없고, 보이지 않는 암시적 라우터인 VPC Router를 통해 가능하다. 서브넷 내의 모든 리소스는 자신이 소속된 서브넷이 아닌 다른 서브넷으로 향하고자 할 때 VPC Router를 거쳐야 한다.

VPC에는 암시적 라우터가 있으며 라우팅 테이블을 사용하여 네트워크 트래픽이 전달되는 위치를 제어한다. VPC의 각 서브넷을 라우팅 테이블에 연결해야 한다. 테이블에서는 서브넷에 대한 라우팅을 제어한다 (서브넷 라우팅 테이블). 서브넷을 특정 라우팅 테이블과 명시적으로 연결할 수 있다. 그렇지 않으면 서브넷이 기본 라우팅 테이블과 암시적으로 연결된다. 서브넷은 한 번에 하나의 라우팅 테이블에만 연결할 수 있지만 여러 서브넷을 동일한 서브넷 라우팅 테이블에 연결할 수도 있다.

위 사진에서 서브넷의 라우팅을 보여주고 있다. 해당 서브넷에 로컬 라우팅이 지정되어 있는 것을 확인할 수 있다. 나머지 서브넷에도 사진과 같은 라우팅 테이블을 보유하고 있기 때문에 VPC 내 서브넷에 할당된 리소스라면 어느 서브넷이든 다른 서브넷의 리소스와 자유롭게 통신이 가능하다.

또한 라우팅 테이블은 로컬 라우팅 뿐만 아니라 서브넷에 소속된 리소스(EC2, RDS 등)가 외부 인터넷망으로 나갈 수 있는 라우팅을 가질 수 있다. 이를 인터넷 게이트웨이(Internet Gateway)라고 한다. 그림에서 igw-***으로 나와있는 것이 바로 인터넷 게이트웨이다.

참고
VPC의 라우팅 테이블 - Amazon Virtual Private Cloud.
환영 도움되는 네트워크 엔지니어. “VPC와 Network 쉽게 이해하기 #2.” 네트워크 엔지니어 환영의 AWS 기술블로그, TISTORY, 1 Sept. 2021


인터넷 게이트웨이

인터넷 게이트웨이는 수평 확장되고 가용성이 높은 중복 VPC 구성 요소로, VPC와 인터넷 간에 통신할 수 있게 해준다. 인터넷 게이트웨이에는 인터넷 라우팅 가능 트래픽에 대한 VPC 라우팅 테이블에 대상을 제공하고, 퍼블릭 IPv4 주소가 할당된 인스턴스에 대해 NAT(네트워크 주소 변환)를 수행하는 두 가지 목적이 있다.

이름에서 알 수 있듯 서브넷 내 리소스(EC2, RDS 등)가 인터넷과 통신하고자 할 때 반드시 거쳐야 하는 관문이 인터넷 게이트웨이다. 인터넷 게이트웨이 없이는 외부 인터넷으로 들어갈 방법은 없다! 인터넷 게이트웨이만 생성하면 외부 인터넷과 통신할 수 있는 것은 아니고 VPC에서 리소스가 외부 인터넷과 통신하고자 할 경우 갖춰야 할 조건은 아래와 같다.

  1. 인터넷과 통신하고자 하는 리소스가 공인 IP를 보유할 것
  2. 리소스가 소속된 서브넷의 라우팅 테이블에 0.0.0.0/0 목적지로 갖는 인터넷 게이트웨이가 있을 것
  3. 네트워크 ACL과 보안 그룹 규칙에서 허용할 것

이미지 출처
Amazon Virtual Private Cloud - Docs.aws.amazon.com

AWS에서는 공인 인터넷과 통신 가능한 서브넷을 Public Subnet, 공인 인터넷이 차단된 사설 IP만 할당된 서브넷은 Private Subnet이라고 한다.

Name이 -인 3개의 서브넷을 가진 라우팅 테이블의 라우팅 설정은 아래와 같다.

인터넷 게이트웨이가 설정되어 있으므로 이 라우팅 테이블은 Public 서브넷에 관한 라우팅 테이블이다.

Name이 my-route01인 하나의 서브넷을 가진 라우팅 테이블의 라우팅 설정은 아래와 같다.

여기서는 인터넷 게이트웨이 대신 NAT 게이트를 설정했다.

NAT 게이트웨이가 설정되어 있으므로 이 라우팅 테이블은 Private 서브넷에 관한 라우팅 테이블이다

참고
환영 도움되는 네트워크 엔지니어. “VPC와 Network 쉽게 이해하기 #2.” 네트워크 엔지니어 환영의 AWS 기술블로그, TISTORY, 1 Sept. 2021


NAT 게이트웨이

NAT 게이트웨이는 NAT(네트워크 주소 변환) 서비스다. 프라이빗 서브넷의 인스턴스가 VPC 외부의 서비스에 연결할 수 있지만 외부 서비스에서 이러한 인스턴스와의 연결을 시작할 수 없도록 NAT 게이트웨이를 사용할 수 있다.

NAT(Network Address Translation): 비공인 네트워크(사설 IP 네트워크)에 속한 여러 개의 호스트가 하나의 공인 IP 주소를 사용하여 인터넷에 접속하는 방법

NAT 게이트웨이를 만들 때 다음 연결 유형 중 하나를 지정한다.

  • 퍼블릭 - (기본값) 프라이빗 서브넷의 인스턴스는 퍼블릭 NAT 게이트웨이를 통해 인터넷에 연결할 수 있지만 인터넷에서 원치 않는 인바운드 연결을 수신할 수 없다. 퍼블릭 서브넷에서 퍼블릭 NAT 게이트웨이를 생성하고 생성 시 탄력적 IP 주소를 NAT 게이트웨이와 연결해야 한다. 트래픽을 NAT 게이트웨이에서 VPC용 인터넷 게이트웨이로 라우팅한다. 또는 퍼블릭 NAT 게이트웨이를 사용하여 다른 VPC 또는 온프레미스 네트워크에 연결할 수 있다. 이 경우 NAT 게이트웨이에서 Transit Gateway 또는 가상 프라이빗 게이트웨이를 통해 트래픽을 라우팅한다.

  • 프라이빗 - 프라이빗 서브넷의 인스턴스는 프라이빗 NAT 게이트웨이를 통해 다른 VPC 또는 온프레미스 네트워크에 연결할 수 있다. 트래픽을 NAT 게이트웨이에서 Transit Gateway 또는 가상 프라이빗 게이트웨이를 통해 트래픽을 라우팅할 수 있다. 탄력적 IP 주소를 프라이빗 NAT 게이트웨이에 연결할 수 없다. 프라이빗 NAT 게이트웨이를 사용하여 VPC에 인터넷 게이트웨이를 연결할 수 있지만 프라이빗 NAT 게이트웨이에서 인터넷 게이트웨이로 트래픽을 라우팅하는 경우 인터넷 게이트웨이가 트래픽을 삭제한다.

NAT 게이트웨이는 인스턴스의 소스 IP 주소를 NAT 게이트웨이의 IP 주소로 바꾼다. 퍼블릭 NAT 게이트웨이의 경우 이것은 NAT 게이트웨이의 탄력적 IP 주소다. 프라이빗 NAT 게이트웨이의 경우 이것은 NAT 게이트웨이의 프라이빗 IP 주소다. 인스턴스에 응답 트래픽을 전송할 때 NAT 디바이스는 주소를 원래 소스 IPv4 주소로 다시 변환한다.

나는 서브넷 c를 Private 서브넷으로 설정하고 서브넷 c의 라우팅 설정에서 NAT 게이트웨이를 지정했다. 이 NAT 게이트웨이는 퍼블릭 유형이고 생성할 때 탄력적 IP 주소도 할당했다. 그리고 VPC에서 Private 서브넷 c가 아닌 나머지 3개의 Public 서브넷에서 서브넷 a를 선택해 NAT 게이트웨이를 생성했다.

참고
Nat 게이트웨이 - Amazon Virtual Private Cloud


보안그룹

보안 그룹은 연결된 리소스에 도달하고 나갈 수 있는 트래픽을 제어한다. 예를 들어 보안 그룹을 EC2 인스턴스와 연결하면 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어한다. VPC를 생성할 경우 VPC는 기본 보안 그룹과 함께 제공된다. 각 VPC 대해 추가 보안 그룹을 생성할 수 있다. 보안 그룹은 해당 보안 그룹이 생성된 VPC의 리소스에만 연결할 수 있다. 각 보안 그룹에 대해 프로토콜 및 포트 번호를 기반으로 트래픽을 제어하는 규칙을 추가한다. 인바운드 트래픽과 아웃바운드 트래픽에 대한 규칙 집합은 별개다. 인바운드 규칙으로 외부에서 우리의 인스턴스로 들어오는 요청을 제한할 수 있고, 아웃바운드 규칙으로 우리의 인스턴스에서 외부로 나가는 요청을 제한할 수 있다.

아래 사진은 예전에 AWS로 프로젝트를 할 때 사용했던 보안 그룹 설정 캡쳐 내용이다. 다 가려져 있긴 하지만..

보안 그룹 규칙

  • 프로토콜: 허용할 프로토콜이다. 가장 일반적인 프로토콜은 6(TCP), 17(UDP) 및 1(ICMP).

  • 포트 범위: TCP, UDP 또는 사용자 지정 프로토콜의 경우 허용할 포트의 범위다. 단일 포트 번호(예: 22) 또는 포트 번호의 범위(예: 7000-8000)를 지정할 수 있다.

  • ICMP 유형 및 코드: ICMP 프로토콜의 경우, 설정할 ICMP 유형과 코드다. 예시: ICMP 에코 요청에 대해 유형 8을 사용하고, ICMPv6 에코 요청에 대해 유형 128을 설정한다.

  • 소스 또는 대상: 허용할 트래픽에 대한 소스(인바운드 규칙) 또는 대상(아웃바운드 규칙)이다.

    • 단일 IPv4 주소. /32 접두사 길이를 사용해야 한다. 예: 203.0.113.1/32.

    • 단일 IPv6 주소. /128 접두사 길이를 사용해야 한다. 예: 2001:db8:1234:1a00::123/128.

    • CIDR 블록 표기법으로 표시된 IPv4 주소의 범위다. 예: 203.0.113.0/24.

    • CIDR 블록 표기법으로 표시된 IPv6 주소의 범위다. 예: 2001:db8:1234:1a00::/64.

    • 접두사 목록의 ID. 예: pl-1234abc1234abc123. 자세한 정보는 관리형 접두사 목록을 사용하여 CIDR 블록 그룹화을 참조하십시오.

    • 보안 그룹의 ID다(여기에서는 지정된 보안 그룹이라고 함). 예를 들어, 현재 보안 그룹, 동일한 VPC의 보안 그룹 또는 피어링된 VPC에 대한 보안 그룹이 해당됩니다. 이렇게 하면 지정된 보안 그룹과 연결된 리소스의 프라이빗 IP 주소를 기반으로 하는 트래픽이 허용됩니다. 이 작업은 지정된 보안 그룹의 규칙을 현재 보안 그룹에 추가하지 않는다.

  • (선택 사항) 설명: 나중에 쉽게 식별할 수 있도록 규칙에 대한 설명을 입력하는 곳이다. 설명 길이는 최대 255자다. 허용되는 문자는 a-z, A-Z, 0-9, 공백 및 ._-:/()#,@[]+=;{}!$*.


PEM

PEM(Privacy Enhanced Mail)은 Base64로 인코딩된 ASCII 텍스트 파일이다. 원래는 Secure Email에 사용되는 인코딩 포맷이었는데 Email 쪽에서는 잘 쓰이지 않고 인증서 또는 키 값을 저장하는 데 많이 사용된다. 바이너리 파일을 전송할 때 손상될 수 있으므로 텍스트 파일로 변환한 것이고, 어떤 바이너리 파일을 PEM으로 변환했는지 구분하기 위해 파일의 맨 앞에 대시(-) 를 5 개 넣고 BEGIN 파일 유형을 넣고 다시 대시(-)를 5개 뒤에 END 파일 유형 구문을 사용한다. (-----BEGIN ???-----, -----END ???-----) 담고 있는 내용이 무엇인지에 따라 ??? 위치에 CERTIFICATE, RSA PRIVATE KEY 등의 키워드가 들어있다.

참고
https://www.letmecompile.com/certificate-file-format-extensions-comparison


SSH

SSH는 Secure Shell의 줄임말로, 원격 호스트에 접속하기 위해 사용되는 보안 프로토콜이다.
기존 원격 접속은 텔넷(Telnet)이라는 방식을 사용했는데, 암호화를 제공하지 않기 때문에 보안상 취약하다. 실제로 WireShark 같은 패킷 분석 프로그램을 이용하면 누구나 쉽게 원격 접속 과정에서 옮겨지는 비밀번호나 파일 내용 등의 데이터를 탈취할 수 있다. 때문에 이를 암호화하는 SSH가 등장했고, 현재 원격 접속 보안을 위한 필수적인 요소로 자리잡고 있다. 그리고 클라우드 서비스에서 제공하는 서버는 기본적으로 원격 접속을 해서 접근하고 사용한다. 그래서 AWS 같은 CSP(Cloud Service Provider)에서 서버 생성시 필수적으로 SSH 보안 과정을 거친다.
터미널에서 AWS EC2로 접속할 때 사용하는 SSH 방식을 알기 전 암호화에 대해서 간단하게 알아보자. 암호화에는 단방향 암호화, 양방향 암호화가 있다.

  • 단방향 암호화: 암호화 후 복호화 할 수 없다.
  • 양방향 암호화: 암호화, 복호화 둘 다 가능하다.
    • 대칭키 암호화(비밀키 암호화): 암호화 할 때 사용하는 키와 복호화 할 때 사용하는 키가 같다.
    • 비대칭키 암호화(공개키 암호화): 암호화 할 때 사용하는 키와 복호화 할 때 사용하는 키가 다르다. 비밀키로 암호화 하면 공개키로 복호화 할 수 있고, 공개키로 암호화 하면 비밀키로 복호화 할 수 있다.

EC2를 생성할 때 키페어를 등록하라고 한다. 키페어를 생성했을 때 우리의 컴퓨터에 다운로드 되는 PEM 파일이 바로 개인키다. 그렇다면 공개키는 어디에 있을까? 공개키는 EC2 인스턴스 안에서 확인할 수 있다. EC2 인스턴스의 ~/.ssh/authorized_keys 파일에 공개키 목록이 있는데 해당 파일에 우리가 받은 PEM 파일(개인키)와 매칭되는 공개키가 포함되어 있다. 그래서 우리는 이 PEM 파일로 ssh 명령어를 통해 EC2 인스턴스에 접속할 수 있다.

참고로 우리가 EC2로 SSH를 통해 해당 서버에 접속을 하면 내 컴퓨터의 ~/.ssh/known_hosts 파일에는 해당 서버의 공개키가 자동으로 등록이 된다.
SSH 공개키 인증 방식은 크게 위와 같지만 SSH 통신에 대한 자세한 내용은 다음 글에서 확인할 수 있다.

참고
https://library.gabia.com/contents/infrahosting/9002


EC2 터미널로 연결

EC2를 생성할 때 키 페어를 생성하는 화면이 나오는데 해당 파일은 유출되어서는 안 된다. 특별히 보안에 신경쓰도록 노력하자.

chmod 400 [파일경로/파일명].pem(.cer)

나에게만 읽기 권한이 있게 한다.

ssh -i [파일경로/파일명].pem(.cer) [계정명]@[퍼블릭 IPv4 또는 DNS주소]

계정명:

  • Amazon Linux2 또는 Amazon Linux AMI ➡️ ec2-user
  • Ubuntu AMI ➡️ ubuntu
  • CentOS AMI ➡️ centos
  • Debian AMI ➡️ admin
  • Fedora AMI ➡️ ec2-user 또는 fedora
  • RHEL AMI ➡️ ec2-user 또는 root
  • SUSE AMI ➡️ ec2-user 또는 root


AWS RDS Proxy

RDS Proxy를 사용하여 Amazon RDS DB 인스턴스와 Amazon Aurora DB 클러스터에 대한 연결 관리를 간소화할 수 있다.

RDS Proxy는 클라이언트 애플리케이션과 데이터베이스 사이의 네트워크 트래픽을 처리한다. 데이터베이스 프로토콜을 이해하여 능동적으로 수행한다. 그런 다음 애플리케이션의 SQL 작업과 데이터베이스의 결과 집합을 기반으로 동작을 조정한다.

RDS Proxy는 데이터베이스의 커넥션 관리를 위한 메모리 및 CPU 오버헤드를 줄인다. 애플리케이션이 많은 연결을 동시에 열 때 데이터베이스에 필요한 메모리 및 CPU 리소스가 더 적다. 또한 오랫동안 유휴 상태를 유지하는 커넥션을 닫았다가 다시 여는 데 애플리케이션의 로직이 필요하지 않다. 마찬가지로, 데이터베이스 문제의 경우 커넥션을 다시 설정하는 데 더 적은 애플리케이션 로직이 필요하다.

Amazon RDS Proxy를 사용하면 애플리케이션이 데이터베이스 커넥션을 풀링하고 공유하도록 허용하여 확장 기능을 향상시킬 수 있다. RDS Proxy는 애플리케이션 커넥션을 유지하면서 예비 DB 인스턴스에 자동으로 연결하여 데이터베이스 장애에 대한 애플리케이션의 복원력을 높인다. RDS Proxy를 사용하면 데이터베이스에 대해 AWS Identity and Access Management(IAM) 인증을 사용하고 AWS Secrets Manager에 자격 증명을 안전하게 저장한다.

RDS Proxy를 사용하면 발생할 수 있는 예기치 않은 데이터베이스 트래픽 급증을 처리할 수 있다. RDS Proxy는 데이터베이스 커넥션 풀을 설정하고 이 풀에서 커넥션을 재사용한다. 이 접근 방식은 매번 새 데이터베이스 커넥션을 여는 데서 오는 메모리 및 CPU 오버헤드 를 방지한다. 초과 구독으로부터 데이터베이스를 보호하기 위해 생성되는 데이터베이스 커넥션 수를 제어할 수 있다.

참고
RDS Proxy 개념 및 용어 - Docs.aws.amazon.com.
Amazon RDS 프록시 사용 - Docs.aws.amazon.com.