[AWS] AWS Well-Architected Framework

AWS 아키텍처를 설계하는 방식은 정말 다양하다고 생각한다. 어떤 회사는 가용성을 가장 중요시 여길 수 있고, 다른 회사는 비용 효율성이 가장 중요할 수 있다. 물론 기본적으로 다 중요한 요소들이지만, 이러한 요소 중에서도 특히 중요하게 생각하는 부분이 있다는 것이다. 이렇듯 각 회사에서 구성되어 있는 아키텍처는 각자의 상황에 맞게 다양한 모습을 띄고 있으며, 어떤 것이 정확한 정답이라고 얘기할 수도 없는 것 같다.

 

하지만 정답에 가까운 아키텍처는 존재한다고 생각하며, 이 정답에 최대한 가까워지기 위해서 AWS에서는 자사의 수많은 고객사들을 통해 쌓아온 데이터들을 활용하여 AWS Well-Architected Framework라는 개념을 제시하고 있다.

 

물론 학부 시절 AWS SAA 자격증을 취득하면서 공부해본 적은 있지만, 현재 시점에서 다시 한번 정리해보고 싶은 마음이 있기에 다시 정리해보겠다. 오늘 정리한 내용을 앞으로 설계할 AWS 아키텍처의 기준점으로 삼으면 될 것 같다. 

 

AWS Well-Architected Framework이란 무엇인지 먼저 알아보자.  

AWS Well-Architected Framework?

출처: https://pcg.io/aws/aws-well-architected-review/

 

AWS Well‑Architected 프레임워크는 AWS에서 안전하고 신뢰성 있으며 효율적이고 경제적이면서 지속 가능한 시스템을 구축하도록 돕는 모범 사례 질문 세트다. 이를 통해 아키텍처를 측정하고 개선할 지점을 파악할 수 있으며, AWS 솔루션 아키텍트(SAA)의 경험을 바탕으로 꾸준한 업데이트가 이루어지고 있다.

 

AWS Well-Architected Framework는 다음 6가지 원칙을 기반으로 한다.

• 운영 우수성(Operation Ecellence)
  • 시스템을 잘 운영하고 개선하는 능력이다.
  • 자동화로 운영하고, 문제가 생겨도 빠르게 파악해서 개선하는 능력을 갖추는 것.
  • 시스템 변경은 코드로 관리되는가? 문제가 발생했을 때 자동 알림이 오는가?
  • ex. 배포 자동화(CI/CD)를 통해 서버를 수동으로 건드리지 않고, 로그를 CloudWatch로 수집해 장애 감지를 자동화하는 구조.
• 보안(Security)
  • 클라우드 기술을 활용해서 데이터, 시스템 및 자산을 보호하고 보안을 향상
  • 권한 최소화, 암호화, 감시 자동화, 사고 대응 훈련 등을 포함
  • IAM 권한이 최소화돼 있는가? S3 데이터는 암호화돼 있는가?
  • ex. 모든 리소스는 IAM Role을 통해 접근 제어하고, CloudTrail로 누가 뭘 했는지 추적 가능하도록 설정. S3, RDS는 암호화 적용.
• 신뢰성(Reliability)
  • 워크로드의 기능이 필요한 때에 기능을 정확하고 일관되게 수행할 수 있는 역량
  • 장애가 발생해도 영향을 최소화하고, 빠르게 복구할 수 있는 구조.
  • 장애 발생 시 자동 복구되는가? 리소스 간 의존성이 분리돼 있는가?
  • ex. EC2 Auto Scaling Group으로 인스턴스가 죽으면 자동으로 재생성되게 설정. DB는 멀티 AZ로 구성해 장애 시 자동 페일오버.
• 성능 효율성(Performance efficiency)
  • 컴퓨팅 리소스를 시스템 요구 사항에 맞게 효율적으로 사용하고, 수요 변화 및 기술 트렌드에 맞춰 효율성을 유지하는 능력
  • 상황에 따라 빠르게 확장 또는 축소하고, 최신 기술을 적극적으로 활용함.
  • 오버 프로비저닝은 없는가? 서버리스 등 최신 기술을 활용하고 있는가?
  • ex. 갑자기 트래픽이 몰릴 수 있는 API는 Lambda로 구성하고, DynamoDB의 온디맨드 모드를 활용해 유연하게 확장함.
• 비용 최적화(Cost Optimization)
  • 가장 낮은 가격으로 비즈니스 가치를 제공하도록 시스템을 실행하는 능력
  • 사용량에 따라 지불하고, 안 쓰는 리소스는 정리함.
  • 미사용 리소스가 방치돼 있지 않은가? 예약 인스턴스를 활용하고 있는가?
  • 테스트용 EC2 인스턴스는 스케줄러를 걸어서 야간에는 자동으로 꺼지게 하고, RDS도 필요 없는 백업은 정리.
• 지속 가능성(Sustainability)
  • 프로비저닝된 리소스이 이점을 극대화 하고, 필요한 총 리소스를 최소화하여 워크로드의 모든 구성 요소에서 에너지 소비를 줄이고 효율성을 높임으로써 지속 가능성에 미치는 영향을 지속적으로 개선할 수 있다.
  • 탄소 배출을 줄이고, 리소스 낭비를 최소화함.
  • 리소스 사용량은 최소화되어 있는가? 고효율 인프라를 사용하고 있는가?
  • ex. GPU 같은 고성능 인스턴스는 꼭 필요한 경우에만 사용하고, 오래된 데이터를 Glacier로 이전해 저장공간 최적화.

 

AWS Well-Architected Framework에서 사용되는 주요 단어와 의미는 다음과 같다.

 

• 구성 요소 (Component)
  • 시스템 요구사항을 충족하는 코드, 설정값, AWS 리소스의 단위이다.
  • 일반적으로 기술 소유권의 단위이며, 서로 독립적이다.
  • ex. EC2 웹 서버, Lambda 함수, RDS DB, S3 버킷 등
• 워크로드 (Workload)
  • 비즈니스 가치를 제공하는 구성 요소들의 집합이다.
  • 기술 팀과 비즈니스 팀이 공통으로 인식하는 시스템 단위다.
  • ex. 쇼핑몰 백엔드, AI 추천 시스템, 사내 메일 서비스
• 아키텍처 (Architecture)
  • 워크로드 내의 구성 요소들이 서로 연결되고 동작하는 방식이다.
  • 데이터 흐름과 컴포넌트 상호작용을 시각화한 구조다.
  • ex. 사용자 → API Gateway → Lambda → RDS로 연결되는 구조 다이어그램
• 마일스톤 (Milestone)
  • 제품 수명 주기에서 아키텍처가 의미 있게 변화하는 시점이다.
  • 설계 → 개발 → 테스트 → 운영 단계를 통해 점진적 개선이 이뤄진다.
  • ex. 베타 릴리스 출시, 구조 리팩토링, 장애 이후 설계 변경 등
• 기술 포트폴리오 (Technology Portfolio)
  • 조직 전체가 운영 중인 모든 워크로드의 집합이다.
  • 기업의 기술 기반을 구성하며 전략적으로 관리된다.
  • ex. ERP, 메신저 시스템, 고객 포털, 내부 관리 시스템 등
• 작업 수준 (Level of Effort)
  • 각 작업이 완료되기까지 필요한 시간, 활동, 복잡도 수준이다.
  • 팀 역량과 워크로드 복잡도에 따라 유연하게 분류됨

중간	수일~수주 소요, 적당한 규모의 변경	ex. CI/CD 구축, 로깅 구조 변경
낮음	수시간~수일 소요, 비교적 간단한 변경	ex. IAM 권한 조정, 로그 포맷 수정
높음	수주~수개월 소요, 여러 작업과 릴리스 포함	ex. DB 마이그레이션, 전체 API 재설계

 

AWS Well‑Architected 프레임워크를 통한 AWS 아키텍처 체크 사항

그러면 만약 내가 나중에 만든 AWS 아키텍처를 위에서 배운 AWS Well-Architected 프레임워크 내용을 통해 체크를 해보려면, 어떤 사항을 체크해야 할 지를 리스트업 해보자. 그리고 해당 체크 리스트에 대한 예시 답변도 작성해보자.

 

1. 운영 우수성 (Operational Excellence)

• 배포는 자동화(CI/CD)되어 있는가? 수동 변경이 없는가?
  • -> Gitlab과 ArgoCD를 통한 배포 자동화 구성
• 인프라 변경은 코드(IaC, ex. Terraform, CloudFormation)로 관리되고 있는가?
  • -> Terraform로 VPC, Subnet, EC2, RDS 등의 인프라 구성
• 시스템 동작을 모니터링하고, 문제가 생겼을 때 경고가 발생하는가?
  
  • -> CloudWatch Metric Alarm + SNS 연동으로 Slack 및 메일 알림 전송됨.
• 장애나 에러 발생 시 복구 프로세스가 문서화되고 테스트되어 있는가?
  • -> SSM 문서 기반 자동 복구 플레이북이 있으며, 분기별로 DR 시나리오 테스트 수행함.
• 개선 사항을 반영하기 위한 운영 회고록이나 로그 분석 체계가 있는가?
  • -> 장애 발생 시 post-mortem 작성 및 운영 노션에 히스토리 관리, 회고 미팅 후 개선 작업 반영.

 

2. 보안 (Security)

• 최소 권한의 IAM Role/Policy를 적용하고 있는가?
  • -> 서비스별 IAM Role을 별도로 생성하여 최소 권한 원칙에 따라 권한 분리 적용.
• 민감한 데이터는 저장 및 전송 시 암호화되어 있는가? (ex. S3, RDS, EBS 암호화)
  • -> S3는 기본 SSE-S3 암호화 설정, RDS는 KMS 기반 암호화, SSL/TLS 통신 강제 적용.
• AWS CloudTrail, GuardDuty, Config 등 보안 감시 기능이 활성화되어 있는가?
  • -> 조직 전체에 CloudTrail이 활성화되어 있고 GuardDuty는 모든 계정에 기본 설정됨. Config도 Rule로 리소스 상태 관리 중.
• 인증/인가(Authorization) 체계가 명확하게 설계되어 있는가?
  • -> 외부 사용자는 Cognito + OAuth2 기반, 내부는 SSO 연동 IAM Identity Center 사용. API 단에서는 JWT 기반 Role 검증 수행.
• 키 관리(KMS 등)는 중앙 집중화되어 있는가?
  • -> 서비스별 Customer Managed Key(CMK)를 생성하여 KMS로 암호화 통합 관리 중.

 

3. 신뢰성 (Reliability)

• 리소스가 자동 복구 가능한 구조인가? (ex. Auto Scaling, Multi-AZ)
  • -> EC2는 Auto Scaling Group으로 구성되어 있고, RDS는 Multi-AZ 설정으로 자동 failover 가능.
• 하나의 구성 요소가 실패해도 전체 시스템이 중단되지 않는가?
  • -> 대부분 구성 요소가 이중화되어 있고, ALB 및 Route53 헬스체크를 통해 장애 전환이 가능하도록 구성.
• 장애를 유발할 수 있는 단일 실패 지점(SPOF)이 제거되었는가?
  • -> Bastion 서버도 2AZ 구성, S3 기반 정적 자산은 CloudFront로 멀티 엣지 전송 구성함.
• 장애 상황을 시뮬레이션하고 테스트한 이력이 있는가?
  • -> DR 테스트, AZ failover 테스트를 연 1회 이상 수행하고 로그 분석을 통해 개선 진행함.
• DNS, 네트워크, API 등 외부 의존성이 높은 요소에 대한 예외처리가 있는가?
  • -> API Gateway 연결 실패 시 Lambda 내 재시도 및 fallback 로직 구성, 네트워크 장애 대비한 timeout 설정 존재.

 

4. 성능 효율성 (Performance Efficiency)

• 시스템은 수요에 따라 자동 확장/축소 가능한 구조인가? (ex. Lambda, Fargate, ASG)
  • -> EC2는 Auto Scaling 구성, ECS는 CPU 기반 스케일 설정. Lambda 및 SQS는 자동 확장.
• 최신 인스턴스 타입, 스토리지, 서버리스 기술 등을 도입했는가?
  • -> EC2는 t4g 및 c7g 기반으로 전환 진행 중이며, 신규 서비스는 대부분 Lambda로 구현함.
• 사용량이 많은 서비스는 캐싱(DynamoDB DAX, ElastiCache 등)을 적용했는가?
  • -> 자주 조회되는 데이터는 ElastiCache(Redis)로 캐싱, 정적 콘텐츠는 CloudFront로 캐싱 구성.
• 정기적으로 성능을 측정하고 리소스 크기를 조정하고 있는가?
  • -> CloudWatch 및 X-Ray로 지연 시간 모니터링하며, 한 달 주기로 리소스 리사이징 작업 수행.

 

5. 비용 최적화 (Cost Optimization)

• 미사용 리소스나 과잉 Provisioning은 없는가?
  • -> AWS Trusted Advisor와 Cost Explorer를 통해 매주 비용 점검, 미사용 리소스는 Tagging 후 자동 종
• EC2, RDS 등은 예약 인스턴스 또는 Savings Plans를 활용하고 있는가?
  • -> EC2, RDS, OpenSearch 등에 대해 1~3년 예약 인스턴스 적용, Lambda/Graviton 전환으로 Savings Plans 도입.
• 백업/로그/데이터 저장 비용을 고려해 적절한 스토리지 클래스를 선택했는가?
  • -> 오래된 로그나 백업은 30일 후 S3 Infrequent Access, 90일 후 Glacier로 이전하도록 정책 설정.
• 스케줄링을 통해 불필요한 리소스를 자동으로 정지시키고 있는가?
  • -> 개발/테스트용 리소스는 업무 외 시간대 자동 종료되도록 Instance Scheduler Lambda 사용 중.

 

6. 지속 가능성 (Sustainability)

• 리소스를 과도하게 사용하거나 낭비하고 있지는 않은가?
  • -> 실사용량 대비 적정 사이징 적용. 대규모 EC2는 spot이나 자동 scaling을 통해 효율화.
• 서버리스, 관리형 서비스 등 에너지 효율이 높은 기술을 도입했는가?
  • -> 서버리스(Lambda, Fargate, S3 static hosting) 우선 채택, EC2는 Graviton 기반 전환 중.
• 오래된 데이터, 리소스를 정리하고 수명 주기 정책을 설정했는가? (ex. S3 Lifecycle)
  • -> S3는 객체 수명 주기 정책 적용 중, CloudWatch Log Group도 자동 만료 설정 운영.

 

Reference

• https://docs.aws.amazon.com/ko_kr/wellarchitected/latest/framework/definitions.html

정의 - AWS Well-Architected 프레임워크