Moving a commercial SaaS product into GovCloud: the parts that actually break

The situation you are probably in

A customer — or a prime, or a program office — has told you the product needs to run in AWS GovCloud (US), and probably attached an impact level to that sentence. Your product runs fine in us-east-1. You open the console, see the same service names, and reasonably conclude this is a redeploy with a different region string. That conclusion is where most GovCloud schedules go wrong. GovCloud is not a region. It is a separate AWS partition with its own identity plane, its own service catalog, its own account lifecycle, and no implicit connectivity to the partition your product lives in today.

None of this is hidden. AWS documents the differences service by service in the AWS GovCloud (US) User Guide, in a section literally titled "How [service] differs." The problem is that almost nobody reads it before quoting a date, because the architecture diagram survives the move intact and the diagram is what people estimate from. The diagram is not what breaks. The seams are. If you take one thing from this piece, take the audit at the end — run it before you put a date in a contract, not after.

GovCloud is a partition, not a region

Start with the identifier, because it propagates everywhere. In standard AWS Regions, Amazon Resource Names begin with arn:aws. In the GovCloud Regions they begin with arn:aws-us-gov, per the User Guide page "Amazon Resource Names (ARNs) in GovCloud (US) Regions." The region strings are us-gov-west-1 and us-gov-east-1.

That one-line change finds every place your codebase assumes the commercial partition: hand-built ARN strings in IAM policies and bucket policies, resource references in Terraform modules and CloudFormation templates, condition keys in trust policies, IDs baked into config maps, and any SDK code that concatenates "arn:aws:" rather than reading the partition from the caller identity. Service principals move too — the Cognito page in the User Guide documents that identity-pool trust policies in GovCloud must grant AssumeRoleWithWebIdentity to cognito-identity-us-gov.amazonaws.com, with a different principal again for US-East.

Credentials are equally hard-separated. The "AWS GovCloud (US) Compared to Standard AWS Regions" page states that you can access GovCloud only with GovCloud credentials, cannot access standard Regions with GovCloud credentials, and that GovCloud authentication is completely isolated from Amazon.com. Console sign-in uses an IAM user name and password rather than an account email address. No single set of keys reaches both sides, so every automation that touches "the AWS account" now touches two accounts, two partitions, two credential chains.

The account and organization plumbing comes first

You cannot self-serve your way into a GovCloud account the way you can into a commercial one. Sign-up includes a review to determine whether the customer is a U.S. entity whose account credentials will be managed by a U.S. person. And every GovCloud account is permanently associated with a standard AWS account: the User Guide states that all GovCloud billing is invoiced to that standard account, and that activity and usage reports are viewable only through it.

Multi-account structure has its own inversion. The AWS Organizations GovCloud page documents that you start creating GovCloud accounts by calling CreateGovCloudAccount from the management account of your organization in the commercial Region — that API is not available from within GovCloud. The call produces two accounts: a standalone GovCloud account and a paired commercial account for billing and support. The GovCloud account remains standalone until you invite it into a GovCloud organization, and accounts created in other AWS Regions can never be members of a GovCloud organization. The two organizations are independent. Available policy types are also narrower — service control policies, resource control policies, tag policies, and declarative policies for EC2 and S3 — with backup policies, chat application policies, and AI services opt-out policies documented as unavailable.

The practical consequence: a mature commercial Organizations deployment with a tuned guardrail set does not copy over. You build a second one, and some of what you built is not expressible on the other side.

Services that are not there — and services that are there differently

"Service availability" undersells the problem. The harder issue is the service that exists in GovCloud but is missing the specific feature your product depends on. A parity check at service granularity will pass and your build will still fail. Check at feature granularity.

Managed AI services carry the same pattern. Amazon Bedrock is available in both GovCloud Regions, but the User Guide enumerates a specific list of models carrying FedRAMP and IL4/IL5 authorization rather than the commercial catalog wholesale. The IAM Identity Center page notes that Amazon SageMaker AI is supported in GovCloud while SageMaker Studio, its web experience for ML workflows, is not — so if Studio is your ML team's daily driver, that is a workflow change, not a config change.

Identity and federation: you now operate two directories

IAM Identity Center is available in both GovCloud Regions, and it is the sane place to land workforce access. But it is a second instance, not a mirror. The GovCloud page documents a distinct access-portal URL pattern under start.us-gov-home.awsapps.com, instance and permission-set ARNs under the arn:aws-us-gov:sso partition, mandatory FIPS endpoints for the administrative console, SDK, and CLI, and — worth reading twice before you design for resilience — that multi-Region support is presently not available.

Because Identity Center integrates with Organizations, it inherits every Organizations difference described above. Your enterprise IdP integration is a second integration to build, test, and operate: a second SAML or OIDC trust, a second SCIM provisioning path, a second set of group-to-permission-set mappings that will drift from the commercial set unless something keeps them honest. Even the hardware is not automatically portable — the comparison page notes that GovCloud users can use the same FIDO security keys or virtual authenticator apps as commercial users, but a TOTP hardware token requires a GovCloud-specific device because of the separate authentication stack.

There is a networking chore hiding here too. The Identity Center GovCloud page publishes a list of domains that must be permitted through next-generation firewalls or secure web gateways for the access portal to work. If the environment sits behind an egress proxy — and in federal environments it usually does — that list becomes a change request with a lead time, filed by someone who does not report to you.

Egress: the assumption that quietly moves the date

This is the section that surprises commercial teams the most. A modern SaaS product is not one system; it is your code plus a long tail of outbound dependencies that nobody has enumerated in years. Every one of those calls is now a question about the authorization boundary.

FedRAMP's boundary policy (RFC-0004) frames it directly: the boundary covers everything in a cloud service offering that handles federal information or directly impacts its confidentiality, integrity, or availability — including external services, authentication systems, management tooling, and keying material. External services that meaningfully affect the security of federal information belong inside the boundary and get assessed. Low-risk ancillary systems may stay outside, documented but not tested. Reuse of an already-authorized offering is explicitly incentivized: you assess your configuration of it against the provider's customer responsibility matrix rather than re-assessing the provider.

So each outbound dependency resolves to exactly one of three outcomes, and every one of them costs something:

• Authorized offering exists — the vendor has a government edition authorized at or above your impact level. Cheapest path, but usually a different SKU, a different endpoint, a different feature set, and a separate contract.
• Bring it in-boundary — you run the software yourself inside the accreditation boundary. Now you own its patching, its STIG posture, its logging, and its place in your inventory.
• Remove it — you rewrite the feature it supported, or you ship without it. This is the honest answer more often than teams expect.

Run the inventory across all of it: payments, authentication-as-a-service, error tracking and APM, feature flags, email and SMS delivery, CDN and WAF, product analytics and session replay, package and container registries, license servers, hosted model APIs, and CI runners. Session-replay and analytics SDKs deserve particular scrutiny — they exfiltrate user content by design and are frequently invisible to the backend team. "We will just allowlist that domain" is not a mitigation; in an assessment, the allowlist entry is the finding.

Data residency is narrower than "the data stays in the Region"

GovCloud restricts physical and logical administrative access to vetted U.S. citizens, and AWS states it is appropriate for all categories of Controlled Unclassified Information. But residency is not absolute, and AWS is specific about the exceptions rather than silent about them: the comparison page notes that customer data fields defined as outside the ITAR boundary — S3 bucket names being the named example — are documented in each service-specific section as not permitted to contain export-controlled data.

For a multi-tenant SaaS product this is not a footnote. If your naming convention encodes customer identity, program names, or mission context into bucket names, queue names, or cost-allocation tags — and most do, because that is how the cost report gets read — you have a rename project. It touches infrastructure code, dashboards, alerts, runbooks, and every saved log query your on-call team relies on. Cheap before you build the landing zone; expensive after.

The dependency audit to run before you commit to a date

This is the part worth doing first, and it is mostly evidence-gathering rather than engineering. It is also the part that turns a guess into an estimate.

• Enumerate services from CloudTrail, not from the architecture diagram — pull the distinct set of API calls your production account actually made over a full billing cycle. The diagram omits things; the audit trail does not.
• Check each service and each feature against its GovCloud page — the "How [service] differs" section, not just whether the service name appears in the Region.
• Enumerate every outbound network destination — VPC Flow Logs plus egress proxy logs plus dependency manifests. Frontend SDKs count; anything a browser calls on your behalf is your dependency.
• Classify each third party as authorized, in-boundary, or removed — with a named owner and a decision date for each, because these are the long-lead items.
• Grep the codebase and IaC for partition assumptions — arn:aws: literals, hardcoded endpoint hostnames, default region constants, and any service principal string.
• Inventory every identity, human and machine — IdP integrations, OIDC trusts, cross-account roles, CI credentials, and anything that assumes one credential reaches both partitions.
• Inventory names before you build — buckets, tags, API names, descriptions, cluster and queue names; anything the service pages document as sitting outside the ITAR boundary.
• Price the target bill of materials against the GovCloud price list — AWS publishes GovCloud pricing separately from commercial pricing. Rates and available purchase options are not uniformly the same, so re-price rather than assuming a multiplier.

What actually gets rewritten

Usually not the business logic. In a well-factored product the domain code moves largely intact — the reassuring part of the report. The cost lands in the seams: infrastructure code and IAM policy, the identity plane, the CI/CD path and where its runners live, observability shipping, the egress dependencies you cannot bring, and the test suites that quietly assumed a reachable internet. Those seams are what our AWS GovCloud engineering work is scoped around.

One more thing worth budgeting: the feedback loop gets slower. Two partitions means two pipelines, two credential paths, and often a customer-controlled environment where you do not hold the console. Plan for that deliberately rather than discovering it in week six. If the end state is a build running inside someone else's accredited environment with no operator access, the constraints tighten further — that case is covered separately in headless deployment into a customer sandbox.

What we do here, and what we do not

We build and migrate workloads in AWS GovCloud (US) — landing zone and multi-account structure, Terraform, networking, identity, data services, CI/CD, and IL4/IL5 architecture patterns. We will run the dependency audit above as a discrete, scoped piece of work and give you the honest version of the answer, including when the answer is "this dependency has to go." Here is the other half, stated plainly because it saves everyone time:

We do not issue ATOs. No vendor does. An authorizing official signs an authorization for a specific system in a specific boundary. We build toward that decision and produce the evidence for it; we do not make it.

We are not a 3PAO or a C3PAO. We cannot assess you for FedRAMP or certify you for CMMC. Nor will we perform an independent assessment and then remediate our own findings — that is a conflict, and an assessor worth having will say so.

We hold no facility clearance today and do not perform classified work on classified networks. IL6 is SIPRNet territory and requires a cleared partner; if that is where the requirement lands, we will say so early rather than late.

We will not tell you a component arrives pre-accredited, because nothing does. AWS GovCloud's FedRAMP High and DoD SRG IL4/IL5 authorizations cover AWS's side of the shared responsibility model. Your application, your configuration, and your boundary are still yours to authorize. Any vendor implying otherwise is selling you a schedule they cannot keep.

We are also not a training vendor, and we do not write proposals for other firms.

If you are staring at a GovCloud requirement and cannot tell whether it is a redeploy or a rebuild, that is a normal place to be. Send us the architecture and the requirement. An engagement typically starts with the dependency audit — bounded work that produces the parity gaps, the egress inventory, and a defensible estimate — before anyone commits to a date.

Where these facts come from

Every AWS statement above comes from the AWS GovCloud (US) User Guide on docs.aws.amazon.com — the pages "What Is AWS GovCloud (US)?", "AWS GovCloud (US) Compared to Standard AWS Regions", "Amazon Resource Names (ARNs) in GovCloud (US) Regions", and the per-service pages for AWS Organizations, IAM Identity Center, Route 53, API Gateway, Cognito, SES, Bedrock, AWS Marketplace, and CloudFront setup. Boundary-scope statements come from FedRAMP RFC-0004 (Boundary Policy) on fedramp.gov. AWS adds services and features to GovCloud regularly, so re-check the current pages before designing against anything here.

Frequently asked questions