Cloud in Strategic Sectors: Engine of Innovation or Systemic Risk?
Yesterday morning, October 20, 2025, went down in tech history as "Black Monday" of the digital age. The global Amazon Web Services (AWS) outage, with its epicenter in the critical US-EAST-1 region, wasn't just another minor hiccup. It was a systemic heart attack. For over fifteen hours, we watched a domino effect paralyze not only streaming services and social media but also banking systems, airlines, and even—what was particularly painful for us—the services of Poczta Polska (the Polish Post).
This event, caused by a trivial DNS error in the DynamoDB database service, exposed a terrifying truth about our civilization: we have built our global economic and social system on an infrastructure controlled by just three (well, maybe four) corporations.
As a cybersecurity section editor, I've been watching the debate about the cloud for years. For a long time, the dominant narrative was "Cloud First." It was synonymous with modernity, agility, and innovation. After yesterday's chaos, that narrative seems not only naive but downright dangerous.
Today, I don't want to ask if companies should move to the cloud. I want to ask: can strategic state sectors—the military, medicine, and critical infrastructure—even afford this model? And if so, at what cost?
The Siren Song of Innovation: Why We Fell in Love with the Cloud
Before we get to the risks, let's be honest. The cloud isn't just a marketing gimmick. It's a fundamental revolution in access to technology, and it has three powerful advantages.
First, economy. The cloud performed a miracle, transforming massive capital expenditures (CAPEX) into flexible operational expenditures (OPEX). Instead of spending years building their own server rooms, buying expensive hardware, and worrying about cooling and power, companies could start "renting" computing power by the minute. This democratized innovation, allowing startups to compete with giants.
Second, scalability. The cloud solved the "Black Friday" problem. Our infrastructure can now be as elastic as rubber—shrinking at night and stretching to unimaginable sizes during peak load.
Third, and perhaps most important today, innovation. The real value of the cloud is no longer virtual machines. It's the ready-to-use, advanced services—platforms for Big Data analysis, machine learning (ML), and, above all, generative artificial intelligence (AI). Today, no serious company "builds" its own AI model from scratch. It rents it from Google, Microsoft, or AWS. This is why migrating to the cloud is no longer an option; it's a competitive imperative.
The Giants' Hangover: Concentration Risk and Loss of Sovereignty
And just at this moment, at the peak of our addiction, October 20th arrived. The AWS outage showed the other side of the coin, which is no longer a theoretical risk but a tangible reality.
The problem isn't that the cloud can fail. The problem is that the entire cloud can fail at once.
We are talking about systemic concentration risk. We've built the global digital economy on just a few pillars. When one of them—in this case, the US-EAST-1 region—begins to wobble, the earthquake is felt worldwide. Yesterday's incident was a perfect illustration of a cascading failure. The DNS for DynamoDB went down, taking 64 other, seemingly independent AWS services with it. This wasn't a server failure; it was a Jenga tower collapsing, where pulling one block from the base brought down the entire structure.
The second, equally serious problem is the issue of sovereignty. Why did an outage in a Northern Virginia data center in the USA affect the operations of the Polish Post? This rhetorical question perfectly illustrates how the abstract concept of "digital sovereignty" translates into hard operational reality. Our data and processes, even those crucial for the functioning of the state, are physically and logically dependent on a commercial company's infrastructure, subject to the jurisdiction of another country.
For an online store or a dating app, an outage lasting over ten hours is a massive financial and reputational loss. But for a hospital, a power plant, or a military command system? It's a catastrophic scenario.
Sectoral Analysis: When "Cloud First" Meets Reality
Let's analyze what this new reality means for strategic sectors. In their case, it's not just cost and innovation that matter, but above all, resilience and mission assurance.
1. Military and Defense: The Digital Battlefield
Armies around the world, including NATO, are investing in the "Combat Cloud" concept. The idea is for data from drones, satellites, tanks, and soldiers (C4ISR) to flow into one place, be analyzed by AI, and give commanders a real-time picture of the situation.
The Problem: Public cloud architecture operates on a "best-effort" model. There is no room for that in the military. Command systems must be deterministic—they must work always, predictably, and with a guaranteed response time. You cannot afford an "authentication error" or a "race condition" when a missile is being launched or intelligence data about an attack is being analyzed.
Conclusion: Relying on a commercial, foreign public cloud for core command systems is strategic suicide. An outage like yesterday's could blind an army at a critical moment of crisis. Therefore, the model for the military must be hybrid. Historical data analysis, training, logistics—these things can run in a public cloud. But real-time C4ISR systems must remain in a private (on-premise) cloud, often physically air-gapped, with key computing capabilities pushed to the "edge" (edge computing)—in vehicles, ships, and forward operating bases.
2. Medicine and Healthcare: The Patient with Near-Zero RTO
The medical sector is undergoing a revolution thanks to the cloud. Electronic Health Records (EHR), telehealth platforms, AI analysis of diagnostic images (X-rays, MRIs), and rapid genomic research—this is all happening in the cloud.
The Problem: In medicine, two metrics are key: RTO (Recovery Time Objective—how quickly the system must be back after a failure) and RPO (Recovery Point Objective—how much data we can afford to lose). For a hospital's EHR system, which the emergency room relies on, RTO must be near-zero. A doctor must have immediate access to a patient's history, allergies, and medications.
Conclusion: An AWS outage lasting over ten hours is not a business problem in the healthcare sector. It's a scenario of direct threat to life and health. Imagine an ER doctor unable to access the data of a patient in critical condition. Remember that ransomware attacks on hospital networks are no longer theoretical—they're reality. A cloud outage can have equally catastrophic consequences. Therefore, for medicine, relying on a single public cloud provider, regardless of their marketing promises, is unacceptable. This forces the adoption of a hybrid or, more likely, a multi-cloud architecture, where data is replicated and systems are ready for immediate failover to another, independent provider.
3. Critical Infrastructure: When a Digital Failure Becomes Physical
We are talking about the backbone of the state: energy, transport, water supply, and the financial sector. These sectors are increasingly embracing the cloud to manage smart grids, optimize energy distribution, control traffic, and analyze risk.
The Problem: In critical infrastructure, there is a convergence of the IT (Information Technology) and OT (Operational Technology) worlds. To put it simply: digital systems control physical devices. An IT system failure can cause a catastrophe in the physical world. If the energy grid balancing system, based on cloud analytics, stops working, the result could be a widespread blackout. If rail traffic control systems fail, the result could be chaos or disaster. It's also worth remembering that the Polish energy sector is the target of thousands of cyberattacks—additional cloud-related risk could be the straw that breaks the camel's back.
Conclusion: The strategy for this sector must be the most conservative. A "private cloud first" policy must be adopted for all core OT systems. SCADA systems that control the flow of energy or water should never be directly exposed to the risk of a commercial public cloud failure. The public cloud is an excellent tool for business intelligence (IT), forecasting consumption, or customer service, but the operational core must remain under full, sovereign control.
The Polish Context: Rapid Adoption and Strategic Debt
Against this backdrop, the Polish cloud market is fascinating. We are in a phase of dynamic growth, fueled by the opening of cloud regions in Poland by Google, Microsoft, and AWS. Companies and the public sector have jumped at the new opportunities, mainly in pursuit of AI innovation.
The problem is that our adoption is often tactical, not strategic. We lack maturity. As reports indicate, many companies and institutions, excited about their new toys, are building their strategies based on a single provider.
In doing so, we are racking up a massive "strategic debt". We migrate quickly to cut costs and gain access to AI, but we don't invest in resilient architecture. We are becoming hostages to one ecosystem (so-called vendor lock-in). Yesterday's outage showed just how painful it can be to repay that debt. Our digital ecosystem, built in haste and without diversification, may be disproportionately vulnerable to future hyperscaler outages. It's also worth noting that the NIS2 Directive imposes business continuity requirements on essential and important entities—relying on a single cloud provider could be considered a violation of these requirements.
From "Cloud First" to "Cloud Smart": An Architecture of Resilience
So, what should we do? Should we turn our backs on the cloud and go back to building server rooms in basements? Absolutely not. That would be setting our development back a decade and giving up on innovation.
The events of October 20, 2025, do not mark the end of the cloud era. They mark the end of the naive cloud era. The slogan "Cloud First" is dead. We must replace it with a "Cloud Smart" strategy.
"Cloud Smart" is the understanding that the cloud is not a monolith, and resilience is not a feature you can "turn on," but a foundation you must design. The answer to concentration risk is not retreat, but diversification.
The architectural imperative becomes Multi-Cloud.
Relying on one provider is a strategic mistake. True systemic resilience requires distributing critical workloads across at least two independent providers (e.g., AWS and Azure, or GCP and a private cloud). There are three basic models for this architecture:
- Backup and Recovery: The simplest. We keep backups with another provider. In case of an outage, we manually restore the systems. The recovery time (RTO) is long (hours, even days), but we protect the data. Good for archival systems.
- Active-Passive Failover: The main system runs in Cloud A, while a "warm" standby environment, ready to take over traffic, waits in Cloud B. Data is continuously replicated. In case of failure, traffic is switched over. RTO is measured in minutes or hours. This is the absolute minimum for most critical services.
- Active-Active Distribution: The gold standard. The application runs simultaneously in both clouds, and user traffic is load-balanced between them. A failure in one cloud is unnoticeable to the end-user—traffic automatically flows to the other. RTO/RPO are near-zero. This solution is expensive and complex, but for real-time banking, emergency medical systems, or infrastructure control—it is the only acceptable one.
Of course, multi-cloud is complex. It requires standardization, automation (e.g., via tools like Terraform), and containerization (Kubernetes) to make applications "portable." It also requires immense competence within IT teams. But after October 20th, we now know that the cost of this complexity is still lower than the cost of systemic paralysis.
Yesterday's outage is a brutal but necessary wake-up call. The cloud will remain the engine of innovation. But for the strategic sectors on which our physical and economic security depends, we can no longer treat it as a magical, infallible entity. We must start treating it as what it is: a powerful but complex tool that demands mastery, risk diversification, and strategic prudence.
Aleksander
About the Author
Dyrektor ds. Technologii w SecurHub.pl
Doktorant z zakresu neuronauki poznawczej. Psycholog i ekspert IT specjalizujący się w cyberbezpieczeństwie.
Powiązane artykuły
Anatomia Katastrofy: Dlaczego Cloudflare zamilkł? Techniczna analiza incydentu z 18 listopada
18 listopada internet wstrzymał oddech. Cloudflare, gigant CDN, zamilkł na kilka godzin. To nie był atak DDoS, lecz błąd, który obnażył kruchość współczesnej infrastruktury. Oto dogłębna analiza techniczna tego, jak jedna zmiana uprawnień w bazie danych położyła na łopatki połowę sieci.
Internet na Kolanach: Cloudflare Pada Miesiąc po AWS. Kronika Czarnej Jesieni
18 listopada zapisze się jako dzień, w którym "Error 500" stał się najczęściej oglądaną stroną świata. Cloudflare dołączył do AWS, paraliżując X, ChatGPT i Zoom. Analizujemy przyczyny i skutki.
Luki 0-Day: Niewidzialna Broń. Anatomia, Rynek i Obrona przed Nieznanym
Kompleksowa analiza fenomenu Zero-Day: od technicznych detali uszkodzeń pamięci, przez wielomilionowy czarny rynek i historię cyberbroni (Stuxnet, Pegasus), aż po polskie realia prawne i strategie obrony w dobie AI.
Komentarze
Ładowanie komentarzy...