Availability improves in a fixed order. First, decide what the application must deliver. Then remove what can fail alone and plan for the failures that remain. Next, protect capacity and release safely. Last, watch from outside and test recovery. Skipping ahead adds cost without a clear gain. An example is buying a second region before setting a target. This guide is for IT heads, app owners and engineering managers at mid-size companies in India and the GCC. They run business apps on AWS, Azure or both. It sets out how to improve application availability as seven steps. Each step has a way to know it worked, an owner and the risk of getting it wrong.
Last reviewed 2026-11-01 by Manish Sharma.
Improve Application Availability: The Short Answer
Work through seven steps in order. The list below names them.
Write one target for each user journey.
Add a second path for anything that can fail alone.
Decide what the app does when a dependency fails.
Scale, shed load and test before the peak.
Keep changes small, automated and reversible.
Watch from outside and alert on what users feel.
Rehearse failures and document who does what.
Key Takeaway Each step makes the next one cheaper and safer, so the order matters as much as the content.
High availability architecture is the result of the first five steps. It is a design with no single point of failure that keeps working through the failures you expect. The last two steps check that it does.
What “Available” Means Here
An app is available when it works for its users, measured from the users’ side. A server that is up while checkout returns errors is not available. This guide covers keeping an app running. Recovery after a larger disaster is a separate subject.
Improve Application Availability, Step 1: Set a Target for Each User Journey
Decide what “available” means for each critical journey before you try to improve application availability. A checkout may need more than an admin report.
For each journey, write down the expected uptime and the tolerable downtime. Add the recovery time objective (RTO, how long recovery may take) and the recovery point objective (RPO, how much data you can afford to lose). Measure successful requests, errors and speed, not server uptime alone. A target is just arithmetic on time. The table assumes a 30-day month and a 365-day year.
| Target | Allowed downtime per 30-day month | Allowed downtime per 365-day year |
|---|---|---|
| 99.9% | 43.2 minutes | 8.76 hours |
| 99.99% | 4.32 minutes | 52.6 minutes |
| 99.999% | 26 seconds | 5.26 minutes |
Rank the risks with a simple matrix of severity and likelihood. Fix the high-impact ones first. Without a signed target, nobody can show whether a change helped. The check that Step 1 worked is a written target for each journey. The business owner signs it.
Ask the business what an hour of downtime means for each journey, such as orders missed or staff idle. Do not guess a money figure.
Improve Application Availability, Step 2: Remove Single Points of Failure
A single point of failure is one component whose failure stops the whole application. Find each one, then add a second path.
Spread Across Zones First
An availability zone is a group of datacenters within a region. It has its own power, cooling and networking, so one zone can fail while the others keep running. AWS and Azure both call them availability zones. Microsoft sorts resources into two kinds. With zone-redundant resources, the service spreads the resource and manages failover. With zonal resources, you choose the zone and manage failover yourself. A resource that uses two or more zones can survive the loss of one. Microsoft advises using multiple zones for production where they are available. It notes that zone support can depend on the service tier, so check each service. However, zones do not protect against the loss of a whole region.
Go Multi-Region Only When the Target Needs It
Multi-region designs protect against a region outage. They also add cost, complexity and operating work. AWS advises weighing the benefit against that extra cost and effort. For mission-critical workloads, Microsoft suggests using several regions and several zones. Other apps can start with several zones. Set recovery objectives for a region failure before you build it. Our post on cloud outage resilience covers outages at the provider.
A second region that nobody has tested to fail over to gives a false sense of safety. If you build one, test it.
Load Balancers, Health Checks and State
Put a load balancer in front of the app. Add health checks that take a failing server out of rotation. On AWS that is Elastic Load Balancing with health checks, and Route 53 health checks for DNS. On Azure, Azure Load Balancer or Application Gateway does the same job. Prefer several small parts to one large one, so losing one costs less. Keep servers stateless where you can. Hold state in a data store, so any server can pick up any request. Database failover and DNS caching need care. A failover that works in the database can still leave clients pointing at the old address until their cached DNS entries expire.
Improve Application Availability, Step 3: Design for Failure
Assume every dependency can fail, and decide in advance what the app does when one does.
Give each call to another service a timeout, so a slow dependency cannot hold every request. Retry only operations that are safe to repeat. These are idempotent operations, where doing the same thing twice has the same effect as doing it once. Bound the retries. Space them with exponential backoff and jitter, which adds a random delay so many clients do not retry at the same instant. Use circuit breakers to stop calls to a dependency that keeps failing. Design a fallback too. Where slightly old data is acceptable, serve the last good copy when a dependency is down.
Fault tolerance is the ability of an app to keep working through a failure. Fault isolation limits how much a failure affects. Split the app so that one fault reaches only a small part of it. Redundancy does not fix a defect that fails every time, so find and remove defects that are not transient.
A product page can show cached prices for a few minutes when the pricing service is down. That is acceptable for browsing and not for taking payment, so choose fallbacks per journey.
Improve Application Availability, Step 4: Protect Capacity
Running out of capacity is a cause of failure you can plan for. The AWS Well-Architected Framework calls resource saturation a common cause of failure in on-premises workloads. It advises that you stop guessing capacity and watch demand and use. Base scaling on measured demand, not on guesses.
Automate scaling. AWS notes that automated scaling might not respond quickly enough to changes in utilization. Then add protection for overload. Load shedding drops low-priority requests when the system is stretched. Circuit breakers stop calls to a failing dependency. Per-customer quotas, which AWS describes as a way to throttle a customer who exceeds their share, keep capacity for others. Also plan for future traffic, and load-test before the peak, whether that is a sale, a result day or a month-end run.
Pick the one resource that runs out first for each app, and test what happens when it does.
Improve Application Availability, Step 5: Release Safely
According to the AWS whitepaper “Availability and Beyond”, which cites a 1985 study by Jim Gray, failure is driven primarily by software and operations. AWS says this still holds. How you change an app matters as much as how you build it.
Make changes small, because AWS notes that smaller changes reduce the complexity of change. AWS also advises standardizing how you deploy, and automating it. The Well-Architected Framework says infrastructure changes made through automation can be tracked and reviewed. As a practice, roll out progressively, to a small share of users first, and keep a quick rollback ready. Blue-green deployment runs the new version beside the old and switches traffic. It fits where you can afford two environments. AWS puts it simply: make it easy for operators to do the right thing.
Manual changes are the hardest to review and undo. Where one is unavoidable, record who made it, when, and how to reverse it.
Improve Application Availability, Step 6: Monitor and Alert
Watch the app from outside as well as inside, and alert on what users feel.
Google’s Site Reliability Engineering book names four signals: latency, traffic, errors and saturation. Alert on symptoms that users notice. Page a person only for problems that are urgent and actionable. Also watch for silent failures, where nothing errors but nothing works. Use synthetic checks, which are scripted requests from outside, from several locations. Microsoft’s Standard availability tests in Application Insights check availability, response time and TLS/SSL certificate validity from several locations. With retries enabled, which Microsoft recommends, a test reports a failure only if three successive attempts fail. Microsoft recommends at least five locations. Then add an expiry check for certificates. Keep alerting independent of the systems it watches. On AWS, use Amazon CloudWatch and its alarms. On Azure, use Azure Monitor and Application Insights.
Key Takeaway An alert that no one owns does not help, so name the person who acts on each one.
Improve Application Availability, Step 7: Test Recovery and Write the Response
A recovery plan that has never been run is an assumption. Tests show whether the design holds.
First, run game days, where the team rehearses a failure on purpose in a safe setting. Use fault injection to confirm that automated recovery works. AWS offers AWS Fault Injection Service, and Azure offers Azure Chaos Studio. Its newer Workspaces and Scenarios model is in public preview and not meant for production use (as of November 2026). Then measure the real recovery time and data loss against the RTO and RPO from Step 1. Finally, write the response as a documented, predictable on-call procedure, so it does not depend on one person’s memory.
AWS recommends running fault injection in pre-production first, and AWS Fault Injection Service can stop an experiment when a CloudWatch alarm fires.
A Method Table: Check, Owner and Risk for Each Step
| Step | How you know it worked | Owner | What can go wrong |
|---|---|---|---|
| Set a target | Written target per journey, signed | Business owner | A target set without the business |
| Remove single points of failure | Failure of one zone or server leaves the journey working | Architect | Redundancy never tested |
| Design for failure | Dependency failure triggers the fallback | Application owner | Retries that make an overload worse |
| Protect capacity | Load test passes at the expected peak | Platform team | Scaling too slow for a spike |
| Release safely | Rollback tested; changes small | Engineering lead | Manual production changes |
| Monitor and alert | An outside check fails before users call | Operations owner | Alerts nobody owns |
| Test recovery | Measured recovery meets RTO and RPO | Program lead | Plans that have never been run |
Key Takeaway Every step needs a named owner and a way to check it worked, or it will slip back.
What This Article Does Not Cover, and When to Get Help
This guide gives the method. It does not list the causes of downtime in detail, give a checklist, or explain the difference between high availability and disaster recovery. Separate guides cover those. For the wider picture, see how Signisys helps with application uptime and availability. Our page on cloud architecture, reliability and resilience adds detail.
An outside review helps when no one owns the application, when nobody can state the target, or when recovery has never been tested. See also cloud services and platform engineering.
References
- AWS Well-Architected Framework, Design principles, Reliability pillar.
- AWS whitepaper, Availability and Beyond: Increasing MTBF, improving the resilience of distributed systems.
- Microsoft Learn, What are Azure Availability Zones?, Azure Reliability.
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.