AWS Well-Architected Framework 직접 써보고 Trusted Advisor한테 평가받은 기록

 

VPC 설계 실습을 마치고 나서 강사님이 이런 말씀을 하셨다.

"설계를 했으면 그게 잘 된 설계인지 확인하는 과정이 있어야 한다. AWS는 그걸 도와주는 도구를 직접 제공한다. 오늘은 본인이 짠 구조를 AWS가 어떻게 평가하는지 직접 받아봐라."

그때까지 나는 EC2 올라가고 RDS 연결되면 설계가 끝난 거라고 생각했다. 그날 Trusted Advisor 결과를 처음 보고 그 생각이 완전히 바뀌었다.

---

AWS Well-Architected Framework — 5가지 기둥이 왜 중요한가

AWS는 클라우드 설계의 품질을 평가하는 기준으로 Well-Architected Framework를 제시한다. 5가지 기둥으로 구성된다.

강사님이 이걸 처음 소개하실 때 이렇게 말씀하셨다.

"이 다섯 개는 체크리스트가 아니다. 설계할 때 항상 머릿속에 켜두는 다섯 개의 질문이다. 하나라도 빠지면 나중에 그 구멍으로 문제가 들어온다."

① 운영 우수성 (Operational Excellence) 인프라가 돌아가는 것과 잘 운영되는 것은 다르다. 변경을 어떻게 추적하고, 장애를 어떻게 감지하며, 운영 절차가 코드로 관리되는지를 본다. 강사님 말로는 "EC2 하나 바꿀 때 콘솔에서 손으로 건드리면 운영 우수성은 0점"이라고 하셨다.

② 보안 (Security) 누가 무엇에 접근할 수 있는지, 데이터는 어떻게 보호되는지, 보안 이벤트는 어떻게 감지하는지를 본다. IAM 권한 설계가 여기 핵심이다.

③ 안정성 (Reliability) 장애가 났을 때 시스템이 어떻게 회복하는지다. 단순히 서버가 죽지 않는 게 아니라, 죽었을 때 자동으로 복구되는 구조인가를 본다. 단일 AZ에만 리소스를 둔 구조는 이 기둥에서 낮은 평가를 받는다.

④ 성능 효율성 (Performance Efficiency) 필요한 만큼의 리소스를 적절한 타입으로 쓰고 있는가다. t3.micro로 충분한데 m5.large를 쓰는 것도, 반대로 부족한 스펙에 트래픽을 몰아넣는 것도 모두 여기서 걸린다.

⑤ 비용 최적화 (Cost Optimization) 불필요한 비용이 없는가, 리소스가 놀고 있지는 않은가다. 개발용으로 만들어둔 EC2를 주말에도 켜두는 습관이 여기서 잡힌다.

---

Well-Architected Tool — 내 설계를 AWS한테 직접 물어봤다

AWS 콘솔에서 Well-Architected Tool을 찾아서 내가 실습한 구조를 직접 평가받아봤다. 사용 방법은 간단하다. 워크로드를 하나 만들고, 각 기둥별 질문에 답하면 리스크를 자동으로 분류해준다.

워크로드 이름: multicloud-practice-vpc 리뷰 날짜: 2025년 1월

질문에 답하면서 바로 걸린 것들이 있었다.

안정성 섹션 질문: "여러 가용 영역에 걸쳐 워크로드를 분산하고 있습니까?"

내 실습 구조는 전부 ap-northeast-2a 단일 AZ에 있었다. 서브넷도 하나, EC2도 하나, RDS도 단일 인스턴스. "아니오"를 체크하니까 즉시 High Risk로 분류됐다.

보안 섹션 질문: "루트 사용자 자격 증명 사용을 추적하고 있습니까?"

IAM 실습 때 루트 계정으로 콘솔에 직접 로그인해서 작업한 게 있었다. 이것도 체크하고 나니까 High Risk가 하나 더 붙었다.

결과 요약 화면에서 내 워크로드 평가가 나왔다.

High Risk: 3개
Medium Risk: 5개
Low Risk: 2개

솔직히 처음엔 당황했다. 나름대로 서브넷 나누고 Security Group도 꼼꼼하게 설정했다고 생각했는데, AWS 기준으로 보니 구멍이 한두 개가 아니었다.

강사님이 결과를 보시더니 이렇게 말씀하셨다.

"High Risk 3개면 솔직히 양호한 편이다. 처음 배우는 사람이 설계한 것치고는. 근데 저 High Risk 중 단일 AZ 문제는 실제 서비스에서 그대로 가면 AZ 장애 하나에 전체 서비스가 다운된다. 2019년에 실제로 특정 AZ에 장애가 났을 때 단일 AZ로 설계된 서비스들이 전부 다운됐다. AWS가 99.99% SLA를 보장한다고 해도 구조가 단일 AZ면 그 보장의 의미가 없다."

---

Trusted Advisor — 실제로 어떤 항목이 걸렸나

Trusted Advisor는 Well-Architected Tool과 다르다. 내가 질문에 답하는 게 아니라, AWS가 내 계정의 실제 리소스 상태를 자동으로 스캔해서 문제를 짚어준다.

Business Support 플랜 이상이어야 전체 항목을 볼 수 있고, 무료 플랜에서는 일부 핵심 항목만 제공된다. 실습 계정은 무료 티어라 제한이 있었지만, 보안과 비용 관련 기본 항목은 확인할 수 있었다.

스캔 결과에서 걸린 것들:

보안 항목 — S3 버킷 퍼블릭 액세스

Warning: Amazon S3 버킷에 퍼블릭 액세스 허용이 감지되었습니다.
버킷 이름: practice-log-bucket-20250112
권장 조치: 퍼블릭 액세스 차단 설정을 활성화하세요.

로그 저장용으로 S3 버킷을 하나 만들었는데, 만들 때 퍼블릭 액세스 차단 설정을 건드리지 않아서 기본값이 그대로였다. 버킷을 외부에서 직접 접근할 일은 없는데 열려있던 거다.

강사님이 이걸 보시고 바로 말씀하셨다.

"S3 퍼블릭 버킷 때문에 개인정보 유출된 사례가 실제로 엄청나게 많다. 버킷 만들 때 퍼블릭 액세스 차단은 기본으로 켜두는 게 맞다. 나중에 CDN 연결한다고 CloudFront 쓸 때도 버킷은 프라이빗으로 두고 OAC(Origin Access Control)로 CloudFront만 접근 허용하는 구조로 가야 한다."

비용 항목 — 사용률 낮은 EC2 인스턴스

Warning: 사용률이 낮은 Amazon EC2 인스턴스가 감지되었습니다.
인스턴스 ID: i-0a3f8d2c1b4e7f9a1
인스턴스 유형: t3.medium
14일 평균 CPU 사용률: 2.3%
예상 월 절감액: $12.32 (t3.micro로 변경 시)

실습 중에 만들어놓고 안 쓰고 있던 EC2가 걸렸다. CPU 2.3%면 사실상 놀고 있는 거다. t3.medium을 쓸 이유가 없었다.

강사님 말씀:

"Trusted Advisor 비용 항목은 무시하기 쉬운데, 현업에서 이게 쌓이면 월 수백만 원이 된다. 특히 개발 환경에서 사이즈 줄이거나 안 쓸 때 꺼두는 습관이 안 된 팀은 AWS 청구서 보고 나서야 부랴부랴 정리한다. 처음부터 리소스 만들면 Trusted Advisor 보는 루틴을 만들어라."

보안 항목 — MFA 미설정 IAM 사용자

Red: IAM 루트 계정에 MFA가 활성화되어 있지 않습니다.
권장 조치: 루트 계정에 즉시 MFA를 활성화하세요.

이건 빨간색 경고였다. 루트 계정 MFA는 필수 중의 필수인데, 실습 계정이라고 설정을 미뤘던 게 걸렸다.

---

내 설계의 실제 구멍들 — 수정 전후 비교

Trusted Advisor와 Well-Architected Tool 결과를 바탕으로 구조를 수정했다.

수정 전 구조:

ap-northeast-2a (단일 AZ)
├── 퍼블릭 서브넷: 10.10.1.0/24
│   └── 배스천 EC2 (t3.medium)
├── 프라이빗 서브넷: 10.10.2.0/24
│   └── 웹서버 EC2 (t3.medium)
└── 프라이빗 서브넷: 10.10.3.0/24
    └── RDS (단일 인스턴스)

수정 후 구조:

ap-northeast-2a                    ap-northeast-2c
├── 퍼블릭: 10.10.1.0/24          ├── 퍼블릭: 10.10.4.0/24
│   └── NAT GW                    │   └── NAT GW (대기)
├── 프라이빗: 10.10.2.0/24        ├── 프라이빗: 10.10.5.0/24
│   └── 웹서버 EC2 (t3.small)     │   └── 웹서버 EC2 (t3.small)
└── 프라이빗: 10.10.3.0/24        └── 프라이빗: 10.10.6.0/24
    └── RDS Primary                    └── RDS Standby (Multi-AZ)

주요 변경 사항:

• EC2 인스턴스 타입을 t3.medium → t3.small로 변경 (실습 환경에서 t3.medium은 과잉)
• RDS를 단일 인스턴스에서 Multi-AZ 배포로 변경
• S3 버킷 퍼블릭 액세스 차단 설정 활성화
• 루트 계정 MFA 활성화, 작업용 IAM 사용자 별도 생성
• 웹서버를 두 AZ에 분산 배치, ALB로 트래픽 분산

수정 후 Well-Architected Tool을 다시 돌렸더니:

High Risk: 3개 → 1개
Medium Risk: 5개 → 3개

단일 AZ 문제가 해소되면서 안정성 관련 High Risk가 두 개 사라졌다. 남은 High Risk 하나는 CloudTrail이 활성화되어 있지 않다는 항목이었다.

강사님이 보시더니:

"CloudTrail은 누가 언제 어떤 API를 호출했는지 전부 기록하는 서비스다. 이게 없으면 보안 사고 났을 때 원인 추적이 불가능하다. 비용은 90일 무료, 이후 GB당 과금인데 웬만한 규모면 월 몇 달러 수준이다. 이걸 아끼려다가 사고 났을 때 로그 없어서 수습 못 하는 경우를 실제로 봤다."

---

강사님이 현업에서 봐온 설계 실수들

수업 끝나고 질문하는 시간에 강사님이 실무 사례를 몇 가지 더 얘기해주셨다.

사례 1 — Security Group 규칙이 220개 쌓인 케이스

"어느 회사 인프라 진단을 맡은 적이 있는데, EC2 하나에 Security Group 규칙이 220개였다. 누군가 필요할 때마다 추가만 하고 정리를 안 한 거다. AWS Security Group 인바운드 규칙 기본 한도가 인바운드 60개인데, 그걸 한도 올려서 쌓아놓은 거다. 어느 포트가 열려있는지 아무도 몰랐다. Trusted Advisor는 이런 것도 잡아준다. Security Group 규칙 과다 경고가 있다."

사례 2 — 개발 환경 EC2 비용이 운영보다 더 나온 케이스

"개발 환경을 운영 환경이랑 똑같은 스펙으로 만들어놓고, 퇴근할 때 안 끄는 팀이 있었다. 인스턴스 타입이 c5.4xlarge였는데, 이게 개발 서버에 12대 있었다. 월 청구서 보고 나서 비로소 Trusted Advisor를 켰다. 처음부터 Well-Architected Tool 비용 최적화 항목 보면서 설계했으면 안 생길 일이었다."

사례 3 — RDS 스냅샷이 없어서 데이터 날린 케이스

"RDS 단일 인스턴스 쓰면서 자동 백업 설정을 꺼둔 팀이 있었다. 백업 켜두면 스토리지 비용이 조금 더 나온다는 이유로. 어느 날 실수로 테이블 드롭했는데 복구할 방법이 없었다. Well-Architected Framework 안정성 기둥에서 '백업 전략이 있는가'를 명시적으로 묻는 이유가 거기 있다."

---

실습하면서 느낀 것 — 설계는 만드는 게 아니라 검증하는 것까지다

AWS VPC 구조를 잡고, Security Group 설정하고, RDS 연결되면 실습이 끝난다고 생각했다. 근데 Well-Architected Tool 돌리고 Trusted Advisor 결과 받아보고 나서 그 인식이 바뀌었다.

설계는 만드는 것과 검증하는 것 두 단계가 있다. 만드는 건 절반이다.

강사님이 마지막에 이런 말씀을 하셨다.

"현업에서 Well-Architected Review를 정기적으로 하는 회사랑 안 하는 회사는 6개월 지나면 인프라 상태가 완전히 달라진다. 안 하는 곳은 기술 부채가 쌓이고, 언젠가 그게 장애로 터진다. 지금 실습 단계에서부터 설계하고 검증하는 루틴을 만들어놔라. 나중에 현업 가서도 그 습관이 남는다."

지금 단계에서 Well-Architected Tool과 Trusted Advisor를 직접 써보고 내 설계가 어디서 부족한지 피드백 받은 게 이론 수업보다 훨씬 많이 남았다. 다음 실습에서는 CloudTrail 켜고, Auto Scaling 붙여서 안정성 기둥 점수를 더 올려볼 생각이다.