The AWS Shared Responsibility Model defines the security boundary between what AWS manages and what customers must manage. When a subcontractor is operating AWS GovCloud environments on behalf of a prime, that model extends a third dimension: what the sub manages, what the prime inherits and is responsible for overseeing, and where the government program's security obligations sit.
Misunderstanding this three-party responsibility boundary is one of the most common sources of ATO control gaps on cloud programs with subcontracted infrastructure.
The Standard AWS Shared Responsibility Model
AWS describes their model as "Security OF the Cloud" vs. "Security IN the Cloud":
AWS is responsible for security OF the cloud:
- Physical data center security
- Hardware and global infrastructure
- Hypervisor and virtualization layer
- Network infrastructure (fiber, switches, hardware firewalls)
- AWS managed service security (S3 service itself, RDS service itself, etc.)
Customer is responsible for security IN the cloud:
- OS patching (for EC2 instances customer manages)
- Application security
- IAM (Identity and Access Management) — who can access what
- Data encryption (at rest and in transit) — configured by customer
- Network controls (security groups, NACLs, VPC design)
- Monitoring and logging configuration (GuardDuty, CloudTrail — customer must enable)
- Data classification and protection
This is straightforward for a single customer operating their own AWS environment. The complexity increases when a subcontractor operates AWS GovCloud on behalf of a prime under a government contract.
Adding the Sub Layer
When Rutagon operates AWS GovCloud infrastructure for a prime's government program, the responsibility model becomes:
AWS manages:
- All "OF the cloud" responsibilities above
- GovCloud-specific: US-region isolation, US-person access restrictions on AWS side
Rutagon manages (as cloud infrastructure sub):
- VPC design and network segmentation
- EC2 OS patching and hardening
- IAM role and policy management
- Encryption configuration (KMS, TLS termination, certificate management)
- Security group and NACL rules
- GuardDuty, CloudTrail, Config, Security Hub — enabled, configured, integrated
- Kubernetes cluster security (node hardening, network policies, RBAC)
- Container image management and scanning
- Infrastructure compliance scanning (Checkov, AWS Config rules)
Prime is responsible for overseeing:
- Prime ISSO is the Authorizing Official's representative — they approve the SSP
- Prime defines the system boundary and data types handled
- Prime ensures contractual flow-down compliance (DFARS, NIST 800-171)
- Prime validates sub's ATO evidence artifacts during authorization
Government program:
- Approves the Authorization to Operate
- Defines acceptable risk thresholds
- May conduct spot audits of controls
The key insight: the prime cannot delegate its security oversight responsibility to the sub. The prime ISSO must understand and attest to the sub's security architecture. This is documented in the SSP and reviewed by the AO.
GovCloud-Specific Considerations
AWS GovCloud (US) is not just a commercial region with extra settings — it's a separate, isolated AWS partition with specific characteristics that affect the shared responsibility model:
US person access restriction: AWS employees who access GovCloud infrastructure must be US citizens or US nationals, screened appropriately. This extends the shared responsibility — when Rutagon needs AWS support on a GovCloud issue, the AWS engineers who respond are US persons. This matters for ITAR-sensitive programs.
Services availability: Not every AWS service is available in GovCloud. Services in scope for FedRAMP High authorization are the operating baseline. Some services available in us-east-1 are not available in us-gov-west-1 or us-gov-east-1. Architecture must account for this service delta upfront.
FedRAMP High boundary: AWS GovCloud maintains FedRAMP High authorization. Programs operating under FedRAMP High leverage this boundary — the controls AWS has implemented pass down through the inheritance model. See AWS Lambda government compliance for how FedRAMP control inheritance applies to specific service usage.
Control inheritance: AWS GovCloud inherits a significant number of NIST 800-53 controls from AWS's FedRAMP package. Typically 170-220 controls are inherited or shared, reducing the customer's direct responsibility. However, the inherited controls must be properly documented in the SSP's control implementation statements.
The ATO Boundary and the Sub's Role
The ATO boundary defines what systems and data are covered by the authorization. For programs where Rutagon operates the cloud infrastructure:
Sub-managed boundary elements:
- VPC infrastructure (all AWS resources in scope)
- Application deployment environments (EKS cluster, EC2 instances)
- Data storage services (RDS, S3, EFS)
- Security services configuration (GuardDuty, SecurityHub, Config)
SSP contribution: Rutagon contributes the infrastructure sections of the System Security Plan — specifically the control implementation statements for infrastructure-level NIST 800-53 controls. The prime ISSO reviews, validates, and incorporates these into the program's SSP.
Evidence generation: For each control Rutagon implements, we generate evidence artifacts during the sprint cycle — Config rule compliance reports, STIG validation outputs, vulnerability scan results, patch status reports. These feed the ATO package directly.
ConMon handoff: After ATO is granted, continuous monitoring is Rutagon's ongoing responsibility for infrastructure controls. Monthly ConMon reports summarize control status, open findings, and remediation progress. See continuous monitoring NIST RMF for how automated ConMon dashboards are built.
Common Shared Responsibility Misunderstandings
Misunderstanding 1: "AWS handles security, so our cloud is secure." AWS handles physical security and infrastructure. Application security, IAM, encryption configuration, and monitoring setup are all customer/sub responsibilities. An unconfigured AWS environment is not a secure one.
Misunderstanding 2: "The sub manages everything, so we don't need an ISSO." The prime's ISSO is a required program role. They sign the SSP. They coordinate with the AO. They're accountable to the government for the system's security posture. The sub provides the technical implementation; the prime ISSO provides oversight and authorization.
Misunderstanding 3: "AWS's FedRAMP authorization covers our program." AWS's FedRAMP authorization covers the services AWS provides — not your application running on top of those services. Your application, data handling, IAM configuration, and business logic must be separately authorized in your program's ATO package.
Frequently Asked Questions
Who is responsible if a data breach occurs on Rutagon-managed GovCloud infrastructure?
Responsibility follows the shared responsibility boundary. If the breach occurred due to AWS infrastructure failure (extremely rare — essentially no real-world cases), AWS is responsible. If the breach occurred due to misconfigured IAM, unpatched EC2 instances, or disabled GuardDuty, Rutagon (the cloud operator) is responsible. If the breach occurred due to an application vulnerability in the prime's code running on the infrastructure, the prime (or application developer) is responsible. Proper SSP documentation establishes this boundary clearly before incidents occur.
How does Rutagon document what it manages vs. what the prime manages?
In the program's System Security Plan, each NIST 800-53 control has an implementation statement that specifies who is responsible. Controls with "Implemented by infrastructure sub" are Rutagon's responsibility; controls with "Implemented by prime application team" are the prime's. The SSP is the authoritative record — Rutagon maintains draft SSP sections for the controls within our boundary, and the prime incorporates them into the full program SSP.
Does Rutagon hold its own FedRAMP authorization?
We operate within the authorization boundaries of AWS GovCloud's FedRAMP High authorization and program-specific ATOs. We don't hold a standalone FedRAMP authorization — our cloud delivery occurs within government-sponsored ATOs for specific programs. For commercial programs, we operate under customer authorization frameworks.
How does the AWS shared responsibility model apply to managed services like RDS and S3?
For AWS managed services, AWS takes on more of the security stack. For RDS, AWS manages the underlying database engine patching and physical storage. The customer (Rutagon, in our programs) manages encryption key configuration, security group rules, IAM access policies, and database user management. For S3, AWS manages the service availability; Rutagon manages bucket policies, ACLs, encryption settings, and access logging configuration.
What happens to our ATO if Rutagon ends the subcontract?
Infrastructure is defined in code (Terraform, Kubernetes manifests) stored in the program's repository. All access credentials are documented with rotation procedures. Runbooks cover every operational procedure. An ATO transition plan is part of the program documentation. A competent new infrastructure team can take over from the code and documentation we leave — no institutional knowledge is held hostage.
If your prime program needs cloud infrastructure operated by a sub who understands the security boundary and generates ATO evidence as part of delivery, contact Rutagon to discuss your requirements.