AWS VPC에 관한 모든 것

 

오늘의 주인공⭐

 

본격적으로 들어가기 전에 살짝의 주절주절 

 

24년 하반기에 AWS Cloud Clubs OB 멤버로 참여하게 되었다. 이번에 OB 제도가 생기면서 동아리에서 새로 바뀐 점은 바로 OB 멤버들이 직접 YB 멤버들을 위해 세션을 진행했어야 하는 것이다. OB가 없었을 때는 아아주 멋진 캡틴들이 고생해줬다.

 

세션은 대개 AWS 서비스들에 대한 개념적인 내용과 핸즈온을 포함한다. 그래서 매주 다른 AWS 서비스들에 대해 세션을 진행하게 되고, OB들은 한 주를 선택해 세션을 진행하면 된다.

 

주어진 주제들을 정말 다양했다. IAM도 있고, Docker Container 관련된 내용도 있었고, CloudFront 관련된 내용 등등 많았다. 방학 테크 세미나 때 발표했던 CloudFront에 대해 또 한 번 세션을 진행해볼까 하다가, 이번에는 새로운 주제를 깊게 파보고 싶어 다른 주제를 선택하게 되었다.

 

그래서 선택한 주제는 바로바로바로!

 

VPC + Route53이었다. 좋은 기회로 내가 아는 사람 중 추진력이 가장 강한 언니와 같이 준비를 할 수 있게 돼서 기뻤다:)

 

언니와 논의 후, 나는 VPC 개념 설명을 담당하고 핸즈온 실습 테스터 역할을 맡게 되었다. 

 

잡담은 여기까지하고

---

 

시작

 

VPC를 알아보기 전, 필요한 네트워크 개념들

 

1. IP

 

IP란 인터넷에 연결되어 있는 모든 장치들(컴퓨터, 서버 장비, 스마트폰)을 식별할 수 있도록 장비에 부여되는 '고유한 주소'를 의미한다. 마치 택배를 보낼 때 국가, 지역, 아파트, 동호수를 정확히 기재해 택배가 잘 배송되도록 하는 것처럼 네트워크 데이터가 대상에게 잘 도달할 수 있도록 알리는 주소 정보가 IP 주소이다. IP는 v4와 v6가 있으며, IPv4는 32bit로 구성이 되어있다.

 

IP는 또 다양한 유형으로 분류가 가능한데, 여기서 알고 갈 개념은 사설 IP(Private IP)이다.

사설 IP는 일반 가정이나 회사 내에서 할당되는 네트워크 IP 주소, 즉 같은 내부 네트워크 안에서만 사용이 되는 주소이고 인터넷에서 직접 사용은 할 수 없다.

사설 IP 대역

 

마지막으로 알면 좋은 부분은 IP 주소의 구조이다. IP 주소는 네트워크 ID + 호스트 ID로 구성된다. 네트워크 ID는 말 그래도 네트워크를 구분해주는 ID이다. 일일이 전세계의 호스트들을 관리하는 건 여간 쉬운 일이 아닐 것이므로, 큼직 큼직한 단위로 호스트들을 묶어 하나의 네트워크 ID로 분류하는 개념이다. 예를 들어, 신촌에 있는 대학생들을 구별하기 위해 우선 이화여대, 연세대, 서강대 등 대학교 이름으로 학생들을 묶어주는 것과 유사하다. 호스트 ID는 호스트를 개별적으로 관리하기 위해 사용되는 ID이며, 전체 IP 주소에서 네트워크 ID를 제외한 나머지 부분이 여기에 속한다. 마치 대학교 별로 묶은 학생들 중 이화여자대학교 학생들을 이름으로 구분하는 것과 유사하다.

 

대학교 이름과 학생 이름을 조합해 특정 학생을 구분할 수 있는 것처럼, 네트워크 ID와 호스트 ID를 알면 특정 호스트를 구별할 수 있다. 

 

2. CIDR (Classless Inter-Domain Routing)

 

지금까지 IP 주소는 네트워크 ID와 호스트 ID로 구분된다는 것을 알았다.그럼 IPv4 주소를 기준으로 했을때, 32비트 중 몇 비트까지가 네트워크 ID이고, 어디까지가 호스트 ID인걸까?

 

네트워크 ID와 호스트 ID의 주소 범위를 구분하기 위해 쓸 수 있는 표기법이 바로 CIDR이다.

 

실제 CIDR 표기법을 보고 해석하는 방법을 알아보자.

 

192.168.0.0/24

 

여기서 192.168.0.0 부분은 Base IP라고 하고, /24 부분은 Subnet Mask라고 명명한다.Subnet Mask는 IP 주소 중 몇 개의 비트를 네트워크 ID로 활용할지, 즉, 마스크할지 결정하는 부분이다. 따라서 주어진 표기법에 의하면 총 32개의 비트 중 24개의 비트를 네트워크 ID로 활용한다. 아래 그림은 192.168.0.0을 2진수로 표현한 그림이다.

 

이 중 앞의 24개의 비트만 네트워크 ID로 쓰여 고정이 되고, 뒤의 8개의 비트만 호스트 ID로 쓰인다. 따라서 총 2^8개 = 256개의 IP 주소를 생성해 쓸 수 있다. 

 

참고로 AWS에서는 mask의 범위를 16 ~ 28까지 허용한다.

 

VPC (Virtual Private Cloud)

 

VPC에 대해 알아보기 전, VPC가 왜 필요한지부터 알아보자.

 

과거 VPC가 없던 시절에 클라우드 리소스들(EC2, S3 등등)은 서로 격리할 방법이 없었기에 서로 복잡하게 연결되어있었다. 이로 인해 전체 시스템 복잡도는 높았고, 하나의 리소스를 추가하거나 삭제할 경우 모든 리소스 관계를 수정해야 하는 번거로움이 있었던 것이다.

 

 

이때 VPC라는 개념이 등장하면서 문제가 해결이 되었다. 어떻게 해결하는지는 아래에서 설명하겠다.

 

VPC란 나만의 독립된 가상 네트워크 망이다. 아래는 VPC의 대표적인 특징들이다.

• 리전 당 5개까지 설계가 가능하며, VPC 별로 5개의 CIDR를 지정할 수 있다.
• VPC의 CIDR는 다른 VPC나 네트워크의 CIDR와 당연히 겹치면 안된다. 때문에 추후 추가될 VPC를 고려해 CIDR 서브넷 마스크를 /28 정도로 설정하는 걸 권장한다고 한다.
• 특이한 점은, AWS 계정을 생성하면 자동으로 기본 VPC가 생성이 된다. AWS 콘솔에서 VPC를 확인해보면 생성하지도 않은 VPC가 존재하는 걸 확인할 수 있다.

 

아까 문제 상황을 다시 보자. VPC를 도입할 경우 VPC 별로 하나의 독립된 네트워크를 구성할 수 있고, 각각의 VPC에 따라 네트워크 설정이 가능하므로 클라우드 리소스들을 따로 관리할 수 있게 된다. 이러면 시스템 의존도도 낮아지고, 유지보수도 훨씬 편해진다. 

 

Subnet

 

VPC하면 빼놓을 수 없는 개념이 바로 Subnet이다.

 

Subnet이란 VPC의 IP 주소를 나눠 리소스가 배치되는 물리적인 주소 범위이며,  IP 네트워크의 논리적인 영역을 쪼개서 하위 네트워크망을 만든 것이다. 서브넷의 특징을 정리하면, 아래와 같다.

 

• 서브넷은 퍼블릭 서브넷과 프라이빗 서브넷이 존재한다.
• 하나의 VPC에 여러 서브넷을 만드는 걸 Subnetting이라 하며, 서브넷을 생성할 때는 반드시 VPC의 IP 범위 안에서만 생성이 가능하다. 
  • 예를 들어, VPC의 IP 주소가 10.0.0.0/16 (10.0.0.0 ~ 10.0.255.255)이라면 서브넷 주소는 10.0.1.0/24 (10.0.1.0 ~ 10.0.1.255)혹은 10.0.2.0/24 (10.0.2.0 ~ 10.0.2.255)가 될 수 있다.
  • VPC와 마찬가지로 CIDR 범위는 /16부터 /28까지 사용할 수 있다.
• VPC가 하나의 리전에 속할 수 있는 것처럼, 서브넷은 하나의 AZ(가용 영역)에만 존재한다.

 

그럼 하나의 VPC를 여러 서브넷으로 나누는 이유는 무엇일까?

간단하다. 바로 IP 주소들을 낭비없이 효율적으로 사용하기 위해서이다. 아래 그림을 보고 더 이해를 해보자. 

 

호스트가 50개가 있는 기업이 192.168.10.0/24라는 IP 주소를 할당 받았다고 해보자. 계산을 해보면, 총 256개의 다른 주소를 할당받은 것이고, 따라서 256개의 호스트를 구별할 수 있는 IP 주소를 받은 것과 같다. 하지만 실제 필요한 IP 주소는 50개이기 때문에, 50개를 제외한 IP 주소들은 낭비된다.

따라서 이 256개를 절반으로 나누고, 또 절반으로 나눠 총 64개만 기업에게 할당을 하고 남는 IP 주소들은 다른 사용처로 할당한다면 IP 주소를 최대한 낭비없이 활용할 수 있다. 256개를 나눈 과정이 바로 하나의 네트워크(VPC)을 여러 서브넷으로 분리한 과정이다. 따라서 서브넷을 만들면 IP 주소들을 낭비 없이 사용할 수 있게 된다.

 

🐾 여기서 좀만 더 가보자

 

서브넷 IP 대역에서 5개의 IP 주소는 예약이 되어있어 사용자가 이용할 수 없다. 서브넷이 10.0.1.0/24인 상황일 때 아래 5개 주소는 사용하지 못한다.

• 첫번째 주소 (10.0.1.0) : 네트워크 주소로 활용된다.
• 두번째 주소 (10.0.1.1) : AWS VPC 가상 라우터 주소로 활용된다.
• 세번째 주소 (10.0.1.2) : AWS DNS 서버 주소로 활용된다. 
• 네번째 주소 (10.0.1.3) : 향후 새로운 기능에 활용할 주소다. 
• 마지막 주소 (10.0.1.255) : 네트워크 브로드캐스트용 주소다. 

따라서 필요한 IP 주소 갯수에 맞춰 서브넷 마스크를 정해야 되는 상황이라면 5개의 주소는 활용하지 못한다는 것을 염두에 두고 정해야 한다. 예를 들어 EC2 인스턴스에 대해 29개의 IP 주소가 필요한 상황이라면, /27보다 작은 수로 설정해야 한다. 그 이유는 /27로 설정 시 (32개 - 5개) = 27개의 가용 IP 주소가 나오기 때문이다. 

 

IGW (Internet Gateway)

 

IGW는 VPC의 리소스를 인터넷에 연결해주는 역할을 하는 EC2 인스턴스나 람다 함수를 의미한다. 

VPC는 기본적으로 격리된 네트워크 환경이기 때문에 VPC 리소스들은 인터넷과 연결된 환경이 아니다. 따라서 인터넷과 VPC를 연결시켜주기 위해 IGW이 필요하다.

하나의 VPC 당 하나의 IGW가 연결되고, 반대로 하나의 IGW 당 하나의 VPC가 할당된다.

 

Route Table

 

이때 IGW를 설치했다고 자동으로 인터넷과 연결되는 게 아니다. IGW는 인터넷으로 나가는 문 역할만 할 뿐, 실제 서브넷이 외부로 나갈 수 있으려면 길을 연결해주는 과정이 필요하다. 이 역할을 Route Table이 해준다.

 

Route Table은 서브넷 혹은 게이트웨이의 네트워크 트래픽이 전송되어야 할 위치(IP 주소)에 관해 라우팅 규칙을 포함한 표이다. 각 서브넷에서 각각의 라우트 테이블이 연결되어있고, 어디로 연결되어 있냐에 따라 Public Subnet과 Private Subnet으로 나뉜다.

만약 연결된 라우트 테이블이 외부 IP로 향하는 IGW로 보내도록 설정이 되어있다면 연결된 서브넷은 Public Subnet이고, 목적지가 내부 VPC 망(내부)로 설정되어 있다면 해당 서브넷이 Private Subnet이 된다.

 

---

 

지금까지 우리는 Public Subnet에서 외부로 나갈 수 있는 방법에 대해 알아보았다. 

그럼 Private Subnet에서 외부에 접근할 수 있는 방법은 없을까? Private Subnet에 DB 역할을 하는 RDS 인스턴스를 만들었다고 해보자. RDS 인스턴스 안에는 유저들의 개인 정보가 포함되어있다.

 

만약에 RDS가 중요한 정보를 업데이트해야 되는 상황이 온다면 어떻게 될까? 그렇다면 분명 외부 인터넷 연결이 필요하게 될 것이다. 

위에서 본 것처럼 IGW에 연결하면 될까? 아니다. IGW에 연결시켜버리게 되면 해당 서브넷은 더 이상 Private Subnet이 아니게 되어버린다.

 

이렇듯, 때로는 프라이빗 리소스들도 외부와 데이터 통신이 되어야 하는 경우들이 종종 있다. 

 

이럴 때 등장하는 서비스들이 NAT Gateway와 Bastion Host이다.

 

Nat Gateway

 

NAT Gateway에 대해 알아보기 전에 NAT 기술에 대해 살짝 알아보고 가자.

NAT란 IP 패킷의 TCP/UDP 포트 숫자와 소스 및 목적지 IP 주소 등을 재기록하면서 라우터를 통해 네트워크 트래픽을 주고 받는 기술이다. 사설 네트워크에 속한 여러 호스트가 하나의 공인 IP 주소를 사용해 인터넷에 접속하기 위한 기술이며, IP 주소의 낭비를 막고 공인 인터넷을 굳이 사용하지 않아도 되는 단말들에게 어느 망이든 중복으로 사용 가능한 IP를 할당하기 위해 사용이 된다.

 

그림으로 표현하면 아래와 같다. LAN 쪽의 호스트가 WAN으로 패킷을 보낼 때 중간에 라우터가 LAN 쪽 호스트 IP 주소와 목적지 IP를 기록해놓고, 실제 WAN 목적지로 보낼 때는 자기 IP 주소로 보낸다. 이러면 LAN에 있는 여러 호스트들이 하나의 공개적인 IP 주소를 이용해 외부 접근이 가능해진다.

 

컴퓨터 네트워크 들었을 때 수업 자료 ;-;

 

그래서 NAT Gateway는 인터넷 접속이 가능한 Public Subnet에 NAT Gateway를 생성해두고, Private Subnet이 외부 인터넷으로 나아갈 경우에만 사용하도록 라우팅을 추가해주는 것이다.

 

정리를 해보자면

Private 서브넷의 AWS 리소스 🡆 Public Subnet의 NAT Gateway 🡆 IGW 🡆 외부 인터넷

순으로 연결이 된다. 하지만 반대로 외부 🡆 Private 서브넷으로 연결은 안 된다. (그건 밑에 배스천 호스트가 해준다(스포))

 

NAT Gateway의 특징은 아래와 같다.

 

• 특정 AZ에서 생성되며, Elastic IP를 사용한다. 
  • Private 서브넷에 있는 인스턴스들은 외부 인터넷으로 나갈 때 Elastic IP가 Source IP로 바뀌어 나가게 된다. 
  • Private 서브넷의 라우팅 테이블에서 내부 트래픽을 제외한 모든 IP에 대해 패킷을 NAT로 보내라는 부분을 추가해줘야 한다. (0.0.0.0/0에 대해 NAT Gateway로)
• 동일한 서브넷에서 사용이 불가능하다. 다른 서브넷에 액세스할 때만 사용할 수 있다.
• 여러 개의 AZ에 다중으로 NAT Gateway를 생성해 내결함성(fault tolerance)을 강화할 수 있다.
  • 이게 뭔 말일까. 아래 그림을 참고해서 보자!
  • AZ-A, AZ-B, AZ-C가 있는 상황이고, 각 AZ는 NAT Gateway가 포함된 Public 서브넷과 EC2 인스턴스를 포함한 Private 서브넷이 존재한다. 이때 AZ-A가 먹통이 되었다면, AZ-B에 있는 EC2 인스턴스는 외부 인터넷과 연결되는 영향을 받을까? 아니다. AZ-B에 있는 NAT Gateway와 연결이 되어있기 때문에 영향을 받지 않는다. 
  • 하지만 만약 하나의 가용 영역에만 NAT Gateway가 있는 상황이었다면, AZ-B의 EC2 인스턴스도 연결된 NAT Gateway를 잃게 되어 외부와의 연결이 끊어졌을 것이다. 따라서 각 AZ에 NAT Gateway를 생성한다는 것은 시스템의 일부 구성 요소가 작동하지 않더라도 나머지 부분들은 계속 작동할 수 있는 것, 즉 내결함성을 높이는 것이라 할 수 있다.

내결함성이 높은 NAT Gateway 구성 예시

 

• NAT Gateway는 비용이 세다. 시간 당 비용 + 전달되는 데이터 양에 따라 책정이 되는데, 시간 당 비용이 일단 시간 당 40.059원이다. 그래서... 좀 비싼 친구다!

 

Bastion Host

 

Bastion Host는 Public 서브넷에 위치해 Private 서브넷과의 통신을 도와주는 대리인 역할을 한다. 내부와 외부 네트워크 사이에서 일종의 게이트 역할을 수행하는 호스트다. 따라서 외부 인터넷 🡆 Private 서브넷으로 통신을 도와준다고 할 수 있다.

 

Bastion Host를 이용하고 싶다면 추가로 AWS 서비스를 사용해야 되는 건 아니고, 보안 그룹에 두 가지 설정을 해주면 된다. 

• Bastion Host로 설정할 대상의 보안 그룹  🡆 외부에서 Private 서브넷으로 접근 허용해야 함. 이때, 모든 외부인에 대해 열어놓기 보다는 특정 IP 주소를 가진 이들만 허용하는 것이 바람직하다. 
• Private 서브넷 안에 있는 인스턴스 보안 그룹   🡆 Bastion 호스트의 보안 그룹 혹은 Bastion 호스트의 개인 IP에 대한 SSH 연결이 필요함

Bastion Host가 사용되는 예는 다음과 같다.

• 보통 다른 서버에 대한 원격 접근을 제한해 보안을 유지하는 경우
• DB 서버에 접속해야 하는 경우. DB 서버는 내부망에서 실행이 되므로, 외부  🡆 DB 서버로 접근하기 위해서는 Bastion Host를 통해 접근을 해야 하며, 이를 통해 DB 서버에 대한 모든 외부 접근은 막되 필요한 접근을 허용할 수 있다. 

---

 

NACL(Network ACL) 및 보안

 

NACL은 서브넷을 오고가는 모든 트래픽을 제어(allow/deny)하는 역할을 하는 서비스로, 인스턴스 단위로 접근 제어를 담당하는 보안 그룹과 다르게 서브넷 단위로 지정된다.

 

서브넷마다 하나의 NACL이 지정이 되고, 서브넷이 생성되면 디폴트로 '기본 NACL(Default NACL)'이 자동으로 연결이 된다. 여기서 기본 NACL은 굉장히 널널한 규칙을 가지고 있다. 인바운드와 아웃바운드의 모든 요청을 허용(allow)하는 특이한 규칙이 지정되어있다. 만약 모두 허용이 되지 않은 상태에서 사용자가 AWS를 이용했다면, 시작부터 수정할 게 많을 것이다. 그래서 초반에 생성되는 NACL은 모든 트래픽이 자유롭게 드나들 수 있게 설정이 되어있다.

다만 이후 사용자가 생성하는 NACL의 경우 인바운드, 아웃바운드 트래픽이 모두 금지(deny)된 상태로 셋팅이 된다. 

 

NACL도 여러 규칙이 지정이 되는데, 규칙이 숫자(1 ~ 32766)을 부여해 우선 순위를 지정할 수 있다. 특이한 건 숫자가 낮을 수록 우선순위가 높다는 점이다. 보통 100단위로 지정을 해준다. 

 

정리하자면, NACL은 서브넷의 수호자라고 할 수 있다.

 

 

🐾 NACL vs 보안 그룹(Security Group)

 

SAA 시험 준비할 때도 그렇고, NACL이 나오면 무조건 강조되는 개념이 NACL과 보안 그룹을 비교하는 것이다. 둘의 차이점은 아래와 같이 비교할 수 있다.

 

보안 그룹	NACL
인스턴스 단위로 지정됨	서브넷 단위로 지정됨
Allow 규칙만 설정 가능	Allow, Deny 규칙 모두 설정 가능
Stateful : 요청에 대한 응답을 보낼 때는 규칙  상관없이 무조건 내보낼 수 있음 (들어올 때 허용이 된 트래픽이었으면 내보낼 수 있음)	Stateless : 응답을 보낼 때도 Allow 규칙에 해당하는 지 확인해야 함. 인바운드 규칙과 별개로 아웃바운드 규칙이 항상 평가되며, 반대도 마찬가지.
모든 규칙이 평가된 후 트래픽 허용 여부 결정	가장 높은 우선순위를 가진 규칙(숫자가 가장 작은 규칙)이 먼저 평가되고, 첫 번째 비교로 결정
EC2 인스턴스 하나에 적용되는 보안	서브넷 안에 있는 모든 인스턴스에 적용되는 보안

 

🐾 NACL과 휘발성 포트(Ephemeral Port)

 

클라이언트는 포트 번호가 정해진 서버에게 연결하고, 휘발성 포트(랜덤) 번호를 열어 응답을 기다린다. 

 

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-network-acls.html

네트워크 ACL을 사용하여 서브넷에 대한 트래픽 제어 - Amazon Virtual Private Cloud

 

 

VPC Peering

 

만약 A라는 회사에 기획부와 마케팅부가 있다고 가정해보자. 각 부서는 각자의 VPC 망을 보유하고 있다. 근데 일을 하다보니 기획부는 마케팅부 VPC 안에 있는 리소스가 필요할 때가 있고, 반대로 마케팅부도 기획부 VPC에 있는 리소스가 필요할 때가 있다. 날이 갈수록 두 부서가 필요한 리소스가 겹치는 일이 점점 늘어간다고 해보자.

 

두 VPC 간의 상호작용이 높아질수록, A 회사 클라우드 설계자는 이런 생각을 할 수 있다.

 

두 VPC를 연결해 마치 하나의 VPC에 있는 것처럼 작동하게 할 수는 없을까?!

 

여기서 등장하는 개념이 VPC 피어링이다.

 

VPC 피어링이랑 프라이빗 IPv4/IPv6 주소를 이용해 두 VPC 간 트래픽을 라우팅할 수 있도록 하기 위한 두 VPC 사이의 네트워크 연결을 의미한다. VPC의 경우 본래 독립적으로 존재하지만, 서로 통신할 수 있게 VPC 피어링을 맺을 수 있다. 특징은 아래와 같다.

 

• AWS 네트워크를 통해 연결되는 것이므로 매우 안전함
• VPC 간 CIDR가 겹치면 안됨
• VPC 피어링 관계는 전이되지 않음
  • VPC A와 B가 피어링 관계를 맺었고, B와 C가 피어링 관계를 맺었다고 해서 A와 C가 피어링 관계라는 것은 아니다.
  • A와 C도 피어링 관계로 두고 싶다면 따로 설정을 해줘야 한다. 
• 피어링을 활성화하고 싶다면 VPC 서브넷의 라우팅 테이블에서 다른 VPC로 통신이 가능하게 설정하면 됨
• VPC 피어링은 서로 다른 계정과 리전에서도 가능함
• 피어링 관계에 있는 다른 VPC의 보안 그룹도 참조 가능함
  • CIDR나 IP를 소스로 가질 필요가 없고, 보안 그룹을 참조할 수 있으니 좋음

 

VPC 엔드포인트

 

AWS S3, CloudWatch, CloudFront, DynamoDB, API Gateway와 같은 AWS 서비스들은 AWS 리전 안에는 존재하지만, VPC 내부 존재하지 않는 서비스들이다. 따라서 해당 서비스들은 퍼블릭 IP를 가지고 외부에서 접근하는 서비스들이다. 

 

상황을 가정해보자! 만약에 Private 서브넷의 EC2 인스턴스가 VPC 내부에 존재하지 않는 AWS SNS에게 접근하고 싶다고 해보자. 그럼 우리는 이런 생각을 할 수 있다.

 

1. Public 서브넷의 NAT Gateway로 이동한다.

 

2. NAT Gateway에서 Internet Gateway를 거쳐 인터넷 외부로 나간다.

 

3. 그리고 Amazon SNS에 접근한다.

 

이것도 방법이 될 수 있다. 근데 아주아주 큰 문제가 존재한다.

 

어디서 돈 나가는 소리가 들리지 않나요

 

일단 돈이 너무 많이 든다. NAT Gateway를 팡팡 쓰게 되므로 돈을 펑펑 쓰게 되는 것이다. 그리고 여러 서비스를 불필요하게 거쳐야 하며, 이 과정에서 트래픽이 외부로 노출되기 때문에 보안 상 문제가 생길 수도 있다. 

 

이 문제를 해결하기 위해 VPC 엔드포인트를 활용할 수 있다. VPC 엔드포인트를 VPC 내부에 설정해준다면, AWS 망 안에서 외부 AWS 서비스와 연결 가능하다. AWS PrivateLink를 함께 활용한다면 프라이빗하게 접근 가능하므로 보안적으로 좋다. 

 

 

🐾VPC 엔드포인트 종류

 

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

• PrivateLink를 통해 구현함
• ENI (VPC의 프라이빗 엔드포인트)를 AWS의 엔트리 포인트로 프로비저닝함 (반드시 보안 그룹을 연결해야 함)
• 대부분의 AWS 서비스들을 지원함
• 시간 당 & 처리된 데이터의 GB 당 비용이 발생함
• 온프레미스, 다른 VPC 혹은 다른 리전에서 액세스가 필요한 경우에 많이 활용됨

 

2. Gateway 엔드포인트

• 게이트웨이를 프로비저닝함
  • 해당 게이트웨이는 반드시 라우팅 테이블의 대상이 되어야 함 (보안 그룹을 사용하지 않고, 라우팅 테이블만 수정하면 된다)
  • 게이트웨이 엔드포인트 대상으로는 S3 및 DynamoDB가 있음
  • 공짜⭐다
  • 온프레미스 환경, 다른 리전의 peered VPC, Transit Gateway는 지원을 안 해준다 (SAA에서 많이 많이 나옴)