AWS Landing Zone Setup: Part 1

If you are new to AWS then AWS will mean just an account with console access where we can provision many resources like- EC2, S3, EBS by few clicks. You can even develop your own application and deploy it in no time using services like- Lambda and Amazon Q for builders.

This approach is good for POC but have you ever wondered what it takes to get Production like setup for hosting your app. These series of articles will help in understanding this clearly.

So let's go back to your original requirement of deploying an application in production grade environment. At high level, you will need AWS account with appropriate security controls.

Next question is how many accounts will you need? Is 1 AWS account good enough?

Answer is No but why? Let's understand this from AWS landing zone concept.

AWS recommends multi account architecture where below accounts are mandatory ones.

1. Management account- This account should only be used for billing and governance. No workload provisioning should happen here.
2. Log Archive account- This account is used for centralized logging from all accounts. This account is created under security OU.
3. Audit account- This account is used for centralized deployment of all security tools. This account is also created under security OU.

What is AWS Landing Zone?

Landing zone concept is not new, it has been there since last several years. Here is official definition of it.

AWS Landing Zone provides a secure and scalable multi-account architecture on the AWS Cloud, with automated setup and customization options, and support for global and regional resource.

AWS recommends building your landing zone before your application can be hosted there. Landing zone is like building your own data center in cloud that has most of the elements of data center like- DNS, AD, NTP, Network design, Firewalls, IDS/IPS, End point security, Cloud security posture management, threat detection, identity and access management, data security, network security, IPAM, VPN, Direct connect and many more components. Since it is cloud, you don't need to deal with H/W.

Setting up your Landing Zone

Setting up landing zone, by no means this is simple task and it easily takes 8-12 weeks and major part of it goes in planning, designing and license procurement.

AWS provides a service called AWS control tower which automates the landing zone creation. When you setup control tower below action happens-

• Organization Unit creation
• Shared accounts creation
• Configuring IAM identity center
• Applying preventive and detective controls using GuardDuty
• Enabling of AWS cloud trails and AWS config in all accounts

So here are the steps that you need to follow-

1. Create your first account and let's convert this into management account
2. Login to this account and enable control tower.
3. Control tower will setup landing zone, it takes up to an hour to complete this setup.

After completing above steps, your basic landing zone is ready but we still don't have any aws account for workload deployment. you can easily create new accounts using control tower. Control tower ensures new account is compliant with default setup hence it takes 10-20 minutes to create new account using control tower. Here you are creating member (child) accounts.

Now the question is, are we good to create workload accounts (say application1 prod account, application 1 dev account etc.) and get going from there?

Not yet as we haven't defined the 2 important aspects.

1. Network design
2. Security

Network Design

AWS recommends using Hub and Spoke model where one central hub account is responsible for all ingress and egress to all member (spoke) accounts. To implement hub and spoke model, you need to consider few things. Key questions here are-

1. Which firewall to use? (AWS native or any 3rd party firewall)
2. What will be the deployment model of firewall? (centralized or distributed)
3. How Hub and spokes will be connected? is it via transit gateway?
4. Do you want to implement centralized egress and ingress?
5. What will be IP schema of all accounts?
6. What all regions should be enabled?
7. What will be your hub region?
8. Will there be more than one hub?
9. How will you connect one hub to another?
10. Do you need direct Internet access on spoke VPCs?
11. How will users access AWS resources from on-prem? (VPN- S2S/Client VPN)
12. Do you need direct connect?
13. How HA will be taken care in this entire deployment to avoid any single point of failure?
14. What are various network flow requirements like- VPC A in account 1 should not talk to VPC B in account 2?
15. How many VPCs, Subnets with what CIDRs and Security groups are required for various applications?

As you can understand that lots of decision making happens here. It is recommended to capture these points in design document along with decision matrix.

Security Design

There are various domains of security and each one of these have sub-domains and goals. Some examples are given below-

1. Identity and access management- e.g. IAM identity center, AD, RBAC
2. Network security- e.g. AWS shield for DDoS, Network Firewall, Application firewall (WAF)
3. App and data protection- e.g. security at rest and in transit using SSL, encryption, secrets manager, vault
4. Threat protection- e.g. AWS GuardDuty
5. Security monitoring and governance- e.g. AWS security hub, SIEM tool, CSPM tool

Based on your audit and compliance requirements, you choose the right security tools and implement those. as you can understand, this is also very wide area, and this is not one time activity. One has to constantly improve security posture.

Only after you complete your network and security implementation, you are ready to welcome new workloads in various workload accounts.

Hope this article provided you high level view of what goes behind setting up AWS greenfield environment. In next part, I will do deep dive on network and security aspects.

Thanks for reading !!!.