VPC는 AWS 서비스들이 있는 가상 데이터 센터이다. 백엔드 개발자는 인프라 엔지니어가 아니더라도, 서버 간의 통신 방식과 보안을 이해하기 위해 VPC의 구조를 명확히 알아야 한다.

1. VPC의 핵심 구성 요소

1.1. VPC (Virtual Private Cloud)

• 정의: AWS 리전 내에 할당된 논리적으로 격리된 가상 네트워크.
• CIDR 블럭: VPC의 크기를 결정하는 IP 주소 범위이다(예: 10.0.0.0/16). 내부에서 사용할 사설 IP 대역을 설정한다.

1.2. 서브넷 (Subnet)

VPC를 더 작은 단위로 쪼갠 네트워크 망이다.

• Public Subnet: 인터넷 게이트웨이(IGW)를 통해 외부 인터넷과 직접 통신이 가능한 영역이다(예: Load Balancer Bastion Host 배치)
• Private Subnet: 외부 인터넷에서 직접 접근할 수 없는 보호된 영역이다 (예: API 서버, DB, 캐시 배치)

1.3. 라우팅 테이블 (Routing Table)

• 네트워크 트래픽이 어디로 갈지 정하는 표이다. 특정 서브넷의 트래픽을 인터넷 게이트웨이로 보낼지 아니면 내부로만 돌릴지 결정한다.

1.4. 인터넷 게이트웨이 (IGW) & NAT 게이트웨이

• IGW: VPC와 인터넷 사이의 관문이다.
• NAT Gateway: Private Subnet에 있는 서버들이 외부(예: 라이브러리 업데이트, 외부 API 호출)로 나갈 수는 있지만, 외부에서는 들어오지 못하게 할 때 사용한다.

---

2. 백엔드 개발자가 알아야할 핵심 키워드

2.1. 보안 그룹(Security Group) & ACL (Network ACL)

백엔드 코드가 동작하는 인스턴스의 방화벽 설정이다.

• 보안 그룹: 인스턴스 단위의 방화벽이다. Stateful 속성을 가진다(보낸 요청의 응답은 자동으로 허용한다). 보통 8080 포트를 특정 로드밸런서 IP에서만 받겠다는 식의 설정을 한다.
• NACL: 서브넷 단위의 방화벽이다. Stateless이며 들어오는 트래픽(Inbound)과 나다는 트래픽(Outbound)을 모두 명시적으로 허용해야 한다.

2.2. 네트워크 지연(Latency)과 가용 영역(AZ)

• AWS 리전은 여러 개의 AZ(Availability Zone로 구성된다.
• 고가용성을 위해 API 서버를 여러 AZ에 분산 배치(Multi-AZ)해야 하며 이때 VPC 내에서 AZ 간 통신이 발생한다는 점을 인지해야 한다.
  * 동일 AZ 내 통신보다 아주 약간 지연이 있을 수 있지만 장애 내성을 위해 필수적이다.
  

2.3. 사설 IP와 서비스 엔드포인트

백엔드 서버가 DB에 접속할 때, Public IP가 아닌 Private IP를 사용해야 한다.

• 만약 S3나 DynamoDB 같은 AWS 서비스를 사용한다면, 인터넷을 타지 않고 VPC 내부 망을 통해 통신하는 VPC Endpoint를 사용하면 보안과 성능(비용 절감) 측면에서 유리하다.

---

3. 가장 많이 사용하는 백엔드 아키텍처 예시

3.1. Public Subnet

• ALB: 사용자 요청을 가장 먼저 받는 곳.
• Bastion Host: 개발자가 내부 서버에 SSH 접속을 하기 위한 곳.

3.2. Private Subnet(Application)

• Springboot 같은 API 서버: 실제 비즈니스 로직을 수행하고 오직 ALB로부터 오는 요청만 허용한다.

3.3. Private Subnet(Data)

• RDS: 데이터베이스, 오직 API 서버가 있는 서브넷의 보안 그룹에서 오는 포트만 허용한다.

---

4. 트러블 슈팅 팁

• 서버에서 외부 API를 호출했는데 타입아웃이 나온다: 해당 서버가 Private Subnet에 있다면 NAT Gateway가 설정되어있는지, 라우팅 테이블이 NAT를 가리키는지 확인해야 한다.
• 로컬에서는 DB 접속이 되는데 서버에서는 안 된다:
  DB의 보안 그룹(Security Group)에서 API 서버가 속한 보안 그룹이나 IP 대역의 Inbound가 허용되었는지 확인해야 한다.
• IP 주소가 부족하다: VPC 생성 시 CIDR을 너무 작게 잡으면(예: /28) 나중에 서버(EC2, Lambda)를 늘릴 때 IP 부족 문제가 생길 수 있다. 초기 설계 시 /16 정도로 넉넉하게 잡는 것이 좋다.