AWS Well-Architected - 2017 예제자료
- 1 AWS
- 1.1 Security
- 1.2 reliability
- 1.3 performance efficiency
- 1.4 cost optimization
- 1.5 operational excellence
- 2 GCP, AWS
AWS
AWS Well-Architected 자료가 업데이트가 많이 된 상태임. 일단 참고로 올림
최신자료
https://docs.aws.amazon.com/ko_kr/wellarchitected/latest/framework/welcome.html
https://aws.amazon.com/ko/blogs/korea/aws-well-architected-framework-updated-white-papers-tools-and-best-practices/ 한국어자료 링크가 여기 있음
Security
정의 | 항목 | 모범사례 | 현황 | 필요사항 |
ID 및 액세스 관리 | AWS 루트 계정 자격 증명에 대한 액세스 및 사용 | MFA를 사용하고 루트를 및 최소한으로 사용 |
|
|
|
| 루트를 사용하지 않음 |
|
|
| AWS Management Console 및 API에 대한 액세스 제어 |
|
| Root-IAM Master-(IAM Maneger)-AWS Account로 분리 |
|
| 사용자 그룹 이용 |
|
|
|
| 직원 수명 주기 관리 |
| 수동관리 : terraform, AD연동 못할 경우 주기적으로 AD의 계정 정보와 비교 필요 |
|
| 최소권한 |
|
|
| AWS 리소스에 대한 자동 액세스 제한 | 자동 액세스에 사용되는 정적 자격 증명 : 자격 증명을 안전하게 저장 |
| hashicorp vault? |
|
| 자동 액세스를 위한 동적 인증 : 인스턴스 프로필 또는 Amazon STS를 사용 |
| EC2 IAM Role 사용 |
탐지 제어 | 로그 캡처 및 분석 | 활동을 적절히 모니터링 : Amazon CloudWatch 로그, 이벤트, VPC 흐름 로그, ELB 로그, S3 버킷 로그 등 |
| Security monkey? |
|
| AWS Cloud Trail을 활성화 |
|
|
|
| 운영 체제 또는 애플리케이션 로그를 모니터링 |
| - |
인프라 보호 |
|
|
| VPC 설계와도 연관있는 부분임 |
| 네트워크 및 호스트 수준 경계 보호 | VPC 내에서 네트워크 트래픽 제어 : 방화벽, 보안 그룹, NACLS, 배스천 호스트 등을 사용 |
| 배스천 호스트 구성 |
|
| 경계에서 네트워크 트래픽 제어 : AWS WAF, 호스트 기반 방화벽, 보안 그룹, NACLS 등을 사용 |
| iptables 이용? SG 이용? |
| AWS 서비스 수준 보안 기능 활용 | 적절할 경우 추가 기능을 사용 |
|
|
| Amazon EC2 인스턴스에서 운영 체제의 무결성 | 파일 무결성 |
|
|
|
| EC2 침입 탐지 |
|
|
|
| AWS Marketplace 또는 파트너 솔루션 |
|
|
|
| 구성 관리 도구 |
|
|
데이터 보호 | 데이터를 어떻게 분류 | 데이터 분류 스키마를 사용 |
|
|
| 저장된 데이터를 어떤 방식으로 암호화하고 보호합니까? | 필요하지 않음 : 저장 데이터 암호화가 필요하지 않습니다. |
|
|
| 키를 어떻게 관리하고 있습니까? | AWS CloudHSM |
| AWS KMS 사용 검토? |
| 전송 중인 데이터를 어떤 방식으로 암호화하고 보호 | 통신 암호화 : 통신에 TLS 등을 적절히 사용 |
|
|
인시던트 대응 | 적절한 인시던트 대응을 보장하기 위해 어떻게 합니까? | 액세스 사전 프로비저닝 |
| 인터넷과 연결되지 않는 격리된 AWS 환경 구성 필요 |
reliability
정의 | 항목 | 모범사례 | 현황 | 필요사항 |
기반 | 계정에 대한 AWS 서비스 한도를 어떻게 관리 | 제한도 모니터링 및 관리 |
| Trust Advisor 주기적으로 확인 |
|
| 자동 모니터링 설정 |
|
|
|
| 고정된 서비스 제한 숙지 |
|
|
|
| 서비스 제한과 최대 사용량 사이에 장애 조치를 수용할 정도로 충분한 갭이 있는지 확인 |
|
|
|
| 모든 관련 계정 및 리전에서 서비스 제한을 고려 |
| VPC 설계시 고려 |
| AWS에서 네트워크 토폴로지 | AWS 와 온프레미스 환경 간 고가용성 연결 |
| IDC-AWS VPN 이중화 |
|
| 워크로드 사용자를 위한 고가용성 네트워크 연결 |
|
|
|
| 비중첩 프라이빗 IP 주소 범위 |
| VPC 설계시 반영 |
|
| IP 서브넷 할당 |
| VPC 설계시 반영 |
변경관리 | 시스템의 수요 변화 | Auto Scaling |
| 인프라 서비스도 탄력성을 갖출 수 있도록 변경해야 함 |
|
| 부하 테스트 |
|
|
| AWS 리소스 모니터링 | 모니터링 |
| CloudWatch 활용? |
|
| 알림 |
|
|
|
| 자동 응답 |
| ?? |
| 변경 관리 | 자동화 |
| Terraform 등 코드로 관리 |
장애 관리 | 데이터 백업 | 자동 백업 |
|
|
|
| 정기적인 복구 테스트 |
| 없으면 필요함. |
| 구성 요소 장애 시 시스템 대처 | 다중 AZ/리전 |
| 구성시 사용하면 됨 |
|
| 소결합 종속성 |
| 서비스 설계시부터 반영 |
|
| 단계적 기능 축소 : 특정 구성 요소의 종속성이 정상 상태가 아닐 경우 구성 요소 자체가 이상으로 보고되지 않습니다. 해당 구성 요소는 계속해서 제한된 방식으로 요청을 처리할 수 있습니다. → ??? |
|
|
|
| 자동 복구 |
|
|
| 복원성 테스트 | 지침서 |
| 실전 연습 |
| 재해 복구 | 목표 정의 |
| ? |
performance efficiency
정의 | 항목 | 모범사례 | 현황 | 필요사항 |
선택 | 최상의 성능을 제공하는 아키텍처를 어떻게 선택합니까? | 벤치마킹 |
|
|
|
| 부하 테스트 |
|
|
| 컴퓨팅 솔루션은 어떻게 선택합니까? | 옵션 고려 |
| 각 zone(dev/test/prod)별 서비스 타입별 권장 ec2 type 필요. |
| 스토리지 솔루션은 어떻게 선택합니까? | 특성 고려 |
|
|
| 데이터베이스 솔루션은 어떻게 선택합니까? | 특성 고려 |
|
|
| 네트워크 솔루션은 어떻게 선택합니까? | 위치 고려 |
|
|
복습 | 새로운 리소스 유형 및 기능을 도입할 때 가장 적절한 리소스 유형을 선택하기 위해 어떻게 합니까? | 새로운 리소스의 유형 및 크기를 검토하는 프로세스를 마련 |
|
|
(성능)모니터링 | 리소스를 시작한 후 정상적으로 수행되고 있는지 확인하기 위해 리소스를 어떻게 모니터링합니까? | 모니터링 |
| AWS 관리 서비스의 경우에도 성능 모니터링 필요함 |
|
| 경보 기반 알림 |
|
|
|
| 트리거 기반 작업 |
|
|
트레이드오프 | 성능을 개선하기 위해 트레이드오프를 어떻게 사용합니까? | 서비스 고려 |
| - |
cost optimization
정의 | 항목 | 모범사례 | 현황 | 필요사항 |
비용 효율적인 리소스 | 솔루션을 위해 AWS 서비스를 선택할 때 비용을 고려하고 있습니까? | 비용 절감을 위한 서비스 선택 |
| AWS Trusted Advisor로 주기적 확인 |
|
| 라이선스 비용에 대해 최적화 |
|
|
|
| 서버리스 및 컨테이너 기반 접근 방식을 사용하여 최적화 |
| AWS Lambda 필요한 곳 사용 |
|
| 적절한 스토리지 솔루션을 사용하여 최적화 |
|
|
|
| 적절한 데이터베이스를 사용하여 최적화 |
|
|
|
| 다른 애플리케이션 수준 서비스를 사용하여 최적화 |
|
|
| 비용 목표에 부합하는 리소스 규모를 선택했습니까? | 측정치 기반 리소스 크기 결정 |
|
|
| 비용 목표에 부합하는 적절한 요금 모델을 선택했습니까? | 예약 용량 및 약정 거래 |
|
|
|
| 스팟 |
| - |
|
| 리전 비용 고려 |
| - |
공급과 수요의 균형 | 필요한 용량에 크게 초과되지 않도록 용량을 맞추기 위해 어떻게 하고 있습니까? | 수요 기반 접근 (Auto Scaling) |
|
|
|
| 버퍼 기반 접근 (SQS 등) |
| 서비스 개발시 고려를 해야 함 |
|
| 시간 기반 접근 |
| 퇴근시간, 주말동안 개발 및 테스트 인스턴스 끄기 등 |
비용 인지 | 아키텍처를 설계할 때 데이터 전송 요금을 고려합니까 | 최적화 |
| - |
| 사용량과 지출을 어떻게 모니터링하고 있습니까? | 모든 리소스에 태그 지정 |
| CMDB 연동 |
|
| 결제 및 비용 관리 도구 활용 |
| 비용할당태그 |
|
| 알림 |
| AWS Trusted Advisor로 주기적 확인 (불필요한 리소스 확인 가능) |
|
| 자금 중심 과금(Charge Back)/확인(Show Back) 방식 ?? |
| 각 조직별 비용 관리하도록 해야 함. |
| 더 이상 필요하지 않은 리소스를 폐기하거나 일시적으로 필요하지 않은 리소스를 중지합니까? | 자동화 |
| AWS Trusted Advisor로 주기적 확인 |
| AWS 사용량을 관리하기 위한 액세스 제어 및 절차를 마련해 두었습니까? | 그룹 및 역할 설정(예: Dev/Test/Prod) |
| Dev/Test는 24시간 돌아갈 필요가 없음. |
|
| 프로젝트 수명 주기 추적 |
|
|
시간에 따른 최적화 | 새로운 서비스의 활용을 어떻게 관리하고 고려합니까? | 비용 최적화 기능 설정 |
|
|
operational excellence
정의 | 항목 | 모범사례 | 현황 | 필요사항 |
준비 | 클라우드 운영을 위해 어떤 모범 사례를 사용하고 있습니까? | 운영 체크리스트 |
| AWS Well architecture |
|
| 사전 예방적 계획 |
|
|
|
| 보안 체크리스트 |
| 향후 검토 필요 |
| 워크로드에 대한 구성 관리는 어떻게 하고 있습니까? | 리소스 추적 |
| Tag 강제화 |
|
| 설명서 : 아키텍처를 문서화 |
| Terraform 등 코드로 관리 |
|
| 운영 관련 교훈 축적 |
| - |
|
| 변경 불가능한 인프라 |
| 서비스에 docker 사용? |
|
| 자동 변경 절차 |
| Terraform 등 코드로 관리 |
|
| 구성 관리 데이터베이스(CMDB) |
| CMDB 구성 |
운영 | 워크로드를 어떻게 변경의 영향을 최소화하면서 진화시키고 있습니까? | 배포 파이프라인 : CI/CD 파이프라인 |
| 점차 도입 |
|
| 릴리스 관리 프로세스 |
|
|
|
| 소규모 증분식 변경 |
|
|
|
| 취소 가능 변경 |
|
|
|
| 위험 완화 전략 : 블루/그린, Canary 및 A/B 테스팅 |
|
|
| 워크로드가 예상대로 운영되는지 확인하기 위해 어떻게 모니터링합니까? | 모니터링 |
|
|
|
| 로그 집계 |
|
|
|
| 경보 기반 알림 |
|
|
|
| 트리거 기반 작업 |
|
|
응답 | 예기치 못한 운영 이벤트에는 어떻게 대응합니까? | 지침서 |
|
|
| 예기치 못한 운영 이벤트에 대응할 때 에스컬레이션을 어떻게 관리합니까? | 적절히 문서화 및 프로비저닝 |
|
|
GCP, AWS
Google Cloud Architecture Framework
https://cloud.google.com/architecture/framework
Azure Well-Architected Framework
Azure Well-Architected Framework - Microsoft Azure Well-Architected Framework