Cloud complexity and misconfiguration epidemic¶

If you have ever stood in the middle of Ankh Morpork and wondered how a city could be both thriving and permanently on fire, you already understand modern cloud architecture. It is a place of great promise and greater confusion where good intentions go to retire, and where temporary solutions set down roots, apply for citizenship and start families.

Most organisations now operate multi-cloud and hybrid environments that resemble a badly organised thieves’ guild. You have your overlapping IAM policies that contradict one another like rival street gangs, your old S3 buckets that linger about like peculiar stains nobody remembers creating, your service accounts that refuse to die even when the systems they served have long since passed into legend, and your VPN solutions that were meant to last two weeks but are now part of the cultural heritage.

Misconfiguration has become the new malware because it is cheap, quiet and grows like weeds between the cobbles. Malware requires skill. Misconfiguration requires only enthusiasm and a console login.

The cloud promise versus reality¶

The official pitch for cloud sounded simple enough. Move to the cloud for simplicity, scalability and security. A convenient package of miracles, all available for a monthly fee.

The reality was more classically Ankh Morporkian.

Simplicity turned out to be theoretical. Scalability expanded faster than a guild budget. Security became entirely your responsibility. Cloud providers hand you astonishingly powerful tools configured in the digital equivalent of leaving the front door on the latch. If you configure it wrong and broadcast your data to the world, that is on you. They will still happily invoice you for the pleasure.

In the old days everything sat in one place. You could point at a server and say that is ours and you were mostly correct. Then cloud arrived. Suddenly nobody knows where anything lives, boundaries dissolved, and your infrastructure expanded like a hydra blessed with regeneration magic. Everyone assumed things would be simpler. Nobody was correct.

Multi-cloud, the accidental nightmare¶

There is a myth that organisations adopt multi-cloud through strategy. This is like claiming Ankh Morpork traffic patterns follow a plan. In truth, multi-cloud happens through a long series of entirely sensible decisions that, when combined, form a monument to chaos.

Email moves to Microsoft 365. Development prefers AWS. Marketing buys something shiny that lives on GCP. You acquire a company running Oracle Cloud because fate enjoys a good joke. You keep on-premises machines because some ancient application will collapse if you look at it funny. Suddenly you have four clouds, a basement server and no map.

Each cloud provider has its own arcane terminology, UI, billing, IAM philosophy and highly specific interpretation of what a firewall should be. Your security team is expected to understand all of them through osmosis. In practice they understand none of them properly and carry on bravely anyway. It is not strategy. It is anthropological study.

IAM, the permission spaghetti¶

Identity and Access Management ought to be simple. One person needs one permission to access one thing. Lovely idea. Never happens.

AWS offers a bewildering collection of users, groups, roles, policies, boundaries and trust relationships. Azure has users, groups, service principals, managed identities and hierarchical scopes. GCP has users, service accounts, groups and more kinds of roles than the Assassins Guild has excuses.

Every cloud does IAM differently and every difference creates an opportunity for confusion. Over time permissions accumulate on people like barnacles on a barge. When someone changes teams nobody removes any access because nobody can agree what is safe to remove. When someone leaves the company, a heroic but inevitably incomplete cleanup occurs. Service accounts spawned for forgotten automation continue to roam the infrastructure with ancient privileges and nobody wants to delete them in case they are load-bearing.

IAM becomes archaeology. Layers of sediment. Fragments of rituals nobody recalls performing.

The temporary bucket problem¶

Once in 2021 someone created an S3 bucket called temp-project-files-2021. The bucket was public because that was convenient at the time. The project ended. The bucket stayed. Four years later it still sits there like an abandoned shopfront containing test data, logs, credentials, backups and possibly someone’s lunch.

Nobody owns it. Nobody monitors it. Nobody remembers why it exists. Deleting it is unthinkable because something might break. So it is documented, tagged as legacy and added to the collection of haunted artefacts.

There are hundreds of them. None temporary. None safe. All awaiting discovery by some opportunistic attacker running a bucket scanner from a laptop in a coffee shop.

Service accounts and their immortal privileges¶

Service accounts are created to help applications behave. They are often given far too much power because the developer is in a hurry and the pipeline must work today. Documentation is optional. Reviews are fictional.

Years pass. The pipeline is retired. The service account continues to exist like an ancient deity nobody officially worships but everyone is afraid to anger. It still holds privileges that could level entire environments. Nobody knows what uses it. Nobody wishes to test this.

Multiply this by a hundred and you have a pantheon of immortal service accounts governing your infrastructure through sheer inertia.

The permanent temporary VPN¶

During the great remote work scramble of 2020, many organisations created temporary VPNs. These gateways were designed in haste with minimal security and maximum convenience.

It is now 2025 and those same VPNs are still here, still granting broad access to everything, still using passwords that were meant to be replaced and still vulnerable to anyone who can guess the name of the company plus a memorable year. MFA was promised. It was deployed for some. It was disabled for others during troubleshooting and never re-enabled.

This is how temporary solutions become infrastructure. Nobody meant it to happen. It just did.

The misconfiguration explosion¶

Attackers used to require actual malware. Now they need only curiosity and a scanner.

Cloud defaults often assume everything is public, exposed and cheerful. Configuration options are numerous, arcane and capable of ruining your day with a single mistaken click. Documentation warns you about what a setting does but not why it is unwise. Guardrails are mostly conceptual.

With a few wrong toggles you can create a situation so insecure that a damp goblin with a pocket calculator could exfiltrate your data.

The configuration drift problem¶

Infrastructure as code is meant to stop all this. Write configuration in code. Deploy consistently. Marvel at your own tidiness.

In reality someone always fixes something in the console before anyone updates the code. Terraform drifts out of sync. More changes are made manually. The gap widens. Eventually the code becomes fiction. The infrastructure becomes folklore.

It starts neat and ends in stories nobody believes.

The forgotten test environment¶

Somewhere out there sits a test environment created for an experiment in 2022. It contains relaxed controls, production data, half baked credentials, outdated software and a unique ability to appear completely harmless on the invoice.

Nobody monitors it. Nobody patches it. It exists solely to be exploited by the first attacker who stumbles across it. When the breach report arrives everyone says we had a test environment where.

The shared responsibility confusion¶

Cloud providers like to say they secure the cloud while you secure what you put in it. This is technically accurate and practically useless.

Clients assume cloud equals secure. Providers assume clients can configure things correctly. Everyone is wrong. Most major breaches are caused by customers leaving their digital underwear on the washing line for all to see.

It is like buying the finest bricks in the world and constructing a building shaped like an imploding flan. The bricks were excellent. The building was not.

The tools that do not help¶

Vendors offer tools that scan your cloud environment and produce alerts in numbers that should be illegal. Critical issues pile up faster than anyone can address them. Teams fix some. The tool finds more. Morale dies. Alert fatigue sets in. The tool remains installed for compliance purposes and nothing else.

This is not failure. This is tradition.

The knowledge gap¶

Cloud platforms are magnificently complicated. Teams are overstretched. Training is rushed. Everyone knows enough to deploy a VM, create a bucket and launch an app. Almost nobody knows how to harden them properly.

The gap between works and secure is enormous. Most teams operate somewhere between mostly secure and hopefully fine.

This is not incompetence. It is the inevitable result of placing everyone in a magical city full of unpredictable machinery, missing signposts and overconfident salesmen.

And thus cloud misconfiguration thrives. Not through malice. Not through stupidity. Simply because the world has become too complex for any one person or team to hold in their head.

Welcome to the modern cloud. It is not pretty. But it is yours.