The AWS Shared Responsibility Gap: What Government IT Directors Are Still Getting Wrong

The AWS Shared Responsibility Model is one of the most cited frameworks in cloud security — and one of the most consistently misread. After twenty years of managed operations engagements with government agencies, higher education institutions, and healthcare organizations, the pattern is nearly universal: teams that understand the model in principle still underestimate what falls on their side of the line when something goes wrong.

What AWS Actually Manages

Amazon Web Services is responsible for the security of the cloud — the physical data centers, networking hardware, the hypervisor, and the managed services AWS itself operates. If a disk fails in an AWS data center, that's Amazon's problem. If the hypervisor has a vulnerability, AWS patches it. If a region-level outage occurs due to hardware failure, AWS manages the recovery.

That's meaningful. And it's genuinely different from running your own data center. But it ends at the hypervisor. Everything above it is yours.

The Gap Above the Hypervisor

When government agencies run workloads on EC2, RDS, or Elastic Beanstalk, the Shared Responsibility Model makes them responsible for the operating system, the application layer, network configuration, identity and access management, logging, monitoring, and data protection. This is not ambiguous — AWS documents it clearly. The problem isn't that agencies don't know it exists. The problem is that understanding it conceptually is not the same as operationalizing it.

The Six Things Government Agencies Consistently Get Wrong

1. OS Patching Is Not Automatic

AWS does not patch your EC2 instances. When a critical CVE is published for Linux or Windows, your team — or your managed operator — is responsible for testing and applying that patch before the vulnerability window opens. The number of government environments we've onboarded with months-old unpatched AMIs is not small.

2. IAM Is the Most Underengineered Layer

Identity and Access Management misconfigurations are the leading cause of cloud breaches. Overly permissive roles, IAM users with long-lived access keys, lack of MFA enforcement on privileged accounts, and missing service control policies at the organization level — these are not edge cases. They are baseline gaps we find in the majority of environments we assess that have been running for more than a year without active management.

3. Network Configuration Requires Ongoing Attention

A VPC that was configured correctly at launch drifts. Security group rules accumulate. Port 22 gets opened for a troubleshooting session and never closed. Network ACLs get bypassed by security groups. Peering connections outlive their purpose. Without someone reviewing network configuration as a standing operational responsibility — not a one-time setup task — the attack surface grows silently.

4. CloudTrail and GuardDuty Are Not Monitoring — They're Inputs to Monitoring

Enabling CloudTrail and GuardDuty is not the same as having a monitoring posture. Logs need to be aggregated, retained appropriately, and actively reviewed. GuardDuty findings need to route to someone who will act on them. We've reviewed environments where GuardDuty had hundreds of unacknowledged medium-severity findings stretching back eighteen months — technically enabled, operationally inert.

5. Application Security Is Yours

AWS WAF can be configured and managed to block common attack patterns, but it doesn't configure itself. HTTP security headers, HTTPS enforcement, dependency vulnerability scanning, and input validation for web applications all sit above the shared responsibility line. For agencies running CMS platforms or custom web applications, this layer is frequently the least governed.

6. Backups Are Validated at Restore, Not at Snapshot

RDS automated backups and EC2 AMI snapshots give you backup artifacts. They don't tell you whether those artifacts actually restore to a functional state under time pressure. We consistently find that government organizations report having backups — and haven't tested restoration in years. RTO and RPO targets written in a BCP document are not operational reality until they've been validated under simulated failure conditions.

The Integrator vs. Operator Distinction

There's a meaningful difference between a cloud integrator and a cloud operator. An integrator builds the architecture, configures the environment, and hands it over. An operator takes ongoing responsibility for keeping it running, patched, monitored, and secure — indefinitely, under SLA, with a defined escalation path when something goes wrong. For agencies running CMS workloads on AWS GovCloud, that operator role is what managed Drupal hosting for government is structured to deliver: the SBA 8(a) procurement path with NIST 800-53 and FedRAMP-aligned controls operated continuously.

Most government agencies that "have AWS managed" have actually engaged an integrator. The environment was configured at a point in time — possibly well — and has been drifting since. Nobody patched the OS last quarter because that wasn't in the statement of work. Nobody reviewed IAM because the engagement closed when the migration finished.

The Shared Responsibility Model doesn't create a gap because it's poorly designed. It creates a gap because "security in the cloud" requires continuous operational ownership — and continuous ownership requires someone who is actually on the hook for it every day.

What to Ask Any AWS Partner Before Signing

• Who owns OS patching, and what's the SLA for critical CVEs?
• Who reviews IAM roles and access keys on what cadence?
• Who receives GuardDuty alerts, and what's the escalation path?
• How often is backup restoration tested, and who validates it?
• What does monthly governance reporting include, and who receives it?
• If something fails at 2am, who gets paged — and is that in the contract?

If these questions don't have clear, contractual answers, you have an integrator — not an operator. The AWS Shared Responsibility Model doesn't close itself. Someone has to own the other half. For agencies that prefer a single contract spanning AWS operations and the Drupal application layer, our SBA 8(a) Drupal hosting partner practice is structured around exactly that.