참조 : https://aws.amazon.com/ko/getting-started/fundamentals-core-concepts/?e=gs2020&p=gsrc
AWS Well-Architected 5대원칙
1. 보안
2. 성능 효율성
3. 안정성
4. 운영 우수성
5. 비용 최적화
1. 보안
제로 트러스트 모델: 모든 시스템 수준에 보안 조치를 적용하는 것을 의미
1) Identity and Access Management(IAM)
: IAM은 시스템에서 ID 및 액세스를 추적하는 서비스입니다. IAM은 IAM 서비스라는 적절한 이름으로 AWS에서 관리됩니다.
AM 정책의 세 가지 기본 구성 요소
- 주체는 권한이 제공되는 대상을 지정합니다.
- 작업은 수행되는 것을 지정합니다.
- 리소스는 액세스되는 속성을 지정합니다.
IAM에 제로 트러스트 모델을 적용하는 것은 최소 권한 원칙을 사용하는 것을 의미합니다. 즉, 모든 에이전트에게는 기능을 수행하기 위해 필요한 최소한의 권한이 부여되어야 합니다.
주체와 연관된 정책을 ID 기반 정책이라고 합니다. 리소스와 연관된 정책을 리소스 기반 정책이라고 합니다.
※ 요점
- IAM 정책은 AWS 내에서 엔터티의 액세스 경계를 명시합니다.
- IAM 정책은 주체, 작업 및 리소스로 구성됩니다.
- IAM 정책을 사용하여 주체에 최소 권한을 적용할 수 있습니다.
- IAM에는 ID 기반 및 리소스 기반 등 여러 정책 유형이 있습니다.
- IAM은 지정된 리스소에 적용할 수 있는 모든 정책 유형에 대한 평가를 기반으로 액세스를 평가합니다.
2) 네트워크 보안
: 네트워크 보안에는 네트워크 및 네트워크에 액세스할 수 있는 리소스의 액세스 및 사용성을 보호하는 시스템, 구성 또는 프로세스가 포함됩니다.
네트워크 보안에 대한 제로 트러스트 접근법에는 네트워크의 모든 레이어(가장 외부 레이어만이 아닌)에 보안 제어를 적용하는 심층적 방어 접근법이 포함됩니다.
※ 요점
- 네트워크 보안에는 네트워크 및 네트워크에 액세스할 수 있는 리소스의 액세스 및 사용성을 보호하도록 설계된 메커니즘이 포함됩니다.
- 네트워크 보안에 대한 제로 트러스트 접근법에는 네트워크의 모든 레이어에 심층적인 방어를 구축하는 것이 포함됩니다.
- VPC 및 WAF를 사용하면 네트워크 수준에 보안 조치를 적용할 수 있습니다.
- 보안 그룹을 사용하면 리소스 수준에 보안 조치를 적용할 수 있습니다.
3) 데이터 암호화
: 데이터 암호화는 데이터의 암호를 해독하기 위해 필요한 키가 없는 제삼자가 이해할 수 없는 방식으로 정보를 암호화하는 프로세스입니다.
데이터에 제로 트러스트 모델을 적용하는 것은 모든 곳에 있는 전송 중 및 저장 중 데이터 모두를 암호화하는 것입니다.
※ 요점
- 암호화는 올바른 키를 가지고 있는 당사자만 정보의 암호를 해독할 수 있는 방식으로 정보를 암호화하는 프로세스입니다.
- 전송 중 및 저장 중 데이터를 암호화하여 데이터의 보안을 유지할 수 있습니다.
- AWS의 모든 스토리지 및 데이터베이스 서비스는 전송 중 및 저장 중 암호화를 제공합니다.
- ALB 등 AWS 네트워킹 서비스를 사용하면 자체 서비스에 전송 중 암호화를 적용할 수 있습니다.
- CMK를 사용하면 감사 추적 생성, 자체 사용자 지정 키 사용 및 자동 키 회전과 같은 고급 기능을 활용할 수 있습니다.
2. 효율성
성능 효율성 원칙은 클라우드에서 서비스를 효율적이고 확장 가능하도록 실행하는 방법에 중점을 줍니다. 클라우드는 모든 규모의 트래픽을 처리할 수 있는 수단을 제공하는 반면, 이를 위해서는 확장을 염두하고 서비스를 선택 및 구성해야 합니다.
성능 효율성에서 중점을 두는 두가지 개념
- 셀렉트
- 확장
1) 셀렉트
AWS에서의 셀렉트는 워크로드에 가장 적합한 서비스를 선택할 수 있는 기능입니다.
- 컴퓨팅은 데이터를 처리하는 서비스(예: 가상 머신)입니다.
- 스토리지는 데이터를 정적으로 저장하는 서비스(예: 객체 저장)입니다.
- 데이터베이스는 데이터를 구조화하여 저장하는 서비스(예: 관계형 데이터베이스)입니다.
- 네트워크는 데이터의 이동 방법과 관련한 서비스(예: 콘텐츠 전송 네트워크)입니다.
위의 범주를 선택할 때 고려해야하는 사항
- 서비스 유형
- 관리 수준
- 구성
※ 요점
- AWS는 원하는 결과를 달성하기 위한 다양한 서비스와 방식을 제공합니다.
- AWS에서 워크로드를 구현하기 위해서는 컴퓨팅, 스토리지, 데이터베이스 및 네트워크 범주에서 서비스를 선택해야 합니다.
- 각 범주 내에서는 사용 사례에 따라 적합한 서비스 유형을 선택할 수 있습니다.
- 각 유형 내에서는 원하는 관리 수준에 따라 특정 서비스를 선택할 수 있습니다.
- 각 서비스 내에서는 달성하려는 특정 성능 특성에 따라 특정 구성을 선택할 수 있습니다.
2) 확장
AWS의 두 가지 기본 확장 방법
- 수직 확장 : 기본 컴퓨팅을 더 큰 규모의 인스턴스 유형으로 업그레이드하는 것이 포함
- 수평 확장 : 기본 인스턴스의 수 증가가 포함
※ 요점
- 수직 확장은 운영이 단순하지만 가용성 위험이 있으며 확장성이 낮습니다.
- 수평 확장은 오버헤드가 증가하지만 복원력과 확장성이 크게 향상됩니다.
3. 안정성
안정성 원칙은 서비스 및 인프라 중단 시 복원할 수 있는 서비스의 구축 방법에 중점을 둡니다.
클라우드에서의 안정성을 고려할 때는 파급 범위를 고려하는 것이 좋습니다. 파급 범위는 시스템 장애 발생 시 지속될 수 있는 최대 영향으로 생각할 수 있습니다. 신뢰할 수 있는 서비스를 구축하려면 개별 구성 요소의 파급 범위를 최소화해야 합니다.
파급 범위의 관점에서 고려할 때, 장애 문제는 가능성의 문제가 아니라 시점의 문제입니다. 장애 발생 시 이를 처리하려면 파급 범위를 제한하기 위해 다음과 같은 기법을 사용할 수 있습니다.
- 장애 격리
- 한도
1) 장애격리
AWS에서 제공하는 세 가지 수준의 장애 격리 영역
- 리소스 및 요청
- 가용 영역
- 리전
① 리소스 및 요청
AWS 서비스는 리소스 ID와 같이 지정된 차원의 모든 리소스 및 요청을 분할합니다.
② 가용 영역
장애 격리는 여러 AZ에 서비스의 중복 인스턴스를 배포하여 AZ 수준에서 수행됩니다. 이를 통해 한 AZ에서 전력 문제가 발생해도 다른 AZ의 트래픽에는 영향을 주지 않습니다.
그리고 대기 시간과 관련하여 AZ는 지리적으로 분리되어 있지만 AZ 사이의 네트워크 대기 시간이 최소화되도록 서로 충분히 가까이에 위치합니다.
③ 리전
AWS 리전은 궁극적인 격리를 제공합니다. 각 리전은 완전한 자율 데이터 센터이며 두 개 이상의 AZ로 구성됩니다. 장애 격리는 다른 AWS 리전에 서비스의 중복 사본을 배포하여 리전 수준에서 수행됩니다(이 방식으로 AWS가 자체 서비스를 수행).
※ 요점
- 기본 격리 영역을 사용하면 서비스 또는 인프라 중단의 파급 범위를 제한할 수 있습니다.
- 리소스 및 요청 수준에서 장애를 격리하려면 모든 AWS 서비스의 설계에서 구현되어야 하며, 이를 위해서는 사용자의 추가 작업이 필요합니다.
- AZ 수준에서의 장애 격리는 여러 AZ에 서비스를 배포하여 수행될 수 있으며, 이는 최소한의 대기 시간 영향으로 수행될 수 있습니다.
- 리전 수준에서의 장애 격리는 여러 리전에 서비스를 배포하여 수행될 수 있으며, 이를 위해서는 상당한 운영 오버헤드가 필요합니다.
2) 한도
한도는 과도한 부하로부터 서비스를 보호하기 위해 적용될 수 있는 제약입니다. 한도는 외부(예:DDoS 공격) 및 내부(예: 소프트웨어의 잘못된 구성) 문제로 인한 파급 범위를 제한하기 위한 효과적인 수단입니다.
AWS 서비스에는 리전 및 계정을 기준으로 서비스별 두가지 유형의 한도가 있습니다.
- AWS에서 증가를 요청하여 증가할 수 있는 소프트 한도
- 증가할 수 없는 하드 한도
※ 요점
- 한도는 과도한 부하로부터 서비스를 보호하기 위해 적용될 수 있는 제약입니다.
- AWS 서비스 한도는 Service Quota 서비스를 사용하여 추적 및 관리가 가능합니다.
- 증가가 가능한 소프트 한도와 증가할 수 없는 하드 한도가 없습니다.
- 사용 중인 서비스의 한도를 모니터링하고 그에 따라 플랜의 안도를 늘려 서비스 중단을 방지할 수 있습니다.
4. 운영 우수성
운영 우수성 원칙은 시스템 운영, 향상된 절차 개발 및 통찰력 확보 역량을 지속적으로 향상할 수 있는 방법에 집중합니다.
클라우드에서의 운영 우수성을 고려할 때는 자동화의 측면에서 생각하는 것이 유용합니다.
인적 오류는 결함 및 운영 문제의 주된 원인입니다. 운영이 자동화될 수록 인적 오류가 발생할 가능성이 줄어듭니다.
자동화를 통해 오류가 방지될 뿐만 아니라 내부 프로세스가 지속적으로 향상될 수도 있습니다. 자동화는 전체 조직에서 적용될 수 있는 반복 가능한 모범 사례 집합을 향상합니다.
운영우수성에 중점을 두어야 할 두 가지 개념
- 코드형 인프라스트럭처
- 관찰 기능
1) 코드형 인프라스트럭처
Infrastructure as code(IaC)는 시스템에서 읽을 수 있는 구성 파일을 통해 인프라를 관리하는 프로세스입니다. IaC는 인프라를 자동화할 수 있는 토대입니다.
사용자는 서비스를 수동으로 프로비저닝하는 대신, 원하는 리소스를 설명하는 템플릿을 생성할 수 있습니다. 그러면 IaC 플랫폼이 사용자를 대신하여 리소르의 프로비저닝 및 구성을 처리합니다.
※ 요점
- IaC는 시스템이 읽을 수 있는 구성 파일을 통해 인프라를 관리하는 프로세스입니다.
- IaC는 인프라를 프로비저닝하기 위한 선언적이고 자동화된 방식입니다.
- 코드와 마찬가지로 동일한 도구와 프로세스를 인프라에 적용할 수 있습니다.
- CloudFormation 및 CDK와 같은 서비스를 사용하여 AWS에서 IaC를 구현할 수 있습니다.
2) 관찰 기능
관찰 기능은 시스템의 내부 상태를 측정하는 프로세스입니다. 이러한 측정은 일반적으로 원하는 최종 상태로 최적화하기 위해 수행됩니다.
관찰기능을 구현하기 위한 단계 : ① 컬렉션 > ② 분석 > ③ 작업
① 컬렉션
컬렉션은 시스템의 상태를 평가하기 위해 필요한 모든 지표를 수집하는 프로세스입니다.
- 인프라 수준 지표 : AWS 서비스에 의해 자동으로 내보내지며 CloudWatch 서비스에 의해 수집, 일부 서비스는 CloudWatch Logs를 통해 활성화 및 수집이 가능한 구조화된 로그를 내보내기도 함
- 어플리케이션 수준 지표 : 소프트웨어에 의해 생성되며 CloudWatch 사용자 지정 지표에 의해 수집, 소프트웨어 로그는 CloudWatch Logs를 사용하여 저장되거나 S3로 업로드될 수 있음
- 계정 수준 지표 : AWS 계정에 의해 기록되며 CloudTrail 서비스에 의해 수집
② 분석
수집한 지표를 분석하려면 AWS가 제공하는 여러 데이터베이스 및 분석 솔루션 중에서 하나를 사용할 수 있습니다.
ex) CloudWatch Logs Insight, Athena, RDS, RedShift, Elasticsearch Service 등
③ 작업
지표를 수집 및 분석한 후에는 이를 사용하여 특정 결과 또는 프로세스를 달성할 수 있습니다.
그러한 결과 및 프로세스의 예는 다음과 같습니다
- 모니터링 및 경보 : CloudWatch Alarms
- 대시보드 : Cloudwatch 대시보드
- 데이터 중심의 의사 결정 : 성능 및 비즈니스 KPI를 추적하여 데이터 중심의 의사 결정을 할 수 있습니다.
※ 요점
- 관찰 기능은 원하는 최종 상태를 달성하기 위해 시스템의 내부 상태를 측정하는 프로세스입니다.
- 관찰 기능은 지표 수집, 분석 및 작업으로 구성됩니다.
- 지표는 서비스, 애플리케이션 및 계정 수준에서 수집할 수 있습니다.
- 지표는 CloudWatch Log Insight, Athena, Elasticsearch Service, RDS 및 Redshift 등의 서비스를 통해 분석할 수 있습니다.
- 성능 및 비즈니스 KPI를 추적하고 경보 및 대시보드를 모니터링하여 지표와 관련한 작업을 수행할 수 있습니다.
5. 비용 최적화
클라우드에서의 비용 최적화를 고려할 때는 자본 지출(CapEx) 대신 운영 비용(OpEx)의 측면에서 클라우드 비용을 고려하는 것이 유용합니다. 운영 비용은 지속적인 종량 과금제 모델이지만 자본 지출은 일회성 구매 모델입니다.
이러한 사용량에 따라 지불하는 모델(운영비용)로 인해 비용 최적화 프로세스가 다음과 같이 변경됩니다.
- 사용량에 따라 지불
- 비용 최적화 수명 주기
1) 사용량에 따라 지불
클라우드 비용을 최적화하기 위한 일반적인 네 가지 방법
- 올바른 크기 조정
- 서버리스
- 예약
- 스팟 인스턴스
① 올바른 크기 조정
올바른 크기 조정은 서비스 프로비저닝과 워크로드 구성을 일치시키는 것을 의미합니다. EC2 기반 서비스의 경우, 이는 올바른 인스턴스 크기와 패밀리는 선택하는 것을 의미합니다.
: AWS Compute Optimizer를 사용하여 과거 시스템 지표에 따라 최적의 EC2 크기에 대한 추천을 받을 수 있습니다.
② 서버리스
Lambda와 같은 서버리스 기술을 사용하는 경우에는 사용한 만큼만 비용을 지불하게 됩니다.
③ 예약
예약 요청은 상당한 할인을 받고 특정 용량에 대한 금액을 지불하는 것을 의미합니다.
: Savings Plans - 1~3년의 기간 동안 특정 컴퓨팅 용량을 사용하도록 계약을 체결하면 EC2, Fargate 및 Lambda 모두에 대한 할인을 받을 수 있습니다. (RDS, DynamoDB 및 CloudFront 등 기타 서비스에 대해서도 예약을 요청 가능)
④ 스팟 인스턴스
EC2 스팟 인스턴스를 사용하면 온디맨드 요금에 비해 최대 90% 할인된 비용으로 미사용 EC2 용량을 활용하여 인스턴스를 실행할 수 있습니다.
※ 요점
- AWS 서비스는 사용량에 따라 과금되므로 사용하는 용량에 대한 비용이 청구됩니다.
- 올바른 크기의 인스턴스를 사용하면 워크로드와 일치하지 않는 서비스에 대한 비용을 절감할 수 있습니다.
- 서버리스 기술을 사용하여 고객이 서비스를 이용할 때만 비용을 지불할 수 있습니다.
- 예약을 사용하면 선불 계약의 대가로 할인이 제공됩니다.
- 스팟 인스턴스를 사용하면 내결함성 워크로드 실행에 대한 할인을 받을 수 있습니다.
2) 비용 최적화 수명 주기
비용 최적화 수명 주기는 시간 경과에 따른 클라우드 비용을 향상하는 연속 프로세스입니다.
비용 최적화 수명 주기 워크플로 : ①검토 > ②추적 > ③최적화
① 검토 : 클라우드 비용을 최적화하기 전, 우선 비용이 어디에서 발생하는 지를 파악
- AWS Cost Explorer : 시간 경과에 따른 클라우드 비용을 시각화 및 검토
- AWS 비용 및 사용 보고서 : 시간별 품목을 확인 (보다 더 자세한 데이터)
② 추적
비용 할당 태그를 사용 : 관심이 있는 차원을 그룹화
태그 범주
- 애플리케이션 ID : 비용 변경 사항 및 프로젝트 종료 시 끄기를 편리하게 추적할 수 있도록 특정 애플리케이션과 관련이 있는 리소스를 식별합니다.
- 자동 옵트인/옵트아웃 : 시작, 중지 또는 크기 조정 인스턴스 등 자동화된 활동에 리소스가 포함되어야 하는지를 나타냅니다.
- 비용 센터/비즈니스 단위 : 일반적으로 비용 할당 및 추적을 위해 리소스와 연결된 비용 센터 또는 비즈니스 단위를 식별합니다.
- 소유자 : 리소스의 책임자를 식별합니다. 일반적으로는 기술 소유자입니다. 필요한 경우에는 별도의 비즈니스 소유자 태그를 추가할 수 있습니다. 소유자는 이메일 주소로 지정할 수 있습니다. 이메일 주소를 사용하면 필요한 경우(예: 리소스가 탄력성 또는 올바른 크기 조정의 후보인 경우) 기술 및 비즈니스 소유자 모두에게 자동화된 알림을 제공할 수 있습니다.
AWS 예산 사용 : 적용한 필터에 따라 현재 AWS 비용에 대한 예측을 추적 및 생성
③ 최적화
비용 최적화는 사용량에 따라 지불에서 설명된 기술을 구현하는 것이 포함
※ 요점
- 비용 최적화 수명 주기는 연속 프로세스로 시간 경과에 따른 클라우드 비용을 향상합니다.
- 비용 최적화 수명 주기는 비용 검토, 추적 및 최적화로 구성됩니다.
- 비용 검토에서는 비용을 파악하기 위해 Cost Explorer와 비용 및 사용 보고서와 같은 도구를 사용할 수 있습니다.
- 비용 추적에서는 비즈니스와 관련이 있는 차원에서 데이터를 필터링하기 위해 비용 할당 태그 및 예산을 사용할 수 있습니다.
- 비용 최적화에서는 포괄적인 예산 목표의 일환으로 이전 섹션에서 설명된 기술을 사용할 수 있습니다.
좋은 글 감사합니당 ㅎㅎ