When Cloud Goes Down: The Hidden Risks of Centralised Infrastructure

Learn how centralised cloud infrastructure creates shared failure risks and how businesses can improve cloud resilience and recovery.

Centralised cloud infrastructure means running applications and storing data on shared cloud platforms and services. For example, what happens when an online store cannot verify customer logins because a cloud identity service becomes unavailable? The website may remain online, yet customers cannot complete their purchases. Understanding these dependencies helps businesses plan for outages and maintain essential services.

What Is Centralised Cloud Infrastructure?

Centralised cloud infrastructure brings computing, storage, networking, databases, and other services into a shared cloud environment. Teams can manage these resources through common platforms instead of maintaining every component themselves. However, this convenience can create dependencies between systems that must work together.

A typical business application may depend on several cloud components:

• Compute: Runs application code and background jobs.
• Databases: Store customer records, orders, and transactions.
• Networking: Connects application components and routes requests.
• Identity services: Authenticate users and control access.
• Storage: Holds files, images, backups, and application data.
• Monitoring: Collects metrics, logs, and alerts.

These components may use different services, but they can share the same region or underlying infrastructure. A failure in one dependency can therefore affect several application functions.

Centralised cloud infrastructure does not automatically create a single point of failure. The risk depends on how teams distribute workloads, isolate dependencies, and design recovery paths.

How Centralised Cloud Infrastructure Creates Failure Risks

Cloud providers operate large, distributed environments. However, an application can still concentrate its dependencies in one region, account, or service. The following design choices can increase outage risk.

Shared Dependencies Across Applications

Several applications may rely on the same database, identity provider, DNS service, or network path. If that dependency fails, every connected application may experience problems.

For example, a company might operate its website, customer portal, and internal dashboard in the same cloud region. All three may depend on one identity service. An authentication failure could block employees and customers, even when the application servers remain healthy.

Regional Concentration

Availability zones protect against certain failures within a region. They do not protect an application from every regional disruption.

A business may distribute servers across multiple zones but keep its database, identity dependencies, or recovery tools tied to the same region. A larger regional incident could still interrupt service.

Control-Plane Dependencies

Cloud platforms separate control-plane operations from application data processing. The control plane manages resources, while the data plane handles workload operations.

A control-plane disruption may prevent teams from creating instances, changing configurations, or managing services. Existing workloads may continue running, depending on the affected service and architecture. Therefore, teams should test both application availability and recovery operations.

Recovery Bottlenecks

Backups alone do not guarantee quick recovery. Teams also need access to credentials, configuration files, deployment tools, network settings, and recovery instructions.

If these dependencies become unavailable during an incident, restoring the application can take longer. Centralised cloud infrastructure needs a recovery plan that accounts for the systems required to restore service.

AWS US-East-1 Outage: Lessons from a Real Incident

On December 7, 2021, AWS experienced a major disruption in its US-East-1 region. Its official post-event report described network congestion between AWS’s internal network and its main network.

An automated scaling activity triggered unexpected behaviour among many clients in the internal network. Their connection attempts overwhelmed network devices, causing communication delays and errors. Repeated retries added to the congestion.

The incident also affected internal monitoring and deployment systems. This made diagnosis and recovery harder for AWS’s operations teams. AWS reported that congestion improved during the afternoon, with affected network devices fully recovering by 2:22 p.m. Pacific time.

Several AWS services experienced elevated errors or delays. Public reports also documented problems with consumer and business services that relied on AWS. However, the disruption did not mean that every AWS workload stopped working.

The event exposed an important distinction. A cloud provider can distribute infrastructure across large systems, yet shared dependencies may still create failure paths.

How Cloud Outages Spread Across Applications

Cloud outages can spread when applications depend on services that share infrastructure or recovery requirements. Consider an online store that uses cloud-hosted application servers, a database, identity services, and monitoring.

A failure may unfold in this order:

1. A shared dependency becomes unavailable. Authentication requests begin to fail or time out.
2. Application functions degrade. Customers cannot sign in or access account-specific features.
3. Transactions fail. The checkout process cannot confirm identity, retrieve data, or complete payment workflows.
4. Retries increase traffic. Applications repeatedly request unavailable services, adding pressure to already strained components.
5. Diagnosis becomes harder. Monitoring gaps or inaccessible management tools delay investigation.
6. Recovery takes longer. Teams must restore dependencies, validate data, and confirm that connected services work again.

This sequence is an example, not a description of every cloud outage. Actual impact depends on the failure, application design, timeout settings, retry behaviour, and available fallback paths.

Teams can reduce cascading failures by setting sensible timeouts, limiting retries, using backoff, and isolating critical components. They should also test whether applications can handle partial failures without taking down unrelated functions.

The Business Cost of Centralised Cloud Infrastructure Failures

The business impact depends on the application and the duration of disruption. A short outage may cause inconvenience, while a longer incident can interrupt essential operations.

Common consequences include:

• Lost revenue: Customers cannot complete purchases or renew subscriptions.
• Operational delays: Employees lose access to internal tools and business data.
• Support pressure: Customers report errors while support teams investigate the incident.
• Data processing delays: Queued jobs, event delivery, and integrations may fall behind.
• Recovery costs: Engineers spend time restoring services and checking system integrity.
• Customer trust issues: Repeated interruptions can reduce confidence in the service.

Not every outage causes data loss, and not every affected application becomes completely unavailable. Businesses should measure the risks that matter to their own services.

Two useful measures are recovery time objective (RTO) and recovery point objective (RPO). RTO defines the target time for restoring service. RPO defines how much recent data loss the business can tolerate.

These targets help teams decide which systems need automated failover, replicated data, or simpler recovery procedures.

How to Reduce Centralised Cloud Infrastructure Risks

Reducing cloud outage risk does not require every business to adopt a multi-cloud architecture. Start by identifying critical dependencies and matching recovery controls to business needs.

1. Distribute Workloads Across Availability Zones

Deploy application components across separate availability zones where the cloud service supports this design. Use load balancing and health checks to route traffic away from unhealthy instances.

However, zone redundancy only helps when the required dependencies also remain available. Check databases, network paths, credentials, and other supporting services.

2. Prepare for Regional Failures

For critical applications, consider a recovery environment in another region. Depending on the recovery target, this may be a warm standby, a pilot light, or a fully active deployment.

Cross-region recovery requires more than copying application files. Teams must plan for data replication, DNS changes, identity access, secrets, network rules, and traffic routing.

3. Keep Independent, Recoverable Backups

Store backups in a way that protects them from failures affecting production resources. Apply suitable access controls and retention policies.

Test restoration regularly. A successful backup job does not prove that the team can restore a usable application within its recovery targets.

4. Monitor User-Facing Service Health

Monitor application requests, transaction success, latency, and dependency health. Use alerts that identify business impact, rather than relying only on infrastructure metrics.

Where practical, keep monitoring access independent from the systems being monitored. Maintain an alternative communication channel for incident updates.

5. Control Retries and Isolate Failures

Set connection timeouts and retry limits for dependent services. Use exponential backoff and jitter where appropriate to reduce synchronized retry traffic.

Circuit breakers can temporarily stop calls to failing dependencies. Queues can also help separate services, provided the application handles delayed or duplicate messages safely.

6. Test Disaster Recovery Procedures

Run recovery exercises that cover realistic failure scenarios. Include unavailable credentials, broken network paths, delayed replication, and inaccessible deployment tools.

Record the actual recovery time and any data gaps. Update the plan when tests reveal missing access, outdated instructions, or manual steps that delay service restoration.

For additional planning ideas, see Bobcares’ guide to cloud disaster recovery strategies.

Choosing the Right Cloud Resilience Strategy

Every resilience measure adds cost, complexity, or operational work. The right design depends on business impact, recovery targets, technical limits, and available engineering resources.

Strategy	Main benefit	Key limitation
Multiple availability zones	Helps withstand certain zone failures	Does not cover every regional or shared-service failure
Cross-region recovery	Supports recovery from regional disruption	Requires data replication and tested failover
Independent backups	Helps restore lost or damaged data	Restoration may take time and cause service downtime
Multi-cloud deployment	Reduces some provider-specific dependencies	Adds integration, security, monitoring, and operational complexity
Monitoring and recovery drills	Improves detection and recovery readiness	Cannot prevent every failure

Multi-cloud is not automatically the safest choice. Running the same application on two providers can create new dependencies in identity, networking, data consistency, and deployment.

Some businesses gain more protection by improving one cloud environment, separating critical dependencies, and testing regional recovery. Others may need broader provider diversity because of strict availability requirements.

Start with a dependency map. Identify what must remain available, what can fail temporarily, and what the team needs to restore service. Then select controls that meet the agreed RTO and RPO without adding unnecessary complexity.

Frequently Asked Questions

Does Centralised Cloud Infrastructure Always Create a Single Point of Failure?

No. Cloud platforms offer redundancy across zones and regions. Risk increases when applications rely on shared components without independent recovery paths.

Are Multiple Availability Zones Enough to Prevent Cloud Outages?

No. Availability zones help with certain local failures, but they cannot prevent every regional, service-level, or configuration-related incident. Applications must also account for dependencies outside the protected zones.

Does Multi-Cloud Eliminate Cloud Provider Risk?

No. Multi-cloud can reduce some provider-specific risks, but it adds operational complexity. Shared application bugs, identity dependencies, data issues, and configuration errors can still cause outages.

How Often Should Teams Test Disaster Recovery?

Test recovery at intervals that match business risk and operational changes. Critical systems may need frequent automated checks and scheduled recovery exercises. Retest after major architecture, identity, network, or backup changes.

What Should a Cloud Recovery Plan Include?

Include recovery targets, dependency maps, backup locations, access requirements, restoration steps, traffic switching, communication procedures, and validation checks. Assign owners and record test results so the plan remains usable during an incident.

Conclusion

Cloud platforms reduce the burden of operating physical infrastructure, but they do not remove the need for resilience planning. Shared dependencies can affect several services at once, especially when teams concentrate workloads and recovery tools in one environment.

Businesses can limit the impact through suitable redundancy, independent backups, controlled retries, monitoring, and tested recovery procedures. The goal is not to prevent every failure. It is to keep failures contained and restore essential services within agreed limits.