Deploy Previews on AWS GovCloud: A Practical Guide

You can run preview environments on AWS GovCloud. The question is whether the deployment model your team uses in commercial AWS still applies. For most federal contractors, it doesn’t. The shape of preview tooling changes when you cross the GovCloud boundary, and the changes have less to do with technology than with authorization.

This guide assumes you already operate in GovCloud, hold or are pursuing an ATO, and understand the FedRAMP authorization boundary.

What’s Different About GovCloud

GovCloud (US-East and US-West) is a separate AWS partition with its own IAM, ARNs, and service inventory.

Service availability lags. Most core services are present — EC2, ECS, EKS, RDS, S3, ALB, Route 53, KMS. Newer services arrive months to years behind commercial regions, and some never arrive. App Runner, App Mesh, several Bedrock models, and a handful of DevOps services have historically been late or absent. Check the GovCloud Services in Scope page before designing anything.

U.S. persons access is a hard boundary. GovCloud is operated only by U.S. persons on U.S. soil — AWS personnel and, by inheritance, anyone with admin access to your tenant. If your preview tooling runs as SaaS in commercial AWS and its support engineers are not all U.S. persons, the tool cannot operate inside your GovCloud boundary on your behalf.

ITAR and CUI drive region choice. GovCloud is the partition designated for ITAR and most CUI categories. It is FedRAMP High at the infrastructure layer. That authorization does not extend to anything you deploy on top.

Cost premium is real. Compute, storage, and data transfer run roughly 15–25 percent above commercial pricing. Cross-partition data transfer is not negligible if your tooling shuttles artifacts across the boundary.

Preview Architecture Inside GovCloud

The dominant commercial-AWS preview architecture is a vendor SaaS — vendor holds API credentials, builds containers in their account, exposes preview URLs through their domain. That maps poorly into GovCloud. The vendor’s SaaS plane is almost always in commercial AWS, which means code, build artifacts, or telemetry crosses the boundary; and vendor support is usually not all U.S. persons, so production access from the vendor side is not lawful inside the boundary.

The architecture that works is BYOC — preview tooling runs inside your GovCloud account. Build and deploy controllers, metadata, ingress, evidence log, all inside the boundary you’ve authorized. Code never leaves. Images are built in CodeBuild or your own runners and pushed to ECR. Previews run in ECS or EKS. Ingress goes through your ALB and Route 53 with ACM certificates issued in GovCloud.

The vendor’s role in BYOC: provide the software, document the architecture, stay out of the data path. Updates ship as container images or Helm charts you deploy on your own cadence. Support runs on artifacts you choose to share, not on access into your tenant.

The Boundary Question

For each component of the preview system, ask whether it sits inside or outside your boundary, and what crosses each interface.

• Source code and build artifacts. Inside. Builds run in GovCloud-resident CI; artifacts in ECR or S3 in GovCloud.
• Preview runtime. Inside. ECS, EKS, EC2, RDS, all in your VPC.
• Orchestration plane. Inside in BYOC. Outside in pure SaaS.
• Evidence log. Inside. Audit data describing what was reviewed is sensitive metadata and should not live in a vendor-controlled commercial-region database.
• Stakeholder access. The friction point. See below.

If any component of orchestration or evidence is vendor SaaS in commercial AWS, you are inheriting that vendor’s authorization (if any) and accepting boundary crossings. For a tool with no FedRAMP authorization — most preview tools today — SaaS deployment is not viable inside an ATO. Self-hosted or BYOC is.

Data Residency vs. Stakeholder Access

The hardest practical tension is social, not technical. The point of a preview is for a human to look at it, and in GovCloud that gets harder.

Stakeholders who need to review — government PMs, IV&V engineers, agency stakeholders, COs — usually do not have GovCloud accounts and do not need them. They need authenticated access to a specific URL with credentials they already hold, ideally PIV/CAC. The pattern that works:

• Terminate ingress on an ALB in GovCloud with an ACM certificate.
• Front it with an authenticating proxy that validates PIV/CAC or accepts federated identity from agency IdPs (login.gov, ICAM, the contractor’s own cleared IdP).
• Restrict access to U.S. persons where the data warrants it, and document the access decision in the evidence log.
• Keep DNS and certificates inside the boundary; do not route preview traffic through a commercial-region edge.

What does not work is a preview URL hosted on a vendor’s commercial-region domain protected by the vendor’s own auth — that’s a boundary crossing for every page load, and it puts authentication of regulated reviewers on a system you have not authorized.

What It Costs

Rough sizing for a contractor running 30–60 active previews/day on GovCloud with small Fargate tasks, Aurora Serverless v2 per-preview databases, and a shared ALB:

• Compute (Fargate, ~0.5 vCPU / 1 GB per service, two services per preview, ~3 hour median lifetime): $400–$800/mo.
• Database (Aurora Serverless v2, scaled to zero between uses): $300–$700/mo.
• Data transfer, registry, logs, supporting services: $200–$400/mo.
• GovCloud premium: 15–25 percent on top.

Numbers vary widely. ECR storage and per-preview databases are the usual surprises. Cost-aware patterns from /blog/cost-aware-preview-environments/ apply; idle compute is more expensive here, so aggressive teardown matters more.

Validating Against Your ATO

No architecture is portable across ATOs. Your boundary, control selections, continuous monitoring requirements, and your agency’s interpretation of NIST SP 800-53 shape what’s acceptable. Walk the proposed architecture through your ISSO and 3PAO. Five questions:

1. Where does source code sit at every step, and is each location inside the boundary?
2. Who has administrative access to each component, and are they all U.S. persons?
3. How is reviewer access authenticated, and does the auth path cross the boundary?
4. Where does evidence live, and how long is it retained?
5. What is the change management story for the preview tooling itself?

A vendor that cannot answer these in writing is not viable for FedRAMP-bound work. The buyer-side version is in /blog/preview-environments-fedramp-tool-requirements/.

A Note on PreviewProof

Honest disclosure: PreviewProof is not currently FedRAMP authorized. It is designed to deploy inside the customer’s authorized boundary — control plane, evidence log, and runtime in your GovCloud tenant, with the vendor relationship covering the software, not operations. If you want preview tooling already shaped for that posture, it’s worth a look; if you’d rather build the same shape yourself or evaluate another vendor against the questions above, the questions are the point. Either way, the right next step is an architecture review with your ISSO in the room, not a procurement decision.