Skip to main content
Welcome, future Solutions Architects. I’m Michael Forrester. In this lesson we’ll cover how to design for performance on AWS. Below is the agenda for this section and the high-level topics we’ll explore: principles you should follow, categories to organize performance work, and concrete service-level trade-offs (for example, when to use Auto Scaling or serverless patterns).
A presentation slide titled "Designing for Performance – Agenda" listing three items: Design Principles and Foundation, Categories for Performance in AWS, and Specific Performance Choices for Specific Services, with a large teal gear/speedometer icon on the right.
Section one — Design principles and foundations When optimizing for performance, use a compact set of guiding questions and principles to direct decisions. These prompts help balance latency, throughput, operational cost, and reliability:
  • Prefer managed services when they meet requirements — they reduce operational overhead and often deliver better performance at scale.
  • Keep technology stacks simple to reduce surface area for bottlenecks and make tuning easier.
  • Favor observable, measurable changes: collect metrics, run experiments, and validate optimizations.
  • Consider trade-offs between consistency, durability, latency, and cost as part of every design decision.
  • Default to patterns that enable safe iteration: automated deploys, feature flags, and canary releases.
These principles are intentionally broad so you can apply them across compute, storage, and networking decisions.
A slide titled "Performance Optimization – Design Principles" showing a central laptop graphic with circuit-like lines connecting to four colored circular icons labeled "Use managed services," "Make technology simple," "Experiment more often," and "And more..."
Section two — Categories for applying performance improvements Grouping performance concerns makes optimizations easier to prioritize. Use these categories to scope investigations and to assign responsibility across teams:
A presentation slide titled "Categories for Performance in Design" showing five labeled cards. The categories are Overall Architecture Selection, Compute and Hardware, Data Management, Networking and Content Delivery, and Process and Culture.
Note: process changes are often faster to implement than cultural changes, but cultural shifts (for example, adopting infrastructure-as-code and continuous improvement practices) have the biggest long-term impact on how reliably you can apply performance improvements. Section three — Specific performance scenarios and AWS services Translate the principles and categories into concrete, service-level choices. Key scenarios to evaluate include:
  • Autoscaling vs. manual scaling: use Auto Scaling groups, ECS/EKS autoscaling, or Lambda scaling for dynamic loads; use manual scaling when workload is predictable and simple.
  • Offloading and distributing work: adopt asynchronous processing (SQS, SNS, Kinesis), background workers, and caching to spread load and reduce synchronous latency.
  • Serverless vs server-based: serverless (AWS Lambda, Fargate for tasks) reduces operational overhead and often scales faster, while server-based architectures (EC2, self-managed containers) can be tuned for specific performance or cost profiles.
A presentation slide titled "Specific Performance Scenarios for Specific AWS Services" showing a semicircular gauge with three colored segments. The segments are labeled (left to right) Autoscaling vs Scaling, Offloading and Distribution of Load, and Server-less vs Server-based, with an icon on each and a needle pointing toward the server segment.
Practical exercise: drag-and-drop design challenge This section includes a hands-on drag-and-drop challenge to map AWS services to architectural roles. The exercise reinforces the mental model of which AWS services fulfill common responsibilities in a performant system. Typical questions include: Working through the diagram helps you map architecture roles (edge compute, CDN, compute, object storage, key-value store, authentication) to concrete AWS services and to understand trade-offs for performance and cost.
A schematic "Drag-and-Design Challenge" AWS architecture diagram showing an account/region boundary with flowchart boxes for services like Route 53, CloudFront, a content distribution network, load balancing, serverless/VM compute, scalable key-value datastore, and object storage. Arrows indicate request and component interactions and optional security/automation components (DDoS defender, WAF, certificate storage).
This drag-and-drop exercise reinforces the mapping between architectural roles and AWS services.
Thank you for following this lesson. If you want to dive deeper into any of the categories — such as autoscaling strategies, caching patterns, or edge compute use cases — check the linked AWS documentation and resources in each section, and join the forums or KodeKloud to discuss real-world scenarios. — Michael Forrester

Watch Video