AWS / Working in GovCloud

Many of my government clients will want to have at least their production infrastructure in AWS GovCloud, which is a set of AWS regions that are separate from commercial AWS regions, with a number of additional controls that allow them to conform to the higher security and compliance standards needed to meet federal guidelines like FedRAMP.

GovCloud Topics

• Setting Up a GovCloud Organization
• ACM in GovCloud

General Considerations With GovCloud

• Every GovCloud account must be attached to a corresponding account in commercial AWS (mostly for billing purposes). This has some impact on how you build AWS Organizations in GovCloud (see below).
• Commercial AWS and GovCloud resources cannot interact directly in any way. This means that you cannot assume roles between the two or tie a commercial resource to a GovCloud resource unless using some publicly addressable method.
• GovCloud accounts do not have a root user; they have an automatically created IAM user named Administrator with full administrative privileges. For most purposes, you can think of this as operating the same way as the root user; however, it is still subject to restrictions you place on all IAM users. This means setting password expiration to a very short period (as is common in some of my commercial AWS environments) can lock you out of the Administrator user; since I can get console access via role assumption, I recommend setting the password expiration on the GovCloud org-root account to six months and instead treating this user as you would the root user in commercial AWS (ie, do not use it for anything other than bootstrapping or “break glass” cases).

• GovCloud resources use a different AWS partition; this is the second part of an ARN. So while an ARN for a commercial resource might look like this:

  arn:aws:iam::123456789000:user/testuser
  

  a GovCloud ARN will look like this:

  arn:aws-me-gov:iam::123456789000:user/testuser
  

  This means that any Terraform modules will need to take this into account; see the Terraform aws_partition data source for how to do this.

• Many AWS services are not available in GovCloud; some are available in one GovCloud region and not others. See the GovCloud Services in Scope and the AWS Region Table for more information.
• Organization CloudTrails are not available in GovCloud. This means you cannot add cloudtrail.amazonaws.com as a service principal in your organization Terraform code.
• Your first GovCloud account will have a randomly-named S3 bucket called something like “cloudtrail-123456789abcedf”, and all additional GovCloud accounts you create via the method described in this document will have a randomly-named CloudTrail and matching S3 bucket automatically created. I recommend replacing these resources with your own CloudTrail pointing to the AWS service logs bucket you create in the account.
• It is not possible to enable CloudWatch Container Insights for an ECS cluster. Therefore, in aws_ecs_cluster Terraform resources, you cannot include a setting configuration block with containerInsights.
• For Amazon RDS, GovCloud does not support backup or read replica events. Therefore event notifications and subscriptions are impossible for those events.
• As of 04/20, the most up-to-date CA cert identifier for RDS instances that is viable in GovCloud is rds-ca-2017 rather than rds-ca-2019.
• Because GovCloud doesn’t have a root account in the traditional sense (it’s tied to a commerical root account), you cannot set check_root_account_mfa_enabled to true in I’ AWS Config module.
• While Route53 is available in GovCloud, it is only available for private DNS, which limits its utility somewhat. You will need to create public DNS entries for your GovCloud environments in your commercial AWS environment.