I recently attended an event with AWS regarding Landing Zones and common blockers clients have and thought, how would I approach deploying a landing zone?
I have personally deployed a couple landing zones now, in AWS and Azure (not GCP yet!), but coming from a SysAdmin>Cloud background I have some unique thoughts!
Spoiler; I absolutely love them, I think they’re great and I have much more to learn, but they really do help speed up your transition into the world of cloud.
Understand what an LZ is
Initially, as a customer I would need to understand what an LZ is and what it can do for me and my business.
I suspect 9/10 times a LZ will be a great solution, even if you’re not fully utilising it as the general LZ framework itself is fairly light on costs vs the services you might deploy and run on it.
Landing zones benefit everyone, the cloud provider benefits as they’re able to onboard new clients quicker and therefore start charging the customer for services and the customer gets onboarded quickly into the platform and can go off and start building and developing applications to generate themselves revenue, in the middle of this you might have a partner who will be able to help you realise best practice and ensure you’re on the right path and the solution is tailored for your requirements.
So, once you have an understanding of what a LZ is , as AWS puts it:
“AWS Landing Zone is a solution that helps customers more quickly set up a secure, multi-account AWS environment based on AWS best practices. With the large number of design choices, setting up a multi-account environment can take a significant amount of time, involve the configuration of multiple accounts and services, and require a deep understanding of AWS services. This solution can help save time by automating the set-up of an environment for running secure and scalable workloads while implementing an initial security baseline through the creation of core accounts and resources. AWS Landing Zone deploys an AWS Account Vending Machine (AVM) product for provisioning and automatically configuring new accounts. The AVM leverages AWS Single Sign-On for managing user account access. This environment is customizable to allow customers to implement their own account baselines through a Landing Zone configuration and update pipeline.”
In basic terms, to visualise what a LZ is, imagine a traditional data centre down the road your company uses but imagine that in the cloud, someones gone to the effort of building the site, filling it with secure rooms, and security on-site and now all you need to do is configure the environment to your needs, and when you’re done with that environment you can easily tear it down or move it to another building in a relatively short amount of time… well sort of…
“Imagine logging into an AWS account using Single Sign On with MFA, being able to utilise tools like Active Directory to login and access your accounts with varying levels of permissions for each user, automatically having a VPC have visibility of other VPCs within your organisation, having IP ranges which automatically append themselves and keep note so each VPC doesn’t have an overlapping CIDR, ensuring Security Groups controlling your ingress and egress, ensuring your environment is secure using Security Policies to ensure everyone deploying an EC2 has volumes encrypted by default or creating a new AWS account and automatically adding it into your LZ and having it invoke all your organisational policies and much much more, this is the power of a LZ and it can be rolled out in an afternoon once you’ve done your initial review of requirements for the environment.”
Versus,
“You as a customer being handed a credit card and being told go off and deploy a an account within AWS, and in that account it’s completely blank, no guardrails, no automation, it will become a living nightmare in a very short time vs utilising a LZ, even if you only plan on having one account in there, you can still scale easily on a whim without having to-do much work.”
I know which one I’d prefer!
Decide on your LZ poison of choice and really engage the cloud supplier as early as possible!
Its at this stage you’re possibly keen to crack on and deploy a LZ but the issue now is the amount of options you have open to you, such as terraform, control tower, cloud formation and then you look at Azure and they’re using terraform and bicep etc, it can get confusing about what product to select so at this stage I would probably seek out an AWS Partner or liaise with AWS directly themselves, from my personal experience they have been absolutely brilliant at doing all the can to help get you onboarded, the pessimist in me feels this is because the sooner they have you in their ecosystem, the harder it is to move away in the same way moving from iPhone to Android is a nightmare, so bare this in mind but this is my own view and everyone has been absolutely amazing and friendly, there are no stupid questions.
Engaging AWS earlier may also help with costing as they might be able to cut you a deal or offer advice on cost effectiveness itself with whatever solution you go for.
Think about engaging a partner sooner rather than later
As such, when going for a LZ and discussing with the partner, ask them about being cloud agnostic, depending on the partner they may be solely AWS or they might also do Azure, if this is the case then they’ll likely suggest Terraform as the IaC to use - speaking with a partner will help you focus your requirements and understand what is and isn’t possible, they’ve deployed a lot of LZs and they’ll be well versed in this type of work, as such the initial upfront costs will be for sure be very high but spending that money now will save you money later down the line and also accelerate your revenue by being set up quicker than going alone, treat deploying a LZ the same way you might do deploying a new data centre, you really do want to get things right, in the same way if your data centre is too small it just won’t scale and cause issues down the line, the same can be said for your LZ.
Utilising Terraform.. and other perfectly viable solutions
Using Terraform it’ll allow you with some level of moderate difficulty be able to mirror your environment in AWS and Azure, meaning you could easily switch to the other provider down the line should there be a reason for it, such as budget or a client requirement. Generally the TF community is great, and often the solution you’re looking for has already been done a million times by someone else and you can re use and re factor for your purposes.
Now, using Terraform isn’t generally a solution for all your problems and understand it can be quite daunting to learn and use, your business and support teams will need to adjust their approach to operating the LZ and it might not be the best solution for you, as the alternatives are possibly better for you such as the AWS LZA which is made in CloudFormation, a much easier and well documented solution you could go with, which is very much config driven rather than code, but gets the job done also - however locks you into the ecosystem more than the freedom using terraform might provide.
Quick recap
- Understand what an LZ is and why you should use one, even for light workloads.
- Utilise the cloud provider support and reach out to partners where possible
- Evaluate all cloud providers, some might offer more than the other but they’re more/less the same.
- Think about being cloud agnostic, utilise open source where possible, don’t corner yourself with a supplier unless there’s a strict requirement for it.
- Openly evaluate the pros and cons of a technology to use for implementation.
Next ask yourself the following…
Is a LZ for you?
Yes, certainly.
Do you have an existing account you need to move across?
Yes, so I might need to evaluate its compatibility with my potential new environment. An easy way to do this might be to produce a custom conformance pack and deploy it to your existing account, the conformance pack will be customised to your requirements so you’ll be able to give the account a score and understand how difficult it might be to make it work in your new LZ. I understand an existing account is potentially a scary thing but can easily be managed if we put safe guards in place, as such I would likle to start by having an environment within my LZ where I can bring new accounts into my LZ but have them seperate from everything else until I am happy everything is ready to be joined up.
You could utilize the following to help achieve this;
Custom Conformance Packs - https://docs.aws.amazon.com/config/latest/developerguide/custom-conformance-pack.html
Do you know what IaC you’ll use to deploy the solution?
Yes, I will use Terraform.
Did you compare cloud providers?
Yes, but AWS is for me. Azure also looks good but I didnt require some of the tooling thier licencing included, felt like a potential waste.
Does your vision scale?
If I use an LZ itll probably scale better than not having one, else ill need to start over each time I deploy an account ensuring its compliant etc, would be alot of work. Do you have capacity to continually improve and evolve? Yes, understand I’d need to expand my team to allow for this.
What are your current struggles?
The ability to scale quickly and deploy into the cloud securely and in a time efficient manner.
I’ve engaged the partner…
Ok, so now I have decided I am using a partner and we’ve agreed terraform is the way forward, the partner has developed a solution template and has worked with me to deploy that into my business, we need to ensure that before we deploy the following things are in place. We are now focusing more on the operational side of things which is ontop of the solution they’ve developed, which will lilkely be a solution they think will fit most of thier clients but require some moving parts to make it mwah (chefs kiss).
Pipelines
I need to have the ability to deploy changes to my environment through a pipeline, any changes to the environment need to go through a CAB to ensure my environment remains secure and fault resistant utilising CICD methodologies. I want to use GitHub for this and GitHub actions seem like a great fit.
Terraform
I need to ensure terraform keeps a state file securely within my environment, and that the file is locked when changes are made to prevent contamination of my state, with secure IAM permissions tied to the account to minimise my attack surface through aforementioned pipeline approvals.
Identity Controls
I need to have IAM permissions in place so that my users can login using SSO rather than having an individual user for each account, this will allow me to easily manage my users at scale but also utilise MFA to secure my environment. Identity Center with AD seems a good fit.
Active Directory
I need an active directory so I can ensure domain joined machines and users logging in have environments that are controlled for external protection but also help prevent inside attacks on the domain, utilising OUs and GPOs to manage the systems and the applications that run on them.
Domains
I need to have a domain hosted so I can tie this to my domain controller, this needs to have the ability to utilise sub domains for all my internal systems and applications. Route 53 seems a good fit.
Guardrails
I need to ensure my environment is secure and compliant, I dont want people deploying S3 buckets with public access enabled, or I want to enforce VPC endpoints are being used and/or allow certain users to deploy TGW attachments, I want to ensure people want to use the environment but also respect they need to be responsible for what they deploy.
Certificates
I need to ensure that certificates can be used, so that my applications can be accessed securely and not be exposed. I want to utilise SSL and TLS where possible.
Networks
I want to ensure that any new account I deploy has a standardised VPC with SG rules applied out the box, I don’t need the default VPC so that needs blockingand I also only want resources like this deployed in certain regions, I also want the ability to have these VPCs talk into a central hub where a network team can review and attach networks together seamlessly. I also want to ensure that when the new account and VPC is deployed, that the LZ knows of all existing CIDRs that have been deployed so we never encounter an overlapping range causing issues with the TGW.
Service Management
I need a tool so that internally my customers can raise requests and tickets, improvements for my environment so that I can offer value but also need common pains the business has so I can further improve the product.
Billing
I need to ensure that all my billing is automated to the right people and paid promptly when invoices come in. I probably need to get my billing team some AWS training on how to manage.
Contacts
I need to ensure resources have contacts so if for example a VPC needs some SG ruling changing, I know who owns that VPC so I can run the change by them to ensure we’ll not be affecting live services.
The above are just some considerations and possible demands I could make depending on the agreement with the partner and if they can help with 75% of it, then that makes my life a lot easier.
Fast forward…
So we worked with the partner and we implemented the solution I set out at the start
“Imagine logging into an AWS account using Single Sign On with MFA, being able to utilise tools like Active Directory to login and access your accounts with varying levels of permissions for each user, automatically having a VPC have visibility of other VPCs within your organisation, having IP ranges which automatically append themselves and keep note so each VPC doesn’t have an overlapping CIDR, ensuring Security Groups controlling your ingress and egress, ensuring your environment is secure using Security Policies to ensure everyone deploying an EC2 has volumes encrypted by default or creating a new AWS account and automatically adding it into your LZ and having it invoke all your organisational policies and much much more, this is the power of a LZ and it can be rolled out in an afternoon once you’ve done your initial review of requirements for the environment.”
We put in the initial time and effort to build out this solution and my business users can now raise a ticket and we can deploy multiple accounts within an hour, fully secure and compliant and each account for the most part follows the same policies which makes my life alot easier, this solution scales really well as I can have a vast amount of accounts with the confidence of security and control.
As you can see in this hyper shortened overview of deploying an LZ, it’s really easy and I may have over simplified a lot of parts, it’s still really easy and important to utilise tools such as this, it really does accelerate the “time to cloud” principles.
If you’d like any advice on deploying a LZ, this being my own personal opinion and no-one else’s then I would be happy to help, reach out on LinkedIn or buy me a coffee if we meet in person. :)
Some useful documents and links:
AWS Landing Zones Accelerator https://github.com/awslabs/landing-zone-accelerator-on-aws
AWS Sample LZ Configurations https://github.com/awslabs/landing-zone-accelerator-on-aws/tree/main/reference/sample-configurations
Manage AWS accounts using Control Tower Account Factory for Terraform https://developer.hashicorp.com/terraform/tutorials/aws/aws-control-tower-aft
Azure Landing zone implementation options https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/implementation-options#implementation-options
Custom Conformance Packs https://docs.aws.amazon.com/config/latest/developerguide/custom-conformance-pack.html
Provision and manage accounts with Account Factory https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html#configuring-account-factory-with-VPC-settings
AWS Control Tower Pricing https://aws.amazon.com/controltower/pricing/
Setting up a secure and scalable multi-account AWS environment https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/welcome.html
Utilize some AWS Conformance Packs https://github.com/awslabs/aws-config-rules/tree/master/aws-config-conformance-packs
AWS Control Tower Detective Guardrails Conformance Pack https://docs.aws.amazon.com/config/latest/developerguide/aws-control-tower-detective-guardrails.html