What happens when the cloud stops feeling like someone else’s computer and starts feeling like everyone’s single point of failure? That question stopped being hypothetical on 20 October 2025, when an outage traced to a latent race condition in DNS automation rippled across a large slice of the internet. The lesson was uncomfortable: most organizations did not break anything that day, yet many of them went down anyway. That gap between “your systems” and “the systems you depend on” is where most cloud infrastructure problems live. (AI cloud architecture: When infrastructure becomes intelligent) (NIST SP 800-145: The NIST Definition of Cloud Computing)
Why Shared Fate Is the First Problem Nobody Budgets For
Cloud providers sell resilience, and they largely deliver it. But resilience is not the same as independence. When thousands of customers build on the same DNS layer, the same control plane, or the same identity service, a single latent defect can cascade globally in minutes. The October 2025 event is the clearest recent example: a race condition in provider-side automation caused a backlog of DNS record updates, and downstream services failed not because of their own code but because name resolution stalled.
This is shared-fate risk, and it is structural rather than accidental. Multi-region design helps with localized failures but does little against a global control-plane problem. What actually works in practice is cataloguing which provider components sit on your critical path, then testing what your application does when those components are slow rather than dead. Teams that have rehearsed degraded DNS behavior recover far faster than teams that have only rehearsed “region goes away.”
Misconfiguration: The Problem That Belongs to You
If shared fate is the problem you inherit, misconfiguration is the one you create. The most quoted number in cloud security comes from Gartner’s 2019 forecast that through 2025, 99% of cloud security failures would be the customer’s fault, with misconfiguration the leading mechanism. Treat that figure carefully. It is a prediction, not a measurement, and it is routinely misquoted as a present-tense statistic. Provider-side incidents prove customers are not the only source of failure.
Still, the pattern is real. Public storage exposure remains stubbornly common. The Capital One breach disclosed in 2019 involved a server-side request forgery flaw against a misconfigured web application firewall and exposed records belonging to roughly 100 million US applicants and 6 million Canadians; the OCC documented an $80 million civil money penalty against the bank in 2020. The uncomfortable detail is that the storage itself was not exotic. The configuration around it was.
Practical fixes that hold up over time:
- Turn on account-level public access blocks and treat any exception as a formal, time-boxed decision.
- Scan infrastructure-as-code for policy violations before deployment, not after.
- Keep a short, enforced allowlist of approved network paths rather than reviewing firewall rules case by case.
- Tag every resource with an owner, so a finding has a name attached to it.
Identity Drift and the Permissions Nobody Remembers Granting
Ask a team who has admin rights in their cloud account and you will often get a pause. That pause is the problem. Identity and access management failures consistently rank among the top cloud threats in the Cloud Security Alliance’s Top Threats to Cloud Computing research, which groups misconfiguration with inadequate identity, credential, and access management. (Cloud Infrastructure and Architecture)
Permission sprawl accumulates quietly. A contractor needs temporary access, a pipeline needs a service role, a debugging session needs a broader policy, and nobody removes the extras afterward. The result is a permission graph that no single person understands. Enforcement beats documentation here: require short-lived credentials, scope roles to specific resources, and run automated checks that flag unused permissions after a set period. Access reviews that happen quarterly on paper tend to fail; access expiry that happens automatically tends to work.
Cost Overruns: The Silent Infrastructure Failure
Cloud problems are not always outages. Sometimes they are invoices. Industry surveys have for years found roughly 30% of cloud spend wasted, with optimizing existing usage ranking as the top initiative among respondents. Those figures come from vendor-sponsored research, so read them as directional rather than precise, and check the methodology and survey year before quoting them in a board deck.
What causes the waste is rarely one dramatic mistake. It is usually a combination: oversized instances chosen once and never revisited, storage tiers that never age out, forgotten non-production environments running nights and weekends, and data transfer charges that appear only after an architecture decision is locked in. Tracking where bytes actually move between regions, zones, and services is its own discipline, and a clearer way to track cloud data transfer costs is worth reading before the next bill arrives. (How cloud reliability skills transfer to AI infrastructure)
The habit that separates disciplined teams from the rest is simple: put a cost owner on every workload, review spend weekly at a workload level rather than monthly at an account level, and make architectural cost impact part of design review instead of a cleanup project.
Lock-In, Egress Fees, and the Exit You Never Planned
Vendor lock-in is less about where workloads run and more about how expensive and slow it is to move them. Proprietary managed services, deeply integrated identity models, and data egress charges all raise the cost of leaving. Regulators have noticed. The EU Data Act, Regulation (EU) 2023/2854, includes cloud-switching provisions with a phased removal of switching charges by 12 January 2027, which changes the negotiating landscape for anyone running workloads in Europe.
The practical countermeasure is not refusing managed services. It is knowing which ones are load-bearing. Keep portable backups in an independent format, document the data model for any service you could not replace in a quarter, and price out an exit at least once. Teams that have never estimated migration cost are usually surprised by the number.
Availability Targets That Do Not Survive Arithmetic
The math of “nines” is unforgiving. At 99.9% availability, a service can be down about 43.8 minutes per month. At 99.99%, that shrinks to roughly 4.4 minutes. Many teams promise the second number while architecting for the first.
Availability targets only mean something when they are tied to design decisions: redundancy across zones, tested failover, and honest dependency mapping. If your service depends on a component with 99.9% availability, you cannot credibly offer 99.99% without a fallback path for that component. Writing the target down and tracing it through the architecture catches more problems than most audits.
Configuration Drift and the Environments That Stop Matching
Staging and production start identical and diverge within weeks. Someone patches production directly during an incident, a manual console change never gets codified, and suddenly the environment that was supposed to predict production behavior predicts nothing.
Configuration drift is one of the most common and least dramatic cloud problems, and it quietly undermines every other control. Infrastructure-as-code and policy-as-code are the standard mitigations, but they only work when manual changes are actually blocked rather than discouraged. Container environments add their own layer of risk; NIST’s Application Container Security Guide (SP 800-190) covers image, orchestrator, and host-level threats that drift makes worse. The rule that works: if a change cannot be made through the pipeline, it cannot be made at all, and the pipeline must be fast enough that nobody wants to bypass it.
Observability Gaps and the Postmortems That Never Happen
Distributed systems fail in ways that logs alone cannot explain. A slow dependency, a retry storm, or a queue backlog can look like a dozen unrelated symptoms. Google’s Site Reliability Engineering book documents the practice that addresses this: distinguish symptoms from causes, alert on what users feel rather than on every internal metric, and run blameless postmortems that produce changes rather than documents.
The common mistake is instrumenting everything and understanding nothing. Teams drown in dashboards while lacking a single view of whether the service is healthy from the user’s perspective. Practical guidance: define service-level objectives first, alert on error budgets rather than raw thresholds, and require every incident review to end with at least one automated check that would have caught the problem earlier.
Concentration Risk and the Regulatory Response
Dependence on a handful of hyperscalers has moved from an architecture debate to a supervisory concern. The EU’s Digital Operational Resilience Act, Regulation (EU) 2022/2554, applies from 17 January 2025 and includes oversight of ICT third-party providers designated as critical. In the UK, the Bank of England’s PS7/24 policy statement on critical third parties, published in November 2024, sets out a similar oversight regime for financial services. For regulated firms, “which provider do we use” is now a question with a compliance answer attached.
For everyone else, concentration risk is still worth measuring. If three of your five most critical services sit on one provider’s control plane, you have a concentration problem whether or not a regulator is watching.
How Cloud Problems Actually Get Fixed
The pattern across all of these problems is the same. Cloud failures rarely come from a single broken component; they come from assumptions that were never tested. The team that assumes DNS will resolve, permissions are minimal, environments match, and costs are understood is the team that discovers otherwise at the worst possible moment.
What works in practice is unglamorous: rehearse degraded dependencies, expire permissions automatically, block manual changes, review costs weekly, and write postmortems that change code. None of it requires a re-architecture. All of it requires treating cloud infrastructure as something you operate rather than something you rent.
Conclusion
Common cloud infrastructure problems are rarely exotic. They are shared fate you did not map, misconfigurations you did not catch, permissions you did not expire, costs you did not attribute, and targets you did not test. Each one is manageable on its own; the danger is letting them compound quietly behind a dashboard that says everything is green. The organizations that handle cloud well are not the ones with the fewest incidents. They are the ones whose incidents are small, brief, and followed by a change that sticks.
Frequently Asked Questions
What is the most common cause of cloud outages?
Provider-side control-plane failures and customer misconfiguration both rank high, and they are different problems. Large outages often trace back to shared dependencies like DNS or identity services, while security incidents more often trace back to configuration errors inside customer accounts. Assuming either one is “the” cause usually leads teams to under-invest in the other.
Is the “99% of cloud failures are the customer’s fault” statistic accurate?
It is a 2019 forecast about failures through 2025, not a measured result, and it is frequently misquoted as a current fact. Provider-side incidents show that customers are not the only source of failure. Use the figure as a prompt to audit your own configuration, not as a settled statistic.
How much cloud spend is typically wasted?
Industry surveys have repeatedly found roughly 30% of cloud spend wasted, though figures vary by survey year, sponsor, and methodology. The more reliable signal is internal: if nobody owns the cost of a workload, that workload is probably over-provisioned.
What is configuration drift and why does it matter?
Configuration drift is the gradual divergence between environments caused by manual changes that never make it back into code. It matters because it breaks the assumption that staging predicts production, and it undermines security controls that were validated against the original configuration. Blocking manual changes entirely is more effective than documenting them.
Do egress fees really make it hard to switch cloud providers?
They contribute, along with proprietary services and integrated identity models. The EU Data Act introduces cloud-switching provisions with a phased removal of switching charges by 12 January 2027, which will change commercial calculations for many buyers. Regardless of regulation, estimating exit cost once is a useful exercise.
How many nines of availability should a typical service target?
Fewer than most teams claim. 99.9% allows about 43.8 minutes of downtime per month, and 99.99% allows roughly 4.4 minutes. The right target depends on what your dependencies can support and what your users actually notice, not on what sounds impressive in a service catalog.
