AWS Well-Architected 6가지 원칙으로 내 클라우드 구성 점검하는 법

클라우드 서비스를 하나씩 배우다 보면 보안 그룹, 백업, 알람, 요금 할인처럼 챙길 것이 계속 늘어납니다. 각각은 이해했는데 "그래서 내 구성이 전체적으로 괜찮은가"라는 질문에는 답하기 어렵습니다. 무엇을 빠뜨렸는지 확인할 기준이 없기 때문입니다.

 

AWS Well-Architected 프레임워크는 이런 점검을 위해 AWS가 정리한 설계 기준입니다. 클라우드 구성을 여섯 가지 관점(원칙)으로 나눠 질문을 던지고, 답하지 못하는 부분을 개선 과제로 삼게 합니다.

 

이 글에서는 여섯 가지 원칙이 각각 무엇을 묻는지, 작은 서비스에서 먼저 확인할 항목, 그리고 콘솔의 Well-Architected Tool로 점검하는 순서를 정리합니다. 이 블로그에서 다룬 주제들을 원칙별로 묶어 보는 정리 글이기도 합니다.

 

AWS Well-Architected 6가지 원칙으로 내 클라우드 구성 점검하는 법

 

여섯 가지 원칙

원칙	묻는 것	작은 서비스에서 먼저 볼 것
운영 우수성	변화를 안전하게 반영하고, 문제를 빨리 알아채는가	지표 알람, 변경 이력 기록
보안	누가 무엇에 접근할 수 있는지 통제하고 기록하는가	루트 계정 MFA, 최소 권한, 퍼블릭 접근 차단
안정성	장애가 나도 정해진 시간 안에 복구되는가	멀티 AZ, 백업과 복원 시험
성능 효율성	요구에 맞는 리소스 유형과 크기를 쓰는가	인스턴스 유형 선택, 캐시와 CDN
비용 최적화	필요한 만큼만 쓰고 지출을 파악하는가	예산 알림, 태그, 유휴 리소스 정리
지속 가능성	같은 일을 더 적은 자원으로 하는가	사용률 높이기, 오래된 데이터 정리

 

지속 가능성은 2021년에 추가된 원칙으로, 다른 원칙과 겹치는 부분이 많습니다. 쓰지 않는 리소스를 줄이면 비용과 환경 부담이 함께 줄어드는 식입니다.

 

원칙마다 한두 가지씩 확인하고, Well-Architected Tool로 위험 항목을 찾아 개선합니다

 

원칙별로 먼저 확인할 질문

운영 우수성

서버의 CPU나 오류 수가 평소와 다를 때 알림을 받고 있는지, 누가 언제 설정을 바꿨는지 찾을 수 있는지 확인합니다. 지표·알람·로그의 차이는 CloudWatch 지표·알람·로그 차이 글에서 정리했습니다.

 

보안

루트 계정을 일상 작업에 쓰지 않고 MFA를 켰는지, 사람과 애플리케이션이 필요한 권한만 갖는지, 데이터가 의도치 않게 공개되어 있지 않은지가 출발점입니다. 관련 내용은 루트 계정 MFA와 IAM 권한 분리, S3 퍼블릭 액세스 차단, 보안 그룹과 네트워크 ACL 글에서 다뤘습니다.

 

안정성

서비스가 몇 시간 멈춰도 되는지(RTO), 데이터를 얼마나 잃어도 되는지(RPO)를 먼저 정하고, 그에 맞춰 멀티 AZ 구성과 백업 주기를 고릅니다. 백업은 만들어 두는 것보다 실제로 복원해 보는 것이 중요합니다. RTO·RPO와 멀티 AZ 구성, EBS 스냅샷과 AWS Backup 글을 함께 보면 좋습니다.

 

성능 효율성

작업 성격에 맞는 인스턴스 계열을 골랐는지, 정적 파일을 CDN으로 사용자 가까이에서 내보내는지 확인합니다. EC2 인스턴스 유형 이름 읽는 법과 로드 밸런서 ALB·NLB·GWLB 차이가 이 원칙에 해당합니다.

 

비용 최적화

예산 알림으로 이상 지출을 바로 알아채는지, 태그로 어떤 서비스가 얼마를 쓰는지 나눠 보는지, 쓰지 않는 IP와 볼륨을 정리하는지 확인합니다. AWS Budgets 예산 알림, 비용 할당 태그와 Cost Explorer, EC2 요금 방식 비교 글을 참고하세요.

 

지속 가능성

사용률이 낮은 서버를 줄이고, 오래된 데이터를 더 낮은 스토리지 등급으로 옮기거나 지우는 것이 가장 쉬운 시작입니다. S3 스토리지 클래스와 수명 주기 정책이 대표적인 예입니다.

 

작은 서비스용 10문항 자가 점검

Well-Architected Tool의 질문은 꽤 많아서 처음에는 부담스러울 수 있습니다. 아래 10문항에 먼저 "예·아니요"로 답해 보고, "아니요"가 나온 항목부터 개선하면 여섯 원칙의 기본은 챙길 수 있습니다.

 

원칙	질문
보안	1. 루트 계정에 MFA를 켜고 일상 작업에는 쓰지 않는가?
보안	2. 사람과 애플리케이션이 필요한 권한만 가지고 있는가?
보안	3. 공개될 이유가 없는 S3 버킷과 포트가 닫혀 있는가?
운영 우수성	4. 서버 이상이나 오류 증가를 알림으로 받는가?
운영 우수성	5. 누가 언제 설정을 바꿨는지 기록으로 찾을 수 있는가?
안정성	6. 데이터 백업이 자동으로 만들어지고, 복원을 실제로 해 봤는가?
안정성	7. 가용 영역 하나가 멈추면 서비스가 어떻게 되는지 알고 있는가?
성능 효율성	8. 인스턴스 유형과 크기를 사용률을 보고 정했는가?
비용 최적화	9. 예산 알림이 있고, 서비스별 비용을 태그로 나눠 볼 수 있는가?
지속 가능성	10. 쓰지 않는 리소스와 오래된 데이터를 정기적으로 정리하는가?

 

"아니요"가 여러 개라면 보안(1~3번)부터 처리하는 것이 좋습니다. 보안 사고는 한 번으로 큰 피해가 나고 되돌리기 어려운 반면, 비용이나 성능 문제는 보통 시간을 두고 조정할 수 있기 때문입니다. 답을 정리했다면 아래 순서대로 콘솔 도구에서 정식 점검을 진행합니다.

 

Well-Architected Tool로 점검하는 순서

1. 워크로드 정의 — AWS 콘솔에서 Well-Architected Tool을 열고, 점검할 서비스(워크로드)의 이름과 리전, 환경(운영·개발)을 입력합니다. 도구 사용에는 별도 요금이 없습니다.
2. 질문에 답하기 — 원칙별 질문마다 이미 하고 있는 모범 사례에 체크합니다. 모르는 항목은 비워 두고 나중에 확인합니다.
3. 위험 항목 확인 — 답변을 바탕으로 높은 위험(HRI)과 중간 위험 항목이 표시됩니다. 높은 위험부터 개선 계획을 세웁니다.
4. 마일스톤 저장 — 점검 결과를 마일스톤으로 저장해 두면, 몇 달 뒤 다시 점검했을 때 얼마나 개선됐는지 비교할 수 있습니다.

 

서버리스나 컨테이너처럼 특정 기술에 맞춘 질문 묶음인 렌즈(Lens)를 추가해 더 구체적으로 점검할 수도 있습니다.

 

Well-Architected 점검에서 자주 묻는 것

작은 개인 프로젝트에도 필요한가요?

모든 질문에 답할 필요는 없습니다. 다만 보안과 비용 원칙의 기본 항목(루트 계정 MFA, 예산 알림, 퍼블릭 접근 차단)은 규모와 상관없이 사고를 막아 주므로 먼저 확인할 가치가 있습니다.

 

여섯 원칙이 서로 부딪히면 어떻게 하나요?

멀티 AZ는 안정성을 높이지만 비용을 늘리는 것처럼 원칙끼리 맞바꿔야 할 때가 있습니다. 서비스가 멈췄을 때의 손실과 추가 비용을 비교해 우선순위를 정하는 것이 프레임워크가 권하는 방식입니다.

 

한 번 점검하면 끝인가요?

서비스와 AWS 기능이 계속 바뀌므로 큰 변경이 있을 때나 분기마다 다시 점검하는 것이 좋습니다. 저장해 둔 마일스톤과 비교하면 빠뜨린 부분이 잘 보입니다.

 

원칙별 첫 조치와 그 비용 — 작은 서비스 기준

여섯 원칙은 거창해 보이지만, 작은 서비스가 처음 할 조치는 대부분 무료이거나 한 가지 비용으로 끝납니다. 서울 리전 단가(AWS Price List 2026년 10월)로 정리했습니다.

원칙	첫 조치	월 비용
운영 우수성	CloudWatch 알람 5개 + 배포 절차 문서화	0달러 (알람 10개까지 무료)
보안	루트 MFA, Identity Center, 계정 단위 S3 퍼블릭 차단, CloudTrail 추적 1개	0달러
안정성	RDS 다중 AZ, 웹 서버 2개 AZ, 일일 스냅샷	+73.73달러 (RDS db.t4g.medium 기준) + 스냅샷 몇 달러
성능 효율성	Graviton 유형으로 전환, CloudFront 적용	−15~20% (인스턴스) · 1TB까지 전송 무료
비용 최적화	Budgets 알림, 태그 5개, 월초 미사용 리소스 점검	0달러
지속 가능성	미사용 리소스 삭제, 사용률 낮은 서버 축소	−(위 점검에서 찾은 만큼)

여섯 줄 중 돈이 드는 것은 안정성 한 줄뿐이고, 나머지는 설정 시간만 듭니다. Well-Architected Tool에서 점검을 돌리면 위험 항목이 수십 개 나오는데, 이 표의 조치를 먼저 끝낸 뒤 다시 돌리면 높은 위험(HRI) 항목의 절반 이상이 사라지는 것이 보통입니다.

정리

AWS Well-Architected 프레임워크는 운영 우수성, 보안, 안정성, 성능 효율성, 비용 최적화, 지속 가능성의 여섯 원칙으로 클라우드 구성을 점검하는 기준입니다. 작은 서비스라면 알람·MFA·멀티 AZ와 백업·인스턴스 유형·예산 알림·데이터 정리처럼 원칙마다 한두 가지부터 확인하고, 콘솔의 Well-Architected Tool로 위험 항목을 찾아 마일스톤으로 개선 과정을 남기면 됩니다.

참고 자료: AWS Well-Architected 프레임워크, AWS Well-Architected Tool 사용 설명서

※ 본 글은 2026년 10월 기준 AWS Well-Architected 프레임워크 문서와 Well-Architected Tool 사용 설명서를 참고해 작성했으며, 질문 항목과 기능은 변경될 수 있으니 최신 내용은 AWS 공식 문서에서 확인해 주세요.