AWS Cloud Design Principles — Study Notes

AWS Academy · Module 1

AWS Cloud
Design Principles

A definitive guide to designing robust, automated, scalable, loosely coupled, and secure cloud architectures.

12 Core Principles Disposable Resources No Single Points of Failure

01 — Design Trade-Offs

Evaluating Trade-offs in Cloud Architecture

As you design a solution, think carefully about trade-offs to select the optimal approach based on empirical data rather than theoretical assumptions.

Slide 20 · Design Trade-offs — Evaluate, balance, and base decisions on empirical data

🔑

Key Considerations

Evaluate trade-offs so you can select the best possible solution
Trade-offs are inevitable in architecture decisions
Base all design decisions on empirical data (not assumptions)

⚖️

Common Examples

Trade consistency, durability, and space for time and latency to deliver higher performance
For new features, prioritize speed to market over cost
Balance performance improvements against increased complexity and cost

✓

Best Practices

Use load testing to validate performance benefits
Perform benchmarking to achieve cost-optimal workloads
Consider the impact of design choices on customers and overall workload efficiency
Be aware that trade-offs can increase cost and complexity if not managed properly

📌

Key Design Concept — Empirical Data

Always base your design decisions on measurable, real-world data rather than theoretical assumptions.

02 — Scalability

Implementing Proactive Scalability

Scale your infrastructure programmatically and dynamically to anticipate demand and scale before capacity limits are reached.

Slide 21 · Implementing Scalability — Scale at every layer to handle changing workloads

📐

Key Principles

Implement scalability at every layer of your infrastructure
Design systems to anticipate demand and scale before capacity is reached
Aim for elastic architectures — scale up when demand increases and scale down when demand drops

⚙️

How Scaling Works on AWS

Use Amazon CloudWatch for continuous monitoring and alarms
Define thresholds (e.g., CPU utilization > 60% for more than 5 minutes)
Create custom metrics based on application-specific needs
When an alarm triggers, Amazon EC2 Auto Scaling automatically launches new instances
New instances are prepared and ready before users experience latency

🎁

Benefits

Provides seamless user experience
Prevents application downtime due to capacity limits
Reduces manual intervention
Optimizes costs by scaling down when demand decreases

Reactive vs Proactive Scaling

✖

Reactive (Bad Practice)

Application servers reach full capacity
Users face delays or cannot access the application
Administrators manually launch new instances
Delay occurs while new instances are being prepared

✓

Proactive (Best Practice)

Monitoring detects rising demand early
Auto Scaling adds capacity automatically
Users experience smooth performance
System scales down automatically during low demand

03 — Automation

Automating Resource Provisioning & Monitoring

Automate deployment, termination, and configuration of resources to make your infrastructure responsive and resilient to changes and failures.

Slide 22 · Automating Your Environment — Build monitoring and automation at every layer

Why Automation Matters

AWS provides built-in monitoring and automation tools at almost every layer of your infrastructure
Automation allows your environment to respond quickly to changes and failures
Reduces manual effort and human error

✖

Traditional Manual Approach

Must manually detect failures
Manually notify administrators
Manually launch and configure replacement resources
Slow response time and higher risk of downtime

✓

AWS Automated Approach

Amazon CloudWatch continuously monitors resources
Automatically detects unhealthy or failed resources
Amazon EC2 Auto Scaling launches and configures replacement instances
Automatically notifies administrators of changes
Logs all changes to a change management solution for tracking and auditing

Key Benefits of Automation

🚀

Faster Recovery

Launches replacement resources instantly when failures are detected.

🤖

Zero Manual Overhead

Eliminates repetitive configurations and human configuration errors.

📝

Full Visibility

Enables systematic tracking, logging, and auditing of all operational changes.

04 — Infrastructure as Code

Using Infrastructure as Code (IaC)

Define and manage your compute, storage, and networking resources programmatically using code templates rather than manual setup.

Slide 23 · Using Infrastructure as Code (IaC) — Version, test, and deploy infrastructure as code

🔑

Key Benefits of IaC

Rapidly deploy duplicate environments
Reduce configuration errors from manual processes
Propagate changes consistently across all environments (stacks)
Enable version control, testing, and rollback of infrastructure

🏛️

Major Advantages

Speed: Deploy identical environments quickly using a single template
Consistency: Eliminate repetitive manual steps and checklists
Reliability: Significantly reduce human errors common in manual configuration
Rollback: Easily revert to previous stable versions if issues arise
Scalability: Change template once and apply it consistently to all stacks

💻

Practical Use Cases

Quickly spin up development, testing, and production environments that are identical
Fix errors by rolling back code to the last known good configuration
Deploy infrastructure changes across multiple stacks reliably

💡

Key Recommendation — Infrastructure as Code

Treat your infrastructure like application code — version it, test it, and automate it.

05 — Disposable Resources

Treating Resources as Disposable

Shift your mindset from traditional physical hardware to dynamically provisioned, disposable, and replaceable cloud resources.

Slide 24 · Treating Resources as Disposable — Automate deployment and terminate unused resources

✓

Best Practices

Automate deployment of new resources with identical configurations
Stop or terminate resources that are not in use
Test updates on new resources, then replace old resources with updated ones

🔎

Why This is Better

Avoids the high cost and inflexibility of over-provisioning hardware
Makes it easy to upgrade applications and manage software
Enables quick response to changes in capacity needs
Simplifies migration between instances or resources
Reduces the impact of "sunk cost" in old hardware

🎁

Key Benefits

Greater flexibility in managing infrastructure
Faster updates and deployments
More cost-efficient resource utilization
Easier experimentation and innovation

06 — Loose Coupling

Using Loosely Coupled Components

Design architectures with independent, loosely coupled components instead of tightly integrated monolithic systems to isolate failures.

Slide 25 · Using Loosely Coupled Components — Decouple components using queues and load balancers

Tightly Coupled vs Loosely Coupled Architectures

✖

Tightly Coupled Monoliths

If one component fails, it can cause system-wide disruption
Scaling is difficult: adding servers at one layer requires updates across all layers
Creates single points of failure across the workflow

✓

Loosely Coupled Systems

Increases overall system fault tolerance and resilience
Makes scaling much easier and completely independent
Reduces blast radius when individual components fail
Improves overall system reliability

Loose Coupling on AWS

Use managed services as intermediaries between architectural layers to handle communication asynchronously and distribute load.

⚖️

Load Balancers (ELB)

ELB sits between layers. If one server fails, the load balancer automatically routes traffic only to healthy instances, isolating users from disruption.

📬

Message Queues (SQS)

Decouples components programmatically. Producers push messages into SQS, and consumers poll for tasks when ready, ensuring no transactions are lost during peaks.

07 — Services, Not Servers

Designing Services, Not Servers

Shift your design focus toward using AWS managed services, containers, and serverless architectures rather than provisioning EC2 servers.

Slide 26 · Designing Services, Not Servers — Maximize use of serverless and managed services

✓

Best Practices

Consider using containers or serverless solutions when appropriate
Use message queues for communication between applications
Store static web assets on Amazon S3 instead of servers
Handle user authentication and state using managed services

⚙️

Advantages

Reduced operational overhead (no OS updates, server provisioning, or server management)
Lower overall operational cost
Higher performance and automatic scaling
Faster development and deployment speeds

🎁

Examples of AWS Services

AWS Lambda (serverless compute)
Amazon SQS (message queuing)
Amazon DynamoDB (managed NoSQL database)
Elastic Load Balancing (ELB)
Amazon SES (email service)
Amazon Cognito (user identity & access)

08 — Database Selection

Choosing the Right Database Solution

Select the database technology based on your workload's actual characteristics, query complexity, and scalability needs.

Slide 27 · Choosing the Right Database Solution — Match database technology to workload requirements

📋

Key Factors to Consider

Read and write throughput needs
Total storage requirements
Typical object size and nature of data access patterns
Durability and latency requirements
Maximum number of concurrent users to support
Nature of queries (simple lookups vs complex joins)
Required strength of integrity controls

🏛️

Important Advice

In traditional on-premises environments, hardware and licensing limitations often restrict database choices
On AWS, you should select the most appropriate data store based on your application’s actual needs
Avoid forcing your workload to fit a particular database technology just because it is familiar

✓

Recommendation

Evaluate your workload requirements first, then choose the best AWS database service that fits (e.g., RDS, DynamoDB, DocumentDB, ElastiCache).

09 — High Availability

Avoiding Single Points of Failure

Assume everything fails. Design your architecture backward to handle infrastructure and software failures gracefully without downtime.

Slide 28 · Avoiding Single Points of Failure — Design redundant data paths and failovers

Redundant Architecture Design

✖

Single Point of Failure (SPOF)

If two application servers connect to a single database server, that database becomes a single point of failure. When it goes offline, the entire application loses connectivity.

Database goes down → total application outage
No automatic recovery
Loss of user connectivity

✓

Better Resilient Design

Use a secondary standby database with automatic data replication. If the primary database fails, application servers automatically fail over and switch to the secondary standby instance.

Combines with the practice of treating resources as disposable
Supports high availability and fault tolerance
Improves overall system resilience and recovery time

Recommended Approaches to Eliminate SPOFs

Standby Databases

Create a secondary database server and replicate data continuously from the primary instance.

🔄 Auto-Replacement

Use automated scaling and monitoring solutions that launch replacement components immediately when failures occur.

🤖 Managed Failover

Leverage AWS managed services that automatically handle underlying hardware failures and routing.

10 — Cost Optimization

Optimizing for Cost & Consumption

Leverage the flexibility of AWS to match resources to your actual workload size and transition from fixed to variable expenses.

Slide 29 · Optimizing for Cost — Transition from fixed to variable cloud expenses

❓

Key Questions to Ask

Are my resources the right size and type for the job?
Which metrics should I monitor to detect waste?
How do I turn off resources that are not in use?
How often will I actually need this resource?
Can I replace any of my EC2 servers with managed services?

⚖️

Expenses Comparison

Fixed Expenses (On-Premises): Pay for servers and physical infrastructure whether they are being utilized or not (24/7 cost).
Variable Expenses (AWS Cloud): Pay only for the resources and services you actually use, for as long as you use them.

✓

Best Practices

Right-size your resources (choose the correct instance type and size for workloads)
Monitor resource usage with metrics
Automatically stop or terminate idle resources when not in use
Use managed services instead of self-managed servers whenever possible
Choose the most appropriate pricing model for each service

⚠️

Key Reminder — Cloud Spending

Replicating an on-premises data center (servers running 24/7) in the cloud can be very expensive. Always provision only what you need and turn off resources when they are not in use.

11 — Caching

Using Caching to Improve Performance

Minimize redundant data retrieval operations from primary storage to improve latency, reduce server loads, and lower network cost.

Slide 30 · Using Caching — Cache data in intermediary locations to reduce latency

💡

What is Caching?

A technique that temporarily stores copy of data in an intermediary location. It reduces the need to repeatedly access slower primary storage, makes future requests for the same data significantly faster, and lowers network throughput and overall cost.

⚙️

caching on AWS (Example)

Use Amazon CloudFront (CDN) in front of Amazon S3:

First request: CloudFront checks cache, fetches file from S3, and stores a copy at an edge location close to the user.
Subsequent requests: Served directly from the nearest CloudFront edge location, resulting in lower latency and reduced S3 data transfer cost.

🎁

Key Benefits

Dramatically improved performance for repeated requests
Lower latency for users globally
Significant cost savings on data transfer
Reduced load on origin databases/servers

12 — Security

Securing Your Entire Infrastructure

Build security into every layer of your architecture, enforcing least privilege and resource isolation instead of relying only on the perimeter.

Slide 31 · Securing Your Entire Infrastructure — Apply Defense-in-Depth at every layer

✓

Best Practices

Use managed services wherever possible
Log access and activity of all resources
Isolate different parts of your infrastructure
Encrypt data both in transit and at rest
Enforce granular access control using the principle of least privilege
Use Multi-Factor Authentication (MFA)
Automate deployments to ensure consistent security

🏛️

Important Concept

Security is not only about protecting the perimeter
Individual components and environments should also be secured and isolated from each other
This limits the blast radius if one component is compromised

💻

Practical Implementation

Use Security Groups in Amazon EC2 to control which ports can send/receive traffic, and which IP addresses or resources can connect. This reduces the risk of a breach spreading from one instance to others.

🛡️

Key Recommendation — Security Posture

Treat security as a layered, continuous practice (Defense in Depth).

AWS Cloud Design Principles Key Takeaways Slide

Module 1 · Takeaways

Key Takeaways:
AWS Cloud Design Principles

✓
Evaluate design trade-offs to select the optimal architectural approach based on measurable empirical data.
✓
Scale proactively at every layer to handle changing workloads and achieve true elasticity.
✓
Automate your environment using Infrastructure as Code (IaC) to ensure consistency, speed, and rapid rollback.
✓
Treat resources as disposable and loosely couple components to isolate failures and eliminate single points of failure.
✓
Design services rather than servers, select database technologies matching your workloads, and implement multi-layered security.

AWS CloudDesign Principles

Evaluating Trade-offs in Cloud Architecture

Key Considerations

Common Examples

Best Practices

Key Design Concept — Empirical Data

Implementing Proactive Scalability

Key Principles

How Scaling Works on AWS

Benefits

Reactive vs Proactive Scaling

Reactive (Bad Practice)

Proactive (Best Practice)

Automating Resource Provisioning & Monitoring

Why Automation Matters

Traditional Manual Approach

AWS Automated Approach

Key Benefits of Automation

Faster Recovery

Zero Manual Overhead

Full Visibility

Using Infrastructure as Code (IaC)

Key Benefits of IaC

Major Advantages

Practical Use Cases

Key Recommendation — Infrastructure as Code

Treating Resources as Disposable

Best Practices

Why This is Better

Key Benefits

Using Loosely Coupled Components

Tightly Coupled vs Loosely Coupled Architectures

Tightly Coupled Monoliths

Loosely Coupled Systems

Loose Coupling on AWS

Load Balancers (ELB)

Message Queues (SQS)

Designing Services, Not Servers

Best Practices

Advantages

Examples of AWS Services

Choosing the Right Database Solution

Key Factors to Consider

Important Advice

Recommendation

Avoiding Single Points of Failure

Redundant Architecture Design

Single Point of Failure (SPOF)

Better Resilient Design

Recommended Approaches to Eliminate SPOFs

Optimizing for Cost & Consumption

Key Questions to Ask

Expenses Comparison

Best Practices

Key Reminder — Cloud Spending

Using Caching to Improve Performance

What is Caching?

caching on AWS (Example)

Key Benefits

Securing Your Entire Infrastructure

Best Practices

Important Concept

Practical Implementation

Key Recommendation — Security Posture

Key Takeaways:AWS Cloud Design Principles

AWS Cloud
Design Principles

Key Takeaways:
AWS Cloud Design Principles