1. 실습 설명
AWS에서 직접 VPC를 생성하는 실습을 진행하였습니다.
이번 실습의 목표는 VPC 마법사를 사용하지 않고 IP 주소 범위를 설정하고, 퍼블릭 및 프라이빗 서브넷을 나누며, 라우팅 테이블과 인터넷 게이트웨이를 수동으로 구성하여 VPC를 구축하는 것이었습니다.
구성한 환경에는 웹 서버와 Amazon RDS(MySQL) 데이터베이스 인스턴스를 각각 하나씩 배포하였으며, 웹 서버에 주소록 애플리케이션을 설치하여 RDS 인스턴스와 연결하는 작업까지 진행하였습니다.
연결이 완료된 후에는 실제로 주소록에 연락처를 추가하고 삭제하는 테스트도 수행하였습니다.
이번 실습을 통해 다음과 같은 작업들을 경험할 수 있었습니다.
-
Amazon VPC 직접 생성
-
퍼블릭 서브넷과 프라이빗 서브넷 분리
-
인터넷 게이트웨이 및 라우팅 테이블 설정
-
웹 서버와 RDS 인스턴스를 위한 보안 그룹 구성
-
웹 서버와 RDS 인스턴스 배포 및 애플리케이션 연결 테스트
단순히 이론으로만 학습하는 것이 아니라, 직접 네트워크를 구성하고 보안 설정까지 진행해 보니 AWS 리소스 간 통신 흐름과 보안 제어의 중요성을 보다 현실감 있게 이해할 수 있었습니다.
이 글에서는 실습 과정을 순서대로 정리하여 공유드리고자 합니다.
위 사진은 외부 사용자로부터 시작하여, 퍼블릭 서브넷의 웹 서버를 거쳐, 프라이빗 서브넷에 있는 RDS 인스턴스까지 데이터가 흐르는 과정을 보여줍니다.
다이어그램의 주요 구성은 다음과 같습니다.
-
VPC: 2개의 가용 영역(Availability Zone)에 걸쳐 구성되어 있으며, 하나의 퍼블릭 서브넷과 두 개의 프라이빗 서브넷이 포함되어 있습니다.
-
퍼블릭 서브넷: 웹 서버 역할을 하는 EC2 인스턴스가 배포되어 있으며, 외부 인터넷 사용자와 통신할 수 있도록 인터넷 게이트웨이(IGW)와 연결되어 있습니다.
-
프라이빗 서브넷: 각각 다른 가용 영역에 위치한 두 개의 프라이빗 서브넷에 MySQL RDS 인스턴스가 분산 배포되어 있습니다. 외부에서는 직접 접근할 수 없고, 오직 퍼블릭 서브넷의 웹 서버를 통해서만 접근이 가능합니다.
-
인터넷 게이트웨이(IGW): 외부에서 퍼블릭 서브넷으로 들어오는 트래픽을 허용하는 역할을 합니다.
데이터 흐름은 다음과 같은 순서로 진행됩니다.
-
외부 사용자가 인터넷을 통해 웹 서버에 접속합니다.
-
웹 서버에서 실행 중인 애플리케이션이 데이터베이스 작업을 요청할 경우, 내부 네트워크를 통해 프라이빗 서브넷에 배포된 RDS 인스턴스와 통신합니다.
이 아키텍처는 다음과 같은 목적을 달성할 수 있습니다:
-
외부에서는 데이터베이스에 직접 접근하지 못하도록 차단하여 보안을 강화합니다.
-
웹 서버를 통해서만 데이터베이스에 접근하도록 경로를 제한합니다.
-
가용 영역을 분산하여 고가용성과 장애 복구성을 확보합니다.
이번 실습에서는 이 다이어그램을 기반으로 하나씩 직접 구성해 나가면서, AWS 리소스들이 어떻게 서로 연결되고 통신하는지를 확인해보겠습니다.
2. VPC 생성
VPC는 고객의 AWS 계정 전용 가상 네트워크로, AWS 클라우드 내 다른 가상 네트워크들과 논리적으로 분리되어 있습니다.
Amazon EC2 인스턴스 같은 AWS 리소스들을 VPC 안에 시작할 수 있으며, IP 주소 범위를 자유롭게 설정하고, 서브넷을 나누고, 라우팅 테이블, 네트워크 게이트웨이, 보안 그룹 등 다양한 네트워크 요소를 직접 구성할 수 있습니다.
이번 태스크(Task)에서는 실습을 위해 기본 VPC를 생성할 예정입니다.
VPC를 생성한 후에는, 퍼블릭 서브넷과 프라이빗 서브넷을 각각 나누고, 나중에 배포할 웹 서버와 RDS 인스턴스가 각각 적절한 서브넷에 배치될 수 있도록 준비할 것입니다.
기본 VPC를 생성하였습니다.
3. Public Subnet 생성
실습 중 퍼블릭 서브넷을 만든 후, Auto-assign public IPv4 address 옵션을 활성화하였습니다.
이 설정을 통해 퍼블릭 서브넷에 배포하는 EC2 인스턴스가 자동으로 퍼블릭 IP를 부여받아, 인터넷을 통한 접근(예: 웹 브라우저 접속, SSH 접속)이 가능하도록 구성할 수 있었습니다.
이 과정을 설정하지 않으면 인스턴스가 퍼블릭 서브넷에 있어도 외부 접속이 불가능해지기 때문에, 퍼블릭 서브넷을 사용할 경우 필수적으로 설정해야 하는 부분입니다.
4. Internet Gateway 생성
퍼블릭 서브넷을 생성하고 Auto-assign public IPv4 address 옵션까지 활성화하였지만, 아직 이 서브넷은 진정한 퍼블릭 서브넷이 아닙니다.
퍼블릭 서브넷이 되기 위해서는 인스턴스에 퍼블릭 IP를 부여하는 것 외에도, 인터넷과 통신할 수 있도록 인터넷 게이트웨이(IGW)가 연결되어야 합니다.
퍼블릭 서브넷을 완성하기 위해서는 인터넷 게이트웨이(IGW) 를 VPC에 연결해야 합니다.
인터넷 게이트웨이는 VPC의 인스턴스와 외부 인터넷 간의 통신을 가능하게 해주는 고가용성 네트워크 구성 요소입니다.
특히, 인터넷 게이트웨이는 수평으로 확장되며, 네트워크 트래픽에 대한 가용성 위험이나 대역폭 제약 없이 안정적으로 동작합니다.
인터넷 게이트웨이의 주요 역할은 다음과 같습니다.
-
인터넷 트래픽을 위한 라우팅 대상 제공: 라우팅 테이블에서 외부(0.0.0.0/0)로 나가는 트래픽을 IGW로 보낼 수 있도록 합니다.
-
퍼블릭 IPv4 주소가 할당된 인스턴스에 대해 NAT(Network Address Translation) 수행: VPC 내부의 사설 IP 주소를 공인 IP로 변환하여 인터넷과 통신할 수 있게 해줍니다.
정리하면, 퍼블릭 IP를 부여받은 인스턴스가 실제로 인터넷과 통신하려면 반드시 IGW가 필요하며,
IGW를 생성하고 VPC에 연결한 후, 라우팅 테이블을 수정하여 "인터넷으로 나가는 길"을 열어주는 작업이 필수적입니다.
이번 태스크에서는 인터넷 게이트웨이를 생성하고, 앞서 만들어둔 기본 VPC에 연결하는 작업을 진행하겠습니다.
인터넷 게이트웨이(IGW)를 생성하고 VPC에 연결하는 작업까지 완료하였습니다.
하지만 여기서 주의해야 할 점이 있습니다.
인터넷 게이트웨이를 VPC에 연결했다고 해서, 퍼블릭 서브넷 안의 인스턴스들이 곧바로 인터넷에 연결되는 것은 아닙니다.
왜냐하면, 인스턴스가 인터넷을 사용하려면 다음 추가 작업이 필요합니다:
라우팅 테이블에 "0.0.0.0/0 → 인터넷 게이트웨이" 경로를 추가해야 합니다.
VPC에 IGW를 연결하는 것은 "물리적인 연결"을 만든 것에 불과합니다.
네트워크 경로(라우팅) 를 명시적으로 설정해주어야, 퍼블릭 서브넷 안의 인스턴스들이 외부 인터넷으로 트래픽을 보낼 수 있습니다.
5. Route tables 생성, Routes 추가 및 Public Subnet 연결
이번 단계에서는 인터넷 인바운드 트래픽을 허용하기 위해 필요한 라우팅 테이블(Route Table) 을 생성하고, 퍼블릭 서브넷과 연결하는 작업을 진행합니다.
라우팅 테이블은 네트워크 트래픽이 어디로 전달되어야 하는지를 결정하는 규칙(라우트)들의 집합입니다.
VPC 내에 존재하는 모든 서브넷은 반드시 하나의 라우팅 테이블과 연결되어야 하며,
이 라우팅 테이블이 해당 서브넷을 통한 트래픽의 흐름을 제어하게 됩니다.
서브넷은 한 번에 하나의 라우팅 테이블만 연결할 수 있지만, 하나의 라우팅 테이블에 여러 서브넷을 동시에 연결하는 것은 가능합니다.
퍼블릭 서브넷을 만들기 위해서는, 라우팅 테이블에 다음과 같은 경로를 명시적으로 추가해야 합니다:
IPv4 트래픽(0.0.0.0/0)을 인터넷 게이트웨이(IGW)로 보내는 경로
이 설정을 통해, 퍼블릭 서브넷 내의 인스턴스가 외부 인터넷과 자유롭게 통신할 수 있게 됩니다.
라우팅 테이블에 추가할 수 있는 경로는 전체 인터넷을 의미하는 기본 경로(0.0.0.0/0)뿐만 아니라,
보다 좁은 범위의 IP 주소 (예: 특정 기업 네트워크의 퍼블릭 IP, 또는 외부 EC2 인스턴스의 Elastic IP)로도 지정할 수 있습니다.
정리하면,
인터넷 게이트웨이로 향하는 경로(0.0.0.0/0)가 설정된 라우팅 테이블에 연결된 서브넷만을 퍼블릭 서브넷이라고 부릅니다.
6. 웹 서버용 보안 그룹 생성
이번 단계에서는 웹 서버(EC2 인스턴스) 가 외부 사용자로부터 HTTP 트래픽(포트 80) 을 받을 수 있도록, 새로운 보안 그룹(Security Group)을 생성합니다.
보안 그룹은 AWS에서 인스턴스 수준에서 적용되는 가상 방화벽(Virtual Firewall) 역할을 합니다.
- 인바운드 트래픽(들어오는 트래픽)과 아웃바운드 트래픽(나가는 트래픽)을 제어할 수 있습니다.
중요한 점은 다음과 같습니다:
-
보안 그룹은 서브넷이 아니라 인스턴스 단위로 적용됩니다.
-
VPC에 있는 각 인스턴스마다 서로 다른 보안 그룹을 적용할 수 있습니다.
-
하나의 인스턴스에는 최대 5개의 보안 그룹을 동시에 연결할 수 있습니다.
-
만약 인스턴스를 생성할 때 별도로 보안 그룹을 지정하지 않으면, 자동으로 VPC의 기본(Default) 보안 그룹이 적용됩니다.
7. 퍼블릭 서브넷에서 웹 서버 시작
퍼블릭 서브넷에 Amazon Linux 2 기반의 EC2 인스턴스를 배포하여 웹 서버를 구성했습니다.
이 웹 서버는 주소록 애플리케이션을 제공할 역할을 합니다.
인스턴스에는 User Data 스크립트를 적용하여,
- Apache 웹 서버
- PHP
- MySQL 클라이언트 를 자동 설치하고,
- 애플리케이션 파일을 다운로드 및 설정하도록 구성했습니다.
보안 그룹은 HTTP(포트 80) 트래픽만 허용하여, 외부 브라우저를 통한 웹 접속만 가능하게 설정했습니다.
인스턴스는 퍼블릭 서브넷에 배치되고, 퍼블릭 IPv4 주소를 받아 인터넷을 통한 접근이 가능하게 했습니다.
최종적으로 웹 브라우저를 통해 인스턴스의 퍼블릭 IP로 접속하면 애플리케이션 초기 화면이 표시됩니다.
(※ 현재는 데이터베이스 연결이 설정되지 않았기 때문에, 애플리케이션 내에서 데이터 조작은 아직 불가능한 상태입니다.)
8. MySQL 서버용 프라이빗 서브넷 생성
Amazon RDS 데이터베이스 인스턴스를 배포하기 위해서는,
서로 다른 두 개의 가용 영역(AZ) 에 위치한 두 개 이상의 서브넷이 필요합니다.
이를 통해 데이터베이스의 고가용성(High Availability)을 확보할 수 있습니다.
이번 태스크에서는 MySQL RDS 인스턴스를 배포할 때 사용할 프라이빗 서브넷 두 개를 새로 생성하였습니다.
진행한 과정은 다음과 같습니다.
- AWS Management Console 상단의 검색창에서 VPC를 검색하여 이동합니다.
- 왼쪽 탐색 창에서 Subnets 메뉴를 선택합니다.
- Create subnet 버튼을 클릭하여 새로운 서브넷을 생성합니다.
첫 번째 프라이빗 서브넷은 다음과 같이 설정하였습니다.
- VPC 선택: My VPC
- Subnet name: Private 1
- Availability Zone: 첫 번째 가용 영역(AZ1)
- IPv4 CIDR Block: 10.0.2.0/24
이어서 두 번째 프라이빗 서브넷을 추가로 생성하였습니다.
- VPC 선택: My VPC
- Subnet name: Private 2
- Availability Zone: 두 번째 가용 영역(AZ2)
- IPv4 CIDR Block: 10.0.3.0/24
이렇게 두 개의 프라이빗 서브넷을 각각 서로 다른 가용 영역에 배치함으로써,
RDS 인스턴스가 장애 발생 시에도 다른 AZ로 장애 조치(Failover)할 수 있도록 준비할 수 있었습니다.
9. Database 서버용 보안 그룹 생성
프라이빗 서브넷을 구성했으므로, 이제 MySQL 데이터베이스 인스턴스에 대해 어떤 트래픽만 허용할지 구체적으로 제어할 수 있습니다.
이번 태스크에서는 웹 서버로부터 오는 MySQL 트래픽만 허용하는 전용 보안 그룹을 새로 생성했습니다.
진행한 과정은 다음과 같습니다.
-
AWS Management Console에서 Security Groups로 이동합니다.
-
기존에 생성해두었던 Web server 보안 그룹의 Security Group ID를 복사하여 따로 기록해두었습니다.
-
새로운 보안 그룹을 생성할 때,
- Security group name: Database
- Description: My Database Security Group
- VPC: My VPC로 설정하였습니다.
-
인바운드 규칙(Inbound Rule)을 추가할 때,
- Type은 MySQL/Aurora (포트 3306)를 선택하고,
- Source는 복사해둔 Web server 보안 그룹 ID를 지정했습니다.
이렇게 설정함으로써, 오직 웹 서버 인스턴스에서 오는 MySQL 트래픽만 데이터베이스 인스턴스에 도달할 수 있도록 제한했습니다.
10. 데이터베이스 서브넷 그룹 생성
Amazon RDS 인스턴스를 생성할 때는,
어떤 서브넷들에 데이터베이스를 배포할지를 지정해주는 DB 서브넷 그룹이 반드시 필요합니다.
DB 서브넷 그룹은 VPC 안에서 데이터베이스가 배포될 프라이빗 서브넷들의 모음입니다.
이번 태스크에서는 MySQL RDS 인스턴스용으로 사용할 DB 서브넷 그룹을 새로 생성하였습니다.
-
Subnet Group Name: My Subnet Group
-
Description: My Subnet Group
-
VPC: My VPC
-
서브넷 추가:
- 가용 영역 1 (AZ1)의 10.0.2.0/24 프라이빗 서브넷
- 가용 영역 2 (AZ2)의 10.0.3.0/24 프라이빗 서브넷
이렇게 두 개의 프라이빗 서브넷을 하나의 DB 서브넷 그룹으로 묶어주었습니다.
"RDS 데이터베이스를 서로 다른 AZ의 프라이빗 서브넷에 안전하게 배포하기 위해, DB 서브넷 그룹을 생성했다."
11. Amazon RDS 데이터베이스 생성
MySQL을 실행하는 Amazon RDS 데이터베이스 인스턴스를 새로 배포하였습니다.
진행한 주요 내용은 다음과 같습니다.
-
DB 엔진: MySQL (버전 5.7.x 최신 버전)
-
DB 인스턴스 식별자: myDB
-
마스터 사용자 이름: admin
-
비밀번호: lab-password
-
DB 인스턴스 클래스: db.t3.micro (Burstable 성능 클래스, 소규모 테스트용)
-
스토리지 오토스케일링: 비활성화 (빠른 실습 완료를 위해)
-
VPC: My VPC
-
퍼블릭 액세스: No (프라이빗 서브넷 전용)
-
보안 그룹: Web Server가 접근 가능한 Database 보안 그룹 적용
-
초기 데이터베이스 이름: myDB
-
자동 백업 및 자동 마이너 버전 업그레이드: 모두 비활성화 (빠른 테스트 환경 구성을 위해)
이렇게 해서 VPC 내부에 완전한 웹 서버 + 데이터베이스 아키텍처를 구축할 수 있게 되었습니다.
12. 주소록 애플리케이션을 데이터베이스에 연결
프라이빗 서브넷에 있는 Amazon RDS MySQL 데이터베이스를 연결하는 작업을 진행했습니다.
Amazon RDS MySQL 인스턴스의 Endpoint(접속 주소) 를 복사합니다.
웹 브라우저에서 열려 있는 주소록 애플리케이션 화면으로 돌아갑니다.
복사한 RDS Endpoint를 입력하고,
- Database: myDB
- Username: admin
- Password: lab-password
정보를 입력하여 데이터베이스에 연결합니다.
연결이 완료되면 주소록 애플리케이션 화면이 나타나고,
새 연락처를 추가하거나 삭제할 수 있게 됩니다.
주소록 정보를 추가
그럼 RDS 엔드포인트를 사용했을까?
-> RDS 인스턴스는 퍼블릭 IP가 없기 때문에, 엔드포인트 주소를 통해 VPC 내부 통신을 해야 함
이번 실습을 통해 AWS VPC 환경 안에서
퍼블릭 서브넷과 프라이빗 서브넷을 설계하고,
웹 서버(EC2)와 데이터베이스(RDS)를 각각 배포하여
서로 연결하는 전체 과정을 직접 구성해볼 수 있었습니다.
특히, 퍼블릭 서브넷에 웹 서버를 배포하고,
프라이빗 서브넷에 MySQL RDS 인스턴스를 배포하며,
보안 그룹을 이용해 통신 경로를 세밀하게 제어하고,
최종적으로 웹 애플리케이션을 통해 데이터베이스와 정상적으로 통신하는 것까지 직접 경험할 수 있었던 점이 매우 의미 있었습니다.
이번 실습을 통해 퍼블릭과 프라이빗 네트워크 구성을 분리하는 이유,
보안 그룹으로 접근을 제한하는 중요성,
그리고 AWS에서 고가용성과 보안을 동시에 고려한 인프라를 설계하는 기본 원칙을 보다 명확히 이해할 수 있었습니다.
이러한 경험은 앞으로 실제 AWS 인프라 설계나 운영 업무를 수행할 때
튼튼한 기반이 되어줄 것이라고 생각합니다.
