AWS 글로벌 인프라의 기반 구조: 리전과 가용 영역
AWS 클라우드의 안정성과 확장성은 리전(Region)과 가용 영역(Availability Zone, AZ)이라는 핵심 빌딩 블록에 의해 보장된다. 이러한 구조를 이해하는 것이 복원력 있는 클라우드 아키텍처를 구축하기 위한 가장 근본적인 토대가 된다.
AWS 리전(Region)의 정의 및 역할
AWS 리전은 지리적으로 독립된 구역으로서, AWS 서비스를 배포하고 운영하는 최상위 단위를 의미한다. 리전 선택은 데이터 거버넌스 및 규제 준수, 최종 사용자 지연 시간(Latency) 최소화, 그리고 광범위한 지역적 재해에 대비한 지리적 격리를 고려하여 이루어진다. 각 리전은 독립적으로 운영되도록 설계된 다수의 AZ를 포함하여, 단일 지역적 실패가 전체 서비스에 영향을 미치지 않도록 높은 복원력을 제공한다.
[출처: https://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-fault-isolation-boundaries/regions.html]
가용 영역(Availability Zone, AZ)의 역할과 중요성
가용 영역(AZ)은 AWS 리전 내에서 논리적으로 격리된 섹션이다. AZ는 인프라 격리 환경에 일종의 추상화 계층을 제공하여 사용자가 물리적 위치에 구애받지 않고 논리적 격리 환경에 클라우드 자원을 프로비저닝할 수 있게 한다.
[출처: https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/using-regions-availability-zones.html]
- 물리적 및 논리적 격리 특성: AZ는 낙뢰, 지진과 같은 광범위한 문제로부터 보호하기 위해 물리적으로 유의미한 거리를 두고 설치된다. 가장 중요한 점은, 각 AZ가 전력이나 기타 기반 인프라를 서로 공유하지 않는다는 것이다. 이러한 인프라 미공유 설계는 연쇄적 장애를 원천적으로 차단한다. 하지만 AZ는 애플리케이션의 신속한 장애 조치를 위해 빠르고 암호화된 프라이빗 광섬유 네트워크로 서로 연결되어 있다.
- AZ ID를 통한 일관성 확보: AZ는 사용자 계정마다 다른 논리적 이름으로 매핑될 수 있지만, AWS는 AZ ID라는 고유하고 일관된 식별자를 사용하여 여러 계정 또는 사용자 간의 인프라 배포 위치에 대한 일관성을 보장한다.
고가용성 및 복원력 설계의 핵심: 정적 안정성(Static Stability) 개념
AWS는 높은 가용성을 달성하기 위해 정적 안정성(Static Stability)이라는 패턴을 적용한다. 이 설계 철학은 종속 시스템(예: 특정 AZ)에서 장애가 발생하더라도 전체 시스템이 정상적으로 작동하도록 설계하는 것을 핵심으로 한다.
전통적인 방식이 장애 발생 시 트래픽을 다른 활성 영역으로 신속하게 전환(Failover)하는 데 중점을 두었다면, 정적 안정성은 모든 영역이 항상 활성 상태로 유지(Active-Active 패턴)되며, 장애가 발생한 종속 시스템의 기능만 제한적으로 영향을 받는 'Fail-in-Place' 방식을 강조한다. 이 설계는 아키텍처 구축 시 단일 AZ 장애에 대비하여 항상 최소 두 개 이상의 AZ에 걸쳐 자원을 분산 배치해야 한다는 강력한 아키텍처적 결론을 제시한다.
VPC의 이해: 나만의 격리된 가상 데이터 센터
AWS 환경에서 Virtual Private Cloud (VPC)는 사용자가 AWS 클라우드 내부에 자체적으로 논리적으로 격리된 가상 네트워크 환경을 구축하고 관리할 수 있도록 해주는 핵심 서비스이다.
VPC 정의 및 논리적 격리 환경
VPC는 사용자에게 할당된 사설 IP 주소 공간을 기반으로 하는 나만의 네트워크 공간을 생성하는 것과 같다. VPC는 공인 IP 주소 부족 문제와, 외부에 노출되어서는 안 되는 민감한 인스턴스에 대한 강력한 보안 격리를 제공한다. VPC의 CIDR 블록 내에서만 트래픽이 로컬로 라우팅되며, 정의된 게이트웨이를 통하지 않고서는 외부 인터넷과 직접 통신할 수 없도록 설계되어 완벽한 주소 공간의 충돌 방지 및 보안 격리를 보장한다.
[출처: https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/what-is-amazon-vpc.html]
VPC 설계의 첫걸음: CIDR 블록 할당
VPC를 생성할 때 가장 먼저 CIDR (Classless Inter-Domain Routing) 블록을 정의하여 해당 VPC 내에서 자원들에게 할당될 수 있는 전체 사설 IP 주소 공간을 결정한다. VPC는 반드시 Private IP 대역(10.x.x.x, 172.16.0.0/12, 192.168.x.x) 내에서 정의되어야 한다. CIDR 블록은 초기 설계 단계에서 미래의 확장성을 충분히 고려하여 충분히 큰 사설 대역을 확보해야 한다.
VPC 구성 필수 요소 및 설계 단계
성공적인 VPC 환경을 구축하기 위해서는 네트워킹의 기본 요소들을 단계적으로 정의하고 구성해야 한다.
| 단계 | 구성 요소 | 설계 의도 | 핵심 개념 연관 |
|---|---|---|---|
| 1 | CIDR 블록 정의 | VPC의 사설 IP 주소 공간 확정 | 사설 IP 주소 대역, 확장성 |
| 2 | 서브넷 생성 (AZ 매핑) | 네트워크 세그먼트 분리 및 AZ 간 고가용성 확보 | AZ 1:1 종속성 |
| 3 | 인터넷 게이트웨이(IGW) 연결 | VPC의 인터넷 통신 관문 설정 | 퍼블릭/프라이빗 분리 |
| 4 | 라우트 테이블 설정 | 트래픽 경로 결정 및 서브넷 유형 정의 | 로컬 라우팅, IGW 연결 |
| 5 | 보안 규칙 적용 (NACL/SG) | 다계층 방화벽을 통한 자원 보호 | Stateless vs. Stateful |
서브넷과 IP 주소 체계
서브넷(Subnet)의 역할과 VPC 내 네트워크 분리
서브넷은 VPC 내 IP 대역에서 분리된 네트워크 세그먼트로서, 자원들을 효율적이고 안전하게 배치하기 위한 최소 단위이다. 주된 목적은 네트워크망을 분리하여 (예: 퍼블릭 서브넷, 프라이빗 서브넷) 보안 요구 사항과 외부 접근성 요구 사항이 다른 자원들을 격리하는 것이다.
가용 영역 종속성의 구조적 함의:
서브넷은 1개의 가용 영역(AZ)에 종속되어야 한다는 가장 근본적인 제약 사항을 가진다. 이 규칙은 클라우드에서 진정한 복원력을 확보하기 위해서는 최소 2개 이상의 AZ에 걸쳐 서브넷을 구성하고 자원을 분산 배치해야 한다는 설계 패턴을 강제한다.
IP 주소 할당 규칙: AWS 예약 IP
AWS는 VPC 내 네트워킹 인프라 운영을 위해 서브넷 IP 대역 내에서 특정 IP 주소들을 예약하고 사용자 할당을 금지한다. 서브넷의 CIDR 블록에서 첫 번째에서 네 번째까지, 그리고 마지막 IP 주소는 예약되어 있으며 할당할 수 없다.
| 예약 IP 주소 (예: 10.0.0.0/24 서브넷) | 역할 |
|---|---|
| 10.0.0.0 | 네트워크 주소 (서브넷의 시작 주소) |
| 10.0.0.1 | AWS VPC 가상 라우터 주소 |
| 10.0.0.2 | AWS DNS 서버 주소 |
| 10.0.0.3 | 향후 사용을 위한 예약 주소 |
| 10.0.0.255 | 브로드캐스트 주소 (현재 미사용) |
필수 IP 주소 개념 상세 분석: Private/Public/Elastic IP
| 특징 | Elastic IP (EIP) | Public IP | Private IP |
|---|---|---|---|
| Static/Dynamic | 고정 (Static) | 유동 (Dynamic) | 고정 (Static) |
| 변경 시점 | 사용자가 연결/해제 시 | 인스턴스 중지/재시작 시 변경됨 | 고정적으로 유지 |
| 목적 | 안정적인 외부 서비스 제공 (DNS 매핑) | 임시적인 외부 통신 | 내부/로컬 통신 |
- Private IP (사설 IP): VPC 내의 로컬 네트워크 내부에서 사용되는 IP 주소이며, 인스턴스의 네트워크 인터페이스(ENI)에 고정되어 내부 통신을 담당한다.
- Public IP (공인 IP): 전 세계에서 유일한 IP 주소이며, 인스턴스가 중지되었다가 다시 시작될 때마다 IP 주소가 달라질 수 있는 유동적(Dynamic) 특성을 가진다.
- Elastic IP (EIP): AWS가 제공하는 고정적(Static) Public IP를 의미한다. 서비스 운영의 안정성을 위해 인스턴스 중지 및 재시작에도 바뀌지 않는 고정된 주소가 필요할 때 사용되며, 장애 발생 시 다른 리소스로 연결 해제 및 재연결이 가능하다.
트래픽 흐름 제어: 라우팅 및 게이트웨이
가상 라우터(Virtual Router)와 라우트 테이블(Route Table, RT)의 작동 원리
VPC 환경의 모든 서브넷에는 암묵적으로 가상 라우터가 존재한다. 가상 라우터는 자신이 보유한 라우트 테이블(RT)을 참고하여 트래픽의 목적지를 결정한다. 라우트 테이블은 최초에 VPC의 CIDR 블록에 대한 라우트 경로만 '로컬'로 설정되어 있어 VPC 내부 트래픽이 외부로 나가지 않고도 통신할 수 있게 한다.
[출처: https://docs.aws.amazon.com/vpc/latest/userguide/subnet-route-tables.html]
인터넷 연결의 관문: 인터넷 게이트웨이(Internet Gateway, IGW)
인터넷 게이트웨이(IGW)는 VPC와 인터넷 간의 연결을 해주는 유일한 통로 역할을 하며, VPC의 핵심 보안 정책(격리)을 구현하는 장치이다. IGW가 실제로 작동하려면 라우트 테이블에 목적지 (0.0.0.0/0, 즉 모든 외부 트래픽)가 IGW로 향하도록 명시적으로 설정되어야 한다.
퍼블릭 서브넷과 프라이빗 서브넷의 설계 및 구분
VPC 내 서브넷을 '퍼블릭' 또는 '프라이빗'으로 구분하는 기준은 오직 해당 서브넷과 연결된 라우트 테이블에 IGW로 향하는 경로(0.0.0.0/0)가 존재하는지 여부이다.
- 퍼블릭 서브넷: IGW로 향하는 라우트 경로를 가지고 있어, 인스턴스가 Public IP를 할당받으면 외부 인터넷으로부터의 접근과 통신이 모두 가능하다.
- 프라이빗 서브넷: 라우트 테이블에 인터넷 게이트웨이 설정이 존재하지 않아, 이 서브넷에 위치한 자원은 외부 인터넷으로부터 직접적인 접근이 원천적으로 차단된다.
| 구분 | 퍼블릭 서브넷 | 프라이빗 서브넷 |
|---|---|---|
| 라우트 테이블 | IGW 경로 포함 (0.0.0.0/0 IGW) | IGW 경로 미포함 |
| 외부 접근 | 인스턴스에 Public IP 할당 시 외부에서 접근 가능 | 외부에서 직접 접근 불가 (강력한 격리) |
| 목적 | 웹 서버, SSH 접속을 위한 배스천 호스트 | 핵심 애플리케이션 및 데이터 보호 |
NAT 게이트웨이: 프라이빗 서브넷의 인터넷 접근 관문
NAT 게이트웨이(NAT Gateway)는 프라이빗 서브넷에 있는 인스턴스가 외부 인터넷으로 아웃바운드(Outbound) 통신을 할 수 있도록 하면서도, 외부 인터넷으로부터 해당 인스턴스에 대한 인바운드(Inbound) 접근을 차단하여 보안을 유지하는 AWS 관리형 서비스이다
[출차: https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/nat-gateway-scenarios.html]
프라이빗 인스턴스가 패치 업데이트나 외부 API 접근 등의 이유로 인터넷 통신이 필요할 때, NAT 게이트웨이가 이 격리된 인스턴스들의 통신 요청을 대신 수행하고 응답을 받아 다시 인스턴스로 전달하는 역할을 한다.
- 배치 원칙: NAT 게이트웨이는 반드시 퍼블릭 서브넷에 위치해야 한다. 이는 NAT 게이트웨이가 외부 인터넷과 통신하기 위해 IGW로의 라우트 경로를 필요로 하기 때문이다.
- 작동 방식: 프라이빗 서브넷의 인스턴스가 외부 인터넷으로 트래픽을 보내면, 해당 트래픽은 NAT 게이트웨이를 거치도록 설정된 라우트 테이블을 따라 전달된다. NAT 게이트웨이는 인스턴스의 사설 IP 주소를 자신의 탄력적 IP 주소(EIP)로 변환하여 트래픽을 IGW를 통해 인터넷으로 내보낸다.
- 비용 및 관리: NAT 게이트웨이는 AWS에서 완벽하게 관리하는 서비스로, 고가용성(High Availability)과 자동 확장(Scalability)이 AZ 내에서 보장되어 운영 부담이 최소화된다.
NAT 게이트웨이와 NAT 인스턴스의 비교
| 구분 기준 | NAT 게이트웨이 (NAT Gateway) | NAT 인스턴스 (NAT Instance) |
|---|---|---|
| 관리 주체 | AWS 완전 관리형 서비스 | 사용자가 직접 관리 (EC2 인스턴스) |
| 고가용성(HA) | AZ 내 고가용성 자동 제공 | AZ 장애 시 수동 대체 필요 |
| 성능/확장성 | 최대 45 Gbps까지 자동 확장 | 인스턴스 타입에 따라 제한적 |
| 보안 제어 | 보안 그룹 설정 없음 | 보안 그룹 설정 가능 |
| 커스터마이징 | 불가능 (단순 게이트웨이 역할) | 가능 (사용자 정의 소프트웨어 설치) |
라우트 테이블을 통한 NAT 설정
프라이빗 서브넷의 라우트 테이블에는 외부 인터넷으로 나가는 모든 트래픽()이 NAT 게이트웨이를 대상으로 하도록 경로가 반드시 설정되어야 한다.
| 목적지 (Destination) | 대상 (Target) | 의도 |
|---|---|---|
| VPC CIDR (예: 10.0.0.0/16) | Local | VPC 내부 통신 (로컬 라우팅) |
| 0.0.0.0/0 (모든 외부 트래픽) | NAT 게이트웨이 ID (nat-xxxxxxxx) | 외부 인터넷 통신은 NAT 게이트웨이 경유 |
이 설정은 프라이빗 서브넷 내 자원들이 VPC 내부 트래픽은 로컬로 처리하고, 외부 인터넷으로 나가야 하는 트래픽은 NAT 게이트웨이로 보내도록 강제하여 핵심 자산의 보안 격리를 유지하면서도 필요한 경우에만 외부 통신을 수행할 수 있게 한다.
이중 방어 전략: 네트워크 보안 제어
AWS VPC 환경은 네트워크 ACL (NACL)과 보안 그룹 (Security Group, SG)이라는 두 가지 주요 방화벽 메커니즘을 통해 다계층(Defense-in-Depth) 보안 구조를 구축한다.
서브넷 레벨 제어: 네트워크 ACL (NACL) 상세 분석
NACL은 VPC 내 서브넷 경계에서 작동하는 가장 바깥쪽 방화벽이다.
- 특성: Subnet 레벨에 적용되며, 허용(Allow) 규칙과 거부(Deny) 규칙을 모두 지원하여 광범위한 IP 대역을 선제적으로 차단하는 '차단 목록(Blacklist)' 역할을 수행한다. 트래픽 허용 여부를 결정할 때 규칙을 우선순위(번호)로 처리한다.
- 작동 방식: Stateless (비상태 기반): NACL은 트래픽의 상태를 저장하지 않는다. 따라서 Inbound 트래픽이 허용되었더라도, 해당 요청에 대한 응답(Outbound 트래픽)은 Outbound 규칙에 의해 명시적으로 허용되어야만 필터링되지 않고 외부로 나갈 수 있다.
[출처: https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-network-acls.html]
인스턴스 레벨 제어: 보안 그룹 (Security Group, SG) 상세 분석
SG는 개별 EC2 인스턴스(네트워크 인터페이스, ENI)에 적용되는 논리적 방화벽이며, NACL이 통과시킨 트래픽에 대한 2차 필터링을 담당한다.
- 특성: 서버(인스턴스) 레벨에서 운영되며, 허용 규칙만 지원하고 명시적으로 허용되지 않은 모든 트래픽은 암묵적으로 거부된다. 규칙 번호 순서에 따른 우선순위는 없으며, 모든 허용 규칙이 동시에 적용된다.
- 작동 방식: Stateful (상태 기반): SG는 트래픽의 상태와 세션 정보를 저장한다. 따라서 Inbound 규칙에 의해 요청 패킷이 허용되면, 해당 요청에 대한 응답(Response) 트래픽은 Outbound 규칙에 상관없이 자동으로 허용되어 규칙 관리가 단순해진다.
| 구분 기준 | Network ACL (NACL) | 보안 그룹 (Security Group, SG) |
|---|---|---|
| 적용 레벨 | Subnet 레벨 (네트워크 경계) | Instance/ENI 레벨 (자원 접근) |
| 규칙 처리 방식 | Stateless (비상태 기반) | Stateful (상태 기반) |
| 규칙 지원 범위 | 허용 및 거부 규칙 지원 | 허용 규칙만 지원 |
| 반환 트래픽 처리 | Outbound 규칙에 명시적으로 허용 필요 | Inbound 허용 시 Outbound 자동 허용 |
결론 및 아키텍처적 권고 사항
AWS의 리전과 AZ는 물리적 격리를 통해 정적 안정성이라는 고가용성 설계 철학을 구현하며, 이는 사용자에게 최소 2개 이상의 AZ에 자원을 분산 배치하도록 강제한다. VPC는 이 물리적 기반 위에 사용자의 사설 네트워크 환경을 논리적으로 격리하고, IGW 경로 유무에 따라 퍼블릭/프라이빗 서브넷을 구분하여 핵심 자산의 보안 격리를 보장한다.
궁극적으로, VPC 네트워킹의 안정성은 보안 메커니즘의 이중 방어 전략에 의해 완성된다. Stateless인 NACL은 서브넷 경계에서 광역적 네트워크 방어를 제공하고, Stateful인 SG는 인스턴스 레벨에서 세밀하고 단순화된 자원 접근 제어를 수행한다. 성공적인 클라우드 아키텍처 설계자는 이러한 요소들의 설계 의도와 작동 방식의 차이를 깊이 이해하고, 이를 바탕으로 보안과 고가용성을 동시에 만족시키는 VPC 환경을 구축해야 한다.
