Three Success Stories of AWS Landing Zone (Technology Overview)
After introducing Terraform Module for AWS Landing Zone and providing Business Overview of Our Experience with AWS Landing Zone, let’s dive deeper into the technical overview.
In this article, we will be covering the technical aspects of implementations and critical details that helped deploy and manage consistent multi-account strategy using AWS best practices. We will start with reference architecture (see picture below) for AWS Landing Zone solution and dive deeper into each customer’s customization that make their solutions both unique and reusable.
Getting Started
First step is to include terraform module for AWS Landing Zone into your code base. For example:
module "landing_zone" {
source = "./modules/landing_zone"
root_path = path.module
landing_zone_providers = {
default = {
account_id = "123456789012"
region = "us-east-1"
}
[...]
}
landing_zone_components = {
landing_zone_vpc = "s3://terraform-aws-landing-zone/mycompany/landing_zone_vpc/default.tfvars"
[...]
}
}
NOTE: Placeholder […] from above is used to suggest that similar syntax can be added. Remove it or update in order to have valid HCL format.
Definition of landing_zone_providers
and landing_zone_components
allow flexible and consistent provisioning of AWS resources across multiple AWS accounts and/or AWS regions. Similar to microservices architecture, customers of this terraform module are encouraged to define one terraform resource per one landing zone component.
For simplicity, we moved both arguments landing_zone_providers
and landing_zone_components
into variables. We are manipulating them at runtime by supplying customized terraform.tfvars
. In this case, our terraform module reference becomes simple and immutable:
module "landing_zone" {
source = "./modules/landing_zone"
root_path = path.module
landing_zone_providers = var.landing_zone_providers
landing_zone_components = var.landing_zone_components
}variable "landing_zone_providers" {
type = map(map(string))
}variable "landing_zone_components" {
type = map(string)
}
VERY IMPORTANT: You can define lots of providers and include tons of components, but only the ones referenced in associated .tfvars
files will be provisioned / deployed by terraform module.
Common Components
The following components are pretty common across our customers:
- AWS Organization (referenced here)
- AWS Service Catalog
- AWS IAM, including Identity Providers; excluding AWS SSO
- Amazon VPC, including Subnets, Routes, Gateways, NACLs, Security Groups, Peering or Direct Connect (referenced here)
As you can see from above mentioned references, the demo .tfvars
files are stored in s3://terraform-aws-landing-zone/mycompany/[component_name]/default.tfvars
(publicly available). The goal is to provide reusable structure of immutable configurations that can consistently provision / deploy terraform resources (to be read: AWS resources) across multiple terraform providers (to be read: AWS accounts and/or AWS regions) without any need to make changes to landing zone components. Only .tfvars
are changed over time.
But more importantly, we can use the same S3 bucket (or create one bucket per customer) and assign IAM temporary credentials (or cross account role) for each customer without exposing private information stored in .tfvars
files. Every execution of terraform module can clearly delimit IAM credentials (or roles) for where .tfvars
files are located, where .tfstate
files are stored as backend and/or where AWS resources are provisioned / deployed.
Unique Components
Unique components are only unique on architecture diagram, while in reality all components are executed the same, meaning terraform configurations are open source and publicly available, while .tfvars
files are private and pretty unique to every customer.
And, to be clear, not all landing zone components were creating AWS resources from scratch. For example, some customers already had VPCs or IAMs. In these cases, we used terraform import
to bring in existing AWS resources and avoid duplicated or colliding resources.
Unfortunately we don’t have written permission to disclose customers names. That is why we will be referencing them below by their revenue from last year.
Customer #1: $49B in revenue
In this case, we worked with a customer who is using the following 3rd party services and tools that are not native to AWS:
- AWS SSO => Office 365
- AWS CodePipeline => Jenkins
- AWS GuardDuty => SignalFX
- Logs => Splunk
As shown in the diagram on the left, terraform based implementation of AWS Landing Zone is perfectly inline with AWS best practices. By replacing AWS native solutions with similar 3 party products, we were able to combine existing solutions and AWS cloud in perfect harmony.
Customer #2: $33B in revenue
In this case, we worked with a customer who is using the following 3rd party services and tools that are not native to AWS:
- AWS SSO => Ping Identity
- AWS CodePipeline => Bamboo
- Amazon S3 => Bitbucket
- AWS Parameter Store => Vault
- AWS GuardDuty => Alert Logic
- Logs => Datadog
Similar to previous customer, the diagram on the left reflects a sustainable customization of AWS Landing Zone solution where some native components to AWS are being replaced with existing comparable 3rd party solutions.
Customer #3: $11B in revenue
In this case, we worked with a customer who is using the following 3rd party services and tools that are not native to AWS:
- AWS SSO => SiteMinder
- AWS CodePipeline => TravisCI
- Amazon S3 => GitHub
- AWS GuardDuty => OSSEC + Grafana
- Logs => Elastic + Grafana
Similar to previous customers, the architecture diagram on the left is a customized version of AWS Landing Zone diagram with several AWS native solutions replace with similar 3rd party services or tools that customer already uses in their organization.
Summary
- This terraform module accepts arguments
landing_zone_providers
andlanding_zone_components
among others - Providers and components can be as many as you want; Only the ones referenced in
.tfvars
files will be provisioned / deployed - Ideally the code for landing zone components is immutable, while
.tfvars
files are adjustable over time - Microservices architecture is highly recommended, aim for one terraform resource per one landing zone component
- Use
terraform import
for existing AWS resources to avoid duplication or collisions with landing zone components
Conclusion
In this article, we tried to describe relevant level of details associated with technical implementation of AWS Landing Zone solution using terraform module. We talked about 3 different customers without disclosing their names and any private information. Component based immutable terraform configurations with adjustable .tfvars
files allowed advanced flexibility and reliable consistency across multiple AWS accounts using AWS best practices.
Share your thoughts and your experience on LinkedIn, Twitter, Facebook or in the comments section below.