While assisting a US municipal government with their cloud migration, we recently had the opportunity to deploy a complete hosting platform to the GovCloud Region. Our task was to provide a platform based on kubernetes, running within a secure VPC built on private subnets and with VPN links to an enterprise-class network that spanned multiple datacenters.
While we had researched particulars of GovCloud before getting into the project, we ran into a few surprises along the way. This is the type of post I had wanted to find earlier.
This post aims to provide an overview of the AWS "GovCloud Region", how it is not just another region in the AWS cloud you have come to know and understand, the types of problems you will run into when you go to deploy your services to GovCloud, and notes on how we overcame these obstacles to use GovCloud effectively while reusing our existing code and experience for AWS. This also serves as an introductory post to a mini-series on “Deploying to GovCloud” - be sure to check back on the follow-up posts where we’ll get deeper into solutions for the problems discussed here.
Consider this a supplement to the AWS doc on specific differences between GovCloud and the "standard regions".
When reading the AWS documentation on GovCloud (and both the FAQ and the User's Guide), you get the impression "it's just another region" (perhaps with a few minor changes). In practice, the difference with GovCloud regions is more fundamental than that.
GovCloud is a separate cloud "partition". At the moment there is one "region" in GovCloud, us-gov-west-1, though it's likely that additional regions will come online in the future (AWS has noted a US-East region coming in 2018). Interestingly, there are also other "partitions", for a total of 3: aws, aws-us-gov, and aws-cn (China). For details on those partitions, see the mini section on partitions in this doc.
Amazon GovCloud is AWS's isolated cloud partition for government contractors and agencies needing to host Controlled Unclassified Information (CUI). According to Amazon itself, "AWS GovCloud (US) gives vetted government customers and their partners the flexibility to architect secure cloud solutions that comply with: the FedRAMP High baseline, the DOJ's Criminal Justice Information Systems (CJIS) Security Policy, U.S. International Traffic in Arms Regulations (ITAR), Department of Defense (DoD) Cloud Computing Security Requirements Guide (SRG) for Impact Levels 2, 4 and 5, FIPS 140-2, IRS-1075, and other compliance regimes." See also this PDF.
In other words,
Different API Endpoints - devops tools need to support these endpoints (based on the GovCloud region).
IAM in the AWS Web Console blocks access to the "Switch Role" functionality that is normally available. It seems possible to assume roles with AWS tools on the CLI (but we didn't investigate that one to be sure, we were limited on time and wanted a consistent auth workflow across both the AWS console as well as the cli utilities).
Must use aws-us-gov in AWS Resource Numbers (ARNs) instead of aws, see this doc (as well as the previous reference on AWS cloud partitions) - devops scripts, resource management code, and Terraform modules, etc, may have hard-coded in the aws, and you may need to update that or add support for flexibility with the ARN. Here is an example from the AWS provider in Terraform. Review your devops tools and scripts.
While there are "egress-only" gateways, they are IPV6-only, and the managed NAT gateway service is unavailable, so you either need to provide your own NAT gateway (on an EC2 instance), or route 0.0.0.0/0 over your VPN/etc links and thru your Corporate Network. We used both methods to address the need for private network topologies and NAT gateways. A future post will dive into the details of NAT and network routing in our VPC.
Here is the list of available services.. not all services are available, and some services (like Direct Connect) may differ from their counterparts on the regular cloud. Be sure to review the AWS docs for each service you plan to use in your project.
While the "GovCloud Region" may appear to be another option in AWS' collection of regions, there are restrictions that are specific to GovCloud. These restrictions are likely to impact the project you run on GovCloud, and we recommend getting up to speed on the details as early as possible. We also have a service dedicated to helping you address your GovCloud requirements which you can find here.
We hope this introductory post has been helpful, stay tuned for the next post in this series on GovCloud where we will dive deeper into options for IAM, DNS and NAT (to work-around what isn't available), and running modern devops on AWS GovCloud in general.
If you liked this blog post you might also be interested in these posts: