BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Slack's Lessons Learned from Supporting Highly Regulated Workloads on AWS GovCloud

Slack's Lessons Learned from Supporting Highly Regulated Workloads on AWS GovCloud

Archie Gunasekara, staff software engineer at Slack, and Andrew Martin, staff software engineer at Slack, recently shared their learnings in building GovSlack, an instance of Slack running on the AWS GovCloud region. They shared challenges in adapting to unsupported services, account creation, and account isolation.

As described by AWS, the GovCloud US region is "[a]n isolated AWS region designed to host sensitive data and regulated workloads in the cloud". Gunasekara and Martin note that one of the first challenges is that "only US persons would be authorized to the production environment" as this is a core requirement of FedRAMP High. AWS also requires only U.S. persons to manage and access root account keys.

To simplify their setup at Slack, Gunasekara and Martin describe an approach of creating "GovDev" and "GovProd" accounts. While the "GovProd" account is locked to only U.S. persons, the "GovDev" account is more relaxed as it does not contain any end-user data. This allows development teams to deploy and test their applications within a GovCloud environment before handing them over to the GovSlack team to deploy into the more restricted "GovProd" account.

To achieve isolation between the accounts, Gunasekara and Martin share that they "have approached the build out using a full shared-nothing paradigm, which enables the environments to operate in completely different AWS organizations". They created two distinct AWS organizations within GovCloud with an identical, duplicated set of child accounts for each of their dev and prod environments.

AWS GovCloud does not possess the same service set as the AWS commercial regions do. Gunasekara and Martin note that the lack of Route 53 public zones in particular caused some challenges. In order to have public DNS they stood up a commercial AWS account to house the public GovSlack DNS records. That account is also only accessed by U.S. personnel.

AWS ARNs are different between commercial and GovCloud accounts. Commercial accounts are prefixed with arn:aws whereas GovCloud is prefixed with arn:aws-us-gov. Gunasekara and Martin shared that the team desired to maintain the same Terraform modules for deploying in their commercial and GovCloud accounts. To accommodate the ARN difference, the team built a Terraform module to "programmatically build ARNs and discover which AWS partition we are in":

data "aws_caller_identity" "current" {}

data "aws_arn" "arn_details" {
  arn = data.aws_caller_identity.current.arn
}

output "partition" {
  value = data.aws_arn.arn_details.partition
}

output "is_govcloud" {
  value = replace(data.aws_arn.arn_details.partition, "gov", "") != data.aws_arn.arn_details.partition ? true : false
}

AWS GovCloud is partitioned logically and physically from their standard regions with distinct credential access between the partitions. AWS recommends that "workloads that are processing or hosting US export-controlled data to be hosted within the AWS GovCloud (US) partition." This includes workloads requiring FedRAMP High P-ATO or DOD IL4 and 5 PA services.

AWS Standard and GovCloud Partition Architecture

AWS Standard and GovCloud Partition Architecture (credit: AWS)

 

AWS provides some resources for understanding best practices in architecting GovCloud workloads. This includes an implementation guide and a user guide. More learnings from Slack's usage of GovCloud can be found on their blog.

About the Author

Rate this Article

Adoption
Style

BT