Cloud

[AWS] VPC

YongE 2025. 5. 2. 12:23

VPC란?

Virtual Private Cloud의 약자로, 독립된 가상 프라이빗 클라우드 네트워크를 의미하며, 이는 사용자만의 격리된 클라우드 네트워크를 구성할 수 있다!

 

VPC 구조

VPC 구조에 대해 알아보자. 아래는 1.0.0.0/16 ip CIDR로 구성된 vpc의 예시다. vpc 생성시 가상 라우터도 생성된다. 

해당 가상 라우터를 통해서 목적지까지 통신할 수 있게 된다.

 

 

 

또한 vpc에서 서브넷을 통해서 부분 네트워크를 분리하여 구성할 수도 있다.

 

 

위와 같은 서브넷 네트워크들은 가상 라우터에 연결돼 통신 환경을 이루고 있다. 또한 서브넷 안을 보면 보안 그룹이 존재하는데 이는 IT 자원의 보안을 위해 구성된 것이며, 네트워크 ACL을 구성해서 필요한 트래픽만 접근가능하게 구성할 수 있다.

 

 

VPC 자체는 격리된 공간이기 때문에 인터넷에 직접적인 연결이 불가능하다. 따라서 인터넷 게이트웨이를 구성하여 인터넷 구간과 직접적인 연결이 가능하다. 또한 필요에 따라서 NAT게이트웨이를 구성해서 IP주소를 변환할 수 있다.

 

AWS의 VPC 유형은 2가지다.

  • 기본 VPC : 리전별로 기본 vpc가 자동으로 생성돼 있다. 다양한 자원들이 기본적으로 정의돼 있다. 리전별로 1개만 있다.
  • 사용자 VPC : 사용자 커스텀한다. 리전별로 최대 5개까지 생성가능하다.

 

VPC 서브넷

 

서브넷에 대한 내용을 조금 더 

위에서 다룬 가정을 그대로 써보자. 당연하겠지만 만약 서브넷을 구성한다면 서브넷의 IP CIDR는 VPC IP CIDR 내에 있어야 한다. 또한, 서브넷은 1개의 가용 영역에 종속돼 있다. 

 

 

VPC는 퍼블릭 서브넷과 프라이빗 서브넷으로 분류할 수 있다.

  • 퍼블릭 서브넷 : 인터넷과 직접적으로 통신할 수 있는 공공 네트워크
  • 프라이빗 서브넷 : 인터넷 구간과 직접적으로 통신할 수 없는 폐쇄적 네트워크

 

VPC 내 가상라우터는 두 서브넷에 모두 연결돼 있고, 인터넷게이트웨이와도 연결돼 있다.  퍼블릭 서브넷에서 인터넷과 통신하려 할 때, 해당 트래픽은 가상라우터의 라우팅 테이블을 보고 인터넷 게이트웨이로 우회된다. 이를 통해 외부 인터넷으로 전달된다. 당연히 프라이빗 서브넷은 가상 라우터를 통해도 인터넷 게이트웨이로 트래픽이 전달되지 않는다. 독립적인 네트워크로 간주할 수 있다.

 

NAT 게이트웨이

인터넷 게이트웨이의 역할은 위에서 사례를 통해 충분히 언급했다고 생각하여 NAT 게이트웨이만 조금 더 상세히 설명해보고자 한다.

Network Address Translation의 약자로, 주로 프라이빗 ip 주소를 퍼블릭 ip 주소로 변환할 때 사용한다.

 

예를 들어, 공유기가 있다고 가정하자. 가정 내 인터넷 연결이 가능한 모든 전자기기는 이 공유기를 통해 인터넷과 연결된다. 다만 모든 기기들에게 퍼블릭 ip 주소를 할당하진 않고, 프라이빗 ip 주소를 할당한다. 이렇게 하면 공유기만이 퍼블릭 ip 주소를 갖는다. 이렇게 하면 특정 기기에서 외부와 통신하려고 할 때 공유기를 통해 ip 주소가 퍼블릭으로 변환된다. 반대의 경우도 마찬가지다.

덧붙여 유명한 ipv4 주소 수량 부족 문제는 이를 통해 해결된다.

 

AWS에서 NAT 게이트웨이는 프라이빗 ip 주소를 퍼블릭 ip 주소로 변환하는 목적으로 퍼블릭 서브넷 상에 위치한다.

 

그렇다면 프라이빗 서브넷에서 인터넷 연결이 불가능할까? 전혀 그렇지 않다.

 

먼저 알아두어야 할 것은, 프라이빗 서브넷의 라우팅 테이블에 인터넷 게이트웨이 주소를 그대로 넣을 수는 없다. 그렇기 때문에 NAT 게이트웨이의 주소를 넣는다.

 

그러면 이제 프라이빗 서브넷에서 외부 인터넷으로 트래픽을 보낸다고 가정하자. 라우팅 테이블을 통해 NAT 게이트웨이로 전달되고, 퍼블릭 서브넷의 NAT 게이트웨이에서 퍼블릭 IP 주소로 변경된다. 그 다음에 퍼블릭 서브넷의 라우팅 테이블을 통해 인터넷 게이트웨이를 통해 외부 인터넷으로 트래픽이 전달된다.

 

그렇다면 반대의 경우에도 가능할까? 그렇지 않다!

프라이빗 ip 주소는 독립된 네트워크에서만 사용가능한 사설 ip 주소이다. 따라서 인바운드 트래픽의 경우는 허용하지 않는다. 이는 프라이빗 서브넷의 궁극적인 목표가 서브넷 내 자원이 외부로 노출되지 않도록 보장하는 보안성 강화에 있기 때문이다.

 

그럼 외부에서 프라이빗 서브넷의 자원에는 접근하지 못하는가?

Bastion Host를 구성하면 가능하다. 퍼블릭 서브넷 내에 ec2처럼 자원을 생성하고, 이를 통해 프라이빗 서브넷의 자원에 접근할 수 있다.

 

보안 그룹과 네트워크 ACL

보안 그룹과 네트워크 Access Control List(ACL)의 공통된 목적은 트래픽 접근 제어다. VPC 내 서브넷과 서브넷 내 IT 자원을 보호하는 가상 방화벽의 기능을 수행한다.

 

이 둘의 차이를 설명하기 전에 각 서브넷에 인스턴스가 2개씩 할당돼 있다고 가정해보자.

 

 

보안 그룹은 서브넷 내 IT 자원들을 보호하기 위해 앞단에 위치하여 트래픽 접근 제어를 수행한다.

네트워크 ACL은 서브넷 자체를 보호하기 위해 앞단에 위치하여 트래픽 접근 제어를 수행한다.

 

이 둘의 차이는 보호하는 대상이다. 만약 특정 트래픽이 가상 라우터를 통해 인스턴스 B1으로 간다고 가정하자. 여기서 네트워크 ACL이 트래픽 접근을 제어한다. 서브넷에서 허용할 트래픽인지 아닌지를 판단한 후에 인스턴스 B1으로 보낸다. 다만 여기서 한 번 더 보안그룹을 통해 인스턴스에 허용될 수 있는지 없는지 판단 후에 전달한다.

 

문득 최근에 배운 대응 방안 중 전제 상황에 이런 게 있었다. 특정 ip 주소에서 대량의 트래픽이 발생했을 때 보안그룹 단에서 제외하지 않고, 네트워크 ACL에서 설정하는 것이다. 트래픽을 서브넷에 들이지 않고 더 앞단에서 필터링함으로써 이에 사용되는 리소스를 줄일 수 있기 때문이다. 

반응형