AWS Well-Architected™ Framework

AWS Well-Architected™ Framework

Get Started. It's Free
or sign up with your email address
AWS Well-Architected™ Framework by Mind Map: AWS Well-Architected™ Framework

1. 5 Pillars: CROPS

1.1. Cost Optimization

1.1.1. The Ability to avoid or eliminate unneeded cost or suboptimal resources

1.1.2. 5 Design Principles

1.1.2.1. Adopt a consumption model

1.1.2.2. Measure overall efficiency

1.1.2.3. Stop spending money on data center operations

1.1.2.4. Analyze and attribute expenditure

1.1.2.5. Use managed services to reduce cost of ownership

1.1.3. 4 Best Practice Area

1.1.3.1. Expenditure Awareness

1.1.3.2. Cost-Effective Resources

1.1.3.3. Matching supply and demand

1.1.3.4. Optimizing Over time

1.1.4. AWS Services/Tools

1.1.4.1. Cost Explorer

1.1.4.2. (Expenditure Awareness) AWS Cost Explorer, Budgets (notifications)

1.1.4.3. (Cost-Effective Resources) Cost Explorer, CloudWatch, Managed or Licenses, Managed/hosted or serverless, AWS Direct Connect, Amazon CloudFront

1.1.4.4. (Matching supply and demand) Auto Scaling

1.1.4.5. (Optimizing Over Time) News & Events like the AWS News Blog, What's New, etc.

1.2. Reliability

1.2.1. The Ability of a system to recover from infrastructure or service failures, dynamically acquire computing resources to meet demand, and mitigate disruptions such as misconfigurations or transient network issues.

1.2.2. 5 Design Principles

1.2.2.1. Test recovery procedures

1.2.2.2. Automatically recover from failure

1.2.2.3. Scale horizontally to increase aggregate system availability

1.2.2.4. Stop guessing capacity

1.2.2.5. Manage change in automation

1.2.3. 3 Best Practice Area

1.2.3.1. Foundations

1.2.3.2. Change Management

1.2.3.3. Failure Management

1.2.4. AWS Services/Tools

1.2.4.1. Amazon CloudWatch

1.2.4.2. (Foundations) AWS IAM, VPC, AWS Shield

1.2.4.3. (Change Management) AWS CloudTrail, AWS Config, Auto Scaling, CloudWatch,

1.2.4.4. (Failure Management) AWS CloudFormation, S3, Glacier, KMS

1.3. Operational Excellence

1.3.1. The ability to run systems to deliver business value at the lowest price point.

1.3.2. 6 Design Principles

1.3.2.1. Perform operations as code

1.3.2.2. Annotated documentation

1.3.2.3. Make frequent, small, reversible changes

1.3.2.4. Refine operations procedures frequently

1.3.2.5. Anticipate failure

1.3.2.6. Learn from all Operational Failure

1.3.3. 3 Best Practice Area

1.3.3.1. Prepare

1.3.3.2. Operate

1.3.3.3. Evolve

1.3.4. AWS Services/Tools

1.3.4.1. AWS Cloud Formation

1.3.4.2. (Prepare) AWS Config & AWS Config Rules

1.3.4.3. (Operate) AWS Cloudwatch

1.3.4.4. (Evolve) Amazon Elasticsearch Service (Amazon ES)

1.4. Performance Efficiency

1.4.1. The Ability to use computing resources efficiently to meet system requirements, and to maintain that efficiency as demand changes and technologies evolve.

1.4.2. 5 Design Principles

1.4.2.1. Democratize advanced technologies

1.4.2.2. Go global in minutes

1.4.2.3. Use serverless architectures

1.4.2.4. Experiment more often

1.4.2.5. Mechanical sympathy

1.4.3. 4 Best Practice Area

1.4.3.1. Selection

1.4.3.2. Review

1.4.3.3. Monitoring

1.4.3.4. Tradeoffs

1.4.4. AWS Services/Tools

1.4.4.1. Amazon CloudWatch

1.4.4.2. (Selection) Autoscaling (Compute), EBS/EFS/S3 (Storage), RDS/Aurora/DynamoDB (Database), Route53/VPC/DitectConnect (Network)

1.4.4.3. (Review) News & Events like the AWS News Blog, What's New, etc.

1.4.4.4. (Monitoring) Amazon CloudWatch, Lambda

1.4.4.5. (Tradeoffs) Amazon ElastiCache, Amazon CloudFront, AWS Snowball, RDS features

1.5. Security

1.5.1. The ability to Protect information systems, and assets while delivering business value through risk assessments and mitigation strategies.

1.5.2. 7 Design Principles

1.5.2.1. Implement a strong identity foundation

1.5.2.2. Enable traceability

1.5.2.3. Apply security at all layers

1.5.2.4. Automate security best practices

1.5.2.5. Protect data in transit and at rest

1.5.2.6. Keep people away from data

1.5.2.7. Prepare for security events

1.5.3. 5 Best Practice Area

1.5.3.1. Identity and Access Management

1.5.3.2. Detective Controls

1.5.3.3. Infrastructure Protection

1.5.3.4. Data Protection

1.5.3.5. Incident Response

1.5.4. AWS Services/Tools

1.5.4.1. AWS Identity and Access Management (IAM)

1.5.4.2. (Identity and Access Management) IAM, MFA, AWS Organization for multiple accounts

1.5.4.3. (Detective Controls) AWS CloudTrail, AWS COnfig, Gaurd Duty, CloudWatch

1.5.4.4. (Infrastructure Protection) VPC, CloudFront, AWS shield, AWS WAF (CloudFront or ALB)

1.5.4.5. (Data Protection) Data Encryption at rest or in transit at different services (ELB, EBS, S3, RDS, etc), AWS KMS, Amazon Macie

1.5.4.6. (Incident Response) IAM, AWS CloudFormation, CloudWatch, AWS Lambda

2. 6 Design Principles: DACITE

2.1. D: Data driven architecture A: Automate C: Capacity I: Improve T: Test E: Evolutionary

2.1.1. Drive architectures using data

2.1.2. Automate to make architectural experimentation easier

2.1.3. Stop guessing your capacity need

2.1.4. Improve through game days

2.1.5. Test systems at production scale

2.1.6. Allow for evolutionary architectures