Skip to main content
Welcome back, Solutions Architects — Michael Forrester here. This lesson describes fundamental design principles you can use to evaluate and improve service performance in the cloud. Treat these principles as a set of filters you apply when choosing architectures, services, and automation strategies so you meet performance goals while balancing cost, reliability, and operational overhead. When evaluating a design, ask:
  • Which performance dimensions matter most (latency, throughput, concurrency, or scalability)?
  • Which architectural patterns or managed services help meet those goals without excessive operational cost?
  • What trade-offs are acceptable to achieve required performance (e.g., cost vs. response time)?
  • What is the target: meet demand just-in-time, with minimal buffer to control cost?
Use these principles as decision checkpoints. For each design option, run a short experiment (load or latency tests) and measure cost-per-performance before standardizing on a pattern.

​
Concept 1 — Democratize advanced technologies

Make advanced capabilities easy to consume by using managed, cloud-native services instead of building and operating specialized infrastructure. Key points:
  • Prefer managed offerings (databases, media transcoding, ML services) so teams focus on business logic instead of operational plumbing.
  • Managed services let you “turn dials” such as capacity, concurrency, and feature flags quickly to meet performance objectives.
  • Democratization increases the set of viable solutions for a workload, reducing time-to-market and operational risk.
A presentation slide titled "Democratize Advanced Technologies" showing an arrow from an empty left box to a right box containing a grid of small calendar/document icons. Two colored buttons at the bottom read "Make technology simple" and "Make technology available."
In cloud environments these capabilities are exposed as on-demand services your team can integrate into applications. This lowers the barrier to entry for high-performance features without requiring deep in-house expertise.

​
Concept 2 — Distribution (Go global in minutes)

Bring services closer to users by distributing workloads across regions and edge locations. Best practices:
  • Deploy user-facing services and caches in regions or edge locations near major user populations to reduce tail latency.
  • Use Infrastructure-as-Code and CI/CD to make regional replication repeatable and fast.
  • Combine distribution with automated failover and health checks to preserve both performance and availability during traffic spikes or failures.
Automation examples:
  • CI/CD pipelines or Terraform modules that create region-specific stacks.
  • Health checks and traffic management rules to route users to the nearest healthy endpoint.
A presentation slide titled "Go Global in Minutes" showing a laptop icon linked to multiple server icons. Bullet points on the right mention deploying workloads globally, bringing services closer to users, using automation, and employing resiliency/failover.
Automation lowers the barrier to multi-region deployments and lets you scale horizontally while keeping operational overhead minimal.

​
Concept 3 — Use serverless architectures where appropriate

Serverless shifts infrastructure management to the cloud provider so you can scale and operate with less effort. Why choose serverless:
  • The provider handles patching, capacity, and scaling, allowing focus on business logic.
  • Event-driven or per-request scaling fits bursty and asynchronous workloads and can be very cost-efficient.
  • Good candidates include scheduled tasks, small APIs, and stateless event processors; avoid serverless for workloads requiring very predictable, high sustained throughput without cold-start tolerance.
A presentation slide titled "Use Serverless Architectures" listing three points about using managed services, invisible automated scaling, and event-driven per-request scaling. To the right is an illustration of stacked server icons inside a dashed box with a hooded figure above.
Serverless reduces operational burden and can deliver excellent scaling characteristics when matched to the workload pattern.

​
Concept 4 — Experiment more often

Measure, test, and iterate. Data-driven experiments beat guesswork. How to experiment efficiently:
  • Use short-lived pre-production environments to validate instance types, storage classes, and networking configurations.
  • Run load tests and track performance metrics (p99 latency, throughput, error rates) and cost metrics (cost per 1M requests, cost per GB served).
  • Compare alternatives quantitatively to choose the best trade-off between performance and cost.
A presentation slide titled "Experiment More Often" listing three tips about trying scenario improvements, creating short‑lived pre‑production environments, and tracking metrics for experiments. On the right is a large rounded‑corner blue outline with a smaller blue rectangle graphic inside.
Automated tests and ephemeral environments let you test many configurations quickly and pick the most cost-effective option.

​
Concept 5 — Consider mechanical sympathy

Use the right service for the right job. Avoid forcing a component to behave outside its design. Examples:
  • Run transactional workloads on RDS/Aurora for ACID semantics; use DynamoDB for high-scale key-value patterns; use S3 for object storage and large-volume static assets.
  • Evaluate whether a scheduled function (serverless) is sufficient for periodic tasks instead of a continuously running VM.
A presentation slide titled "Consider Mechanical Sympathy" with two panels advising to use technologies for their intended purpose (e.g., prefer SQL for SQL needs and use Lambda for small cron jobs). To the right are colored tool icons — a screwdriver marked wrong and a hammer marked correct — illustrating choosing the right tool.
Choosing the correct service for the workload often yields better performance at lower cost than trying to retrofit a mismatched technology.
Avoid using object storage (like S3) as a primary transactional database. If you need consistent, low-latency reads and writes with ACID guarantees, move to a database service designed for that workload.

​
Applying the principles — an S3 example

When a stakeholder asks for “managed storage with minimal ops overhead”:
  1. Serverless: Start with Amazon S3 for static storage and low-ops requirements.
  2. Experiment: Test different S3 storage classes and measure access latency and cost for your workload.
  3. Mechanical sympathy: If you find S3 access patterns emulate database behavior (frequent small reads/writes, conditional updates, strong consistency needs), migrate to a database (RDS/Aurora or DynamoDB) that matches those semantics and performance expectations.
S3 storage-class considerations (example summary): Run tests that measure throughput and cost for each candidate to determine the best fit.

​
Quick decision checklist

  • Democratize: Can a managed service meet the need?
  • Distribute: Would regional or edge placement reduce latency?
  • Serverless: Is the workload event-driven or intermittent?
  • Experiment: Can you validate choices with short tests?
  • Mechanical sympathy: Is the chosen service designed for the access pattern?

​
Summary

  • Treat these five principles as practical filters when designing for performance: democratize advanced tech, distribute globally, prefer serverless when appropriate, experiment frequently, and choose tools that fit the problem.
  • Use automation and repeatable experiments to make informed, data-driven trade-offs between performance, cost, and reliability.
  • These principles are not an exam checklist, but they help you reason about performance-focused architecture questions and choose effective designs.
Resources and further reading: I’m Michael Forrester. Thank you for listening.

Watch Video