카테고리 없음

[26지방기능1] Cross VPC 환경에서의 WAS + DB 아키텍처 구축하기

CloudBackend 2026. 4. 1. 13:36

 

2026년도 지방기능경기대회 제 1과제 아키텍처 다이어그램

 

개요

서비스 규모가 커질수록 애플리케이션과 데이터베이스를 하나의 네트워크 경계 안에만 두는 구조는 점점 한계를 드러낸다.
운영 환경과 보안 요구사항이 세분화되면서, WAS와 DB를 서로 다른 VPC에 분리해 배치해야 하는 상황은 이제 특별한 경우가 아니라 흔한 아키텍처 선택지가 되었다.

 

예를 들어, 애플리케이션 서버는 외부 연동이나 확장성을 고려해 별도의 애플리케이션 VPC에 두고, 데이터베이스는 더 엄격한 접근 통제와 독립적인 관리가 가능한 데이터 VPC에 두는 방식이 대표적이다. 이런 구조는 보안성과 관리 측면에서 분명한 장점을 제공하지만, 동시에 네트워크 연결 방식, 라우팅, 보안 그룹, DNS, 지연 시간, 장애 대응 같은 여러 요소를 함께 고민해야 하는 복잡성도 가져온다.

 

특히 AWS 환경에서는 VPC Peering, Transit Gateway, PrivateLink 등 다양한 연결 방법이 존재하기 때문에, 단순히 "서로 통신되게 만든다"는 수준을 넘어 어떤 방식이 현재 요구사항에 가장 적합한지 판단하는 것이 중요하다. 잘 설계된 Cross VPC 아키텍처는 보안성과 확장성을 모두 확보할 수 있지만, 반대로 설계 기준 없이 접근하면 운영 난이도와 장애 포인트만 늘어날 수 있다.

 

이번 실습에서는 아래 레포[참고자료 5]를 참고하여 사용하여 실습을 진행하도록 한다.

목차

더보기

1. VPC 생성 및 pcx/tgw 연결

2. Security Group Setup

3. Bastion host setup

4. Database Setup

5. WAS Setup (ASG 기준)

6. ALB Setup

7. CloudWatch 모니터링 구성 

8. 검증 및 테스트

1. VPC 생성 및 pcx/tgw 연결

1-1. VPC 생성

먼저, 아래와 같이 VPC를 생성한다. 필자는 아래와 같이 worldpay-app-vpc(10.10.0.0/16)와 worldpay-db-vpc(10.20.0.0/16)를 구성하였다.

TGW를 사용하는 경우, 각 VPC에 TGW Attach용 Subnet을 따로 추가하는 경우가 있으니 알아두길 바란다.

worldpay-app-vpc의 리소스 맵
worldpay-db-vpc의 리소스 맵

1-2. VPC Endpoint 설정

기본적으로 DB VPC는 Public Subnet 또는 NAT Gateway가 없는 형태이기에 해당 VPC에 생성될 RDS 리소스는 Secrets Manager 등의 리소스에 접근하지 못한다. 그렇기 때문에 AWS PrivateLink를 통해 내부 AWS 네트워크에 연결될 수 있도록 해주어야 한다.

아래 명령어를 통해 VPC에 필요한 VPC Endpoint들을 추가해주도록 하자. 만약 필요하다면, create_endpoint.sh의 services 부분에 추가적으로 필요한 것을 추가할 수 있도록 하자.

https://github.com/cloud-is-my-life/w1-script <- 여기서 create_endpoints.sh 찾기
chmod +x create_endpoints.sh
./create_endpoints.sh worldpay-db-vpc

1-3. Peering Connection 설정

1-3과 1-4는 상황에 따라 택 1하여 진행하도록 한다.

이제, 두 VPC를 연동하는 작업을 진행해주도록 하자. 2개의 VPC를 연동하는 방법은 크게 Peering Connection과 Transit Gateway로 나뉜다. 1-3에서는 pcx를 사용하여 두 VPC를 연동해보도록 하겠다.

 

 

VPC Peering 연결 생성에 들어가 위와 같이 세팅한 후, 생성한다.

요청자와 수락자는 지시에 따라 적절히 선택하도록 한다.

pcx가 생성된 후, 작업 -> 요청 수락을 눌러 두 VPC를 연결한다.

그 후, DNS 설정 편집에 들어가 요청자 <-> 수락자 간 DNS -> Private IP 질의를 허용한다. 이 옵션을 활성화해야 RDS DNS 기반 접근이 가능해진다.

1-4. Transit Gateway 설정

1-3과 1-4는 상황에 따라 택 1하여 진행하도록 한다.

1-3에서 pcx를 알아보았으니, 이제는 Transit Gateway를 진행하도록 하겠다. 간단하게 구성만 하고 넘어가므로 자세한 설명은 Transit Gateway로 여러 개의 VPC를 연결하기를 참고할 것을 권장한다.

 

ASN, Name tag는 적절히 정하도록 하며, 생성한다.

잘 생성되었다면, Transit Gateway 연결에 들어가 App, DB VPC 모두 TGW Attachment를 생성해주도록 하자.

TGW Attachment가 잘 생성된 후, Available 인 것을 확인하고, 1-5로 넘어가자.

1-5. Route Table 설정

Route table은 자동화 스크립트를 통해 추가합니다.

https://github.com/cloud-is-my-life/w1-script <- 여기서 add_routes.sh 찾기
chmod +x add_routes.sh

# pcx 사용 시
./add_routes.sh worldpay-app-vpc worldpay-db-vpc pcx worldpay-pcx

# tgw 사용 시
./add_routes.sh worldpay-app-vpc worldpay-db-vpc tgw worldpay-tgw

# Usage
./add_routes.sh <vpc1> <vpc2> <type; pcx/tgw> <pcx or tgw name>

 

만약 특정 Subnet에서 pcx/tgw routing을 설정해선 안된다면 해당 스크립트 실행 후, 수동으로 rtb에서 Rule을 제거합니다.

2. Security Group Setup

SG 또한 자동화 스크립트를 사용합니다.

https://github.com/cloud-is-my-life/w1-script <- 여기서 provision_sg.sh 찾기
chmod +x provision_sg.sh
./provision_sg.sh

 

해당 쉘 스크립트 실행 후 반드시 AWS Mgmt Console에서 SG가 제대로 구성되었는지 확인할 것. 해당 Shell script로 cover 되지 않거나, 별도로 지시된 사항이 있다면 수동으로 rule 추가하길 바랍니다.

 

이후, DB Security Group에 들어가 아래 Rule을 하나 더 추가합니다.

VPC Endpoint Security Group에서 DB Port로의 inbound를 허용해줘야 정상적으로 RDS Proxy를 통한 DB 접속이 가능해집니다.

 

또한, 포트 번호 지시된대로 잘 맞췄는지 꼼꼼히 확인!

3. Bastion host setup

별도의 지시가 없는 한, Bastion host는 기본적으로 모든 리소스에 접근할 수 있도록 구성한다.

이를 위해 AdministratorAccessPolicy를 가진 IAM Role을 아래와 같이 생성한다.

https://github.com/cloud-is-my-life/w1-script <- 여기서 create_admin_role.sh 찾기
chmod +x create_admin_role.sh
./create_admin_role.sh <role_name>

 

Keypair를 생성한다. 이 파일은 매우 매우 중요하니 반드시 잘 보관한다.

PuTTY를 쓴다면 .ppk 형식을, Git bash 등을 통해 openssh로 접속한다면 .pem 형식을 통해 내려받는다.

필자는 Git bash를 주로 사용하므로 .pem 형식을 사용하였다.

 

이후, 알아서 잘 Bastion Host 구성. App VPC의 Public subnet에 하는거 잊지 말고, IAM Instance Profile 반드시 줘라. 저장공간 넉넉히 20GiB 주고, SG 기존에 만들어둔걸로 잘 맞추기.

IAM Role 부여, EIP 할당, SG 설정, Keypair 할당 잘 되었는지 체크 후, 인스턴스에서 aws sts get-caller-identity로 다시 확인.

 

※ 만약 Bastion 접속 Port 변경하게 할 경우 userdata.sh

#!/bin/bash

SSH_PORT=2222

sed -i "s/#Port 22/Port ${SSH_PORT}/" /etc/ssh/sshd_config
systemctl restart sshd

 

이후, 아래 Github 참고해서 Bastion Setup 진행.

https://github.com/cloud-is-my-life/work1 or 25Setup

4. Database Setup

4-0. KMS Key Setup

RDS 암호화에 사용할 KMS 키는 아래 명령어로 생성하도록 합니다.

단, 아래 명령어의 TagValue와 Alias는 상황에 맞게 적절히 교체하도록 합니다.

KEY_ID=$(aws kms create-key \
  --description "RDS KMS Key" \
  --tags TagKey=Name,TagValue=worldpay-rds-kms-key \
  --query 'KeyMetadata.KeyId' \
  --output text)

aws kms create-alias \
  --alias-name alias/worldpay-rds-kms-key \
  --target-key-id $KEY_ID

 

생성 후, 별도의 Key Policy를 설정해야 할 경우 AWS Mgmt Console에서 생성합니다.

4-1. RDS Cluster or Instance

본 파트에서 언급하는 옵션들은 모두 권장값 또는 필자의 선택입니다. 여러분의 니즈에 맞게 적절히 조합하여 사용하십시오!

먼저, 서브넷 그룹과 파라미터 그룹을 생성하여야 합니다.

아래와 같이 SubnetGroup의 이름, 설명, 지정할 VPC를 선택한 후, 생성할 서브넷 

 

서브넷 그룹을 생성한 후, RDS의 데이터베이스 설정 옵션 값의 집합인 Parameter Group을 생성한다.
파라미터 그룹을 사용하지 않는다면 기본 ParamGroup의 설정 값을 그대로 따라가야 하므로 가능하다면 별도로 생성을 권장한다.

엔진 유형, 파라미터 그룹 패밀리와 PG 유형은 상황에 맞게 적절히 선택하도록 한다.

만약, DB 클러스터 생성을 해야한다면, Cluster ParameterGroup도 하나 더 생성함에 유의합니다!

 

자, 이제 RDS를 생성해봅시다.

Engine Option, 템플릿, 가용성 및 내구성 부분은 과제지의 지시에 맞게 적절히 설정합니다. 단, DB 클러스터와 인스턴스를 잘 구분하여야 합니다.

 

DB 클러스터 식별자와 루트 유저 이름을 잘 지정한 후, Secrets Manager에서 비밀번호를 관리하도록 지정합니다. 필요 시, IAM 기반의 데이터베이스 인증을 활성화할 수 있습니다.

 

네트워크 파트에서는 기존에 생성해둔 DB VPC와 SubnetGroup을 선택하고, 퍼블릭 액세스 여부를 지시에 맞게 설정합니다. 또한, 2번에서 생성한 SG를 지정하고, 데이터베이스 포트를 지시에 맞게 설정합니다.

 

이후, 모니터링 파트에서 AWS KMS 키를 4-1에서 생성한 KMS 키로 지정합니다.

 

추가 모니터링의 경우, 지시에 따라 적절히 설정합니다.

 

DB 추가 구성을 진행합니다. 초기 데이터베이스 이름을 지정하는 것을 권장하며, ParameterGroup을 전에 생성한 옵션으로 설정합니다. 백업 등의 옵션도 지시에 맞게 적절히 설정합니다.

 

백업을 암호화할 KMS 키를 지정하고, 역추적 옵션은 지시에 맞게 설정합니다.

이 외에도 유지 보수 기간, 삭제 방지 등의 옵션을 지시에 맞게 설정하도록 합니다.

 

자, 이제 데이터베이스를 생성해봅시다. 몇 분 정도 기다리면, 아래 사진과 같이 DB 클러스터와 인스턴스가 잘 프로비저닝됩니다.

적지 않은 시간동안 기다려야 하므로 미리 5번 WAS를 셋업하다 돌아오는 것을 권장합니다.

 

위와 같이 RDS Cluster와 Instance가 잘 생성된 것을 볼 수 있습니다. 이제, 필요하다면 4-2, 4-3을 진행하고, 5번으로 넘어가 WAS를 구성해봅시다.

4-2. (Optional) Additional Secrets Manager setup

추가적으로 필요할 경우, AWS Mgmt Console의 Secrets Manager에서 보안 암호를 따로 생성하도록 합니다.

적절히 필요한 값을 채워넣고, KMS 키를 이전에 생성한 CMK로 지정합니다.

 

데이터베이스는 4-1에서 생성한 DB를 선택합니다.

 

그 후, 보안 암호 이름과 설명, 태그를 설정합니다.

 

필요하다면, 비밀번호를 자동으로 교체할 수 있는 옵션을 활성화할 수 있습니다.

아래 옵션은 매일 2시간 내로 비밀번호를 교체하는 옵션입니다.

 

교체 함수의 경우, 기존 함수가 있다면 재사용해도 무관하나, 필자는 새로 생성하도록 하겠습니다.

또한, 비밀번호 교체 전략을 설정해야 합니다. 이 옵션은 단일 사용자와 여러 사용자 간 옵션이 있습니다. 

단일 사용자 옵션은 단순히 교체 함수를 사용하여 DB User의 인증 정보를 업데이트하는 옵션이며, rotation 순간에 짧게 불일치 구간이 생길 수 있다.

반면, 여러 사용자 간 옵션은 첫 rotation 시 기존 user를 복제한 새로운 user를 만들고, 시크릿을 해당 user의 secrets으로 업데이트하는 기법입니다. 그리고 다음 Rotation 시, 기존 user의 Secrets를 갱신 후, 시크릿을 기존 user의 secrets으로 업데이트합니다.

IAM 권한은 기본 역할을 생성하여 사용하고, 관리자의 보안 인증 암호를 선택합니다.

그리고, 생성합니다.

4-3. (Optional) RDS Proxy

본 파트에서 언급하는 옵션들은 모두 권장값 또는 필자의 선택입니다. 여러분의 니즈에 맞게 적절히 조합하여 사용하십시오!

만약, 필요한 경우 RDS Proxy를 생성하도록 합니다.

엔진 패밀리는 MySQL을 선택하고, 프록시 식별자는 임의로 입력합니다.

 

대상 그룹을 적절히 원하는 대로, 또는 지시대로 설정합니다.

 

이제, 중요한 파트 중 하나인 인증 파트를 설정합니다.

기본 인증 체계, IAM 인증 등은 지시 또는 여러분의 입맛에 맞게 설정한 뒤, Proxy가 사용할 Secrets Manager 보안 암호를 선택합니다.

 

연결 부분의 경우, 아래와 같이 적절히 DB VPC의 Subnet들을 선택한 후, 2번에서 생성한 Database용 SG를 지정합니다.

'전송 계층 보안 필요' 옵션의 경우, 필요 또는 지시에 맞게 적절히 설정하도록 합니다.

 

고급 구성 옵션은 입맛에 맞게 적절히 설정하고, 생성합니다.

RDS Proxy 생성 역시 시간이 걸리는 작업이므로 5번을 이어서 작업하다 돌아오도록 합시다.

조금 기다리면, 아래와 같이 RDS Proxy가 정상적으로 프로비저닝된 모습을 볼 수 있습니다.

DB가 생성된 후, Bastion에서 아래 명령어를 실행하여 Table, Data를 DB로 밀어넣자.

sudo dnf install -y mariadb105
mysql -u admin -h <mysql_addr> -P <port> -p'<password>' < table.sql

5. WAS Setup (ASG 기준)

5-1. Artifact Bucket

제공된 Python App 파일을 저장하고, ASG에서 쉽게 불러와서 사용하기 위해 S3에 Artifact Bucket을 생성합니다.

버킷 이름은 worldpay-artifact-<account_id> 형식을 사용했습니다.

 

버킷을 만든 후, 제공된 app.py, requirements.txt 파일을 업로드합니다.

5-2. Create Launch Template

제공된 Python App을 배포하기 위해 EC2 기반의 ASG를 구성합니다.

먼저, ASG가 사용할 시작 템플릿을 생성합니다. AutoScaling 지침을 활성화하고, 관련 값들을 작성합니다.

템플릿 태그는 이 시작 템플릿으로 시작하는 리소스에 붙는 태그가 아닌 시작 템플릿 자체에 붙는 태그입니다.

 

이후, AMI를 적절히 설정합니다. 필자는 Amazon Linux 2023으로 설치하였습니다.

그리고, 인스턴스 유형과 키 페어를 지정합니다. 이 부분은 여러분의 선택대로 설정하시기 바랍니다.

 

서브넷은 ASG에서 지정할 예정이므로, '시작 템플릿에 포함하지 않음'을 선택하고, SG는 2번에서 생성한 was-sg를 지정합니다.

 

스토리지를 입맛에 맞게 설정한 뒤, 시작 템플릿을 통해 생성될 EC2 인스턴스, 볼륨, ENI 등의 태그를 설정합니다.

 

이제, 시작 템플릿을 통해 생성되는 EC2 인스턴스에 할당할 IAM Role을 생성 또는 선택합니다. 기본적으로 아래 스크립트를 통해 생성하여 지정하나, IAM Role 기반 DB 인증을 필요로 할 경우 [2]를 참고하여 생성한다.

마지막으로, Userdata 스크립트를 추가합니다. userdata를 통해 App을 실행시킬 예정이므로 매우 중요합니다.

https://github.com/cloud-is-my-life/work1

 

해당 파일을 받아와서 UserData에 넣어줍니다.

해당 Userdata를 적절히 여러분들의 니즈와 지시에 맞게 커스텀하여 사용하여야 합니다!

또한, 반드시 #!/bin/bash 아래의 모든 주석을 삭제하고 업로드하세요. 아니면 오류 날 수 있습니다!

5-3. Create AutoScalingGroup

시작 템플릿을 생성했으니, 해당 템플릿을 기반으로 EC2 Auto Scaling Group을 생성해봅시다. 

아래와 같이 ASG 이름을 설정하고, 아까 만든 시작 템플릿을 선택하도록 합니다.

 

네트워크의 경우 App VPC와 Private Subnet 전체에 EC2 인스턴스들이 배치되도록 설정한다. 

 

로드밸런서는 별도로 연결할 것이므로 스킵하고, VPC Lattice, ARC는 활성화하지 않는다.

필자의 경우 Instance 수를 Desired 3, Min 2, Max 5대로 설정하였다.

이 값은 여러분들의 니즈 또는 지시에 맞게 설정하기 바란다.

 

스케일링 정책의 경우, 평균 CPU 사용률 50%를 유지할 수 있도록 Scaling 정책을 설정하였다. 

이 값 또한 여러분들의 니즈 또는 지시에 맞게 설정하기 바란다.

 

인스턴스 스케일링 시 가용성을 위한 정책을 가용성 우선순위로 설정하였다. 이것도 니즈 / 지시에 따라 알잘딱!

 

이 옵션도 알잘딱합니다.

 

이제 생성까지 쭈욱 간다.

Yarr~

6. ALB Setup

6-1. Create Application Load Balancer

ASG의 인스턴스에 트래픽을 분배하기 위해 ALB와 Target Group을 생성합니다.

적절히 대상 유형과 이름, App이 작동하는 포트를 지정합니다.

 

ASG의 인스턴스가 배치된 VPC를 선택하고, Health check path를 지정합니다.

 

이후, 인스턴스를 추가하지 않은 상태로 TG를 생성합니다.

 

이제 ALB를 생성해보겠습니다. 

이름을 입력한 후, 체계를 Internet-facing로 설정합니다.

 

이후, ALB를 배치할 VPC와 서브넷, 보안 그룹을 모두 선택합니다. 보안 그룹은 2번에서 생성한 ALB SG로 지정하도록 합니다.

이제, 트래픽을 라우팅하기 위한 리스너를 설정합니다. 대상 그룹으로 전달 옵션을 선택하고,

 

이제 생성합니다.

6-2. Connect with ASG

다시 AutoScalingGroup으로 들어가서 통합 탭으로 이동하여, 로드 밸런싱 -> 편집을 클릭합니다.

 

이렇게 방금 만든 Target Group을 추가한 후, 저장한다.

그리고 TG로 가보면 Yarr~!

 

7. CloudWatch 모니터링 구성

CloudWatch를 통한 모니터링 구성의 경우, 다양한 후보가 있어 모두 작성해보았습니다.

7-1. ASG -> CloudWatch Log Group

사실, Launch Template을 구울 때, userdata에 LOG_GROUP 이라는 환경 변수와 CloudWatch Agent를 설치하고, 로그를 export 하는 설정이 포함되어 있었습니다.

그렇기 때문에 로그 그룹만 생성해주면, 자동으로 로그 스트림이 생기고, 로그가 쌓이게 됩니다.

마치 이렇게.

 

이를 커스텀하기 위해서는, 아래 Userdata를 수정하면 됩니다.

 

 

자세한 내용은 Userdata 파일에 작성해두었으니 참고해주시면 좋겠습니다.

https://github.com/cloud-is-my-life/work1

7-2. CloudWatch Alarm

CloudWatch Alarm 챕터에서는 4XX, 5XX, ASG CPUUtilization 수치에 대한 알람을 구성합니다. 

가. ALB Target의 4XX 수치가 1분 내에 30개 이상 측정될 경우

아래와 같이 worldpay-alb의 HTTPCode_Target_4XX_Count 지표를 선택합니다.

 

그 후, 정적 임계값 유형의 '보다 크거나 같음'을 선택하고, 30으로 임계값을 정의합니다.


SNS Alarm 등은 임의로 추가한 후, 생성합니다. 이름은 WorldPay ALB 4XX >= 30으로 설정하였습니다.

테스트를 위해 아래 명령어로 404 요청을 생성해봅니다.

 while :; do curl http://worldpay-alb-2038413529.ap-northeast-2.elb.amazonaws.com/404 &> /dev/null ; done

 

조금 기다린 후, 경보 페이지를 새로고침하면 경보가 활성화된 것을 알 수 있습니다.

 

나. ALB Target의 5XX 수치가 1분 내에 20개 이상 측정될 경우

아래와 같이 worldpay-alb의 HTTPCode_Target_5XX_Count 지표를 선택합니다.

그 후, 정적 임계값 유형의 '보다 크거나 같음'을 선택하고, 20으로 임계값을 정의합니다.

SNS Alarm 등은 임의로 추가한 후, 생성합니다. 이름은 가 항목과 비슷하게 WorldPay ALB 5XX >= 20으로 설정하였습니다.

테스트를 위해 Secrets Manager의 DB 연결 값을 다르게 바꿔버린 후, 아래 명령어로 요청을 생성해봅니다.

while :; do curl http://worldpay-alb-2038413529.ap-northeast-2.elb.amazonaws.com/products &> /dev/null ; done

조금 기다린 후, 경보 페이지를 새로고침하면 경보가 활성화된 것을 알 수 있습니다.

 

다. AutoScalingGroup의 CPUUtilization 수치가 3분 평균 70% 이상으로 높아질 경우

가, 나 항목과 유사하게 아래처럼 worldpay-app-asg의 CPUUtilization 지표를 선택합니다.

 

그 후, 정적 임계값 유형의 '보다 크거나 같음'을 선택하고, 70으로 임계값을 정의합니다.

 

SNS Alarm 등은 임의로 추가한 후, 생성합니다. 이름은 가, 나 항목과 비슷하게 WorldPay ASG; 3m CPUUtil >= 70%으로 설정하였습니다.

테스트를 위해 SSM으로 Node 하나에 접속한 후, 아래 명령어를 실행하여 CPU 사용률을 높여봅니다.

sudo dnf install stress-ng
stress-ng --cpu 1 --cpu-load 90 --timeout 10m

 

조금 기다린 후, 경보 페이지를 새로고침하면 경보가 활성화된 것을 알 수 있습니다.

7-3. CloudWatch Dashboard 구성

이번 챕터에서는 CloudWatch를 사용하여 대시보드를 구성해보겠습니다. 모든 위젯 설정을 json으로 첨부하면 글이 너무 길어지므로, 대시보드 구성 Manifest 파일은 https://github.com/cloud-is-my-life/work1 에 업로드 해두었습니다.

 

가. ALB 대시보드 구성

 

나. WAS 대시보드 구성

 

다. Database 대시보드 구성

8. 검증 및 테스트

이 링크(https://github.com/cloud-is-my-life/work1)에 있는 traffic_gen.py를 찾아서 실행해보자.

 

이렇게 CRUD 작업이 정상적으로 실행되는 것을 알 수 있다.

TroubleShooting

- AWS CloudWatch Agent 로그 확인하는 법

 

마무리

이번 실습은 단순히 WAS와 DB를 띄우는 데서 끝나는 게 아니라, 서로 다른 VPC에 분리된 자원을 어떻게 안전하고 안정적으로 연결할 것인가를 직접 설계하고 검증해보는 과정이었다. VPC Peering 또는 Transit Gateway를 통한 네트워크 연결부터, Security Group, Bastion Host, RDS, ASG, ALB, CloudWatch까지 하나씩 구성해보면서, 실제 운영 환경에서 필요한 보안 원칙, 확장성, 관측성을 함께 고려하는 아키텍처가 어떻게 만들어지는지 확인할 수 있었다.

 

결국 중요한 건 "통신이 된다"가 아니라, 왜 이런 구조로 나눴고, 어떤 방식으로 연결했으며, 장애가 났을 때 어떻게 확인하고 대응할 수 있는가까지 설명할 수 있는 설계다. 이번 과제를 통해 Cross-VPC 환경의 기본기를 익혔다면, 다음 단계에서는 이를 IaC로 자동화하거나 더 큰 규모의 멀티 VPC 구조로 확장해보는 것도 좋다. 작은 실습처럼 보여도, 이런 경험이 쌓이면 실무 아키텍처를 보는 눈이 확실히 달라진다

참고할 문서

[1] DB비밀번호 없이 AWS RDS 접속하는 방법 (feat, RDS IAM 인증) - https://malwareanalysis.tistory.com/892

[2] RDS IAM 기반 접근제어 예시 - https://ninejuan.tistory.com/entry/26WKRD1-MySQL-RDS%EC%97%90-IAM-%EC%9D%B8%EC%A6%9D%EC%9C%BC%EB%A1%9C-%EC%97%B0%EA%B2%B0%ED%95%98%EA%B8%B0

[3] Secrets Manager 강제 삭제하는 법 - https://ehdtn1219.tistory.com/195

[4] Amazon CloudWatch Agent 관련 문서 - https://brunch.co.kr/@topasvga/618

[5] 관련 예제 - https://github.com/cloud-is-my-life/work1