The Cloud Sold You Complexity. It Called It Security.

Your cloud provider's IAM console has 1,200 possible permission actions. Your attack surface is not a misconfigured server. It's the system itself.

By Catalin Sugau · Sugau Infrastructure

There is an axiom in security that has been quietly buried under a decade of cloud marketing: you cannot audit what you cannot understand. A system you cannot fully audit is, by definition, not secure. It is merely unverified.

Cloud providers have built empires on the premise that complexity, managed by them, is equivalent to safety. It is not. It is the opposite. And as a CTO, the moment you accepted that premise, you handed the keys to a building whose floor plan only your landlord fully knows.

Simplicity is not a constraint. It's a property.

Consider a bare Linux server running a single application. SSH access via key pairs. A stateful firewall. No inbound ports except the one the application needs. Two engineers can read the entire security configuration in an afternoon. Every rule has an owner. Every permission has a reason. The threat model fits on a whiteboard.

Now consider AWS. To deploy the equivalent application you are expected to navigate IAM policies, resource-based policies, permission boundaries, Service Control Policies, identity federation, VPC security groups, NACLs, endpoint policies, resource tags used as conditions, and a service catalog that adds a new product roughly every two weeks. The AWS IAM policy engine alone has over 1,200 documented action strings across its services. Each one is a potential misconfiguration.

“The number of possible permission states in a mid-size AWS account exceeds what any human team can reason about completely. That is not a bug in your configuration. It is a feature of the product.”

The Verizon Data Breach Investigations Report has consistently identified misconfiguration as one of the leading causes of cloud breaches for years running. Gartner estimated that through 2025, nearly all cloud security failures would be the customer's fault. The cloud vendors love that framing. It neatly externalises the liability for a complexity they designed and profit from.

Complexity as a business model

Let's be direct about the incentive structure. AWS, Google Cloud, and Azure are not in the security business. They are in the consumption business. Every new service they launch — every new managed identity provider, every new policy primitive, every new network abstraction — is a billable unit. Complexity is the product. Security certifications are the marketing.

SOC 2 Type II. ISO 27001. FedRAMP. These are not evidence that your workload is secure. They are evidence that the provider's internal controls meet a documented baseline. Your configuration, your IAM sprawl, your forgotten S3 bucket with a public ACL set in 2019 — none of that is covered. The certification gives you comfort while your actual exposure accumulates silently.

The cloud providers will tell you the answer is more tooling: GuardDuty, Security Hub, Macie, Defender for Cloud. More products, more dashboards, more alerts — each generating revenue, each adding another system you must learn, monitor, and trust. Security theatre priced as a managed service.

The engineer who built your on-premise rack never needed a certification to know it was locked

There was a time — not so long ago — when a senior infrastructure engineer could walk into a data centre, look at the physical topology, read the firewall ruleset, and give you a confident answer about what was and was not reachable from the outside world. That confidence was earned through simplicity and legibility. The system was small enough to hold in one mind.

That is not nostalgia. It is a security property. Systems that are legible to their operators are fundamentally more secure than systems that require a dedicated toolchain to observe. When you need a PhD in cloud IAM to reason about whether your production database is internet-accessible, you have already lost the audit.

“Secure by default means that if you do nothing, the system is safe. The cloud's default is permissive, sprawling, and expanding. You must actively fight the architecture to make it secure.”

What CTOs should be asking

The question is not whether the cloud provider is secure. They probably are, within their own perimeter. The question is whether your organisation has the operational capacity to maintain a secure configuration across a system of this complexity — permanently, through staff changes, through sprint pressure, through the 3am emergency deploy that skips the security review.

The honest answer, for most organisations, is no. And no amount of CSPM tooling changes that fundamental equation.

The alternative is not a return to physical infrastructure for its own sake. It is a deliberate choice to right-size your infrastructure to your operational reality. Run fewer services. Own fewer abstractions. Prefer systems your team can fully reason about over systems that impress on an architecture diagram. Accept that a smaller, legible system is more secure than a larger, certified one.

Complexity is not sophistication. It is accumulated risk. And someone is billing you for every unit of it.

Catalin Sugau is a senior infrastructure engineer and founder of Sugau, a consultancy specialising in bare-metal Kubernetes, private AI infrastructure, and cloud repatriation. sugau.com