AWS Public Sector Blog
Navigating common use cases spanning AWS GovCloud (US) and standard AWS
There may be use cases where customers must orchestrate actions spanning AWS GovCloud (US) and standard AWS partitions. The common reasons customers may need to invoke Amazon Web Services (AWS) services in a standard account from an AWS GovCloud (US) account (or vice versa) include: cross-domain applications, feature parity, and if the AWS service doesn’t exist in AWS GovCloud (US). In this blog post, we explore how customers can navigate these scenarios.
An AWS Region is a physical location around the world where AWS clusters data centers. Each group of one or more discrete data centers forms an Availability Zone (AZ) and multiple AZs make up a Region. Distinct Regions exist in the AWS standard partition and AWS GovCloud (US) partition. An AWS partition logically and physically separates groups of AWS Regions. This provides data, network, and machine isolation from AWS Regions in other AWS partitions. An AWS Region can’t be a part of two partitions.
Why AWS GovCloud (US)?
AWS GovCloud (US) supports customers who must adhere to U.S. International Traffic in Arms Regulations (ITAR) regulations; the Federal Risk and Authorization Management Program (FedRAMP) requirements; Defense Federal Acquisition Regulation Supplement (DFARS); Department of Defense (DoD) Cloud Computing Security Requirements Guide (SRG) Impact Levels 2 and 4 and 5; and several other security and compliance requirements. Workloads that don’t adhere to these compliance requirements can be deployed in the AWS standard partition.
The use cases in this post are a few examples of using AWS services across the partitions. However, note that the design principles and methods can be extended to use other AWS services as well.
Security considerations
The following security considerations apply to all use cases:
- AWS GovCloud (US) is an isolated partition of AWS with internet access and its own AWS Identity and Access Management (IAM). A process connecting across partitions will need access keys to authenticate against public API endpoints.
- AWS recommends storing access keys in AWS Secrets Manager, to encrypt and access keys programmatically. Credentials must be manually updated in the Secrets Manager when they are rotated, as they are in different partitions.
- You can retrieve values from Secrets Manager in AWS Lambda function code by directly invoking the Secrets Manager’s GetSecretValue API method, or through the use of a software development kit (SDK) in your programming language of choice. For example, you can use the GetSecretValue SDK
- By storing key/value secrets in Secrets Manager, you can retrieve a set of related configuration values with a single API call.
Figure 1. Key/value secret in Secrets Manager.
- Secrets Manager will return the Plaintext value of your secret as a JSON string.
Figure 2. Key/value secret as plaintext/JSON.
- AWS SDKs simplify the use of AWS service APIs by providing a set of libraries that are consistent and familiar. They provide support for API lifecycle considerations, such as credential management, retries, data marshaling, and serialization. SDKs automatically sign requests using the Sigv4 protocol, which secures requests in several ways.
- When creating the IAM user for your automation, apply the principle of least privilege, granting access only to the specific service functions that are required for the automation to execute.
- An additional security measure could use a AWS Site-to-Site VPN encrypted tunnel between partitions. To configure site-to-site VPN, customers should use a third-party virtual firewall appliance from an AWS Partner and deploy these appliances on Amazon Elastic Compute Cloud (Amazon EC2). AWS Transit Gateway provides connectivity between virtual private clouds (VPCs). IPsec encryption protects sensitive data.
Figure 3. Site-to-Site VPN between AWS GovCloud (US) and AWS standard cloud.
| Note: The security of customer data in the cloud is a customer specific responsibility in the Shared Responsibility Model. Customers must be mindful to store and move data according to the conditions and controls of the compliance frameworks with which they must comply. |
Use Case 1: Calling Amazon Simple Email Service in standard AWS from AWS GovCloud (US)
In this use case, we explain how to send the customer a confirmation email using Amazon Simple Email Service (Amazon SES) hosted in a standard AWS account. An AWS Lambda function triggers the email in AWS GovCloud (US). Figure 4 below depicts an architecture deployed on AWS GovCloud (US) to support compliance standards, and Amazon SES in the AWS standard account.
A timely email confirmation of user activity serves an important purpose in enhancing the customer experience. Email confirmations verify that an action taken by a customer has been successful. Figure 4 below shows an Amazon API Gateway publishing raw data from the customer to Amazon SNS. Amazon Simple Queue Service (Amazon SQS) subscribes to this message and queues the message. An AWS Lambda function retrieves the message from the queue, processes the message, reads the access keys from Secrets Manager to access the AWS standard account, and invokes the Amazon SES SendEmail API (example SDK method). Amazon SES sends the confirmation email to the user.
Figure 4. Calling Amazon SES in standard AWS from AWS GovCloud (US).
Use Case 2: Event-driven architecture between AWS GovCloud (US) and standard AWS
In this use case, a compute service such as AWS Lambda or Amazon Elastic Kubernetes Service (Amazon EKS) deployed in the standard AWS account processes the messages arriving to an event-driven service such as Amazon SQS or Amazon EventBridge.
Figure 5. Event-driven processing spanning AWS GovCloud (US) and standard AWS.
In this architecture, common business logic is hosted in the standard AWS account. Messages coming to Amazon SQS and EventBridge in the AWS GovCloud (US) account trigger Lambda in the AWS GovCloud (US) account. This Lambda function serves as a dispatcher, retrieving the required IAM access keys for the standard AWS account using Secrets Manager and invoking the appropriate AWS services, such as AWS Lambda and Amazon EKS, via an Application Load Balancer (ALB) in the standard AWS account. Note that the same AWS Lambda in the standard AWS account can also be invoked from other event sources in standard AWS. This allows for centralized deployment of common business logic, as opposed to having to deploy and support redundant logic in both partitions.
This pattern is interchangeable between an AWS GovCloud (US) account and a standard AWS account. If the messages coming to Amazon SQS and EventBridge are in the standard AWS account and the business logic lives in the AWS GovCloud (US) account, then messages can trigger dispatcher Lambda function(s) in the standard AWS account. These dispatcher Lambda functions get the AWS GovCloud (US) account IAM access keys from Secrets Manager and then invoke the compute service(s) containing the business logic in AWS GovCloud (US).
Use Case 3: Extending AWS Budget actions to AWS GovCloud (US)
Customers can use AWS Budget actions to control costs of services. While AWS GovCloud (US) costs can be monitored with AWS Budgets, it does not support budget actions on AWS GovCloud (US). In this use case, we describe how to respond to a budget alert and attach a restrictive service control policy (SCP) to an AWS GovCloud (US) Organization.
Figure 6. Example SCPs.
Figure 7. Budget relationship between AWS GovCloud (US) and linked standard AWS accounts.
Figure 7 shows how Lambda can securely retrieve and use narrowly scoped API credentials to communicate with the AWS GovCloud (US) Organization’s management account and attach a restrictive SCP to the Infrastructure Organization Unit (OU). This SCP prevents new instances of Amazon EC2 and Amazon Relational Database Service (Amazon RDS) from being launched when the assigned budget crosses a preset threshold.
Let’s dive deeper into how this works. In the AWS standard account, AWS Budgets will publish a message to the Amazon SNS topic upon exceeding a preset budget threshold. Amazon SNS triggers a Lambda function. As discussed in the previously mentioned Security Considerations segment, users can store credentials for the AWS GovCloud (US) Organization’s management account safely in the standard AWS management account within Secrets Manager. The Lambda function retrieves the AWS GovCloud (US) account IAM access keys from the Secrets Manager (as previously described in the Security Considerations section). Then it invokes AWS Organizations AttachPolicy API request (example SDK method) in the AWS GovCloud (US) account, using the credentials to authenticate the request, and attach the SCP policy. This policy prevents new Amazon RDS and Amazon EC2 instances from being provisioned. At the end of the month when the budget resets, the SCP is detached using the DetachPolicy API request (example SDK method) and normal operations can resume.
Conclusion
In this post, we discussed three examples illustrating how to use AWS services spanning AWS GovCloud (US) and standard AWS with Lambda and Secrets Manager using AWS SDKs.
Another common use case is moving data in and out of AWS GovCloud (US) from Amazon Simple Storage Service (Amazon S3) buckets, which is detailed in this post. If your architecture requires a single shared path from your on-premises data center to both AWS GovCloud (US) and standard AWS, refer to this post.
Related resources for AWS GovCloud (US):
- AWS GovCloud (US) or standard? Selecting the right AWS partition
- SpinSys Accelerates Defense Health Agency Migration of Applications and Data to AWS GovCloud in Days Instead of Months
- 10 years of government cloud innovation with AWS GovCloud (US)
- IAM Identity Center for AWS environments spanning AWS GovCloud (US) and standard Regions
- How to improve government customer experience by building a modern serverless web application in AWS GovCloud (US)
- How the US DOJ Tax Division built a remote telework application in six weeks with AWS
Subscribe to the AWS Public Sector Blog newsletter to get the latest in AWS tools, solutions, and innovations from the public sector delivered to your inbox, or contact us.
Please take a few minutes to share insights regarding your experience with the AWS Public Sector Blog in this survey, and we’ll use feedback from the survey to create more content aligned with the preferences of our readers.