[AWS] VPC 란 무엇인가

 

 

공부하기에 앞서..

필자는 인프라 구축을 담당하고 있다.

그러던 중 멀티 리전간의 통신을 가능하게 하기 위해

VPC Peering 설정을 하려던 중

무언가 잘못건드려 인터넷 통신을 끊어버렸던 전적이 있다...

 

결국 이사님께 전달하여 해결해주셨다...

 

혼나느라 원인을 여쭙질 못해서..

스스로 공부해 원인을 파악해보려 한다.

ㅠㅠ

 

 

 

VPC 는 Virtual Private Cloud 의 약어이다.

기존 EC2-Classic Platform이라는게 VPC가 나오기 전에는 있었다는데

EC2 인스턴스들이 거미줄처럼 연결되어

복잡도가 매우 높았다고 한다.

 

 

그런데 VPC를 적용하고 나면 VPC 별로 네트워크를 구축할 수 있으니

VPC 별로 다르게 네트워크 설정을 줄 수도 있고

VPC Peering을 통해 VPC 끼리 연결할 수도 있다!

 

VPC의 동작 원리

생성: VPC를 생성하면, 기본적으로 인터넷에 접근할 수 없는 상태가 된다. 인터넷과 연결하려면 인터넷 게이트웨이를 추가하고

라우팅 테이블을 설정해야 된다.
서브넷 분할: VPC를 여러 서브넷으로 나누어, 애플리케이션의 서로 다른 계층을 분리할 수 있다. 퍼블릭 서브넷에는 웹 서버를,

프라이빗 서브넷에는 데이터베이스 서버를 배치하는 것이 일반적이라고 한다.
트래픽 관리: 보안 그룹과 네트워크 ACL을 사용해 인바운드와 아웃바운드 트래픽을 제어한다.

라우팅 테이블을 통해 트래픽의 방향을 설정한다.

 

 

위 사진은 aws 사용설명서에 나와있는 VPC의 특성들이다.

VPC에 서브넷을 설정할 수 있고 그 서브넷을 추가한 후에야 AWS 리소스를 배포할 수 있나보다.

읽어보니 중요한 것은 라우팅과 게이트웨이 및 엔드포인트, 피어링 연결이다.

 

그럼 VPC가 인터넷에 연결되기 위한 구성을 알아보자.

 

인터넷 게이트웨이

VPC와 인터넷 간의 양방향 통신을 가능하게 한다. 즉, 퍼블릭 서브넷의 리소스가 인터넷과 통신할 수 있도록 한다. VPC에 하나의 인터넷 게이트웨이를 연결해야 한다.

 

NAT 게이트웨이

프라이빗 서브넷에 있는 리소스가 인터넷과의 아웃바운드 통신(예: 소프트웨어 업데이트 다운로드)을 할 수 있게 해준다. NAT 게이트웨이는 인바운드 트래픽을 허용하지 않으므로, 프라이빗 서브넷의 보안을 유지한다.

 

라우팅 테이블

트래픽의 방향을 설정한다고 생각하면 된다.

 

퍼블릭 서브넷 라우팅 테이블: 인터넷 게이트웨이로의 경로를 추가하여 퍼블릭 서브넷의 리소스가 인터넷과 통신할 수 있도록 한다.
프라이빗 서브넷 라우팅 테이블: NAT 게이트웨이로의 경로를 추가하여 프라이빗 서브넷의 리소스가 NAT 게이트웨이를 통해 인터넷과 통신할 수 있도록 한다.

 

Destination: 트래픽의 목적지 IP 주소 대역이다. 예를 들어, 0.0.0.0/0은 모든 IP 주소를 의미한다.
Target: 트래픽을 전송할 대상이다. 예를 들어, 인터넷 게이트웨이(igw), NAT 게이트웨이(nat),

또는 다른 서브넷의 라우터 등이 될 수 있다.
Subnet Association: 특정 서브넷이 이 라우팅 테이블을 사용하도록 연결된다.

 

 

그러니까 라우팅 테이블을 활용해서 어떤 인터넷 게이트 웨이와 NAT 게이트웨이를 사용해서 인터넷과 연결할지 결정하는 것이고, 인터넷 게이트웨이는 VPC 와 인터넷 간의 양방향 통신이 가능하게 하고(퍼블릭 서브넷) NAT 게이트웨이는 프라이빗 서브넷이 아웃바운드 통신을  하게 한다.

 

 

VPC 피어링

프라이빗 네트워크 통신: VPC 피어링을 통해 두 VPC 간의 트래픽이 프라이빗 네트워크로 전달되므로, 보안이 강화된다. 인터넷을 거치지 않고, AWS 네트워크를 통해 직접 연결된다.

고가용성 및 확장성: 피어링 연결은 고가용성 및 확장성을 제공한다. 트래픽은 AWS의 네트워크 인프라를 사용하여 전달되므로, 안정성과 성능이 뛰어나다.

리소스 공유: VPC 피어링을 사용하면 서로 다른 VPC에 있는 리소스를 공유할 수 있다. 예를 들어, 하나의 VPC에서 실행 중인 데이터베이스 서버에 다른 VPC에서 접근할 수 있다.

 

이 리소스 공유를 보면 VPC peering을 통해서 내가 멀티 리전을 설정했을 때,

서로 다른 리전의 프라이빗 서브넷에 둔 ec2 인스턴스끼리 

각 프라이빗 ip만을 가지고

보안 그룹 설정을 통해서 통신할 수 있었다.

 

오늘의 결론

내가 사고쳤던 부분은 NAT 게이트 웨이 설정을 고장내버렸던 것이라 생각된다.

우리는 퍼블릭 서브넷에는 bastion 서버만이 존재하고 있다.

나머지 리소스들은 프라이빗 서브넷에 존재하는데

바스티온을 통한 ssh 접근은 가능했으나, 

프라이빗 서브넷에 있는 ec2 인스턴스의 아웃바운드가 되지 않았기에

이를 가능하게 하는 것은 NAT 게이트웨이이기 때문이다!