VPC

작성자

익명

작성일

2026.07.27

조회수

None

버전

VPC (Virtual Private Cloud)

1. 개요

VPC(Virtual Private Cloud)는 퍼블릭 클라우드 환경 내에서 사용자 전용으로 격리된 가상 네트워크 공간을 제공하는 서비스이다. 이를 통해 물리적 인프라를 공유하면서도 보안상 완전히 분리된 독립적인 네트워크 환경을 구축할 수 있다.

클라우드 컴퓨팅 환경에서 VPC는 논리적으로 완전히 분리된 네트워크 영역을 생성하여, 사용자가 IP 주소 범위 선택, 서브넷 생성, 라우팅 테이블 및 네트워크 게이트웨이 구성 등 네트워크 환경을 직접 제어할 수 있게 한다. 이는 물리적인 데이터 센터의 네트워크 인프라를 소프트웨어 정의 네트워크(SDN, Software Defined Networking) 기술을 통해 가상화한 것으로, 물리적 하드웨어 변경 없이 소프트웨어 설정만으로 네트워크 구조를 유연하게 변경할 수 있다는 점이 물리적 네트워크와의 핵심적인 차이점이다.

2. CIDR 블록 설정 및 IP 설계

VPC를 생성할 때 가장 먼저 정의해야 하는 것이 CIDR(Classless Inter-Domain Routing) 블록이다. CIDR은 IP 주소를 효율적으로 할당하기 위해 클래스 개념을 없애고 서브넷 마스크를 가변적으로 사용하는 방식이다.

2.1 IP 주소 설계 원칙

충돌 방지: VPC 내부 IP 대역은 연결될 가능성이 있는 다른 VPC나 온프레미스(On-premises, 자체 구축 서버실) 네트워크 대역과 중복되지 않아야 한다.
확장성 고려: 서비스 성장에 따라 인스턴스 수가 증가할 것을 대비하여 충분한 크기의 IP 대역을 설정해야 한다.
표준 대역 사용: 일반적으로 사설 IP 대역인 RFC 1918 표준(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) 범위 내에서 설계한다.

2.2 CIDR 표기법 예시

10.0.0.0/16: 총 $2^{16}$ (65,536)개의 IP 주소를 가질 수 있는 대역이다.
10.0.1.0/24: 위 대역을 쪼갠 서브넷으로, 총 $2^8$ (256)개의 IP 주소를 가진다.

참고: 실제 클라우드 환경(AWS 등)에서는 네트워크 주소, VPC 라우터, DNS, 브로드캐스트 주소 등 5개의 IP 주소가 예약되어 사용자가 사용할 수 없다. (예: /24 서브넷의 실제 사용 가능 IP는 251개)

3. 핵심 구성 요소

VPC는 네트워크 트래픽의 흐름을 제어하고 외부와 통신하기 위해 다음과 같은 구성 요소를 사용한다.

구성 요소	정의 및 역할	주요 특징
서브넷 (Subnet)	VPC의 IP 대역을 더 작은 단위로 나눈 네트워크 영역	퍼블릭/프라이빗으로 구분하여 보안 수준 차등 적용
라우팅 테이블 (Route Table)	네트워크 트래픽이 어디로 향해야 하는지 정의한 규칙 집합	서브넷별 할당. VPC 내부 리소스 간 통신을 위한 기본 로컬 라우팅 규칙이 자동으로 생성됨
인터넷 게이트웨이 (IGW)	VPC와 인터넷 간의 통신을 가능하게 하는 게이트웨이	퍼블릭 서브넷의 리소스가 외부 인터넷과 통신하기 위해 필수
NAT 게이트웨이	프라이빗 서브넷의 리소스가 외부로 나가는 통신만 가능하게 함	외부에서 내부로의 직접 접속은 차단하며, 업데이트 등 외부 통신 지원

4. 네트워크 트래픽 제어 및 보안

VPC는 다층 방어 전략을 위해 보안 그룹(Security Group)과 네트워크 ACL(NACL)이라는 두 가지 보안 계층을 제공한다.

4.1 보안 그룹 vs 네트워크 ACL 비교

구분	보안 그룹 (Security Group)	네트워크 ACL (NACL)
적용 대상	인스턴스(ENI) 단위	서브넷 단위
상태 유지	Stateful (요청 허용 시 응답 자동 허용)	Stateless (요청/응답 각각 규칙 필요)
규칙 설정	허용(Allow) 규칙만 설정 가능	허용(Allow) 및 거부(Deny) 규칙 모두 설정 가능
평가 순서	모든 규칙을 평가 후 결정	규칙 번호 순서대로 평가 후 즉시 적용

4.2 설정 예시

구분	보안 그룹 (SG) 설정 예시	네트워크 ACL (NACL) 설정 예시
인바운드 (Inbound)	`Allow TCP 80` from `0.0.0.0/0`	`Rule 100: Allow TCP 80` from `0.0.0.0/0`
아웃바운드 (Outbound)	`Allow All` to `0.0.0.0/0`	`Rule 100: Allow TCP 1024-65535` to `0.0.0.0/0` (응답 트래픽 허용 필요)

Stateful: 한 번 허용된 트래픽은 반대 방향의 트래픽도 자동으로 허용하는 방식이다.
Stateless: 들어오는 트래픽(Inbound)과 나가는 트래픽(Outbound)을 각각 독립적으로 제어해야 하는 방식이다.

5. VPC 연결 및 확장 방법

단일 VPC를 넘어 다른 네트워크와 연결하는 방법은 다음과 같다.

VPC 피어링 (Peering): 두 VPC 간에 트래픽을 라우팅하여 마치 하나의 네트워크에 있는 것처럼 통신하게 하는 방식이다. 1:1 연결 방식이며, 연결된 VPC 간의 CIDR 대역이 중복되지 않아야 한다.
Transit Gateway: 중앙 집중식 허브 역할을 하는 라우터이다. 수많은 VPC와 온프레미스 네트워크를 성형(Hub-and-Spoke) 구조로 연결하여 관리를 단순화한다.
VPC 엔드포인트 (PrivateLink): 인터넷 게이트웨이를 거치지 않고 클라우드 서비스(예: S3, DynamoDB)에 프라이빗하게 접속하는 인터페이스이다.
VPN (Virtual Private Network): 암호화된 터널을 통해 온프레미스 데이터 센터와 VPC를 연결한다.
Direct Connect: 전용 회선을 사용하여 온프레미스와 클라우드를 물리적으로 연결함으로써 안정적인 대역폭과 낮은 지연 시간을 보장한다.

[비교] VPC 피어링 vs Transit Gateway

구분	VPC 피어링 (Peering)	Transit Gateway (TGW)
연결 구조	1:1 Point-to-Point	Hub-and-Spoke (중앙 집중형)
관리 복잡도	연결 수가 늘어날수록 Mesh 구조로 복잡해짐	중앙에서 모든 연결을 관리하여 단순함
트래픽 흐름	두 VPC 간 직접 통신	TGW를 거쳐 목적지로 라우팅
적합한 사례	소수의 VPC 간 단순 연결	대규모 VPC 환경 및 복잡한 네트워크 토폴로지

6. VPC 설계 베스트 프랙티스

안정적이고 보안성이 높은 아키텍처를 위해 다음과 같은 설계 원칙을 권장한다.

6.1 계층형 서브넷 분리

Public Subnet: 외부 인터넷에서 접근이 필요한 리소스(ALB, Bastion Host) 배치. IGW로 향하는 라우팅 경로를 가진다.
Private Subnet: 데이터베이스, 애플리케이션 서버 등 내부 리소스 배치. 외부 접근을 차단하고 NAT 게이트웨이를 통해 필요한 외부 통신만 수행한다.

[퍼블릭/프라이빗 서브넷 구조도]

graph TD
    Internet((Internet)) <--> IGW[Internet Gateway]
    subgraph VPC
        IGW <--> PublicSubnet[Public Subnet]
        PublicSubnet <--> PrivateSubnet[Private Subnet]
        PrivateSubnet --> NATGW[NAT Gateway]
        NATGW --> IGW
        
        subgraph PublicSubnet
            ALB[ALB / Bastion]
        end
        
        subgraph PrivateSubnet
            AppServer[App Server]
            DB[(Database)]
        end
        
        ALB --> AppServer
        AppServer --> DB
    end

6.2 고가용성(High Availability) 구성

Multi-AZ 배치: 단일 가용 영역(Availability Zone) 장애에 대비하여 최소 2개 이상의 AZ에 서브넷을 분산 배치한다.

[권장 아키텍처 계층 구조]

Layer 1 (External): User $\rightarrow$ Internet Gateway $\downarrow$ Layer 2 (Public): Public Subnet $\rightarrow$ ALB (Load Balancer) $\downarrow$ Layer 3 (Private): Private Subnet $\rightarrow$ App Server $\downarrow$ Layer 4 (Data): Private Subnet $\rightarrow$ Database

7. 실제 구축 예시

웹 서비스를 위한 표준 VPC 아키텍처의 트래픽 흐름은 다음과 같다. 1. 사용자 요청: 사용자가 브라우저를 통해 서비스 URL에 접속한다. 2. IGW 진입: 요청이 인터넷 게이트웨이를 통해 VPC 내부로 들어온다. 3. ALB 전달: 퍼블릭 서브넷에 위치한 Application Load Balancer(ALB)가 요청을 수신하여 적절한 서버로 분산한다. 4. EC2 처리: 프라이빗 서브넷의 EC2 인스턴스가 비즈니스 로직을 처리하고 DB에서 데이터를 조회한다.

Terraform 코드 예시 (VPC 생성 및 라우팅 설정)

# VPC 생성
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = { Name = "main-vpc" }
}

# 퍼블릭 서브넷 생성
resource "aws_subnet" "public_subnet" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "ap-northeast-2a"
  map_public_ip_on_launch = true
  tags = { Name = "public-subnet-1" }
}

# 인터넷 게이트웨이 생성
resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main.id
  tags = { Name = "main-igw" }
}

# 퍼블릭 라우팅 테이블 생성
resource "aws_route_table" "public_rt" {
  vpc_id = aws_vpc.main.id

  # 외부 인터넷으로 나가는 경로 설정 (0.0.0.0/0 -> IGW)
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }

  tags = { Name = "public-route-table" }
}

# 서브넷과 라우팅 테이블 연결
resource "aws_route_table_association" "public_assoc" {
  subnet_id      = aws_subnet.public_subnet.id
  route_table_id = aws_route_table.public_rt.id
}

8. 추가 정보 및 트러블슈팅

8.1 주요 클라우드사별 명칭 비교

AWS	Google Cloud (GCP)	Microsoft Azure
VPC	VPC	VNet (Virtual Network)
Subnet	Subnet	Subnet
Internet Gateway	Cloud Router / Default Gateway	Internet Gateway / Azure Firewall
Security Group	VPC Firewall Rules	Network Security Group (NSG)

8.2 트러블슈팅 체크리스트

네트워크 통신 장애 발생 시 다음 항목을 순차적으로 점검한다. - [ ] 라우팅 테이블: 목적지 IP에 대한 타겟(IGW, NAT GW, Peering 등)이 올바르게 설정되어 있는가? - [ ] 보안 그룹: 인바운드/아웃바운드 규칙에서 필요한 포트와 IP 대역이 허용되어 있는가? - [ ] 네트워크 ACL: 서브넷 수준에서 트래픽을 명시적으로 거부(Deny)하고 있지는 않은가? - [ ] 인터넷 연결성: 퍼블릭 서브넷의 인스턴스가 퍼블릭 IP를 가지고 있으며, IGW 경로가 설정되어 있는가? - [ ] NAT 게이트웨이 상태: 프라이빗 서브넷에서 외부 통신이 안 될 경우, NAT 게이트웨이가 정상 작동 중이며 라우팅 테이블에 등록되어 있는가?

📝 마크다운 원본

이 문서의 마크다운 원본 내용입니다.

# VPC (Virtual Private Cloud)

## 1. 개요
**VPC(Virtual Private Cloud)**는 퍼블릭 클라우드 환경 내에서 사용자 전용으로 격리된 가상 네트워크 공간을 제공하는 서비스이다. 이를 통해 물리적 인프라를 공유하면서도 보안상 완전히 분리된 독립적인 네트워크 환경을 구축할 수 있다.

클라우드 컴퓨팅 환경에서 VPC는 논리적으로 완전히 분리된 네트워크 영역을 생성하여, 사용자가 IP 주소 범위 선택, 서브넷 생성, 라우팅 테이블 및 네트워크 게이트웨이 구성 등 네트워크 환경을 직접 제어할 수 있게 한다. 이는 물리적인 데이터 센터의 네트워크 인프라를 소프트웨어 정의 네트워크(SDN, Software Defined Networking) 기술을 통해 가상화한 것으로, 물리적 하드웨어 변경 없이 소프트웨어 설정만으로 네트워크 구조를 유연하게 변경할 수 있다는 점이 물리적 네트워크와의 핵심적인 차이점이다.

## 2. CIDR 블록 설정 및 IP 설계
VPC를 생성할 때 가장 먼저 정의해야 하는 것이 **CIDR(Classless Inter-Domain Routing)** 블록이다. CIDR은 IP 주소를 효율적으로 할당하기 위해 클래스 개념을 없애고 서브넷 마스크를 가변적으로 사용하는 방식이다.

### 2.1 IP 주소 설계 원칙
- **충돌 방지**: VPC 내부 IP 대역은 연결될 가능성이 있는 다른 VPC나 온프레미스(On-premises, 자체 구축 서버실) 네트워크 대역과 중복되지 않아야 한다.
- **확장성 고려**: 서비스 성장에 따라 인스턴스 수가 증가할 것을 대비하여 충분한 크기의 IP 대역을 설정해야 한다.
- **표준 대역 사용**: 일반적으로 사설 IP 대역인 RFC 1918 표준(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) 범위 내에서 설계한다.

### 2.2 CIDR 표기법 예시
- `10.0.0.0/16`: 총 $2^{16}$ (65,536)개의 IP 주소를 가질 수 있는 대역이다.
- `10.0.1.0/24`: 위 대역을 쪼갠 서브넷으로, 총 $2^8$ (256)개의 IP 주소를 가진다.
> **참고**: 실제 클라우드 환경(AWS 등)에서는 네트워크 주소, VPC 라우터, DNS, 브로드캐스트 주소 등 **5개의 IP 주소가 예약**되어 사용자가 사용할 수 없다. (예: `/24` 서브넷의 실제 사용 가능 IP는 251개)

## 3. 핵심 구성 요소
VPC는 네트워크 트래픽의 흐름을 제어하고 외부와 통신하기 위해 다음과 같은 구성 요소를 사용한다.

| 구성 요소 | 정의 및 역할 | 주요 특징 |
| :--- | :--- | :--- |
| **서브넷 (Subnet)** | VPC의 IP 대역을 더 작은 단위로 나눈 네트워크 영역 | 퍼블릭/프라이빗으로 구분하여 보안 수준 차등 적용 |
| **라우팅 테이블 (Route Table)** | 네트워크 트래픽이 어디로 향해야 하는지 정의한 규칙 집합 | 서브넷별 할당. **VPC 내부 리소스 간 통신을 위한 기본 로컬 라우팅 규칙이 자동으로 생성됨** |
| **인터넷 게이트웨이 (IGW)** | VPC와 인터넷 간의 통신을 가능하게 하는 게이트웨이 | 퍼블릭 서브넷의 리소스가 외부 인터넷과 통신하기 위해 필수 |
| **NAT 게이트웨이** | 프라이빗 서브넷의 리소스가 외부로 나가는 통신만 가능하게 함 | 외부에서 내부로의 직접 접속은 차단하며, 업데이트 등 외부 통신 지원 |

## 4. 네트워크 트래픽 제어 및 보안
VPC는 다층 방어 전략을 위해 **보안 그룹(Security Group)**과 **네트워크 ACL(NACL)**이라는 두 가지 보안 계층을 제공한다.

### 4.1 보안 그룹 vs 네트워크 ACL 비교
| 구분 | 보안 그룹 (Security Group) | 네트워크 ACL (NACL) |
| :--- | :--- | :--- |
| **적용 대상** | 인스턴스(ENI) 단위 | 서브넷 단위 |
| **상태 유지** | **Stateful** (요청 허용 시 응답 자동 허용) | **Stateless** (요청/응답 각각 규칙 필요) |
| **규칙 설정** | 허용(Allow) 규칙만 설정 가능 | 허용(Allow) 및 거부(Deny) 규칙 모두 설정 가능 |
| **평가 순서** | 모든 규칙을 평가 후 결정 | 규칙 번호 순서대로 평가 후 즉시 적용 |

### 4.2 설정 예시
| 구분 | 보안 그룹 (SG) 설정 예시 | 네트워크 ACL (NACL) 설정 예시 |
| :--- | :--- | :--- |
| **인바운드 (Inbound)** | `Allow TCP 80` from `0.0.0.0/0` | `Rule 100: Allow TCP 80` from `0.0.0.0/0` |
| **아웃바운드 (Outbound)** | `Allow All` to `0.0.0.0/0` | `Rule 100: Allow TCP 1024-65535` to `0.0.0.0/0` (응답 트래픽 허용 필요) |

- **Stateful**: 한 번 허용된 트래픽은 반대 방향의 트래픽도 자동으로 허용하는 방식이다.
- **Stateless**: 들어오는 트래픽(Inbound)과 나가는 트래픽(Outbound)을 각각 독립적으로 제어해야 하는 방식이다.

## 5. VPC 연결 및 확장 방법
단일 VPC를 넘어 다른 네트워크와 연결하는 방법은 다음과 같다.

1. **VPC 피어링 (Peering)**: 두 VPC 간에 트래픽을 라우팅하여 마치 하나의 네트워크에 있는 것처럼 통신하게 하는 방식이다. 1:1 연결 방식이며, 연결된 VPC 간의 CIDR 대역이 중복되지 않아야 한다.
2. **Transit Gateway**: 중앙 집중식 허브 역할을 하는 라우터이다. 수많은 VPC와 온프레미스 네트워크를 성형(Hub-and-Spoke) 구조로 연결하여 관리를 단순화한다.
3. **VPC 엔드포인트 (PrivateLink)**: 인터넷 게이트웨이를 거치지 않고 클라우드 서비스(예: S3, DynamoDB)에 프라이빗하게 접속하는 인터페이스이다.
4. **VPN (Virtual Private Network)**: 암호화된 터널을 통해 온프레미스 데이터 센터와 VPC를 연결한다.
5. **Direct Connect**: 전용 회선을 사용하여 온프레미스와 클라우드를 물리적으로 연결함으로써 안정적인 대역폭과 낮은 지연 시간을 보장한다.

### [비교] VPC 피어링 vs Transit Gateway
| 구분 | VPC 피어링 (Peering) | Transit Gateway (TGW) |
| :--- | :--- | :--- |
| **연결 구조** | 1:1 Point-to-Point | Hub-and-Spoke (중앙 집중형) |
| **관리 복잡도** | 연결 수가 늘어날수록 Mesh 구조로 복잡해짐 | 중앙에서 모든 연결을 관리하여 단순함 |
| **트래픽 흐름** | 두 VPC 간 직접 통신 | TGW를 거쳐 목적지로 라우팅 |
| **적합한 사례** | 소수의 VPC 간 단순 연결 | 대규모 VPC 환경 및 복잡한 네트워크 토폴로지 |

## 6. VPC 설계 베스트 프랙티스
안정적이고 보안성이 높은 아키텍처를 위해 다음과 같은 설계 원칙을 권장한다.

### 6.1 계층형 서브넷 분리
- **Public Subnet**: 외부 인터넷에서 접근이 필요한 리소스(ALB, Bastion Host) 배치. IGW로 향하는 라우팅 경로를 가진다.
- **Private Subnet**: 데이터베이스, 애플리케이션 서버 등 내부 리소스 배치. 외부 접근을 차단하고 NAT 게이트웨이를 통해 필요한 외부 통신만 수행한다.

**[퍼블릭/프라이빗 서브넷 구조도]**
```mermaid
graph TD
    Internet((Internet)) <--> IGW[Internet Gateway]
    subgraph VPC
        IGW <--> PublicSubnet[Public Subnet]
        PublicSubnet <--> PrivateSubnet[Private Subnet]
        PrivateSubnet --> NATGW[NAT Gateway]
        NATGW --> IGW
        
        subgraph PublicSubnet
            ALB[ALB / Bastion]
        end
        
        subgraph PrivateSubnet
            AppServer[App Server]
            DB[(Database)]
        end
        
        ALB --> AppServer
        AppServer --> DB
    end
```

### 6.2 고가용성(High Availability) 구성
- **Multi-AZ 배치**: 단일 가용 영역(Availability Zone) 장애에 대비하여 최소 2개 이상의 AZ에 서브넷을 분산 배치한다.

**[권장 아키텍처 계층 구조]**
> **Layer 1 (External)**: `User` $\rightarrow$ `Internet Gateway`
> $\downarrow$
> **Layer 2 (Public)**: `Public Subnet` $\rightarrow$ `ALB (Load Balancer)`
> $\downarrow$
> **Layer 3 (Private)**: `Private Subnet` $\rightarrow$ `App Server`
> $\downarrow$
> **Layer 4 (Data)**: `Private Subnet` $\rightarrow$ `Database`

## 7. 실제 구축 예시
웹 서비스를 위한 표준 VPC 아키텍처의 트래픽 흐름은 다음과 같다.
1. **사용자 요청**: 사용자가 브라우저를 통해 서비스 URL에 접속한다.
2. **IGW 진입**: 요청이 인터넷 게이트웨이를 통해 VPC 내부로 들어온다.
3. **ALB 전달**: 퍼블릭 서브넷에 위치한 Application Load Balancer(ALB)가 요청을 수신하여 적절한 서버로 분산한다.
4. **EC2 처리**: 프라이빗 서브넷의 EC2 인스턴스가 비즈니스 로직을 처리하고 DB에서 데이터를 조회한다.

### Terraform 코드 예시 (VPC 생성 및 라우팅 설정)
```hcl
# VPC 생성
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = { Name = "main-vpc" }
}

# 퍼블릭 서브넷 생성
resource "aws_subnet" "public_subnet" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "ap-northeast-2a"
  map_public_ip_on_launch = true
  tags = { Name = "public-subnet-1" }
}

# 인터넷 게이트웨이 생성
resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main.id
  tags = { Name = "main-igw" }
}

# 퍼블릭 라우팅 테이블 생성
resource "aws_route_table" "public_rt" {
  vpc_id = aws_vpc.main.id

  # 외부 인터넷으로 나가는 경로 설정 (0.0.0.0/0 -> IGW)
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }

  tags = { Name = "public-route-table" }
}

# 서브넷과 라우팅 테이블 연결
resource "aws_route_table_association" "public_assoc" {
  subnet_id      = aws_subnet.public_subnet.id
  route_table_id = aws_route_table.public_rt.id
}
```

## 8. 추가 정보 및 트러블슈팅

### 8.1 주요 클라우드사별 명칭 비교
| AWS | Google Cloud (GCP) | Microsoft Azure |
| :--- | :--- | :--- |
| **VPC** | **VPC** | **VNet (Virtual Network)** |
| Subnet | Subnet | Subnet |
| Internet Gateway | Cloud Router / Default Gateway | Internet Gateway / Azure Firewall |
| Security Group | VPC Firewall Rules | Network Security Group (NSG) |

### 8.2 트러블슈팅 체크리스트
네트워크 통신 장애 발생 시 다음 항목을 순차적으로 점검한다.
- [ ] **라우팅 테이블**: 목적지 IP에 대한 타겟(IGW, NAT GW, Peering 등)이 올바르게 설정되어 있는가?
- [ ] **보안 그룹**: 인바운드/아웃바운드 규칙에서 필요한 포트와 IP 대역이 허용되어 있는가?
- [ ] **네트워크 ACL**: 서브넷 수준에서 트래픽을 명시적으로 거부(Deny)하고 있지는 않은가?
- [ ] **인터넷 연결성**: 퍼블릭 서브넷의 인스턴스가 퍼블릭 IP를 가지고 있으며, IGW 경로가 설정되어 있는가?
- [ ] **NAT 게이트웨이 상태**: 프라이빗 서브넷에서 외부 통신이 안 될 경우, NAT 게이트웨이가 정상 작동 중이며 라우팅 테이블에 등록되어 있는가?

AI 생성 콘텐츠 안내

이 문서는 AI 모델(gemma-4-31b)에 의해 생성된 콘텐츠입니다.

주의사항: AI가 생성한 내용은 부정확하거나 편향된 정보를 포함할 수 있습니다. 중요한 결정을 내리기 전에 반드시 신뢰할 수 있는 출처를 통해 정보를 확인하시기 바랍니다.

위키너와나

VPC