A robust cloud design starts with business requirements and evidence about the workload. Choose services only after agreeing acceptable downtime, data loss, security constraints, operating responsibilities and cost. A provider’s feature list or certification does not establish those outcomes for your application.
Reviewed 16 October 2026: removed promises of automatic availability, instant scaling, comprehensive provider compliance and future compatibility. This guide now emphasizes decisions you can document and test.
1. Understand your business needs
Record the applications, datasets, integrations and people required to deliver the service. Measure the existing workload, including peak demand and latency. Identify the consequences of service failure rather than choosing availability targets from a competitor’s website.
Agree two recovery targets for each critical service: the recovery time objective (RTO), covering tolerable restoration time, and the recovery point objective (RPO), covering the acceptable point in time to which data can be recovered. NIST’s contingency-planning guide connects recovery planning with business impact. A target needs a tested implementation behind it.
2. Choose services and assign responsibilities
Decide which tasks your team will operate and which a provider will handle. IaaS, PaaS and SaaS describe different responsibility boundaries. One application may use several models.
Write a responsibility table covering identity, application updates, infrastructure updates, data protection, monitoring, recovery and incidents. For a managed database, verify the exact backup, retention, failover and maintenance behavior instead of assuming that “managed” includes every recovery need.
Compare public, private or hybrid deployment against the same requirements. The deployment-model guide explains why network isolation and dedicated hardware are different decisions.
3. Design capacity and resilience deliberately
Autoscaling needs appropriate metrics, policies, quotas and application behavior. It cannot guarantee capacity in every location or repair a database bottleneck simply by adding web servers. Test the demand you expect and the failure conditions you need to tolerate.
List shared dependencies such as a single database, region, identity provider, DNS service or external API. Decide what happens when one becomes unavailable. Redundancy needs attention to data consistency, failover, network paths and operating procedures, rather than just a second server.
AWS’s Reliability Pillar explicitly assigns customers responsibility for resilient workload design, including appropriate distribution of EC2 instances. Service availability commitments are not a guarantee that your complete application stays online.
4. Prioritize security and data requirements
Document which identities may access which resources, how privileges are approved, and where audit records go. Protect administrative access and plan for staff departures. For AWS, the IAM permissions review separates observed activity from business need before permissions are reduced.
Map data locations, processing purposes, retention and third-party access. Review applicable contractual and regulatory requirements with qualified owners. Encryption, a region selection and a provider audit report may contribute evidence, but do not establish that your complete service is compliant.
Include backups, restoration credentials and key recovery in the design. A recovery process that depends on the failed production account or an unavailable employee needs another route.
5. Model the full cost
Compare compute, databases, storage, requests, data movement, network services, observability, support, licences and staff time. Separate recurring charges, commitments and implementation costs. State the region, currency, tax treatment, usage assumptions and quote date.
Test whether a planned scaling or recovery design fits the budget. A replica, retained snapshot or provisioned gateway can continue charging when application traffic is quiet. Use the cloud-cost review guide for a reproducible comparison rather than assuming pay-as-you-go is automatically cheaper.
6. Rehearse deployment and recovery
Define checks that prove the application works: login, important transactions, integrations, access restrictions and measured performance. Record rollback triggers and who may make the decision. Rehearse restoring a critical dataset into an isolated environment and compare the result with the agreed RTO and RPO.
For a move from an existing environment, use the migration checklist. Pay particular attention to new writes after cutover, which can make a simple switch back unsafe.
7. Review the architecture as it changes
Keep the architecture diagram, owners, risks and decisions with the operating documentation. Review again when demand, team capacity, regulation, services or business priorities change. Terraform and infrastructure as code can help reproduce infrastructure changes, but still need review and state protection.
AWS’s Well-Architected Framework groups reviews into operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. Use those as prompts for trade-offs, not as a certification that your application meets a universal architecture standard.
If the proposal introduces containers, the containerization guide explains the deployment and operating questions to ask before choosing Kubernetes.
