AWS GovCloud Guide for Federal SaaS Vendors

Authorization gives federal SaaS vendors a path to close the federal pipeline.

A federal SaaS deployment must define where government data sits and what falls within its authorization boundary. It must also identify who operates the service and show that the service has been assessed against federal control baselines.

Amazon Web Services (AWS) GovCloud (US) answers the first two. Its regions hold Federal Risk and Authorization Management Program (FedRAMP) High authorization status and Impact Level 5 provisional authorizations, and account holders pass a U.S. person screening.

AWS's authorization covers its own infrastructure, so a SaaS vendor still owes its own authorization for everything it builds on top.

Key Takeaways

• Isolated GovCloud partition. Two regions sit apart from commercial AWS, with separate credentials and administration by US citizens.  
• Vetted account holders. The root account holder must be a US-incorporated entity with a US person holder in the seat, even without International Traffic in Arms Regulations (ITAR) data.  
• AWS authorization stops short. The vendor primarily inherits infrastructure-layer controls from AWS, while retaining responsibility for application-layer and customer-facing controls.  
• Updated sponsorship rules. FedRAMP 20x Classes A through C need no agency sponsor; Class D still does.

AWS GovCloud Is an Isolated AWS Region Built for Sensitive Government Workloads

AWS GovCloud (US) is a separate AWS partition of two regions: us-gov-west-1, launched in 2011, and us-gov-east-1, launched in 2018.

The AWS GovCloud User Guide states that the regions "are physically isolated and have logical network isolation from all other AWS Regions," and GovCloud restricts physical and logical access for supporting staff to US citizens. GovCloud credentials do not work in commercial regions, and commercial credentials do not work in GovCloud.

GovCloud's access model separates it from us-east-1. GovCloud provides a defensible basis for hosting Controlled Unclassified Information (CUI) and ITAR-regulated data. AWS permits certain non-government workloads there too, when they have specific regulatory or controlled-data requirements.

Microsoft Azure Government uses a similar isolated-cloud model with separate, pre-vetted account environments. Google Cloud's Assured Workloads applies software-defined controls within standard commercial infrastructure, keeping the vendor in one account.

AWS enforces that isolation first at the account boundary, and eligibility constrains which vendors can open an account.

Only Vetted US Entities Can Hold an AWS GovCloud Account

GovCloud sign-up is automated, but the root account holder must pass a U.S. person screening.

• Eligible organizations. GovCloud eligibility includes U.S. government agencies, contractors, commercial entities, educational institutions, and nonprofits. A commercial SaaS vendor qualifies on its own, without a government customer.  
• Account-holder requirements. The entity must be US-incorporated and based in the US, and the individual must be "a U.S. citizen or active Green Card holder" able to handle ITAR export-controlled data. AWS applies the rule even when no ITAR data is involved.  
• Ownership exclusions. Foreign nationals who are neither citizens nor Green Card holders cannot own an account, and non-US-incorporated entities do not qualify. AWS Identity and Access Management (IAM) users and end users need not be US persons; the customer must restrict them.  
• SaaS deployment options. A vendor may host government data in its own GovCloud account or deploy into another party's authorized environment. Sign-up runs through a linked standard AWS account plus the GovCloud Amendment.

Each region's compliance program determines which workloads the account can support.

GovCloud Holds AWS's Highest Compliance Authorizations Outside the Secret Region

GovCloud's authorizations top out at FedRAMP High and Impact Level 5; Impact Level 6 exists only in the AWS Secret Region. FedRAMP provides a standardized security approach based on the Federal Information Security Modernization Act (FISMA) and National Institute of Standards and Technology (NIST) security requirements. Each program covers a different slice of the federal buyer's checklist.

• FedRAMP High. The Consolidated Rules for 2026 (v2026.07.14.01) released June 24, 2026, become mandatory January 1, 2027; FedRAMP Authorized became FedRAMP Certified. Class D corresponds to the legacy High baseline minus CA-5.  
• ITAR. No certifying agency exists for ITAR, and storing unclassified technical data under end-to-end encryption is not an export.  
• Criminal Justice Information Services (CJIS). Version 5.9.5 governs FBI audits through March 31, 2027, while v6.0 and v6.1 restructure the policy into 20 control families aligned to NIST SP 800-53 Rev5.  
• DoD SRG V1R6. The December 2025 SRG sets Impact Levels for Department of War (DoW, formerly the Department of Defense) workloads: IL-2 (publicly releasable), IL-4 (CUI, including higher-sensitivity CUI on non-NSS systems), IL-5 (unclassified National Security Systems), and IL-6 (classified up to SECRET).  
• Cybersecurity Maturity Model Certification (CMMC). AWS’s Controlled Working Environment holds CMMC Level 2, which measures the defense contractor. The cloud service’s authorization is separate.  
• Federal Information Processing Standards (FIPS) cryptography. GovCloud uses FIPS 140-3-validated modules for service API endpoints unless a specific endpoint says otherwise, meeting FedRAMP requirements.

Authorization applies to services listed in scope, with coverage limited to that scope.

GovCloud Offers Fewer Services Than Commercial AWS; Vendors Should Verify Before Architecting

Service availability changes frequently in GovCloud. The AWS Regional Services table (updated daily) shows current coverage before vendors make design decisions.

Data movement and end-user access create two immediate constraints:

• Data egress needs a federal signature. FedRAMP Request for Comments 0004 requires cloud service providers (CSPs) to document every connection between the authorization boundary and external systems that handle federal data. AWS DataSync guidance states: "Any data transfer of federal information from AWS GovCloud (US) to a commercial AWS Region requires explicit authorization from the relevant federal information owners."  
• End-user access constrains the network. The Cybersecurity and Infrastructure Security Agency's TIC 3.0 Cloud Use Case defines how agencies apply multi-boundary security. IL-4 and IL-5 traffic between the DoW's unclassified network and off-premises cloud must pass through a Defense Information Systems Agency (DISA) Boundary Cloud Access Point (DISA BCAP), which the provider funds and maintains.

Resilience runs on two regions and six zones. GovCloud has no edge locations and no cross-partition failback to commercial AWS.

AWS publishes no GovCloud multiplier. Pricing varies by service and configuration, so vendors should compare current rates before finalizing an architecture and weigh infrastructure pricing alongside the full FedRAMP costs.

Service scope, network paths, and pricing together shape the architecture, but they don't change the vendor's compliance work. Controls above the infrastructure layer determine how long authorization actually takes.

GovCloud Provides Infrastructure, but FedRAMP Authorization Remains the Vendor's Job

GovCloud delivers an authorized infrastructure layer, but the vendor still owns the security work that sits above it. AWS's shared responsibility model divides security of the cloud, which AWS owns, from security in the cloud, which the customer owns. Everything above the infrastructure layer stays with the vendor and gets assessed by an independent assessment service (formerly called a Third-Party Assessment Organization, or 3PAO).

• Inherited controls are narrow. An AWS Public Sector Blog post on control ownership states: "Inherited controls exist only at the AWS infrastructure layer, covering physical security, hypervisor management, and core network infrastructure."  
• Patch management splits. AWS patches the hypervisor, while the vendor patches guest operating systems and every layer above.  
• The JAB path is gone. The Joint Authorization Board (JAB) and its provisional Authority to Operate (ATO) no longer exist as an authorization path.  
• FedRAMP 20x is the default. Classes A, B, and C need no agency sponsor, while the Rev5 agency-sponsored path stops accepting new applications on June 11, 2027.  
• Rev5 scope is heavy. Work above the infrastructure layer spans hundreds of NIST SP 800-53 Rev5 controls and traditionally takes 12 to 36 months.

Infrastructure inheritance from GovCloud narrows the assessment scope but, on its own, does not shrink the vendor's control count to a manageable level. The following sequence determines how the remaining work is planned, staffed, and delivered.

Federal SaaS Vendors Follow a Defined Sequence to Reach Authorization

The path from commercial SaaS to a FedRAMP-certified product on GovCloud runs in six steps.

1. Assessing Current Posture

Existing System and Organization Controls (SOC) 2 Type II or International Organization for Standardization (ISO) 27001 evidence can serve as a starting point for the NIST SP 800-53 baseline and reduce the FedRAMP gap.

Common remaining gaps include FIPS 140-3 validated modules, vulnerability scanning, accurate boundary documentation, and complete security documentation.

2. Defining the Target Class

Under the FedRAMP Consolidated Rules for 2026, Class C and Class D are FedRAMP certification classes with distinct NIST SP 800-53 Rev5 control baselines.

FedRAMP Moderate reciprocity reaches only IL-2, so selling CUI handling to DoW mission owners requires an IL-4 or IL-5 provisional authorization from DISA.

3. Establishing a GovCloud Account

The eligibility attestation and GovCloud Amendment run through a linked standard account. Vendors then build the separate GovCloud organization structure GovCloud requires.

4. Defining the Authorization Boundary

The boundary must include every component that handles federal information, plus privileged security tooling, authentication systems, orchestration, and keying material and secrets.

GovCloud's FedRAMP certification allows vendors to inherit eligible AWS controls and focus assessment scope on what sits above that infrastructure.

5. Engaging an Independent Assessment Service and Selecting a Path

A FedRAMP-recognized independent assessment service independently verifies and validates the vendor’s security materials.

Class A, B, or C vendors apply directly under 20x. Class D vendors still need an agency sponsor whose Authorizing Official (AO) accepts the risk, creating an additional dependency for first-time entrants.

6. Planning for Continuous Monitoring (ConMon)

Post-ATO requirements arrive monthly, so vendors typically wire them into an existing DevSecOps pipeline rather than run them as a separate project.

Under legacy Rev5 practice, each month brings scan files, Plan of Action and Milestones (POA&M) and inventory updates, and deviation requests, with an annual assessment on top.

Under the Consolidated Rules for 2026, the Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) model replaces provider POA&Ms. An immature ConMon process can delay or block certification.

These six steps consume the vendor's budget regardless of the account choice. The biggest driver of cost and timeline is whether the vendor builds its own boundary from the application layer down or inherits a pre-authorized boundary from a compliance platform.

A Pre-Authorized Boundary Shortens the Path to ATO

GovCloud settles the infrastructure question; the boundary decision settles the timeline. Traditional Rev5 authorization runs 12 to 36 months, but a platform-inherited boundary can significantly shrink that path. The choice between building and inheriting is the single largest lever a federal SaaS vendor holds over speed to federal revenue.

Knox Systems operates a pre-authorized FedRAMP boundary that lets vendors inherit most required controls rather than implement them from scratch. Vendors reach FedRAMP certification in roughly 90 days at about 90% less cost than the traditional path. Current scope covers FedRAMP Moderate, FedRAMP High, and DISA IL-4, with IL-5 authorization in process and estimated completion in December 2026.

Vendors preparing a federal launch can schedule a demo to map product architecture onto an authorized boundary and confirm which impact levels align with the target pipeline.

FAQs about AWS GovCloud

Does Deploying Through Knox Require Containerization?

No. Knox does not require containerization, so a SaaS vendor can bring its existing architecture into the deployment model without a container-specific rebuild.

Can Knox Support Clouds Beyond AWS GovCloud?

Yes. Knox supports AWS, Azure, and Google Cloud Platform within a single FedRAMP boundary. Vendors can plan federal deployments without committing the broader product to one cloud provider.

How Many Controls Can a Vendor Inherit Through Knox?

Vendors can inherit an estimated 60% to 80% of required security controls through Knox’s pre-authorized infrastructure. The vendor remains responsible for the application layer and customer-specific implementation.

What Does the Knox Deployment Model Cost?

Knox lists its managed service at approximately $500,000 per application and its platform subscription at $350,000 per year. The appropriate model depends on whether the vendor wants an end-to-end managed authorization service or support for its internal team.

‍