[Infra] AWS 인프라 입문 (VPC, Subnet, Route Table, NAT Gateway, AZ..)

그동안 EC2 인스턴스만 활용해 비교적 단순한 방식으로 서버를 배포해왔는데, 최근 새로운 프로젝트에 합류하면서 다양한 AWS 서비스(VPC, 서브넷, 가용 영역(AZ) 등)를 사용하는 클라우드 기반의 아키텍처를 접하게 되었다. 아키텍처를 보자마자 어느 정도 파악은 했지만, 온전히 이해하지 못한 부분이 많아 아쉬움이 남았다는 슬픔.. 하지만 이제 서버 개발자는 나 혼자이기 때문에 혼자서 유지보수와 확장을 담당해야 하므로, 각 기술이 어떤 역할을 하는지 이해해야 한다. 그래서 뜬금없지만 오늘은 AWS 인프라에 대해 정리해 보려고 한다.

 

1.  AWS 클라우드 아키텍처 살펴보기

EC2 인스턴스만으로도 기본적인 서버를 구축할 수 있지만, 복잡한 애플리케이션 운영이나 보안, 고가용성, 확장성과 같이 요구 사항을 만족하려면 AWS 네트워크 인프라의 구성 요소들을 알아야 한다.(물론 AWS를 사용한다 가정했을 경우에) 따라서 이 글에선 서브넷, 라우팅, NAT 게이트웨이, 인터넷 게이트웨이, 보안 그룹, 네트워크 ACL과 같은 AWS 네트워크 인프라의 구성 요소 개념들을 정리하려 한다. 이 요소들은 AWS 환경에서 네트워크를 효과적으로 관리하고, 보안을 강화하며, 다양한 서비스 간 원활한 통신을 구현하는 것을 도와준다.

 

위 그림들은 다양한 AWS VPC 구성 예시를 담고 있다. 물론, 이 아키텍처들이 꼭 정답은 아니다. 하지만 오늘 다룰 개념들을 보다 직관적으로 이해할 수 있도록 여러 예시를 준비했다. 이 글을 통해 그림에 등장하는 다양한 구성 요소들이 어떤 역할을 수행하는지, 그리고 이를 통해 AWS 인프라를 어떻게 효과적으로 구성할 수 있는지 알아볼 예정이다.

 

2. AWS VPC란?

2.1. VPC란?

VPC의 정의

VPC란 Virtual Private Cloud의 약자로, 논리적으로 격리된 가상 네트워크이다. AWS VPC는 이 VPC 개념을 AWS 클라우드에서 구현한 서비스이다. VPC를 사용하면 다른 사용자와 네트워크가 분리되며, 보안 및 네트워크 관리를 쉽게 할 수 있도록 도와준다. 또한, IP 주소 대역을 사용자가 직접 지정할 수 있으며, 네트워크 토폴로지를 자유롭게 설계할 수 있다. VPC는 마치 온프레미스 데이터센터의 네트워크처럼 동작하여, IP 주소 범위, 서브넷, 라우팅, 보안 정책 등을 사용자가 자유롭게 설정할 수 있게 해 준다.

 

(온프레미스 네트워크는 기업이나 조직이 자체적으로 소유하거나 관리하는 물리적 데이터센터 및 네트워크 환경이다. 온프레미스 환경은 서버, 스토리지, 네트워크 장비 등이 조직 내부에 설치되어 있으며, 외부 클라우드 서비스와는 별도로 운영된다. 온프레미스 네트워크는 보안, 데이터 제어, 성능 측면에서 장점이 있으며, 특정 규제나 요구사항에 따라 클라우드 대신 선택되기도 한다.)

 

VPC에서 관리하는 네트워크 구성 요소 및 리소스

VPC 내부에서는 여러 구성 요소와 리소스를 체계적으로 관리하여, 네트워크의 안정성과 보안, 효율적인 트래픽 흐름을 보장한다. 하나의 VPC에서 다음과 같은 네트워크 구성 요소와 리소스를 관리한다.

• IP 주소 관리: VPC 내에서 사용할 IP 주소 범위(CIDR 블록)를 설정하고, 이 범위를 서브넷으로 나누어 각 서브넷에 할당한다. 이를 통해 네트워크의 크기와 각 서브넷의 용도를 미리 계획할 수 있다.
• 서브넷 구성: 퍼블릭 서브넷과 프라이빗 서브넷을 생성하여, 외부와 직접 통신하는 리소스와 내부 전용 리소스를 구분한다. 이로써 보안 및 접근 제어가 용이해진다.
• 라우팅 테이블 설정: 내부 트래픽의 이동 경로뿐 아니라, 각 서브넷에서 나가는 트래픽의 경로를 제어하기 위해 라우팅 테이블을 구성한다. 이를 통해 인터넷 게이트웨이나 NAT 게이트웨이와 같은 외부 연결을 효과적으로 관리할 수 있다.
• 보안 정책 적용: 보안 그룹과 네트워크 ACL(Access Control List, 네트워크 접근 제어 목록)을 사용하여 인스턴스 및 서브넷 단위의 트래픽을 제어하고, 접근 권한을 설정한다. 이를 통해 외부 침입이나 불필요한 접근을 차단할 수 있다.
• 외부 연결 관리: 인터넷 게이트웨이, NAT 게이트웨이, VPN 연결 등을 통해 외부 네트워크와의 통신 경로를 설정하고 관리한다. 이는 VPC 내부 리소스가 필요할 때 외부와 안전하게 통신할 수 있도록 해준다.

이처럼 VPC에서는 IP 주소 관리, 서브넷 구성, 라우팅 테이블 설정, 보안 정책 적용, 외부 연결 관리 등 다양한 네트워크 구성 요소를 체계적으로 운영할 수 있다. 따라서, VPC를 활용하면 같은 물리적 클라우드 인프라 내에서도 완벽하게 격리된 환경을 제공받아 보안을 강화하고, 온프레미스 네트워크와 유사하게 유연한 구성 및 통합 관리가 가능하다.

 

 

보통 VPC를 나누는 기준은 다음과 같다.

• 환경 분리: 운영, 스테이징, 개발 등 서로 다른 환경을 분리하기 위해 별도의 VPC를 구성하거나, 하나의 VPC 내에서 서브넷으로 분리하는 경우가 있다.
• 조직 또는 부서 분리: 서로 다른 조직 단위나 부서 간에 네트워크 격리가 필요할 경우, 각 부서별로 VPC를 구성하거나, VPC 내에서 논리적으로 분리된 서브넷을 사용할 수 있다.
• 보안 요구 사항: 민감한 데이터가 포함된 서비스와 일반 서비스 간에 보안 격리가 필요할 경우, 별도의 VPC를 사용하여 네트워크를 완전히 분리하기도 한다.
• 리소스 및 관리 효율: 하나의 VPC 내에서 리소스를 집중적으로 관리하거나, 여러 VPC로 분산하여 관리 부담을 줄이는 방안을 상황에 따라 선택한다.

 

2.2. 서브넷(Subnet)이란?

https://medium.com/harrythegreat/aws-%EA%B0%80%EC%9E%A5%EC%89%BD%EA%B2%8C-vpc-%EA%B0%9C%EB%85%90%EC%9E%A1%EA%B8%B0-71eef95a7098

서브넷은 VPC 내에서 전체 IP 주소 범위(CIDR 블록)를 더 작은 단위로 나눈 논리적 네트워크 영역이다. 서브넷을 사용하면 하나의 VPC 내에서 네트워크를 여러 개의 구역(웹 서버, 애플리케이션 서버, 데이터베이스 등)으로 분리하여, 용도나 보안 정책에 따라 리소스를 그룹화할 수 있다.

 

일반적으로 퍼블릭 서브넷과 프라이빗 서브넷으로 나누어 사용한다.

• 퍼블릭 서브넷: 외부 인터넷과 직접 연결할 수 있도록 설정된 서브넷이다. 보통 인터넷 게이트웨이(IGW)와 연결되어 있으며, 웹 서버나 애플리케이션 서버 등 외부와 통신이 필요한 리소스를 배치한다.
• 프라이빗 서브넷: 외부와 직접 통신하지 않도록 격리된 서브넷이다. 보안이나 내부 데이터베이스 등 외부 노출이 민감한 리소스를 배치한다.

사용자는 VPC에 할당된 CIDR 블록에서 특정 범위를 선택하여 서브넷의 CIDR 블록을 정의한다. 이를 통해 네트워크의 규모와 각 서브넷에 배치할 리소스의 용도를 미리 계획할 수 있다.

 

2.3. 라우팅 테이블(Route Table) & 라우터란?

라우팅 테이블은 네트워크 내에서 패킷이 어떤 경로를 통해 전달되어야 하는지를 결정하는 설정 목록이다. 라우팅 테이블은 서브넷 단위로 적용되며, 각 서브넷의 인바운드와 아웃바운드 트래픽이 어디로 이동해야 하는지 경로를 정의한다. 

 

1. 라우팅 테이블의 주요 기능

• 내부 트래픽 제어: 같은 VPC 내의 서브넷 간 또는 동일 VPC 내의 리소스 간 통신 경로를 지정할 수 있다.
• 외부 연결: 예를 들어, 퍼블릭 서브넷의 라우팅 테이블은 0.0.0.0/0(모든 외부 IP)에 대한 경로를 인터넷 게이트웨이(IGW)로 지정하여, 외부 인터넷과의 연결을 가능하게 한다. 프라이빗 서브넷의 경우, 외부로 나가는 트래픽을 NAT 게이트웨이를 통해 라우팅함으로써, 외부 접근은 차단하면서도 아웃바운드 통신은 가능하게 한다.
• 세부 제어: 각 서브넷에 연결된 라우팅 테이블을 통해 트래픽을 세밀하게 제어할 수 있으며, 필요에 따라 특정 IP 대역으로의 접근만 허용하는 등의 정책을 적용할 수 있습니다. 

각 라우팅 테이블에는 여러 개의 라우트(경로)가 존재하며, 이들 라우트는 목적지 IP 범위와 해당 트래픽을 전달할 다음 홉(IGW, NAT Gateway, VPN Gateway 등)을 명시한다.

 

2. VPC 내 라우팅 테이블 구성

• VPC의 기본 라우팅 테이블: VPC를 생성하면 하나의 기본 라우팅 테이블이 자동으로 생성되며, 서브넷이 별도로 지정된 라우팅 테이블이 없으면 이 기본 테이블과 암시적으로 연결된다.
• 서브넷의 라우팅 테이블 연결: 각 서브넷은 한 번에 하나의 라우팅 테이블과 연결된다. 서브넷마다 고유한 라우팅 테이블을 가질 수도 있고, 여러 서브넷이 동일한 라우팅 테이블을 공유할 수도 있다. 즉, 명시적으로 다른 라우팅 테이블을 지정하지 않으면 서브넷은 기본 라우팅 테이블의 규칙을 따르게 되며, 필요에 따라 추가 라우팅 테이블을 만들어 특정 서브넷에 할당할 수 있다.

이처럼 라우팅 테이블은 VPC 내에서 네트워크 트래픽의 경로를 결정하는 중요한 요소로, 기본 라우팅 테이블과 서브넷별 연결을 통해 내부와 외부 트래픽을 세밀하게 제어할 수 있다.

 

라우터는 실제로 패킷을 전달하는 네트워크 장비 또는 소프트웨어 구성 요소이다.

• 라우터는 라우팅 테이블에 정의된 규칙을 참고하여, 패킷을 적절한 경로로 전송한다.
• AWS 환경에서는 물리적인 라우터 대신, 이 기능이 추상화되어 VPC 내에서 기본적으로 관리된다.

즉, 라우팅 테이블은 "어디로 보내야 할지 결정하는 규칙 모음"이고, 라우터는 이 규칙을 바탕으로 실제 패킷을 전달하는 "실제 통신 장치"이다. AWS에서는 사용자가 직접 라우터를 관리하지 않고, 라우팅 테이블 설정을 통해 네트워크 경로를 제어하는 방식으로 구성된다.

 

2.4. NAT 게이트웨이란?

NAT(Network Address Translation) 게이트웨이는 프라이빗 서브넷의 인스턴스가 외부 인터넷에 접근할 때, 인스턴스의 프라이빗 IP 주소를 공용 IP 주소로 변환해 주는 역할을 한다. 프라이빗 서브넷에 배치된 인스턴스는 외부에서 직접 접근할 수 없으므로, NAT 게이트웨이를 통해 아웃바운드 요청(소프트웨어 업데이트, API 호출 등)을 외부 인터넷으로 전송할 수 있다. 이를 통해 프라이빗 서브넷의 리소스는 직접 외부에 노출되지 않고, 아웃바운드 통신은 안전하게 수행할 수 있다.

 

NAT 게이트웨이의 동작 원리는 먼저 프라이빗 서브넷의 인스턴스가 자신의 프라이빗 IP 주소를 사용해 트래픽을 전송하는 것으로 시작된다. 퍼블릭 NAT 게이트웨이가 이 트래픽을 받으면, 인스턴스의 프라이빗 IP를 NAT 게이트웨이의 프라이빗 IP로 매핑한 후, 인터넷 게이트웨이가 이를 엘라스틱 IP(공용 IP)로 다시 매핑하여 외부로 전송한다. 외부에서 응답 트래픽이 도착하면, NAT 게이트웨이는 이 응답의 대상 IP를 원래 인스턴스의 프라이빗 IP로 다시 변환하여 전달함으로써, 통신이 원활하게 이루어지도록 한다.

 

이와 같은 주소 변환 과정을 통해 NAT 게이트웨이는 프라이빗 서브넷의 인스턴스에 직접적인 외부 접근을 차단하면서도, 아웃바운드 요청은 가능하게 하여 보안을 강화한다. NAT 게이트웨이는 보통 퍼블릭 서브넷에 배치되며, 프라이빗 서브넷의 라우팅 테이블에 0.0.0.0/0 트래픽을 NAT 게이트웨이를 경유하도록 설정함으로써, 모든 외부 트래픽이 이 장치를 통해 전달되도록 구성된다.

결과적으로, NAT 게이트웨이는 프라이빗 서브넷의 인스턴스들이 외부와 안전하게 통신할 수 있도록 주소 변환을 수행하고, 외부로부터 직접 접근을 차단하여 네트워크 보안을 강화하는 중요한 역할을 수행한다.

 

• NAT 인스턴스: NAT 인스턴스는 NAT 게이트웨이와 유사한 기능을 수행하지만, AWS가 관리하는 서비스가 아니라 사용자가 직접 EC2 인스턴스를 설정하고 관리하는 방식이다. 따라서 유지보수나 스케일링 같은 작업을 직접 처리해야 하며, 성능과 확장성 면에서는 NAT 게이트웨이가 더 선호된다.

 

2.5. 보안 그룹(Security Group) & 네트워크 ACL(Access Control List)이란?

AWS VPC는 네트워크 보안을 강화하기 위해 Security Group과 Network ACL이라는 두 가지 계층의 제어 기능을 제공한다. 이 둘은 각각 다른 수준에서 트래픽을 필터링하며, 함께 사용될 때 보다 더 견고한 보안 모델을 만들 수 있다. 아래 그림을 보면, Security Group과 Network ACL이 VPC 내에서 서로 다른 위치에서 동작한다는 것을 좀 더 직관적으로 이해할 수 있을 것이다.

항목	Security Group	Network ACL
적용 대상	인스턴스(EC2) 단위	서브넷 단위
허용/거부 규칙	허용(Allow) 규칙만	허용(Allow) 및 거부(Deny) 규칙 모두 지원
상태 저장 여부	상태 저장(Stateful)	상태 비저장(Stateless)
응답 트래픽 처리	인바운드 허용 시 응답 트래픽 자동 허용	인바운드와 아웃바운드 규칙을 각각 정의
룰 평가 방식	모든 규칙 종합 평가	룰 번호 순서대로 평가

 

Security Group(1차 보안)

• 인스턴스(EC2) 레벨에서 적용 : Security Group은 각 인스턴스(또는 해당 인스턴스의 네트워크 인터페이스)에 직접 할당된다. 웹 서버라면 80/443 포트를 열고, DB 서버라면 3306 포트만 허용하는 식으로 구체적으로 설정할 수 있다.
• 상태 저장(Stateful) 방식 : 인바운드 트래픽을 허용하면, 그에 대한 응답 트래픽은 자동으로 허용된다. 예를 들어, 인스턴스가 외부에 요청을 보냈다면, 그 응답 패킷은 별도의 규칙 없이도 들어올 수 있다.
• 허용된 규칙만 지원 : 명시적으로 허용(Allow)되지 않은 모든 트래픽은 기본적으로 거부(Deny)된다. 거부(Deny) 규칙을 따로 설정할 필요 없이, 허용할 트래픽만 지정하면 된다.

Network ACL(2차 보안)

• 서브넷 레벨에서 적용 : Network ACL은 서브넷 전체에 걸쳐 트래픽을 필터링한다. 서브넷 내부의 모든 인스턴스는 해당 Network ACL의 규칙을 공유한다.
• 상태 비저장(Stateless) 방식 : 인바운드와 아웃바운드 트래픽 규칙을 각각 정의해야 한다. 예를 들어, 인바운드 80/443 포트를 허용해도, 아웃바운드에 80/443 규칙이 없으면 응답이 차단될 수 있다.
• 허용/거부 규칙 모두 지원 : Allow와 Deny 규칙을 모두 지정할 수 있다. 룰 번호에 따라 순서대로 평가되므로, 가장 먼저 매칭되는 규칙에 의해 트래픽이 허용되거나 거부된다.

Security Group은 인스턴스 레벨에서 세밀한 트래픽 제어를 제공하고, 상태 저장 방식이므로 설정이 간편하다. Network ACL은 서브넷 단위로 전체 트래픽을 필터링하고, 허용/거부 규칙을 모두 지원해 더 세밀한 제어가 가능하지만, 상태 비저장 방식이라 인바운드와 아웃바운드 규칙을 각각 설정해야 한다. 이 둘을 함께 사용하면, 인스턴스에 도달하기 전(서브넷 차원)과 인스턴스 레벨 모두에서 트래픽을 제어할 수 있어 이중 보안을 구현할 수 있다.

 

2.6. 인터넷 게이트웨이(Internet Gateway, IGW)

인터넷 게이트웨이(Internet Gateway, IGW)는 AWS VPC와 외부 인터넷을 연결하는 다리 역할을 한다. 즉, VPC 내 퍼블릭 서브넷에 배치된 인스턴스들이 외부와 양방향 통신할 수 있도록 하는 구성 요소이다.

예를 들어, 퍼블릭 서브넷의 라우팅 테이블에 '0.0.0.0/0' 경로가 IGW로 지정되어 있으면, 해당 서브넷의 인스턴스는 아웃바운드 트래픽을 IGW를 통해 외부 인터넷으로 전송하고, 외부에서 들어오는 응답 트래픽도 IGW를 통해 VPC 내부로 전달된다. IGW는 AWS가 관리하는 서비스이므로, 안정적이고 확장 가능한 인터넷 연결을 제공하며, VPC와 쉽게 통합하여 사용할 수 있다.

결과적으로, 인터넷 게이트웨이는 퍼블릭 IP를 가진 인스턴스가 외부와 안전하게 통신할 수 있도록 지원하는 네트워크 장치로, VPC 내부와 인터넷 간의 트래픽 흐름을 원활하게 관리한다.

 

 

3.  네트워크 확장 옵션 & 인프라 고려 사항

앞서 소개한 구성 요소들 외에도, AWS 인프라를 더욱 효율적으로 확장하고 관리하기 위해 고려할 수 있는 다양한 연결 옵션들이 있다.

 

AZ(Availability Zone, 가용 영역)은 AWS 리전 내에서 하나 이상의 물리적 데이터 센터를 묶어 구성한 논리적 단위이다. 각 AZ는 독립적인 전원, 냉각, 보안 시스템과 초저지연 네트워크로 연결되어 있다. 따라서, VPC 내 여러 AZ에 리소스를 분산 배치하면 단일 AZ에 장애가 발생해도 VPC에 배치된 다른 AZ의 인스턴스들이 자동으로 서비스를 유지해 고가용성과 내결함성을 확보할 수 있다. 또한, AWS 리전은 최소 두 개 이상의 AZ로 구성되며, 예를 들어 서울 리전(ap-northeast-2)은 ap-northeast-2a, 2b, 2c, 2d와 같이 여러 AZ로 이루어져 있어, 애플리케이션을 다중 AZ 환경에 배포하여 장애에 대비할 수 있다. 

 

Auto Scaling은 AWS 서비스로, 애플리케이션 서버를 Auto Scaling 그룹에 배치하여, 트래픽 부하에 따라 자동으로 인스턴스의 수를 늘리거나 줄여주는 기능이다. 부하가 증가하면 자동으로 인스턴스 수를 늘려 응답 속도와 처리량을 유지하고, 부하가 감소하면 불필요한 리소스를 축소하여 비용 효율성을 높인다. 이를 위해 Auto Scaling은 CloudWatch와 같은 모니터링 도구를 사용하여 CPU 사용률, 네트워크 트래픽 등 다양한 지표를 지속적으로 감시하며, 미리 정의한 스케일링 정책에 따라 스케일 아웃(인스턴스 추가) 또는 스케일 인(인스턴스 축소)을 수행한다. 또한, Auto Scaling 그룹은 여러 가용 영역(AZ)에 걸쳐 인스턴스를 분산 배치하여 한 AZ에 장애가 발생하더라도 다른 AZ의 인스턴스를 통해 서비스가 계속 운영될 수 있도록 하여 고가용성과 안정성을 확보한다.

 

로드 밸런싱(Load Balancing)은 외부에서 들어오는 트래픽을 여러 인스턴스로 균등하게 분산시켜, 한 인스턴스에 과부하가 걸리거나 장애가 발생해도 다른 인스턴스가 서비스를 지속할 수 있도록 하는 기술이다. AWS에서는 ALB(Application Load Balancer)와 NLB(Network Load Balancer)를 통해 이를 구현하며, VPC 내 여러 가용 영역에 인스턴스를 분산 배치함으로써 고가용성과 내결함성을 높인다. 장점은 트래픽 분산을 통한 안정적인 서비스 제공과 자동 스케일링과의 연동이 용이하다는 점이며, 단점으로는 복잡한 라우팅 규칙 구성 시 추가 관리 오버헤드가 발생할 수 있다는 점이 있다.

 

이외에도, AWS에서는 다양한 연결 옵션들이 있다. 예를 들어, VPN은 암호화된 터널을 통해 VPC와 온프레미스 또는 다른 외부 네트워크 간에 안전한 통신을 지원하며, Transit Gateway는 여러 VPC와 온프레미스 네트워크를 중앙 집중식으로 연결해 네트워크 관리를 단순화한다. 또한, VPC 피어링을 통해 서로 다른 VPC 간 프라이빗 IP 기반의 직접 통신이 가능하고, Direct Connect는 온프레미스 데이터 센터와 AWS 클라우드를 전용 회선을 통해 안정적이고 낮은 지연 시간으로 연결해 준다. 이러한 추가 옵션들을 상황과 요구 사항에 맞게 선택해 활용하면, AWS 네트워크 인프라를 더욱 확장 가능하고 효율적으로 운영할 수 있다.

 

 

결론

이번 글에서는 AWS VPC를 중심으로 주요 네트워크 인프라 구성 요소들을 간단하게 정리해 봤다. 하지만 AWS에는 이외에도 정말 정말 많은 기술들이 있다. 물론 인프라를 구축할 때 AWS를 많이 사용하긴 하지만 무조건적으로 사용하는 것은 아니다. (특히나 자체 클라우드를 사용하는 기업에선 더더욱 그럴 수도..?!) 하지만 대부분의 클라우드 환경이나 인프라 구축 시, 기술 명칭의 차이만 있을 뿐이지 전체적인 구조는 유사하다고 생각했다. 따라서 각 상황에 맞는 인프라를 구축하기 위해서는 하나의 클라우드에서라도 다양한 옵션들을 폭넓게 알고 있으면 좋을 것 같아서 가장 사용을 많이 하는 AWS를 기반으로 이렇게 공부를 시작하게 됐다. 물론 오늘 정리를 기반으로 기술별 장단점, 사용 환경과 단점에 대한 개선 방안과 같은 부분에 대해서 더 찾아보면 좋을 것 같다. (하지만 인프라를 입문하는 지금 나에겐 이미 너무 방대한 지식이다 ㅎㅎ.. 저런 건 실전에서 하나하나 고쳐가면서 배워야겠다)

 

클라우드 아키텍처를 그리는 것이 처음에는 다소 어려울 수 있지만, 아니 그냥 어렵다.. 이 글을 시작으로 차근차근 정리하면 조금씩 잘 이해되지 않을까.. 싶다!!!!!  앞으로는 프로젝트 운영 환경에서 기술들을 적용해 보며 그 과정을 기록해 봐야겠다.