Layered Defense in the Cloud Era: Modernizing Infrastructure Security

Every enterprise architect I know has a version of the same story: a security review turns up a control everyone assumed someone else owned. A backup job with no encryption at rest. A management console reachable from anywhere on the internet. A firewall rule that made sense in 2019 and hasn’t been touched since. These gaps rarely come from carelessness. They come from a model of infrastructure security layering that was built for one world and is now being stretched to cover another.

I’ve spent close to 14 years designing infrastructure for organizations moving between data centers, colocation facilities, and public cloud platforms, and the pattern is consistent. Teams understand their old model well. They understand their new model less well than they think. And the handoff between the two is where incidents happen. This piece walks through how infrastructure security layering actually worked in a traditional data center, how the shared responsibility models at AWS, Azure, and GCP redraw those same lines, and what a working architect should do differently because of it.

What Infrastructure Security Layering Meant Before the Cloud

On-premises infrastructure security was built around a simple, honest premise: you owned everything, so you had to defend everything. That produced a fairly consistent stack across most enterprise environments.

Physical security came first — badge access, camera coverage, mantraps, and environmental controls around the racks themselves. Nobody got near a server without clearing a door. Next came perimeter and network security: firewalls at the edge, intrusion detection sitting behind them, VLANs and subnets carving the network into zones so a breach in one segment didn’t automatically become a breach of everything. Host and endpoint security followed — hardened operating system builds, patch cycles, local firewalls, endpoint agents watching for anomalous behavior. Application security sat above that, dealing with the code itself: input validation, secure coding practices, web application firewalls in front of anything customer-facing. Data security wrapped around all of it, with encryption, access controls, and classification schemes meant to keep sensitive information away from people who didn’t need it. And holding the whole thing together was security operations — the policies, logging, monitoring, and incident response procedures that turned individual controls into an actual defense.

That’s six layers, and if you’ve worked in information security governance you’ll recognize a related structure: ISO/IEC 27001’s Annex A, in its long-standing 2013 edition, organized its controls into 14 distinct domains, from organizational policy through physical security, operations, and supplier relationships. The number stuck with a generation of security and infrastructure professionals because it gave a sprawling discipline a checklist you could actually audit against. That instinct — break the problem into named layers, assign clear ownership to each one, and audit them independently — is the real inheritance from the on-premises era. It’s also the thing that gets lost fastest when infrastructure moves to the cloud, because the boundary between layers stops being a rack, a switch, or a locked door and becomes a line item in a provider’s documentation.

The Shared Responsibility Model Changes the Question

The phrase “shared responsibility model” gets used so often in cloud security conversations that it’s easy to stop noticing what it’s actually claiming. It isn’t a security control. It’s a division of labor. The cloud provider secures the infrastructure that runs the cloud — the physical facilities, the host hardware, the virtualization layer, and in many cases the managed service internals. The customer secures what they put on top of it and how they configure it — identity and access management, network configuration inside their own environment, data classification and encryption choices, and the security posture of whatever they deploy.

That sounds clean in a slide deck. It is much messier in practice, because the line moves depending on which service you’re using. Run a virtual machine and you own the operating system, the patching, and most of the network configuration. Run a fully managed database or a serverless function and the provider absorbs more of that burden, but you still own the data, the access policies, and how the service is wired into everything else. This is the single most common source of enterprise cloud incidents I’ve seen: someone assumes a managed service handles more than it does, because the line shifted from the last service they worked with. Get this wrong and infrastructure security layering stops being a design choice and becomes a list of assumptions nobody wrote down.

AWS, Azure, and GCP Draw the Line Differently

AWS frames its division as “security of the cloud” versus “security in the cloud.” AWS is responsible for the global infrastructure, the hardware, and the software that runs the underlying services. The customer is responsible for guest operating system configuration, network and firewall settings within their environment, identity and access management, and encryption of their own data. For infrastructure-as-a-service offerings like EC2, that customer-side list is long. For higher-level managed services, AWS absorbs more of the operational burden, but access control and data handling stay with the customer regardless of which service tier is in play.

Azure describes a similar split but ties it explicitly to service model. In an on-premises deployment, the organization owns every layer. Move to infrastructure-as-a-service and the responsibility for physical hosts, network infrastructure, and the hypervisor shifts to Microsoft, while the customer still owns operating systems, applications, identity, and data. Move further into platform-as-a-service and software-as-a-service, and Microsoft’s share of the stack grows again — but identity and access management remains a customer responsibility across every tier, which is worth repeating because it’s the layer most often mishandled.

Google Cloud takes essentially the same structure and adds a framing it calls shared fate, an acknowledgment that GCP has a stake in customer security outcomes beyond the strict contractual boundary, expressed through default-secure configurations and built-in guidance rather than a redrawn responsibility line. The underlying split — Google secures the infrastructure, the customer secures their configuration, workloads, and data — is consistent with AWS and Azure. The differences between the three providers are mostly about where the managed-service boundary sits for any given product, not about the existence of the boundary itself.

An enterprise architect running workloads across more than one of these platforms has to hold three slightly different maps of the same territory in their head at once, and that’s before accounting for whatever infrastructure security layering the organization still has to maintain on its own hardware.

Where the Comparison Actually Matters

Put the traditional model and the cloud model side by side and the honest conclusion is that infrastructure security layering hasn’t disappeared in the cloud — it’s been redistributed and partially hidden. Physical security is effectively solved by the provider and rarely worth another conversation. Perimeter security is reinvented as security groups, network security groups, VPC firewall rules, and cloud-native web application firewalls, which function like their on-premises counterparts but are defined in configuration rather than hardware, and are far easier to get wrong at scale because a single misapplied rule can expose a resource to the entire internet with no physical barrier to catch the mistake.

Host security becomes a shared concern that depends entirely on service tier — heavy for virtual machines, light for serverless. Application and data security stay squarely with the customer in almost every scenario, which is exactly where the biggest cloud breaches of the last several years have originated: not from a provider failing to secure its infrastructure, but from a customer leaving a storage bucket public, an access key in a public repository, or an identity policy far broader than it needed to be.

The uncomfortable truth for a lot of organizations is that moving to the cloud reduces the total surface area they have to defend, but it does not reduce the skill required to defend what remains. If anything it raises the skill bar, because the controls that matter most — identity, network configuration, encryption policy — are now expressed as code and can drift silently in ways a locked server room never could.

Building a Defense That Actually Spans Both Worlds

For architects running hybrid environments — and most enterprises still are, whether by strategy or by the simple fact that migration takes years — rebuilding infrastructure security layering into something that actually spans on-premises and cloud comes down to a handful of practices that consistently separate organizations with a coherent security posture from the ones patching gaps after an audit.

Map every layer to an explicit owner, on both sides of the boundary, for every environment you run. Don’t leave “who owns this” as an assumption. Write it down, service by service, and revisit it whenever you adopt a new managed offering, because the boundary moves with every new service tier.

Treat identity as the new perimeter. Across AWS, Azure, and GCP, identity and access management is the one layer that never transfers to the provider, and it’s the layer attackers target first because a stolen credential bypasses network controls entirely. Least-privilege access, short-lived credentials, and regular entitlement reviews matter more in cloud environments than they ever did on-premises.

Keep configuration under the same change control discipline you’d apply to a physical network change. A firewall rule change in a data center usually went through a ticket and a review. The equivalent cloud change — a security group edit, a storage permission change — should go through the same rigor, not less, even though it takes thirty seconds to make.

Don’t assume parity between providers. A control that’s automatic in one cloud may require explicit configuration in another. Architects working across AWS, Azure, and GCP need a service-by-service understanding of where each provider’s responsibility ends, not a single mental model applied uniformly across all three.

Keep the on-premises layers you still operate to the same standard as the day you built them. It’s common for organizations to modernize their cloud security posture while their remaining data center infrastructure quietly ages out of the review cycle, because attention naturally follows the newer, more visible project.

Closing Thoughts

Infrastructure security layering was never really about the specific list of layers — physical, network, host, application, data, operations, or any other breakdown you prefer. It was about the discipline of knowing exactly where one control ends and the next begins, and making sure nothing falls into the gap. The cloud didn’t remove that discipline. It moved half of it behind a provider’s boundary and left the rest, often the harder half, squarely with the customer. Architects who treat the shared responsibility model as a security guarantee rather than a division of labor are the ones who end up explaining an incident after the fact. The ones who treat it as exactly what it is — a map that tells you which layers are still yours — are the ones who catch the gap before someone else does.

Frequently Asked Questions

Is the cloud more secure than on-premises infrastructure?

Neither is inherently more secure; they distribute the work differently. Cloud providers typically outperform individual organizations on physical security and infrastructure-level controls simply through scale and specialization, but the customer’s share of the responsibility — identity, configuration, data handling — is just as demanding, and often more exposed to misconfiguration than an equivalent on-premises control would be.

Does the shared responsibility model differ significantly between AWS, Azure, and GCP?

The core principle is the same across all three: the provider secures the underlying infrastructure, and the customer secures what they configure and deploy on top of it. What differs is where that boundary sits for specific services, and how each provider documents and communicates it. An architect working across multiple clouds needs to verify the boundary per service rather than assuming consistency.

What is the most commonly missed layer in cloud environments?

Identity and access management. It never transfers to the provider under any shared responsibility model, and it’s frequently under-scoped, over-permissioned, or left without regular review, making it the layer attackers target most often.

Do hybrid organizations need two separate security strategies?

No — they need one strategy applied consistently, with explicit mapping of ownership at every layer in every environment. Consistent infrastructure security layering across both worlds, rather than separate mental models for on-premises and cloud infrastructure, is exactly what closes the gaps that show up during audits and incidents.

How does a framework like ISO/IEC 27001 fit into cloud infrastructure security?

Frameworks like ISO/IEC 27001 give organizations a structured way to audit layered controls regardless of where infrastructure lives. Its long-referenced 2013 Annex A, with its 14 control domains, is a useful reminder that layering and auditability were core security principles well before cloud computing existed, and they remain the right lens for evaluating a shared responsibility model today.

References