Skip to main content
All right — welcome back, future Solutions Architects. This is Michael Forrester. In this lesson we cover how to design and optimize for performance in the cloud. You’ll learn the five foundational areas that influence application performance on AWS, where to apply design principles, and how to structure your optimization process. Apply these areas together — architecture choices drive compute, storage, and networking decisions, and your process/culture determines how reliably you implement and iterate on those choices.
These five areas form a practical framework for evaluating and improving application performance on AWS. Use them together: architecture choices will drive compute, storage, and networking decisions, and your process/culture will determine how reliably you implement and iterate on those choices.
Summary of the five areas:
  • Architecture selection
  • Compute and hardware performance
  • Data management performance (storage)
  • Networking and content delivery performance
  • Process and culture

Quick reference table

For more background on AWS services and design patterns, see:

1. Architecture selection

Choose the overall architecture that fits the workload’s non-functional and business requirements (latency, throughput, consistency, durability, and cost). A single application often needs multiple architectural approaches so each component uses the right tool for its job. Key guidance:
  • Start with requirements: identify latency, throughput, consistency, and durability targets before selecting services.
  • Use purpose-built services when they match requirements (for example, DynamoDB for single-digit millisecond NoSQL access patterns).
  • Balance performance with cost and operational complexity — prefer simpler solutions that meet requirements.
  • Validate decisions with benchmarking and POCs; use a data-driven approach to prove assumptions.
Practical steps:
  • Map each component’s SLA to potential AWS services.
  • Create simple reference architectures for alternative approaches and size them according to expected load.
  • Run real-world performance tests (load, latency, and error-rate scenarios) before committing to a design.

2. Compute and hardware performance

Compute selection impacts latency, throughput, cost, and operational burden. Different parts of the same system may need serverless, containers, or provisioned VMs. Best practices:
  • Re-evaluate compute choices periodically — traffic patterns and available instance types change over time.
  • Use monitoring data (not intuition) to guide instance sizing, CPU provisioning, and memory allocation.
  • Prefer dynamic, automated scaling: Auto Scaling groups, serverless autoscaling, or container orchestrator autoscaling.
  • Choose instance families and sizes that match required network and I/O capabilities (some instance types include enhanced networking or higher EBS throughput).
A slide titled "Area #2 – Compute and Hardware Performance" with three short recommendations: periodically reselect your compute choice, evaluate via monitoring and metrics, and scale dynamically for performance and cost. To the right is a stylized monitor icon connected by lines to stacked server racks.
Operational tips:
  • Instrument CPU, memory, disk, and network metrics with CloudWatch (or a preferred monitoring stack).
  • Set autoscaling rules based on meaningful business or system metrics (requests/s, latency p95/p99, queue depth).
  • Right-size regularly and consider Savings Plans or Reserved Instances for predictable workloads.
Relevant docs:

3. Data management performance

Storage design must be driven by access patterns: read/write ratio, random vs sequential access, throughput and latency needs, and data lifecycle (hot vs cold). Use the right storage abstraction for the job. Principles:
  • Match storage type to workload:
    • Object storage (S3) for large, immutable objects and archival needs.
    • Block storage (EBS) for low-latency volumes attached to EC2.
    • File storage (EFS) for shared POSIX workloads.
    • Purpose-built databases (DynamoDB, RDS) for transactional and query patterns.
  • Model and measure access patterns; design caches and tiering accordingly.
  • Capture metadata to enable efficient placement, lifecycle policies, and tiering.
  • Reassess and migrate data as patterns evolve (e.g., move cold data to cheaper tiers).
A presentation slide titled "Area #3 – Data Management Performance" with three bullet points about using purpose-built tools, relearning access patterns, and collecting metadata. The slide also shows colored server/table icons connected by dashed lines and a small multi-line performance chart.
Design considerations:
  • Use caching (e.g., Amazon ElastiCache) to reduce read latency and offload databases.
  • For databases, choose appropriate indexing, partitioning/sharding, and consistency models to meet latency and throughput targets.
  • Apply lifecycle rules and tiering for cost-effective storage without compromising performance for hot data.
Useful links:

4. Networking and content delivery performance

Network characteristics (latency, throughput, jitter) are critical — especially for distributed systems and geographically dispersed users. In cloud environments, networking is virtualized but still needs explicit design. Key considerations:
  • Instance type/size often affects network bandwidth and features; plan placement and sizing accordingly.
  • Use load balancers (ALB/NLB) and traffic distribution strategies to scale and isolate workloads.
  • Employ CDNs (Amazon CloudFront) and edge services to lower latency for global users.
  • Monitor network metrics and design topology to minimize costly cross-AZ or cross-region hops where low latency is required.
A presentation slide titled "Area #4 – Networking and Content Delivery Performance" listing three key points about AWS networking, performance awareness, and load balancing. To the right is a simple diagram of a load balancer distributing traffic to three server stacks.
Practical tips:
  • Use VPC design patterns that place services close to their consumers (same AZ/region) when latency matters.
  • Choose the right load balancer: NLB for extreme performance & static IPs, ALB for HTTP(S) routing.
  • Use CDN caching and TTLs to minimize origin load and improve perceived latency.
  • Test network behavior under load and account for spikes in connection setup rates.
Reference docs:

5. Process and culture

Technology alone won’t sustain performance improvements. Processes, ownership, and continuous practices enable reliable, repeatable performance at scale. Recommended practices:
  • Infrastructure as Code (IaC) for versioned, reproducible infrastructure (CloudFormation, Terraform).
  • Build “paved roads”: standardized CI/CD pipelines and platform patterns that make it easy for developers to deploy responsibly.
  • Define and track technical and business KPIs; surface performance metrics to teams and tie alerts to meaningful thresholds.
  • Include regular performance testing (load, stress, soak) in release pipelines and capacity planning.
  • Promote a culture of continuous improvement: measure, iterate, and automates corrective actions.
A presentation slide titled "Area #5 – Process and Culture" with a bullet list including Infrastructure as Code, deployment pipelines, metrics, performance/load testing, and process improvement. To the right is a stacked, rainbow-colored ribbon graphic topped by a lightbulb/gear icon.
Operational checklist:
  • Automate deployments and rollbacks to reduce human error.
  • Instrument applications and infrastructure end-to-end for observability.
  • Run gamedays and post-incident reviews to improve operational readiness.
  • Assign clear ownership for SLAs and runbooks.
Measure before you optimize. Changes without data can increase cost or risk. Always establish baselines and use automated tests to validate improvements.

Putting it all together

Performance optimization on AWS is multi-dimensional. Use this practical framework to guide decisions and trade-offs:
  • Architecture selection shapes which AWS services you use.
  • Compute choices determine raw processing and network ability.
  • Data management choices affect latency, throughput, and cost.
  • Networking and CDN choices influence geographical performance and scalability.
  • Process and culture ensure the changes are repeatable, observable, and sustainable.
Performance issues typically map to compute, storage, or networking — but process and culture are often the most powerful levers for continuous improvement. Adopt metrics-driven decision-making, automate wherever possible, and validate with realistic testing. These patterns may not appear verbatim on exams, but they mirror how AWS approaches architecture and will help you reason through scenario-based questions and real-world designs. I’m Michael Forrester. Thank you for reading. Understanding which AWS services and architecture patterns map to these five areas will help you design high-performing systems in production.

Watch Video