At a glance
What you need to know.
Cloud architecture is the set of choices that lets a workload run within its performance, recovery, security and spending constraints. A good starting design is the smallest one your team can operate and test against the real user journey.
Turn business expectations into workload constraints
Record the critical user journey, normal and peak activity, acceptable response time and consequences of an outage. Define recovery time and tolerable data loss with the business owner; these values influence storage and backup choices. Note geographical restrictions, private network dependencies and the team's operating capacity. A public marketing site and a stock-reservation system need different decisions even if they share a programming language. Keep assumptions visible until real usage or a load test replaces them.
Choose compute by how the workload behaves
Compare managed application hosting, functions, containers and virtual machines against request duration, background work, state, network access and deployment requirements. Check platform limits in current provider documentation before committing. More control usually brings more operating responsibility. For a small stateless application, managed hosting may reduce routine work; a long-running specialized process may need another model. Avoid adopting a cluster solely because it appears in a reference diagram. Include startup behavior and dependency access in the evaluation.
Keep persistence and recovery visible in the diagram
Draw the database, object storage, caches and queues with their ownership and consistency assumptions. Decide which state must survive a deployment or host restart. A cache should have an explicit rebuild strategy; it should not silently become the only copy of an important record. Define backups, retention and restoration checks around the data the application actually uses. Redundancy can help availability, but it does not replace testing recovery from an accidental deletion or a bad application update.
Create environments and access boundaries early
Separate production from development through credentials, data and deployment authority. Give workloads only the access they need, and keep secret values out of images, source files and browser bundles. Map inbound and outbound network paths so an unexpected public endpoint is easier to detect. Confirm who can change domain routing and provider settings. An application can have correct code while its deployed identity has excessive access. Test the intended deployment identity and record the prerequisites for a release.
Test degradation as well as healthy traffic
Exercise a database interruption, slow dependency, exhausted connection pool and failed background job in a controlled environment. Set timeouts and bounded retries that avoid multiplying load during an outage. Decide which features can remain available and how the interface represents stale or unavailable information. Observe one full user journey with logs, metrics and correlation references. A health endpoint should expose meaningful dependency readiness where appropriate; returning a fixed success value does not prove the application can serve the journey.
Compare cost and release with measured evidence
Estimate compute, storage, requests, data transfer, managed dependencies and operational effort using a clearly stated workload. Revisit the estimate after measuring actual traffic. Capture infrastructure configuration and deployment steps so environments can be reproduced. Before cutover, prove the deployed version, domain routing, database compatibility and rollback path. If a schema change cannot be reversed, plan a forward repair or staged migration explicitly. Review architecture again when traffic, data volume or the operating team changes.
Before you start.
- Define the critical journey, response budget and recovery targets.
- Check provider limits against foreground and background workloads.
- Identify authoritative data, backups and a tested restore procedure.
- Separate environments and verify deployed access permissions.
- Test slow and unavailable dependencies without uncontrolled retries.
- Record realistic cost assumptions, cutover checks and rollback steps.
Common questions.
Do we need multiple cloud providers from the start?
That depends on a defined resilience, regulatory or commercial requirement. Additional providers add identity, data synchronization, deployment and operating work. Establish a tested single-provider design first unless the requirement justifies the added complexity and the team can operate it.
Is serverless always cheaper than containers?
No. Costs depend on execution duration, volume, resource needs, data transfer and managed dependencies. Compare the full workload and operational cost using current provider pricing, then measure actual use. A request-count comparison alone misses important expenses.