This guide is for IT heads, CTOs and engineering managers at mid-size companies in India and the GCC. You may be designing a new application, or reviewing one, on AWS, Azure or both. It sets out seven practices for a cloud architecture strategy in an order you can follow, with the failure each one prevents and the provider document to read next. Where the availability method already exists on this site, you get a link instead of a repeat. That way, the cloud architecture best practices here stay at design level. Read them in order the first time. Then use them as a review list, and revisit the list whenever the workload changes in a way that touches design.
Last reviewed 2026-11-01 by Manish Sharma.
Cloud Architecture Best Practices: The Short Answer
Seven practices, applied in proportion to the workload, make up a sound cloud architecture strategy. Start from requirements, and then set a few design principles. Then decouple, decide where data lives and build security in. Last, handle failure by design, and document and review. A practice here is a design decision a team makes once and checks again at each review. The order is our own framing. Microsoft’s catalog of practices, for one, is a table, not a ranking.
All three major providers publish a framework of their own, so this guide is a route into them rather than a replacement. Each practice below also names the source to open next.
Write down what the workload needs before choosing patterns.
Agree a short list the team tests each design against.
Separate parts so one can fail or change alone.
Decide where data lives, how it splits and what is cached.
Set identity, boundaries and encryption in the design.
Map the failure-handling practices to the guides that cover them.
Record why you chose a design and check it on a schedule.
Cloud Architecture Best Practices: Five Pillars, Six Pillars
A pillar is a headline quality area that a provider’s framework asks you to design for. The counts differ by provider, so check which one you mean. A page that says “the six pillars” without naming one is wrong for another. As of November 2026, Microsoft’s Azure Architecture Center says the Azure Well-Architected Framework defines five, the AWS Well-Architected Framework lists six, and the Google Cloud Well-Architected Framework lists six.
| Provider | Pillar count | Pillar names |
|---|---|---|
| Azure | Five pillars. | Reliability, security, cost optimization, operational excellence and performance efficiency. |
| AWS | Six, because sustainability joins those five. | Sustainability, listed beside operational excellence, security, reliability, performance efficiency and cost optimization. |
| Google Cloud | Six, with privacy and compliance named in its security pillar. | Operational excellence, security (including privacy and compliance), reliability, cost optimization, performance optimization and sustainability. |
Key Takeaway Name the provider whenever you quote a pillar count, because the number is five on Azure and six on AWS and Google Cloud.
Cloud Architecture Best Practices, Practice 1: Start From Requirements
Write down what this workload needs before you choose any pattern. That means users and peak load, availability and recovery targets, and where data must sit. Add the rules that apply, the skills your team has and the cost limits. Your cloud architecture strategy starts here, because each later choice depends on these answers.
Apply the practices in proportion, because every workload differs in how much load it carries, how much downtime it can bear and how much change it sees. For example, a back-office reporting tool does not need what a payments service does. A design that fits the second will cost the first more effort than it returns. For availability targets and recovery objectives, Step 1 of the guide to improving application availability gives the method, so this guide does not repeat it.
Write the requirements on one page, and put the date on it so a reader knows how current they are. Each later design choice can then point back to a line on that page.
Cloud Architecture Best Practices, Practice 2: Set a Few Design Principles
Agree a short list that the team can test each design against. Your cloud architecture strategy then has something written down to compare reviews with. Google’s framework names five core principles, and they make a useful starting list. The table gives each in our own words, with the failure it prevents. The framework words them as “design for change”, “document your architecture” and “decouple your architecture”. It also lists “simplify your design and use fully managed services” and “use a stateless architecture”.
| Principle | Failure it prevents |
|---|---|
| Design for change | If the design is rigid, each release becomes a rewrite. |
| Document your architecture | Otherwise, the next engineer can’t see why a choice was made. |
| Simplify and use managed services | When a team runs everything itself, effort goes to plumbing. |
| Decouple your architecture | If parts are tied together, one failure spreads to the rest. |
| Use a stateless architecture | When servers hold state, adding or restarting one loses data. |
Azure’s design principles are a second list to read beside it. The Azure Architecture Center’s best-practices page summarises them as design for self-healing, scale out, and minimize coordination. Pick five or six that fit your workload, and then drop the rest. Keep it short. A list the team can remember is worth more than a complete one, because a long list gets skipped when a release is due.
Key Takeaway A principle earns its place when you can name the failure it prevents. If you can’t, remove it from the list.
Cloud Architecture Best Practices, Practice 3: Decouple and Keep Compute Stateless
Decoupling means separating parts so that one can fail, scale or change without the others. Queues and events do the main work: they absorb a burst and isolate a slow part from the parts that call it. The Azure Architecture Center’s background jobs guidance uses the Queue-Based Load Leveling and Competing Consumers patterns for this.
Stateless compute is the second half. It lets servers come and go. A stateless server keeps no user data of its own. State lives in a managed data store, so you can add, remove or restart servers without losing user data. For the stateless step itself, see Step 2 of the availability guide. The load-failure mechanism behind it belongs to a separate explainer on why apps fail under load.
Decoupling has a cost. Decouple where a boundary earns its cost, and leave a simple back-office tool as one piece.
Cloud Architecture Best Practices, Practice 4: Decide Where Data Lives
Make data decisions on purpose, because partitioning and caching choices shape how the application scales. Two decisions matter first: how data splits, and what is kept close to the reader.
Partition Data Before It Becomes the Limit
Partitioning splits a data store into parts, which spreads the load. Horizontal partitioning splits rows across stores, vertical partitioning splits columns by how they are used, and functional partitioning splits by business function. Azure’s data partitioning guidance says partitioning can improve scalability, availability and performance, and reduce contention. The cost is complexity. Queries that cross partitions get harder, and moving data between them takes planning.
Cache and Use a Content Delivery Network for Read-Heavy Data
A cache holds a copy of data nearby so that repeat reads skip the slow store. Azure’s caching guidance advises caching data that you read often but rarely modify, and managing data expiration so stale copies leave. It relates the guidance to the Cache-Aside pattern, which loads items into the cache on demand. A content delivery network (CDN) serves static content from locations close to users. That reduces load on the web application.
Say what happens when the cache is down: the application should slow down, not stop. When a copy of data is stale or lost, backups, restore tests and replication lag matter. They are covered in Part 3 of the high availability checklist.
Test the application with the cache switched off before launch. The result shows how much load the data store would carry on its own.
Cloud Architecture Best Practices, Practice 5: Build Security In and Limit the Blast Radius
Decide identity, network boundaries and encryption in the design, not after launch. Security belongs in the cloud architecture strategy from the first draft. Google’s framework lists “Security, privacy, and compliance” as a pillar of its own. That tells you where to read next.
Three decisions carry the practice. Give each component only the access it needs (least privilege). Then encrypt data in transit and at rest. Isolate components so that one compromised or failed part reaches only a small area of the application. That small area is what blast radius means. This guide stays with design decisions, while the checklist covers operations. For who can change production, see check 23 of the checklist.
Cloud Architecture Best Practices, Practice 6: Handle Failure by Design
A cloud architecture strategy has to say how the design survives faults. Two existing guides hold the method, and this table is a map.
| Practice | What it prevents | Where covered |
|---|---|---|
| Zones and redundancy | If one zone fails, the whole application goes down. | Step 2; check 7 |
| Timeouts, bounded retries, circuit breakers | When a dependency slows, the slowdown spreads. | Step 3; check 14 |
| Capacity, scaling, quotas | If demand outruns capacity, requests fail. | Step 4; check 18 |
| Safe release | Otherwise, one bad change reaches all users. | Step 5; check 22 |
| Monitoring | When failures go unseen, users report them first. | Step 6; check 24 |
| Recovery tests | If recovery is untried, it may fail when needed. | Step 7; check 26 |
Cloud Architecture Best Practices, Practice 7: Document Decisions and Review Against the Pillars
Write down why a design was chosen, and review it on a schedule against the pillars. Both habits make your cloud architecture strategy visible to the people who inherit it, including new hires and the teams that take over the application later.
Keep Decision Records
Google’s framework includes a principle to document your architecture, and decision records put it into practice. A short record per major decision is enough, and it needs only the choice, the options dropped, the reason and the date, written down while the discussion is still fresh. The next engineer can then see why the design looks as it does. This guide provides no template file, since a few lines in a shared document do the job.
Use a Review Habit
AWS describes the AWS Well-Architected Tool as a mechanism in the AWS Management Console. It is for regularly evaluating workloads, identifying high-risk issues and recording improvements. Azure publishes performance antipatterns, which it describes as common designs that don’t scale. It also advises using them as a checklist in design and code reviews. Treat cost as a design input at each review, alongside the pillars, but do not turn the review into a savings exercise or a hunt for items to cut.
Failover runbooks and the on-call response are covered in check 12 and check 27 of the checklist.
Add one review question per pillar to your existing release review. A new meeting isn’t needed, because the review already exists.
Signisys provides cloud services and platform engineering, and can talk through your design for scalable and resilient cloud architecture. The reliability and resilience work page explains the wider approach.
What This Guide Does Not Cover
This guide gives design practices, not the availability method or its checks. The method is in the availability guide and the checks in the high availability checklist. The comparison of high availability with disaster recovery is in a separate article. It does not define cloud architecture or explain why apps fail under load. It does not compare monolith, microservices and serverless designs, and it makes no cost-saving claims.
An outside review helps when no one owns the design, when decisions are undocumented, or before a large build. Until then, a written cloud architecture strategy and the seven practices above give a team a shared starting point. To check one design item by item, use the 21 checks for reviewing a cloud design.
Cloud Architecture Best Practices FAQ
Which practice should a small team start with?
What are the cloud architecture best practices to apply first?
How many pillars does a cloud architecture framework have?
Do cloud architecture best practices differ for AWS and Azure?
What is an architecture decision record?
When should we review the architecture?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.