AWS Management Console과 Cloud9으로 3-Tier Architecture 환경 구성하기

카테고리 없음

AWS Management Console과 Cloud9으로 3-Tier Architecture 환경 구성하기

O3O2 2025. 11. 25. 12:45

AWS에서 웹 애플리케이션을 구축할 때, 가장 먼저 해야 할 일은 개발 환경을 구성하는 것임. 로컬 컴퓨터에 복잡한 도구들을 설치하는 대신, AWS가 제공하는 클라우드 기반 IDE인 Cloud9을 활용하면 브라우저만으로 언제 어디서나 개발을 시작할 수 있다!

이 글에서는 AWS Management Console의 기본 개념을 이해하고, Cloud9 환경을 구성한 뒤, 3-Tier Architecture의 기반이 되는 VPC(Virtual Private Cloud)를 설계하는 방법까지 다루고자 함.

1. AWS Management Console 이해하기

Console이란?

AWS Management Console은 AWS의 모든 서비스를 웹 브라우저에서 관리할 수 있는 그래픽 사용자 인터페이스(GUI)임. 마치 윈도우의 제어판이나 맥의 시스템 환경설정처럼, AWS 리소스를 시각적으로 확인하고 조작할 수 있는 중앙 관리 도구라고 생각하면 이해가 쉬움.

Console을 통해 EC2 인스턴스를 생성하고 관리하거나, S3 버킷에 파일을 업로드하고, RDS 데이터베이스를 설정하는 등 거의 모든 AWS 작업을 수행할 수 있음! AWS CLI(Command Line Interface)나 SDK를 통해 프로그래밍 방식으로도 같은 작업을 할 수 있지만, 처음 AWS를 배우는 단계에서는 Console이 직관적이고 이해하기 쉬움.

Console 둘러보기

AWS Console에 로그인하면 가장 먼저 보이는 것이 대시보드임. 여기서 최근 방문한 서비스, 즐겨찾기한 서비스, 그리고 비용 및 사용량 요약을 한눈에 볼 수 있음. 특히 상단의 검색창은 매우 유용함. AWS에는 200개가 넘는 서비스가 있어서 메뉴를 뒤지는 것보다 검색하는 것이 훨씬 빠름. "EC2", "VPC", "Cloud9"처럼 서비스 이름을 입력하면 바로 해당 서비스로 이동할 수 있으며, 별표 표시해두면 즐겨찾기도 가능함.

오른쪽 상단에는 리전(Region) 선택 메뉴가 있음. AWS 리소스는 특정 리전에 생성되므로, 작업 전에 올바른 리전이 선택되어 있는지 확인하는 습관을 들이는 것이 좋음(중요함). 한국에서 서비스한다면 보통 서울 리전(ap-northeast-2)을 선택할 것.

리전과 가용 영역

AWS의 인프라는 전 세계에 분산되어 있음. **리전(Region)**은 지리적으로 분리된 데이터센터 클러스터임. 서울, 도쿄, 버지니아 등 각 리전은 독립적으로 운영되며, 한 리전의 장애가 다른 리전에 영향을 주지 않음.

각 리전 안에는 여러 개의 **가용 영역(Availability Zone, AZ)**이 있음. 가용 영역은 물리적으로 분리된 데이터센터로, 같은 리전 내에서도 하나의 AZ에 장애가 발생해도 다른 AZ는 정상 운영됨. 고가용성을 위해 리소스를 여러 AZ에 분산 배치하는 것이 AWS 아키텍처의 기본 원칙임.

서울 리전의 경우 ap-northeast-2a, ap-northeast-2b, ap-northeast-2c, ap-northeast-2d 총 4개의 가용 영역이 있음.

2. Cloud9 환경 구성하기

Cloud9이란?

AWS Cloud9은 브라우저만으로 코드를 작성, 실행, 디버깅할 수 있는 클라우드 기반 통합 개발 환경(IDE)임. 코드 편집기, 디버거, 터미널이 모두 포함되어 있어서 별도의 설치 없이 바로 개발을 시작할 수 있음.

Cloud9의 장점은 여러 가지가 있음. 우선 일관된 개발 환경을 제공하며, 어디서나 접근 가능함. 인터넷만 있으면 집, 카페, 회사 어디서든 같은 프로젝트를 이어서 작업할 수 있음. 특히 AWS 서비스와의 연동이 매우 편리함. Cloud9 환경에는 AWS CLI가 이미 설치되어 있고, 자격 증명도 자동으로 구성되어 있어서 별도의 설정 없이 바로 AWS 리소스를 다룰 수 있음!

참고: 2024년부터 신규 AWS 계정에서는 Cloud9을 사용할 수 없게 됨...(교육 받을 때는 사용 가능했는데...) 기존 사용자는 계속 사용 가능하지만, 신규 사용자는 VS Code와 AWS Toolkit 조합이나 다른 대안을 고려할 필요가 생김.

Cloud9 환경 생성하기

Console에서 Cloud9을 검색하여 서비스 페이지로 이동한 뒤, "Create environment" 버튼을 클릭할 것.

환경 이름 설정: 프로젝트를 식별할 수 있는 의미 있는 이름을 지정할 것. 예) "3tier-dev-environment"

환경 유형 선택: 두 가지 옵션이 있음.

New EC2 instance: Cloud9이 새로운 EC2 인스턴스를 자동으로 생성함. 가장 간편한 방법임.
Existing compute: 이미 존재하는 EC2 인스턴스나 외부 서버에 Cloud9을 연결함.

처음이라면 "New EC2 instance"를 선택하는 것이 좋음. Cloud9이 EC2 생성과 설정을 모두 처리해줌!

인스턴스 타입 선택: 개발 용도로는 t2.micro나 t3.micro면 충분함. 이 타입들은 프리 티어(Free Tier)에 포함되어 있어 비용 부담이 없음!

자동 종료 설정(Cost-saving setting): (중요함) Cloud9 IDE를 닫은 후 지정된 시간이 지나면 EC2 인스턴스가 자동으로 중지됨. 기본값인 30분이면 적당하며, 불필요한 과금 방지 가능함.

네트워크 설정: 기본 VPC와 퍼블릭 서브넷을 사용하거나, 직접 생성한 VPC를 선택할 수 있음. 처음에는 기본값을 사용해도 무방함!

Cloud9 인터페이스 살펴보기

환경이 생성되면 1-2분 후에 브라우저에서 Cloud9 IDE가 열림. 화면 구성은 일반적인 IDE와 유사함.

왼쪽 패널에는 파일 탐색기가 있음. 프로젝트 파일과 폴더를 트리 구조로 보여줌. 드래그 앤 드롭으로 파일을 업로드할 수도 있음.

중앙 영역은 코드 편집기임. 여러 파일을 탭으로 열어두고 작업할 수 있으며, 구문 강조, 자동 완성, 코드 포맷팅 등 현대적인 IDE 기능을 모두 지원함.

하단 패널에는 터미널이 있음. 이 터미널은 EC2 인스턴스에 직접 연결되어 있어서, 리눅스 명령어를 실행하거나 AWS CLI를 사용할 수 있음.

초기 환경 설정

Cloud9 환경이 준비되면 몇 가지 초기 설정을 해두면 편리함.

AWS CLI 버전 확인 및 업그레이드: Cloud9에는 AWS CLI가 기본 설치되어 있지만, 최신 버전이 아닐 수 있으므로 확인 요망.

# 현재 버전 확인
aws --version

# 최신 버전으로 업그레이드
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install --update

유용한 도구 설치: 작업에 따라 추가 도구가 필요할 수도 있음.

# jq (JSON 파싱 도구) 설치
sudo yum -y install jq

# tree (디렉토리 구조 시각화) 설치
sudo yum -y install tree

디스크 용량 확인: Cloud9 환경의 기본 디스크 용량은 10GB임. 대규모 프로젝트를 진행하거나 많은 패키지를 설치해야 한다면 용량을 늘려야 할 수도 있음...

# 현재 디스크 사용량 확인
df -h

3. 3-Tier Architecture 개념 이해하기

3-Tier Architecture란

3-Tier Architecture는 애플리케이션을 세 개의 논리적 계층으로 분리하는 소프트웨어 설계 패턴임. 각 계층은 독립적으로 개발, 배포, 확장할 수 있어서 유지보수가 쉽고 보안도 강화됨.

프레젠테이션 계층(Presentation Tier): 사용자와 직접 상호작용하는 계층임. 웹 브라우저에 표시되는 UI, 로드 밸런서, 웹 서버 등이 여기에 해당함. 인터넷에서 직접 접근 가능한 퍼블릭 서브넷에 배치됨.

애플리케이션 계층(Application Tier): 비즈니스 로직을 처리하는 계층임. 사용자 요청을 받아 실제 데이터 처리를 수행하고 결과를 반환함. 보안을 위해 프라이빗 서브넷에 배치되며, 외부에서 직접 접근할 수 없음.

데이터 계층(Data Tier): 데이터를 저장하고 관리하는 계층임. RDS, DynamoDB 같은 데이터베이스 서비스가 여기에 위치함. 가장 깊숙한 프라이빗 서브넷에 배치되어 애플리케이션 계층에서만 접근 가능함.

왜 계층을 분리하는가

계층 분리의 가장 큰 이유는 보안임. 데이터베이스 서버가 인터넷에 직접 노출되면 해킹 위험이 높아짐. 3-Tier 구조에서는 데이터베이스가 여러 겹의 보호막 뒤에 있어서, 공격자가 침입하려면 여러 단계를 거쳐야 함.

확장성도 중요한 이유임. 웹 트래픽이 증가하면 프레젠테이션 계층만 확장하고, 데이터 처리량이 증가하면 애플리케이션 계층만 확장할 수 있음. 모든 것이 한 덩어리로 묶여있으면 이런 유연한 확장이 불가능함.

유지보수 측면에서도 유리함. 각 계층이 독립적이므로 한 계층의 변경이 다른 계층에 영향을 주지 않음. 프론트엔드 개발자와 백엔드 개발자, DBA가 각자의 영역에서 독립적으로 작업할 수 있음.

4. VPC 설계하기

VPC란 무엇인가

**VPC(Virtual Private Cloud)**는 AWS 클라우드 내에서 논리적으로 격리된 가상의 네트워크임. 비유하자면, 거대한 아파트 단지(AWS 클라우드)에서 나만의 전용 층(VPC)을 갖는 것과 같음. 이 층 안에서 방을 어떻게 나눌지(서브넷), 출입구를 어디에 둘지(게이트웨이), 누구를 들여보낼지(보안 그룹)는 모두 내가 결정함.

VPC를 생성할 때 가장 먼저 정해야 하는 것이 CIDR 블록임. CIDR(Classless Inter-Domain Routing)은 IP 주소 범위를 표현하는 방법임. 예를 들어 10.0.0.0/16은 10.0.0.0부터 10.0.255.255까지 총 65,536개의 IP 주소를 사용할 수 있다는 의미임.

서브넷 설계

VPC 안에서 **서브넷(Subnet)**은 IP 주소 범위를 더 작은 단위로 나눈 것임. 3-Tier Architecture를 구현하려면 최소 6개의 서브넷이 필요함. 고가용성을 위해 2개의 가용 영역(AZ)을 사용한다고 가정하면:

서브넷 용도 CIDR AZ

Public-Subnet-A	웹 서버, 로드밸런서	10.0.1.0/24	AZ-A
Public-Subnet-B	웹 서버, 로드밸런서	10.0.2.0/24	AZ-B
Private-Subnet-A (App)	애플리케이션 서버	10.0.10.0/24	AZ-A
Private-Subnet-B (App)	애플리케이션 서버	10.0.11.0/24	AZ-B
Private-Subnet-A (DB)	데이터베이스	10.0.20.0/24	AZ-A
Private-Subnet-B (DB)	데이터베이스	10.0.21.0/24	AZ-B

퍼블릭 서브넷과 프라이빗 서브넷의 차이는 인터넷 게이트웨이와의 연결 여부임. 퍼블릭 서브넷은 인터넷 게이트웨이를 통해 외부와 직접 통신할 수 있고, 프라이빗 서브넷은 그렇지 않음.

게이트웨이 이해하기

**인터넷 게이트웨이(Internet Gateway, IGW)**는 VPC와 인터넷을 연결하는 관문임. 퍼블릭 서브넷의 리소스가 인터넷과 통신하려면 반드시 인터넷 게이트웨이가 필요함. VPC당 하나만 연결할 수 있음.

**NAT 게이트웨이(NAT Gateway)**는 프라이빗 서브넷의 리소스가 인터넷에 접근할 수 있게 해주는 서비스임. 예를 들어, 프라이빗 서브넷의 애플리케이션 서버가 소프트웨어 업데이트를 받거나 외부 API를 호출해야 할 때 NAT 게이트웨이를 통해 나감.

중요한 점은 NAT 게이트웨이는 아웃바운드(내부→외부) 연결만 허용한다는 것임. 외부에서 프라이빗 서브넷으로 들어오는 인바운드 연결은 차단됨. 이것이 보안의 핵심임.

NAT 게이트웨이는 반드시 퍼블릭 서브넷에 위치해야 함. 자신이 인터넷과 통신해야 하기 때문임. 또한 **탄력적 IP(Elastic IP)**를 할당받아야 함.

라우팅 테이블 구성

**라우팅 테이블(Route Table)**은 네트워크 트래픽이 어디로 가야 하는지 알려주는 "이정표"임. 각 서브넷은 하나의 라우팅 테이블과 연결되어 있으며, 이 테이블에 따라 트래픽의 경로가 결정됨.

퍼블릭 라우팅 테이블의 핵심 규칙:

10.0.0.0/16 → local (VPC 내부 통신)
0.0.0.0/0 → igw-xxxxx (그 외 모든 트래픽은 인터넷 게이트웨이로)

프라이빗 라우팅 테이블의 핵심 규칙:

10.0.0.0/16 → local (VPC 내부 통신)
0.0.0.0/0 → nat-xxxxx (그 외 모든 트래픽은 NAT 게이트웨이로)

0.0.0.0/0은 "모든 IP 주소"를 의미함. VPC 내부 주소가 아닌 모든 트래픽에 대한 기본 경로를 지정하는 것임.

5. Cloud9에서 VPC 생성하기

이제 Cloud9 터미널에서 직접 VPC를 생성해볼 것임. AWS CLI를 사용하면 Console에서 클릭하는 것보다 더 빠르고, 나중에 자동화하기도 쉬움.

VPC 생성

# VPC 생성
VPC_ID=$(aws ec2 create-vpc \
    --cidr-block 10.0.0.0/16 \
    --query 'Vpc.VpcId' \
    --output text)

# 이름 태그 추가
aws ec2 create-tags \
    --resources $VPC_ID \
    --tags Key=Name,Value=3tier-vpc

# DNS 호스트네임 활성화
aws ec2 modify-vpc-attribute \
    --vpc-id $VPC_ID \
    --enable-dns-hostnames

echo "VPC 생성 완료: $VPC_ID"

서브넷 생성

# 퍼블릭 서브넷 A
PUBLIC_SUBNET_A=$(aws ec2 create-subnet \
    --vpc-id $VPC_ID \
    --cidr-block 10.0.1.0/24 \
    --availability-zone ap-northeast-2a \
    --query 'Subnet.SubnetId' \
    --output text)

aws ec2 create-tags --resources $PUBLIC_SUBNET_A \
    --tags Key=Name,Value=public-subnet-a

# 퍼블릭 서브넷에 퍼블릭 IP 자동 할당 활성화
aws ec2 modify-subnet-attribute \
    --subnet-id $PUBLIC_SUBNET_A \
    --map-public-ip-on-launch

나머지 서브넷도 같은 방식으로 생성함. 서브넷 이름과 CIDR 블록, 가용 영역만 바꿔가며 실행하면 됨.

인터넷 게이트웨이 생성 및 연결

# 인터넷 게이트웨이 생성
IGW_ID=$(aws ec2 create-internet-gateway \
    --query 'InternetGateway.InternetGatewayId' \
    --output text)

aws ec2 create-tags --resources $IGW_ID \
    --tags Key=Name,Value=3tier-igw

# VPC에 연결
aws ec2 attach-internet-gateway \
    --internet-gateway-id $IGW_ID \
    --vpc-id $VPC_ID

echo "인터넷 게이트웨이 연결 완료: $IGW_ID"

NAT 게이트웨이 생성

# 탄력적 IP 할당
EIP_ALLOC=$(aws ec2 allocate-address \
    --domain vpc \
    --query 'AllocationId' \
    --output text)

# NAT 게이트웨이 생성 (퍼블릭 서브넷에 배치)
NAT_GW_ID=$(aws ec2 create-nat-gateway \
    --subnet-id $PUBLIC_SUBNET_A \
    --allocation-id $EIP_ALLOC \
    --query 'NatGateway.NatGatewayId' \
    --output text)

aws ec2 create-tags --resources $NAT_GW_ID \
    --tags Key=Name,Value=3tier-nat

echo "NAT 게이트웨이 생성 중: $NAT_GW_ID"
echo "완전히 활성화되기까지 1-2분 소요됨."

NAT 게이트웨이는 생성 후 "available" 상태가 되기까지 시간이 걸림. 상태를 확인하려면:

aws ec2 describe-nat-gateways \
    --nat-gateway-ids $NAT_GW_ID \
    --query 'NatGateways[0].State' \
    --output text

라우팅 테이블 구성

# 퍼블릭 라우팅 테이블 생성
PUBLIC_RT=$(aws ec2 create-route-table \
    --vpc-id $VPC_ID \
    --query 'RouteTable.RouteTableId' \
    --output text)

aws ec2 create-tags --resources $PUBLIC_RT \
    --tags Key=Name,Value=public-rt

# 인터넷 게이트웨이로의 라우트 추가
aws ec2 create-route \
    --route-table-id $PUBLIC_RT \
    --destination-cidr-block 0.0.0.0/0 \
    --gateway-id $IGW_ID

# 퍼블릭 서브넷과 연결
aws ec2 associate-route-table \
    --route-table-id $PUBLIC_RT \
    --subnet-id $PUBLIC_SUBNET_A

프라이빗 라우팅 테이블도 같은 방식으로 생성하되, 인터넷 게이트웨이 대신 NAT 게이트웨이를 지정함.

6. 보안 그룹 설정

보안 그룹이란

**보안 그룹(Security Group)**은 EC2 인스턴스 수준에서 트래픽을 제어하는 가상 방화벽임. 어떤 포트로, 어떤 IP에서 오는 트래픽을 허용할지 규칙을 정의함.

보안 그룹의 특징은 **상태 저장(Stateful)**이라는 것임. 인바운드 트래픽을 허용하면, 그에 대한 응답(아웃바운드)은 자동으로 허용됨. 별도로 아웃바운드 규칙을 추가할 필요가 없음.

3-Tier Architecture에서는 각 계층별로 보안 그룹을 생성함.

계층별 보안 그룹 규칙

웹 계층 보안 그룹:

인바운드: HTTP(80), HTTPS(443) - 모든 IP에서 허용
인바운드: SSH(22) - 관리자 IP에서만 허용 (선택)

애플리케이션 계층 보안 그룹:

인바운드: 애플리케이션 포트(예: 8080) - 웹 계층 보안 그룹에서만 허용

데이터베이스 계층 보안 그룹:

인바운드: MySQL(3306) 또는 PostgreSQL(5432) - 애플리케이션 계층 보안 그룹에서만 허용

이렇게 구성하면 계층 간 통신만 허용되고, 외부에서 데이터베이스로 직접 접근하는 것은 불가능함.

# 웹 계층 보안 그룹 생성
WEB_SG=$(aws ec2 create-security-group \
    --group-name web-tier-sg \
    --description "Security group for web tier" \
    --vpc-id $VPC_ID \
    --query 'GroupId' \
    --output text)

# HTTP 허용
aws ec2 authorize-security-group-ingress \
    --group-id $WEB_SG \
    --protocol tcp \
    --port 80 \
    --cidr 0.0.0.0/0

# HTTPS 허용
aws ec2 authorize-security-group-ingress \
    --group-id $WEB_SG \
    --protocol tcp \
    --port 443 \
    --cidr 0.0.0.0/0

현재글AWS Management Console과 Cloud9으로 3-Tier Architecture 환경 구성하기

No.0302

techno-0302 님의 블로그 입니다.

Today :
Yesterday :

No.0302