AWS for United States Government Work

Prerequisites and outcomes

Prerequisites. Read the chapters on the Amazon Web Services (AWS) request path, provider comparison, and identity, data protection, reliability, and cost. The identity lesson explains workload principals, audit events, encryption keys, recovery point objective (RPO), and recovery time objective (RTO). A direct-link reader should know that a cloud provider operates some controls while a customer configures and operates other controls.

After this chapter, you can:

• explain what AWS GovCloud (US) Regions change and what they do not change;
• distinguish Federal Risk and Authorization Management Program (FedRAMP) evidence for a cloud offering from an agency authorization to operate for an information system;
• connect information categorization, control responsibility, implementation evidence, assessment, authorization, and continuous monitoring;
• calculate audit-storage volume from event counts and record sizes; and
• reject claims that a Region, certification, cryptographic endpoint, or product name automatically makes a workload compliant.

The lesson describes engineering and evidence practices, not legal advice. Statutes, regulations, contracts, agency policy, data categories, authorization packages, and product scope change. Counsel, contracting officials, privacy officials, security officers, data owners, assessors, and the agency authorizing official make decisions within their authority. Version-sensitive statements in this lesson were checked against official sources in July 2026.

A premature compliance claim

CivicPermit accepts permit applications containing personally identifiable information (PII), address data, site-plan attachments, payment references, and staff decisions. The agency requires auditable administrative changes and continued intake after failure of one Availability Zone. A contractor proposes an Application Load Balancer, application capacity in two zones, Amazon Relational Database Service (Amazon RDS) for PostgreSQL, Amazon Simple Storage Service (Amazon S3), AWS Key Management Service (AWS KMS), and AWS CloudTrail.

A design review slide says, “Deployment in AWS GovCloud (US) is FedRAMP High compliant.” The sentence joins three separate decisions. AWS has provider-operated offerings and controls within defined authorization boundaries. The contractor builds and configures a particular CivicPermit workload. An agency authorizing official decides whether to accept risk for the agency information system and its use of the cloud offering.

The reviewer asks for evidence. The team must identify CivicPermit's information, authorization boundary, impact category, selected services and features, control owners, data flows, access rules, audit coverage, contingency tests, assessment results, and unresolved risks. A Region name supplies useful platform facts, but the name cannot supply those workload records.

Evidence that exists before an authorization decision

An information inventory is produced by the agency data owner and CivicPermit team during design and updated when data flows change. Each row should name an information type, source, destination, purpose, sensitivity or regulatory handling basis, retention, and approved recipients. A row directly establishes the team's declared handling design. The row does not prove that production traffic follows the design.

A data-flow diagram is produced by the architecture team from deployed routes, interfaces, Domain Name System (DNS) names, application behavior, and interviews. Each arrow must name both endpoints, protocol, data category, authentication method, encryption arrangement, and artifact producer. A line from the browser to “cloud” hides the customer-to-provider boundary, the Internet path, and the exact termination endpoint.

An infrastructure inventory is produced from provider application programming interfaces (APIs) or infrastructure-as-code evaluation. The inventory should include account, partition, Region, Availability Zone where applicable, service, feature, Amazon Resource Name (ARN), encryption setting, network attachment, tags, and creation evidence. AWS GovCloud (US) ARNs begin with arn:aws-us-gov, while standard AWS partition ARNs begin with arn:aws. The different string changes policies, templates, and integrations that previously assumed arn:aws.

AWS supplies certification and compliance artifacts for provider-controlled offerings through the applicable FedRAMP process and AWS channels such as AWS Artifact. The current AWS “services in scope” page lists services inside particular assurance-program boundaries and includes an update date. A check mark for one service and boundary is evidence about that provider offering. The mark does not establish that every feature, third-party product, customer configuration, or external connection in CivicPermit belongs to the same boundary.

The customer produces implementation evidence. Examples include identity policies, key policies, configuration snapshots, change approvals, training records, incident exercises, vulnerability findings, backup reports, restore results, access reviews, CloudTrail events, application audit entries, and plans of action and milestones. Each artifact needs a producer, collection interval, integrity protection, retention, and link to the control implementation. A screenshot without account, time, query, and source cannot support repeatable assessment.

What AWS GovCloud (US) changes

AWS GovCloud (US) consists of isolated AWS Regions intended for sensitive government-related and regulated workloads. The Region codes are us-gov-west-1 and us-gov-east-1. AWS documentation describes physical and logical separation, GovCloud-specific endpoints, distinct credentials, and administration of the AWS boundary by vetted United States citizens under the documented conditions. AWS GovCloud documentation also describes use for Controlled Unclassified Information (CUI) and unclassified data.

The word partition names an AWS administrative and naming separation larger than one Region. AWS GovCloud resources use the aws-us-gov partition. Standard AWS credentials cannot access AWS GovCloud resources, and GovCloud credentials cannot access standard AWS resources. A GovCloud account is associated one-to-one with a standard AWS account for billing, support, and account purposes, but the credentials remain distinct. An AWS Organization in the standard partition is separate from an AWS Organization created in the GovCloud partition.

The separate partition affects automation. CivicPermit templates must use GovCloud Region codes, endpoints, ARNs, service principals, certificate options, and product availability. A continuous-integration runner in the standard partition does not gain GovCloud access because both accounts appear on one invoice. The team must create an approved identity path and network path, then verify that build artifacts and diagnostic content remain within allowed locations.

Federal Information Processing Standards (FIPS) endpoints expose provider endpoints using cryptographic modules under the documented validation context. Endpoint selection does not prove that CivicPermit's browser code, third-party library, local file handling, database client, or export job uses an approved module correctly. The National Institute of Standards and Technology (NIST) Cryptographic Module Validation Program explicitly warns that module validation does not assure that a product correctly uses the embedded module.

Product availability also differs. A service available in standard AWS can be absent in GovCloud, present with fewer features, or documented with fields that must not contain export-controlled content. Current service documentation must be checked before selection. AWS support documentation, for example, warns users not to put export-controlled data in support cases because support-case handling has its own boundary considerations.

The institutional mechanism from data to authorization

Federal Information Processing Standards Publication 199 (FIPS 199) categorizes federal information and information systems according to potential impact on confidentiality, integrity, and availability. The responsible organization identifies information types and analyzes mission harm. Choosing GovCloud first cannot replace categorization because the category and governing requirements determine which protections and authorization path are necessary.

NIST Special Publication (SP) 800-37 Revision 2 describes the Risk Management Framework (RMF) as a lifecycle: prepare, categorize, select, implement, assess, authorize, and monitor. NIST SP 800-53 Revision 5 supplies a catalog of security and privacy controls. Control baselines and tailoring decisions come from the applicable framework and organizational requirements, not from copying every catalog entry into a spreadsheet.

During selection, the team states the required control outcome and planned responsibility. During implementation, AWS may provide an inherited control, CivicPermit may provide a customer control, or both parties may implement different portions of a shared control. During assessment, an assessor examines evidence and tests whether the implementation satisfies the selected requirement. During authorization, the authorizing official uses the security plan, assessment, remediation information, mission need, and risk analysis to make a risk decision. During monitoring, provider and customer evidence supports continued awareness and future decisions.

FedRAMP standardizes reusable security assessment, certification, and continuous-monitoring evidence for cloud service offerings used by federal agencies. Current 2026 FedRAMP guidance distinguishes the certified cloud service offering from the agency information system that uses the offering. The agency still evaluates its data, configuration, integrations, customer-operated controls, and risk. An agency authorization to operate (ATO) therefore applies to the agency information system and its use of external cloud capabilities; provider certification is evidence for that decision, not a transfer of the decision.

Shared responsibility as a control statement

AWS describes security of the cloud as AWS responsibility for the infrastructure that runs AWS products. Security in the cloud remains with the customer according to the selected product. Amazon Elastic Compute Cloud (Amazon EC2) customers patch and configure guest operating systems and applications. More abstracted products move operating-system work to AWS, while customers still classify data, manage identities, configure access, secure application code, choose retention, and verify recovery.

A useful control statement names five fields:

1. Required outcome: what protection or evidence must exist.
2. Provider implementation: which AWS capability or inherited control contributes.
3. Customer implementation: which CivicPermit configuration or procedure contributes.
4. Evidence: which artifact, producer, interval, and query demonstrate operation.
5. Gap owner: who must resolve a missing or ineffective portion.

For audit accountability, AWS can operate CloudTrail infrastructure and document provider controls. CivicPermit must select relevant event categories, protect destinations, avoid PII leakage, retain evidence for the required period, review alerts, synchronize application identifiers, and test retrieval. Calling the entire audit control “inherited” would hide customer work. Calling the entire control “customer-owned” would ignore provider-operated infrastructure and reusable assessment evidence.

Certification scope also has levels. The selected AWS service must be in the relevant program boundary. The selected feature and Region must match current scope. CivicPermit must configure the feature correctly. External software-as-a-service telemetry, contractor laptops, identity providers, code repositories, payment processors, and support workflows can cross the authorization boundary. A complete data-flow and responsibility analysis must include those connections.

A storage model for audit evidence

CivicPermit estimates audit storage before setting retention. The team forecasts 12,000 management events per day at an average serialized size of 1.8 kilobytes and 600,000 application or data events per day at 2.2 kilobytes. The retention requirement used for the exercise is 365 days. The team keeps two protected copies and adds 20 percent for indexes and metadata.

Using decimal units for the estimate:

or about 1.18 decimal terabytes. The event rate means completed serialized events divided by the collection interval in seconds or days; the model uses daily completed-event counts.

The calculation assumes constant volume, stated average serialized sizes, two full copies, no compression, and 20-percent overhead. The result predicts initial capacity and a cost input. The result omits query scans, archive retrieval, growth, burst delivery, provider framing, cryptographic metadata, retention locks, backups, duplicates, and failed delivery. Measured exports must replace guessed averages. Compliance cannot be reduced to retaining 1.18 terabytes because audit content, access, integrity, review, and response matter as much as volume.

Test the evidence path

Use an authorized nonproduction GovCloud account with synthetic data. Hold the trail configuration, destination, identity, Region, and query constant. Perform one labeled management action and one labeled object data action. Preserve the command, synthetic resource identifier, Coordinated Universal Time interval, request identifier, principal, source endpoint, CloudTrail configuration, delivered object checksum, and query result.

Expected evidence shows the management event in the configured collection and the data event only when the relevant data-event selector is enabled. Disable only the nonproduction selector through the approved change method, repeat the data action, and verify the documented difference. A result in which the event remains can reject the selector explanation, or it can indicate another trail, event data store, duplicate delivery, or delayed record. Restore the configuration and verify current state.

The test makes collection visible. The test does not establish every selected control, full retention, incident response, or legal sufficiency. A separate restore or retrieval exercise should measure how long an authorized investigator needs to find a one-year-old event, validate integrity, and relate the event to an application action.

Worked investigation: can CivicPermit use the claimed boundary?

Initial question. Does the proposed GovCloud architecture provide enough scoped implementation and evidence for CivicPermit to enter formal assessment?

Operating conditions. CivicPermit handles agency-defined moderate-impact PII in this scenario. The design uses two Availability Zones in one GovCloud Region, an Application Load Balancer, application instances, Amazon RDS for PostgreSQL, S3, KMS, and CloudTrail. A third-party error-reporting agent sends diagnostic payloads to a commercial software-as-a-service endpoint outside GovCloud.

Evidence collected. The team obtains the current AWS services-in-scope listing and applicable authorization package through approved channels. Infrastructure inventory confirms aws-us-gov ARNs and GovCloud endpoints. Data-flow testing shows that the error agent sends stack context outside the proposed boundary. Identity review finds broad administrator access for contractor accounts. Audit testing finds management events but no configured S3 object data events. A restore test succeeds in 47 minutes against a 60-minute RTO. A 28-row scoped responsibility matrix marks 9 outcomes as provider-inherited, 11 as shared, and 8 as customer-operated for this review sample.

Interpretation. The named AWS products can contribute relevant authorized capabilities, but CivicPermit has an external diagnostic flow and missing customer implementations. Two-zone placement and an in-scope service list do not resolve the gaps.

Proposed intervention and prediction. Remove or reconfigure external diagnostics so approved sanitized evidence remains in the assessed boundary. Replace standing broad access with federated, role-based, time-bounded administration. Enable and validate required object data-event collection. Attach artifacts to every matrix row and run an incident exercise. The prediction is that assessors can reproduce 27 of 28 sampled outcomes, with the remaining incident-response exercise explicitly scheduled rather than silently marked complete.

Observed or calculated result. After remediation, controlled network testing finds no connection to the former telemetry endpoint. Intended object actions appear in the configured audit destination with correlated application identifiers. Access tests show that ordinary contractor roles receive a denial for administrator actions. Twenty-seven matrix rows contain current reproducible evidence; one row remains open for the scheduled exercise.

Bounded conclusion. The remediated sample is better prepared for formal assessment and no longer has the reproduced external diagnostic flow. The evidence does not declare CivicPermit compliant, FedRAMP certified, or authorized to operate. Only the designated assessment and authorization process can reach the applicable decisions.

Remaining uncertainty. The sample does not cover every control, product feature, supply-chain dependency, privacy requirement, continuous-monitoring interval, contract term, or later configuration change. The agency must evaluate the open item and the complete authorization package.

Normal operation, edge cases, and qualifications

A normal government-cloud deployment starts with categorized information and an explicit authorization boundary. The team selects services and features in the required Region and current program scope, maps provider and customer responsibilities, configures identities and evidence collection, tests normal and failure behavior, supplies assessment evidence, resolves findings, and supports an authorizing official's risk decision.

Important edge cases include:

• PII does not by itself prove that GovCloud is legally required or sufficient. Agency requirements, impact, contracts, and applicable law determine the handling design.
• GovCloud eligibility and U.S.-person requirements do not automatically enforce the customer's workforce access decisions. The customer controls customer identities and content access.
• A service listed in GovCloud can have different features from the standard partition. A service available in GovCloud can still be outside a particular assurance-program boundary.
• A FedRAMP High provider boundary does not convert an incorrectly configured customer workload into a compliant workload.
• A FIPS endpoint does not validate every cryptographic path or correct module use.
• Two Availability Zones do not provide Region-wide disaster recovery. The two GovCloud Regions require explicit replication, routing, recovery procedures, and testing where a cross-Region objective applies.
• Resource names, log messages, support cases, and metadata fields can have handling restrictions even when payload storage is approved.
• An ATO is a risk decision with scope and conditions. An ATO is not a guarantee that no incident will occur.

Common reasoning errors

“GovCloud equals compliance.” GovCloud supplies documented platform characteristics and eligible offerings. CivicPermit still needs correct scope, configuration, customer controls, assessment, authorization, and monitoring.

“AWS has a certification, so every AWS product is covered.” Assurance boundaries list specific offerings, Regions, and current status. Features and external dependencies require individual verification.

“Shared responsibility means every failed control belongs partly to AWS.” A control can be inherited, shared through distinct implementations, or customer-operated. The responsibility matrix must name the exact outcome and evidence.

“Encryption at rest satisfies all PII requirements.” PII handling also involves collection, use, access, disclosure, retention, deletion, audit, incident response, privacy analysis, and external flows.

“An audit log proves continuous monitoring.” Continuous monitoring requires defined collection, review, analysis, response, reporting, and update intervals. Unread events in storage supply potential evidence, not completed monitoring work.

Knowledge check

Question. CivicPermit uses only AWS services that show a current check mark under FedRAMP High in the AWS scope table. Can the project manager state that CivicPermit has an ATO?

Answer. No. The check marks provide scoped provider-offering evidence. The agency must evaluate CivicPermit's information, configuration, external connections, customer controls, assessment findings, and risk. The authorizing official issues or withholds the agency information system's ATO through the applicable process.

Evidence exercises

Check

Create a ten-row responsibility matrix for CivicPermit covering identity lifecycle, privileged access, encryption key control, object audit events, application audit entries, vulnerability response, backup, restore, incident response, and personnel training. For each row, name provider implementation, customer implementation, artifact producer, collection interval, assessor test, and gap owner. Submit the matrix and mark unknowns explicitly.

Practice

Build a synthetic data-flow diagram for one permit submission. Include the resident browser, DNS, Transport Layer Security (TLS) endpoint, application target, PostgreSQL, object storage, key management, audit destination, administrator workstation, code pipeline, support path, and every external product. Submit the diagram plus a table of protocols, data types, partitions, Regions, principals, and evidence. Highlight any flow that leaves the proposed authorization boundary.

Challenge

Use official July 2026 sources to prepare a mock authorization evidence index. Base the index on FIPS 199 categorization reasoning and 15 selected NIST SP 800-53 control outcomes. Link each outcome to provider package evidence or customer-produced evidence without copying restricted package content. Include one normal test, one intended-denial test, one zone-failure test, one restore test, and one one-year audit-retrieval plan. Submit unresolved risks and never label the mock workload compliant or authorized.

Authoritative sources and further reading

Required government sources

• FIPS 199: Security Categorization establishes impact-based categorization for confidentiality, integrity, and availability.
• NIST SP 800-37 Revision 2 defines the Risk Management Framework lifecycle and the roles of assessment, authorization, and continuous monitoring.
• NIST SP 800-53 Revision 5 supplies the security and privacy control catalog; the NIST page also identifies current release updates.
• FedRAMP 2026: Using Rev5 Certification Packages distinguishes reusable provider certification evidence from an agency's authorization of its information system.

AWS GovCloud implementation documentation

• What is AWS GovCloud (US)? documents intended workload categories, U.S.-citizen administration of the AWS boundary, and shared responsibility.
• AWS GovCloud compared with standard Regions identifies partition isolation, credentials, endpoints, billing association, and feature differences.
• GovCloud Amazon Resource Names documents arn:aws-us-gov and the two Region codes.
• GovCloud service endpoints documents current endpoint selection and FIPS qualifications; revisit the page before implementation.
• Services in AWS GovCloud Regions lists product-specific availability, differences, and export-controlled-content warnings.

Compliance and cryptographic scope

• AWS services in scope for FedRAMP provides a dated, version-sensitive table of service status within specific provider boundaries.
• AWS shared responsibility model distinguishes provider infrastructure work from customer configuration, data, identity, and application work.
• NIST Cryptographic Module Validation Program provides current validation status and transition information.
• NIST CMVP frequently asked questions explains why module validation does not assure correct product use of a validated module.

Transition

Part II has followed a request from DNS to application and data, translated the design across three providers, connected operations to identity and recovery, and placed government-cloud choices inside an authorization process. The next part can now introduce containers and Kubernetes without presenting them as an alternative to these foundations. A container still uses provider identity, networks, storage, evidence, capacity, cost meters, and an authorization boundary.