[AWS] - SSH 터널링 구성과 AWS Subnet 구조

✏️ 왜 내 VPC에는 서브넷이 8개나 있었을까?

AWS에서 EC2, RDS, SSH 터널링, CodeDeploy까지 한 번에 구성하다 보면 어느 순간 콘솔 화면이 꽤 복잡해진다.
처음에는 분명 간단하게 시작했는데 왜 네트워크 리소스가 이렇게 많아졌지?라는 생각이 들었다.

서버 배포 자동화를 위해 CodeDeploy를 구성하고, RDS에 외부에서 직접 접속할 수 없도록 SSH 터널링까지 설정하였다.
그리고 팀 회의를 하는 도중 프론트엔트를 담당하고 있는 팀 동료분께서 AWS 콘솔을 구경하던 중 VPC안에 서브넷이 무려 8개가 생긴 사실을 발견하였다.(이 프론트분은 어떤 삶을 사신 걸까)

 

사실 VPC나 서브넷에 대해 그렇게까지 자세히 생각을 해본적이 없었기에 처음에는 단순하게 생각이 들었다.

• 혹시 VPC가 여러 개가 생긴 건가?
• 내가 배포를 하다가 혹은 터널링을 설정하다가 잘못 생성한 건가?
• 서브넷이 많으면 비용이 더 드는 건가?

그런데 하나씩 뜯어보니, 이 구조는 실수가 아니라 AWS 네트워크 구조를 이해하면 자연스럽게 생기는 결과였다.
오히려 지금의 구성은 EC2와 RDS를 분리하고, 데이터베이스를 외부에 직접 노출하지 않도록 하기 위한 정상적이고 권장되는 형태에 가까웠다. 

이 글에서는 내가 실제로 확인했던 정보들을 바탕으로 다음 내용을 정리해보려고 한다.

• 왜 서브넷이 8개가 되었는지
• default subnet과 RDS용 subnet은 어떻게 다른지
• public subnet과 private subnet은 무엇으로 구분하는지
• SSH 터널링이 왜 가능한 구조인지
• AWS 콘솔에서 네트워크 구조를 어떻게 해석하면 되는지

 

✏️ 1. 문제 상황: AWS 콘솔을 보니 서브넷이 8개였다

처음 문제의식은 아주 단순했다.

 

VPC 콘솔에서 서브넷 목록을 보니, 하나의 VPC 안에 서브넷이 총 8개가 존재하고 있었다.
그래서 내가 뭔가를 중복으로 만들었나?라는 생각이 들었다. 특히 RDS를 만들고, SSH 터널링을 설정하고, EC2와 CodeDeploy까지 붙이는 과정이 한꺼번에 섞이다 보니 네트워크 리소스가 왜 이렇게 늘어났는지 감이 잘 오지 않았다.

 

당시 확인된 서브넷 대역은 두 그룹으로 나뉘었다.

첫 번재 그룹은 다음과 같았다.

• 172.31.0.0/20
• 172.31.16.0/20
• 172.31.32.0/20
• 172.31.48.0/20

두 번째 그룹은 다음과 같았다.

• 172.31.64.0/25
• 172.31.64.128/25
• 172.31.65.0/25
• 172.31.65.128/25

여기서 바로 눈에 띄는 점이 있었다. 앞의 4개는 /20이고 뒤의 4개는 /25, 즉 서브넷의 크기부터 다르게 설계되어 있었다.
이는 단순히 여러 개가 우연히 생긴 것이 아니라, 용도에 따라서 크기가 다른 두 종류의 서브넷이 공존하고 있다는 의미로 받아들여졌다.

 

이 시점에서 궁금했던 질문은 다음과 같았다.

• 왜 서브넷이 8개나 필요한가
• 왜 어떤 서브넷은 크기가 크고, 어떤 서브넷은 크기가 작은가
• EC2는 어디에 속하고, RDS는 어디에 속하는가
• SSH 터널링은 이 구조에서 어떻게 동작하는가

 

✏️ 2.  서브넷의 출처

AWS 콘솔을 하나씩 확인해보니, 서브넷 8개는 전혀 다른 두 개의 그룹이였다.

 

2-1. 기본(Default) 서브넷 4개

먼저 아래 네 개의 서브넷은 AWS가 기본 VPC를 만들 때 자동으로 생성한 기본 서브넷이었다.

• 172.31.0.0/20
• 172.31.16.0/20
• 172.31.32.0/20
• 172.31.48.0/20

이 서브넷들은 각각 서로 다른 Availability Zone(AZ)에 하나씩 배치되어 있었다.

예를 들면 다음과 같은 식이다

• 172.31.0.0/20 → ap-northeast-2a
• 172.31.16.0/20 → ap-northeast-2b
• 172.31.32.0/20 → ap-northeast-2c
• 172.31.48.0/20 → ap-northeast-2d

 

그리고 내가 실제로 확인한 EC2 인스턴스가 속한 서브넷은 172.31.32.0/20 대역이었다.
해당 서브넷 상세를 보니 다음과 같은 특징이 있었다.

• 기본 서브넷: 예
• 퍼블릭 IPv4 주소 자동 할당: 예
• 연결된 라우팅 테이블에 0.0.0.0/0 → Internet Gateway 존재

즉, 이 서브넷은 단순한 기본 서브넷이 아니라, 인터넷과 통신 가능한 public subnet이었다.

 

2-2. RDS용 Private Subnet 4개

반면 아래 네 개의 서브넷은 이름부터 달랐다.

• RDS-Pvt-subnet-1
• RDS-Pvt-subnet-2
• RDS-Pvt-subnet-3
• RDS-Pvt-subnet-4

CIDR도 다음과 같았다.

• 172.31.64.0/25
• 172.31.64.128/25
• 172.31.65.0/25
• 172.31.65.128/25

그리고 RDS의 DB Subnet Group을 확인했더니, 이 4개의 서브넷이 실제로 하나의 RDS subnet group으로 묶여 있었다. 그리고 설명에는 다음과 같이 표시되어 있었다. => Created from the RDS Management Console

즉, 이 서브넷들은 RDS를 구성하는 과정에서, 혹은 RDS 콘솔에서 subnet group을 만들면서 생성된 것이었다.

 

여기까지 조사를 해보니 결론은 => 8개의 서브넷은 AWS 기본 서브넷 4개 + RDS용 프라이빗 서브넷 4개의 합이였다.
따라서 잘못 만들어진 것도 아니고, VPC가 여러 개 생긴 것도 아니었다. 하나의 VPC 안에서 역할별로 분리된 네트워크 구조가 형성된 것이었다.

 

✏️ 3.  AWS 네트워크 구조를 이해하기: VPC, Subnet, Route Table, Internet Gateway

3-1. VPC는 하나의 큰 사설 네트워크다.

VPC(Virtual Private Cloud)는 AWS 안에서 내가 사용하는 가상의 사설 네트워크 공간이다.
쉽게 말하면, 내 서비스가 돌아가는 독립된 네트워크 환경이라고 보면 된다.

나의 경우 VPC CIDR은 다음과 같았다 => 172.31.0.0/16

즉, 이 전체 주소 공간이 하나의 큰 네트워크이고, 서브넷은 이 공간을 잘게 쪼갠 조각들이다.

 

3-2. Subnet은 VPC를 더 작은 네트워크 단위로 나눈 것

서브넷은 VPC 내부를 목적별로 나누는 단위다.

예를 들어, 

• 인터넷에서 접근 가능한 리소스는 public subnet
• 외부에서 직접 접근되면 안 되는 리소스는 private subnet

이번 구조를 보면 실제로 그렇게 나뉘어져 있었다.

• EC2는 public subnet
• RDS는 private subnet

즉, 애플리케이션 서버와 데이터베이스를 네트워크 레벨에서 분리한 구조였다.

 

3-3. Public Subnet과 Private Subnet의 차이는 Route Table이 만든다

Public Subnet에 연결된 기본 라우팅 테이블

처음에는 서브넷 이름에 public/private가 써 있나? 같은 식으로 생각할 수도 있는데, 실제로 public/private를 가르는 핵심은 라우팅 테이블이다. EC2가 있던 기본 서브넷에 연결된 라우팅 테이블은 다음과 같았다.

• 172.31.0.0/16 → local
• 0.0.0.0/0 → igw-...

여기서 핵심은 두 번째 줄이다 => 0.0.0.0/0는 모든 외부 네트워크이고 igw는 Internet Gateway이다.
즉, 이 라우팅 테이블은 외부로 나가는 모든 트래픽을 인터넷 게이트웨이로 보낸다는 의미다. 그래서 이 라우팅 테이블을 사용하는 서브넷은 인터넷과 직접 통신 가능한 public subnet이 된다.

 

RDS용 서브넷에 연결된 라우팅 테이블

반면 RDS용 서브넷들의 라우팅 테이블은 다음과 같았다.

=> 172.31.0.0/16 => local / 여기에는 0.0.0.0/0 -> igw가 없다.

 

즉: 이것이 바로 private subnet이다.

• VPC 내부 통신은 가능
• 외부 인터넷으로 직접 나가는 경로는 없음

 

정리하면

• 0.0.0.0/0 → IGW가 있으면 public subnet
• 외부 경로 없이 local만 있으면 private subnet

이 차이를 실제 화면에서 확인하고 나니, public/private 구분이 훨씬 명확하게 이해되었다.

 

✏️ 4.  왜 RDS는 별도의 subnet group이 필요할까?

이제 다음 궁금증이 생긴다. => EC2는 그냥 기본 서브넷에 올려도 되는데, RDS는 왜 굳이 별도의 subnet group까지 필요할까? 이건 AWS가 데이터베이스를 단순한 VM처럼 취급하지 않기 때문이다. RDS는 관리형 데이터베이스 서비스이고, 기본적으로 가용성, 장애 대응, AZ 분산을 고려해서 설계된다.

 

4-1. RDS는 서로 다른 AZ의 서브넷이 필요하다

RDS subnet group을 보면 서브넷이 4개였고, 각각 다른 AZ에 있었다.

• ap-northeast-2a
• ap-northeast-2b
• ap-northeast-2c
• ap-northeast-2d

 

이 구조는 단순히 많이 만들어진 것이 아닌, 서로 다른 가용 영역(AZ)에 걸쳐 RDS를 배치할 수 있도록 미리 네트워크를 준비하는 구조이다. RDS는 장애 복구나 Multi-AZ 구성을 위해 최소 2개 이상의 AZ를 요구하는 경우가 많다. 그래서 subnet group도 여러 AZ에 걸쳐 있어야 한다. 본인의 경우에는 4개의 AZ 각각에 하나씩 프라이빗 서브넷이 생성되어 있었다. 즉, 정리하자면 콘솔에서 RDS용 subnet group을 만드는 과정에서 고가용성을 고려한 네트워크 구성이 함께 만들어진 것이다.

 

 

4-2. 왜 /25처럼 작은 서브넷을 썼을까?

기본 서브넷은 /20이라 IP 수가 크고, RDS용 서브넷은 /25라 훨씬 작았다.
CIDR 기준으로 보면 대략 다음과 같다.

• /20 → 약 4096개 주소
• /25 → 약 128개 주소

RDS Subnet은 일반적으로 대규모의 인스턴스를 많이 올리는 용도가 아니라, 특정 관리형 DB 리소스를 배치하기 위한 구획이다. 그래서 비교적 작은 크기로 분리하는 것이 자연스럽다. 따라서 이 구조는 다음과 같은 의미를 가진다 + 왜 이런 서브넷 크기를 가지는지도 이해할 수 있다.

• 기본 서브넷: 범용 리소스용 큰 네트워크
• RDS 서브넷: DB 전용의 작은 private 네트워크

 

✏️ 5.  실제 아키텍처: EC2는 Public, RDS는 Private

지금까지 확인한 내용을 아키텍쳐로 그리면 아래와 같다.

Internet
   │
   ▼
EC2 (Public Subnet)
   │
   │ VPC 내부 통신
   ▼
RDS (Private Subnet)

 

5-1. EC2는 Public Subnet에 있다

EC2가 위치한 서브넷은 기본 서브넷이었고, 라우팅 테이블에는 Internet Gateway가 연결되어 있었다.
즉, 이 인스턴스는 외부에서 접근 가능한 위치에 있고 보통 이런 인스턴스는 다음과 같은 역할을 할 수 있다.

• 애플리케이션 서버
• SSH 접속 대상 서버
• 배포 대상 서버
• Bastion Host 역할

본인 같은 경우에는 SSH 터널링 접속의 중간 지점 역할도 하고 있었기 때문에, 네트워크상 public subnet에 있는 것이 자연스러운 것 같다

 

5-2. RDS는 Private Subnet에 있다

반면 RDS는 RDS Subent Group에 포함된 private subnet들에 속해 있었다.
이 라우팅 테이블에는 외부 인터넷으로 나가는 경로가 없기 때문에, RDS는 인터넷에 직접 노출되지 않는다.

• 외부 사용자 → RDS 직접 접근 불가
• VPC 내부 리소스 → RDS 접근 가능

이 구조는 데이터베이스를 안전하게 보호하기 위한 기본적인 방식이다.

 

✏️ 6.  SSH 터널링은 이 구조에서 어떻게 동작할까?

처음에 SSH 터널링을 구성한 이유는 RDS를 외부에 직접 공개하지 않고도, 로컬 개발 환경에서 안전하게 DB에 접속하기 위해서이다. 이 구조에서는 SSH 터널링이 다음과 같이 동작한다.

즉, 로컬 PC가 직접 RDS에 붙는 것이 아니라

1. 먼저 EC2에 SSH로 접속하고
2. EC2를 경유해서
3. VPC 내부에 있는 RDS로 접속하는 방식이다.

이렇게 하면 RDS는 여전히 private subnet 안에 머물러 있고, 외부에서 직접 열리지 않는다.
하지만 필요한 경우에는 로컬에서도 안전하게 접근할 수 있다.
이런 패턴은 흔히 Bastion Host 패턴이라고 부른다.
공개된 서버 하나를 점프 서버처럼 두고, 그 뒤쪽 private 네트워크로 진입하는 방식이다.

Local PC
   │
   │ SSH
   ▼
EC2 (Public Subnet)
   │
   │ 내부 네트워크 통신
   ▼
RDS (Private Subnet)

 

 

✏️ 7. 느낀 점: 리소스 수보다 구조를 먼저 봐야 한다

이번 경험에서 가장 크게 느낀 점은, AWS 콘솔에서 리소스 개수만 보고 판단하면 쉽게 헷갈릴 수 있다는 것이다.

처음에는 그냥 이렇게 보였다.

• 서브넷이 많다
• 네트워크가 복잡하다
• 내가 뭘 잘못 만들었나?

하지만 실제로는 전혀 달랐다.

서브넷이 많았던 이유는:

• AWS가 기본으로 만들어 둔 default subnet이 있었고
• RDS를 private하게 구성하기 위해 subnet group이 추가되었으며
• 각 AZ별로 분산된 설계가 들어갔기 때문이었다

즉, “불필요한 리소스가 늘어난 것”이 아니라
서비스를 안전하게 운영하기 위한 구조가 구체화된 결과였다.

이후부터는 AWS에서 네트워크를 볼 때, 단순히 리소스 개수를 세기보다 먼저 다음을 확인하게 되었다.

1. 이 서브넷은 어느 라우팅 테이블에 연결되어 있는가?
2. 0.0.0.0/0 → igw가 있는가?
3. 이 서브넷은 public인가 private인가?
4. 어떤 리소스가 이 서브넷을 실제로 사용하고 있는가?
5. 이 서브넷은 기본 생성된 것인가, 서비스 목적상 추가된 것인가?

이 순서로 보면 콘솔이 훨씬 덜 복잡하게 보인다.

✏️ 8.  왜 내 VPC에는 서브넷이 8개 있었을까?

이제 처음 질문으로 돌아가 보면 왜 내 VPC에는 서브넷이 8개나 있었을까? 에 대한 답은 다음과 같다.

• 4개는 AWS가 기본 VPC를 만들 때 자동 생성한 default subnet
• 4개는 RDS를 private하게 운영하기 위해 만든 RDS subnet group용 subnet

그리고 이 둘은 역할이 달랐다.

• default subnet: 인터넷 통신이 가능한 public subnet
• RDS subnet: 외부에서 직접 접근할 수 없는 private subnet

최종 구조는 이렇게 요약할 수 있다.

VPC (172.31.0.0/16)
│
├── Public Subnet (Default Subnet)
│   └── EC2
│
└── Private Subnet (RDS Subnet Group)
    └── RDS

 

그리고 SSH 터널링은 다음 경로로 동작한다.

Local PC → EC2 → RDS

 

즉, 이번에 보게 된 “서브넷 8개”는 혼란의 원인이 아니라,
AWS가 서비스 운영을 위해 네트워크를 계층적으로 분리한 흔적이었다.

✏️ 9. 마무리

이번 경험을 통해 AWS 네트워크를 바라보는 방식이 조금 달라졌다. 예전에는 VPC, 서브넷, 라우팅 테이블이 서로 따로따로 보였다면, 지금은 다음처럼 연결해서 보게 되었다.

• VPC는 전체 네트워크 공간
• 서브넷은 역할별 구획
• 라우팅 테이블은 public/private를 결정하는 기준
• EC2는 public에 두고
• RDS는 private에 두며
• 필요한 경우 SSH 터널링으로 안전하게 접근한다