VPC(가상 사설 클라우드)와 네트워킹에 관하여

 

 

📍 VPC를 알기 전에 먼저 AWS에서의 IP 주소에 대해 먼저 알아보자 📍

먼저 익히 알다시피 IPv4(인터넷 프로토콜 버전4)와 IPv6(인터넷 프로토콜 버전6)이 존재한다.

 

<IPv4> - (생김새 예시 : 192.168.1)

AWS에서는 EC2 인스턴스를 만들 때마다 새로운 Public IPv4를 얻게 되고, 중지했다가 다시 시작할 때에도 새로운 Public IPv4 주소를 얻게 된다..!

Private IPv4는 사용자의 자체 네트워크 내에서 사용할 수 있는 내부 IP인데 이것은 EC2 인스턴스 수명 주기동안에는 고정되어 있어서 중지했다가 다시 시작해도 그대로인 것을 예전 내 게시글에서 다루었었다..! 

--> https://670811.tistory.com/47

EC2 인스턴스 생성하기, 윈도우로 SSH 실행하는 방법과 더 편한 방법

+) 여기서 Elastic IP라는 개념이 도입되는데 이걸 사용하면 고정 Public IPv4를 만들 수 있다

(EC2 인스턴스에도 적용 가능 - 그러나 Elastic IP를 사용하는 것부터 비용이 든다)

 

<IPv6> - (생김새 예시 : 2001:db8:3333:4444:cccc:dddd:eeee:ffff)

IPv6은 인터넷 프로토콜의 차세대 진화버전으로서 모든 IPv6은 Public이고 Private은 없다.

여기서 다룰 VPC가 IPv6도 사용하도록 설정할 수 있다.

 

#0 VPC(Virtual Private Cloud) - 가상 사설 클라우드 & 서브넷과 게이트웨이에 관해

사설 네트워크를 사용해서 EC2 인스턴스에 리소스를 배포할 수 있는데 특정 region이랑 연결되어 AWS에 여러 region이 있으면 여러 VPC를 갖게 된다. 

VPC에는 서브넷이 있는데 서브넷은 VPC의 일부가 된다.

(서브넷 = 네트워크의 파티션, 가용 영역과 연결됨)

그림에서 나온 것처럼 Public 서브넷과 인터넷이 서로 바로 연결되어 있고 private 서브넷도 있는데 인터넷을 통해 액세스하지 않는 서브넷이라 직접적으로 연결되어있지는 않다. 

아무튼 인터넷으로의 액세스와 서브넷 간의 액세스를 정의해서 리소스와 통신하려면 '라우팅 테이블'을 사용한다..!

EC2 인스턴스를 생성할 때, Public 서브넷 안에서 생성한다. Public 서브넷 안에는 로드 밸런서를 포함할 수 있다.

Private 서브넷은 기본적으로 VPC가 있고 인터넷 액세스가 필요 없어서 데이터베이스를 배치할 수 있다. (그래서 더 안전하다)

AWS 안에 region이 있고 그 안에 VPC가 있는데 이는 VPC에서 허용하는 IP주소의 범위라고 보면 편하다.

2개의 AZ와 1개의 VPC, 4개의 서브넷이 있는 것이고 각 서브넷에서 EC2 인스턴스를 실행할 수 있다.

...

그렇다면 이 서브넷에 관한 인터넷 액세스는 어떻게 정의할까?

VPC가 인터넷 게이트웨이를 가지게 되고 Public 서브넷은 인터넷에 액세스하는 인터넷 게이트웨이에 관한 라우트를 가진다. 

=> 간단하게 정리하자면 인터넷 게이트웨이와 인터넷 게이트웨이로의 라우트가 있으면 서브넷이 Public 서브넷이 되는 것

Private 서브넷은 인터넷에 연결할 수는 없지만 인터넷 액세스 권한을 부여할 수 있다. (운영체제 업데이트, 파일 다운로드 등..)

=> 부여하려면 NAT 게이트웨이 설치 (AWS에서 관리하거나 인스턴스에서 자체 관리)

 

#1 VPC 내의 네트워크 보안 - 첫 번째 방어선(ACL)과 두 번째 방어선(Security Group)⚔️

위의 그림과 같이 EC2 인스턴스의 첫 번째 방어선은 네트워크 ACL 또는 NACL이다.

서브넷에 들어오고 나가는 트래픽을 제어하는 방화벽으로 서브넷 수준에서 허용 또는 거부 규칙을 정의할 수 있고 연결할 수 있다. 규칙에는 IP주소만 포함할 수 있는데 위의 그림에서 보는 것처럼 NACL이 EC2 인스턴스에 도달하기 전에 서브넷에 들어오고 나가는 트래픽을 필터링한다.

두 번째 방어선은 Security Group이다.

ENI(탄력적 네트워크 인터페이스)와 EC2 인스턴스에 들락거리는 트래픽을 제어하는 방화벽이다.

=> 결론 : NACL의 보안은 서브넷 수준이고 Security Group은 EC2 인스턴스 수준이다.

 

#2 VPC Flow Logs - IP 트래픽 기록들🧾

VPC Flow Logs(플로우 로그)는 인터페이스를 통과하는 모든 IP 트래픽에 대한 로그이다.

VPC Flow Logs, Subnet Flow Logs, Elastic Network Interface Flow Logs를 통해 EC2 인스턴스로 들어오고 나가는 트래픽을 확인할 수 있다. Flow Logs를 활성화하면 연결 문제를 모니터링하고 해결할 수 있다.

 

+) <VPC Peering(피어링)>

AWS의 네트워크를 사용해서 두 VPC를 private으로 연결함으로써 마치 동일한 네트워크인 것처럼 동작하도록 하는 것

위의 그림을 참고해서 설명하면 VPC A와 VPC B가 있다고 가정, 서로 피어링이 완료되면 동일한 네트워크에 있거나 마치 동일한 네트워크에 있는 것처럼 동작한다.

=> 이를 위해서는 IP주소 범위가 겹치지 않는지 확인 필요

또한 VPC 피어링 연결은 전이적이지가 않아서  VPC C 와의 피어링 연결을 만들어도 직접적으로 연결하지 않은 다른 VPC와는 서로 통신할 수가 없다..! (통신하려면 꼭 직접적으로 연결해야 한다)

 

#3 VPC Endpoints - AWS 네트워크 사용하는 서비스 📶

지금까지 사용한 AWS 서비스는 모두 서비스에 연결하면 Public(공용 - 예 :  www)으로 연결되었는데 VPC Endpoints를 사용하면 Public 인터넷 네트워크 대신에 AWS 네트워크로 프라이빗한 액세스를 사용하게 된다.

=> 사용하는 이유는 더 나은 보안을 제공받고 싶을 때 사용한다.

     (+ 그리고 네트워크 Hop(홉)을 통해 액세스하지 않아서 지연 시간도 짧다)

 

< Endpoint 유형 알아보기 >

1. VPC Endpoint Gateway

그리고 EC2 인스턴스로 게이트웨이를 통해  Amazon S3와 DynamoDB에 연결할 수 있는데 비공개로 연결할 수 있다.

(☑️ VPC Endpoint Gateway는 Amazon S3와 DynamoDB 전용이니 기억해두기)

2. VPC Endpoint Interface

 AWS의 다른 모든 서비스와 연결할 수 있다.

(예 : CloudWatch로 커스텀 지표를 푸쉬하는 경우, 이것을 사용하면 EC2 인스턴스와 CloudWatch가 연결된다)

 

#4 Private Link

자체 VPC 내의 자체 계정에서 서비스를 실행하고 그 서비스를 AWS 유저들에게 노출하고 싶을 때 AWS 내의 VPC는 수만개가 되니 AWS 서비스에 연결하려면 해당 서비스에 대한 프라이빗 액세스 권한이 있어야 한다. 

=> VPC 피어링을 사용한다? - 그러나 확장성이 떨어지고 안전하지도 않다⚠️

...

이때 쓰는 것이 Private Link이다.

 

Private Link는 VPC Endpoints 서비스 제품군 중 하나로

VPC 내에서 실행 중인 서비스를 다른 VPC private으로 직접 연결할 수 있게 해준다..!

(프라이빗 네트워크에 있기 때문에 VPC 피어링, 인터넷 게이트웨이, NAT 등 같은게 필요 X)

위의 그림을 예를 들어, AWS 마켓 플레이스에서 '애플리케이션 서비스를 운영하는 업체'와 대화한다고 했을 때, '애플리케이션 서비스를 운영하는 업체'는 자체 VPC에서 사용하는 자체 서비스를 보유하고 있는데 거기에 나의 VPC에서, 나의 계정에서 나의 Consumer Application으로 액세스하고 싶을 때 '애플리케이션 서비스를 운영하는 업체'에게 프라이빗 링크를 요청해야 하고 '애플리케이션 서비스를 운영하는 업체'는 해당 서비스를 노출하기 위해 Network Load Balancer를 만들어야 한다. 그리고 나는 Elastic Network Inteface를 만든다. 그리고 이 둘 사이에 private Lnk를 설정해서 해당 서비스에 대한 프라이빗 액세스 권한을 갖게한다. 

=> 그러면 모든 인터넷 트래픽은 공용 인터넷을 통과하는 것이 아니라 프라이빗 네트워크를 통과하게 된다. (모든 통신은 프라이빗으로 유지)

      & 3rd party에 신규 유저가 있을 경우에 해당 유저를 위해 새 private Kink를 만들기만               하면 되어서 관리가 쉽고 확장성도 뛰어나다.

 

#5 Direct Connect와 Site-to-Site VPN - 하이브리드 클라우드의 VPC 연결 방법🖇️

하이브리드 클라우드를 다룰건데 온프레미스와 AWS와의 VPC 연결을 하고자 한다면 두 가지 연결 방법을 소개해줄 수 있다.

✴️ 첫 번째 방법 : Site-to-Site VPN - 연결이 빠르다

먼저 VPN이란 온프레미스 데이터 센터와 VPC간의 암호화된 연결을 말하는데 공용 인터넷을 통해 연결된다. 연결하는데 시간이 굉장히 짧아서 좋은데 공용 인터넷을 통하기 때문에 암호화가 되어있어도 대역폭에 제한과 보안 문제가 발생할 수 있다. 

Site-to-Site VPN을 공용 인터넷으로 구현하는 방법

Site-to-Site VPN을 공용 인터넷으로 구현하는 방법(그림 참조) :

온프레미스에 Customer Gateway가 필요하고 AWS에서는 Virtual Private Gateway(가상 프라이빗 게이트)가 필요하다. 이 2가지가 프로비저닝되고 생성이 되면 Site-to-Site VPN으로 연결한다. 

✴️ 두 번째 방법 : Direct Connect(DX) - private 네트워크 사용

Direct Connect는 온프레미스 데이터 센터와 AWS간의 물리적인 연결을 설정하는 것으로 비공개로 연결되어 안전하고 빠르기도 하다. (그리고 private 네트워크를 사용한다)

그러나 물리적인 연결이라 비용이 굉장히 높고 설정하는데만 한 달이 소요된다. 

 

#6 Client VPN - 우리들의 컴퓨터를 VPN에 직접 연결하려면..

우리의 컴퓨터를 AWS VPC에 프라이빗으로 연결하고 싶다고 하자.

그러려고 한다면 ClintVPN으로 OpenVPN을 사용해 AWS의 private 네트워크 혹은 온프레미스에 연결하면 된다. 

클라이언트 VPN은 컴퓨터에 설지하고 공용 인터넷을 통해 VPN 연결을 설정한다. 온프레미스 데이터 센터에 ㅅ이트 간 VPN 연결을 설정한 경우에는 컴퓨터에서도 온프레미스 데이터 센터의 서버에 private으로 액세스할 수 있다. 

 

#7 Transit Gateway - 방대한 인프라를 정리하는 툴🏳️

이런 식으로 AWS에 방대한 인프라가 있는 경우 네트워크 구조는 꽤 복잡해진다.

이를 해결하기 위해서 새로운 서비스가 생겼는데 바로 'Transit Gateway'이다.

복잡한 네트워크 전 /  Transit Gateway로 정리된 네트워크

Transit Gateway는 hub-and-spoke 형태로 수천 개의 VPC와 온프레미스 시스템 간의 피어링 연결을 설정하는 것이다.

그리고 VPC 연결은 Transit Gateway를 통해 연결된다.

=> 따라서 다른 VPN에 피어링 할 필요가 없고 단일 게이트웨이에서 실행 가능한 형태

=> Transit Gateway는 이렇게 수백 또는 수천 개의 VPN을 온프레미스 인프라와 연결하는 방법으로 자리잡고 있다!

 

 

✅짤막한 개념 정리

VPC Peering : 두 개의 VPN을 연결하려는 경우, IP범위가 겹치지 않으면 VPC Peering을 사용할 수 있다.