Optimize AWS Landing Zone

Optimize AWS Landing Zone

This post was originally published on Caylent.com here.

AWS consistently releases best practices guides, whitepapers, and documentation to outline more and more ways for developers to simplify cloud infrastructure management. Manually maintaining and managing cloud infrastructure is utterly feasible when you have a single, simple environment to control. Add complexity into the mix, however, and it is easy to lose track of the nodes and services you have running.

Architectural complexity becomes even more challenging when you start leveraging multi-account environments across your organization. Using multiple accounts and services allows you to overcome specific challenges of developing and running cloud-native apps in a seamless and efficient way, but it is certainly not something you want to do manually.

This is where AWS Landing Zone is designed to come in handy. AWS Landing Zone is a solution that is designed from the ground up around running multiple account and cloud environments with complex AWS clusters while staying true to AWS Well-Architected Framework best practices. Even better, there are ways you can optimize AWS Landing Zone for specific purposes.

Starting from Scratch

The real challenge of deploying cloud-native apps on top of Amazon services doesn’t lie in the actual deployment process itself. Amazon offers tools like CodePipeline and CodeDeploy, both of which streamline your deployment pipeline significantly.

The real challenge is configuring a base environment that can support the native apps running on top of it in an efficient yet sustainable way. You have to think not only about the challenges you face right now but the potential challenges you face in the future.

There are a lot of basics to cover in this phase. The base environment is called the landing zone because it is where your cloud-native apps and microservices land when they are ready to be deployed.

The landing zone includes key elements such as your account structure, your IAM and security configurations, the default network settings, and of course, the basic services you use to power your AWS environment.

Support for multiple accounts allows for larger environments to be managed by multiple teams. Since teams can focus on a specific part of the environment?—or certain services they are regulating?—you can configure the accounts in such a way that they don’t overstep each other.

Key Components

A multi-account structure provides the best balance between ease of use and control. Rather than having teams sharing a single master account?—which is the root of many fundamental issues faced by those running their apps this way?—they can have core and team accounts with separation of access and resources.

The organization still has a single master account, and this is the account that provisions member accounts and cloud resources. Amazon provides AWS Organizations Service to make managing your organization’s master account a smooth process.

There are also Core accounts in an organizational unit with access to critical functions such as Shared Services and Log Archive. For teams and departments, you can configure Team or Group accounts, each with its own group level; this allows for detailed control over accounts.

Team accounts can have Core accounts in them. This means a Team can have access to security functions and Shared Services in such a way that access control becomes easy. Alongside team accounts, you can also have Developer accounts for individuals completely sandboxed.

Another key component to this setup is connectivity. Accounts can have customized networking patterns, but it is still necessary to set up default networking patterns for both the accounts and external data centers and services.

Keep in mind that setting up these accounts?—the structure of your multi-account cloud environment?—manually involves making a lot of design decisions and staying true to them. As mentioned before, trying to configure a complex cloud environment manually can be daunting.

AWS Landing Zone Optimization

Fortunately, AWS Landing Zone eliminates the need for manual configuration of cloud structure and replacing it with a simple, automated workflow. When you configure AWS Landing Zone, the service automatically configures your multi-account architecture and key components.

When you start adding new accounts and altering the base configuration of your cloud architecture, Landing Zone maintains efficiency and scalability behind the scene. Account Baseline, Shared Services, and other components can be linked to organizational units.

The service also lets you comply with AWS best practices without doing manual checks, regardless of the architecture you are trying to build. You can have a Log Archive Account with CloudTrail logs, Audit Account with CloudWatch aggregator, and Security account with GuardDuty and SNS.

Landing Zone grants you access to the Account Vending Machine, which simplifies creating new accounts even further. AWS Single Sign-On is used by default, so there is no need to manually configure user roles or create separate accounts to compartmentalize different AWS services.

As an added feature, Landing Zone integrates well with AWS Service Catalog; well, all AWS services play well with each other. AWS Service Catalog allows self-service architecture management from multiple accounts.

More Optimization Tips

If you think AWS Landing Zone is useful enough with the automation features that it offers, you will certainly appreciate the optimization options the service also offers, starting with the fact that you can optimize the manifest file used by AWS CodePipeline to configure the way accounts are set up.

Blueprints and security measures are also fully integrated, but you can take it a step further and integrate your own security policies for an air-tight cloud environment. Since Landing Zone always follows AWS best practices, security becomes less of a concern.

Other optimizations?—and modifications?—that can be added to Landing Zone for better visibility and scalability are:

  • Auto-tagging, which can be achieved with a simple auto-tagging template
  • Access key rotation for better security via IAM
  • MFA enforcement
  • KMS rotation configured to the specific timeframe that suits your needs
  • Integration external services like Slack for alerts and notifications
  • Budgeting and billing notifications for accounts
  • Global security mods, including denying the creation of an internet gateway for accounts
  • CloudWatch integration for better visibility

That last part is actually very important. You can create a comprehensive dashboard by integrating CloudWatch status check and using Lambda function to monitor CloudTrail for certain activities such as specific API calls.

Everything else is easy from there. With AWS Landing Zone creating the perfect, well, landing zone for your cloud-native apps, you can focus on developing and deploying the apps rather than creating a suitable environment for them to run.


Caylent provides a critical DevOps-as-a-Service function to high growth companies looking for expert support with Kubernetes, cloud security, cloud infrastructure, and CI/CD pipelines. Our managed and consulting services are a more cost-effective option than hiring in-house, and we scale as your team and company grow. Check out some of the use cases, learn how we work with clients, and read more about our DevOps-as-a-Service offering.

要查看或添加评论,请登录

Agustin Romano的更多文章

社区洞察

其他会员也浏览了