Using a Well-Architected Landing Zone to Shape Cloud Success

Cloud landing zones make it quicker and easier to launch and deploy workloads in a consistent, secure and repeatable manner. But to maximise the benefits, you need to ensure their build is properly aligned with wider technical and business-related factors.

Customised vs Custom Build

Security, repeatability and operability are critical success factors for any cloud deployment. A good landing zone sets you up to achieve this from day one. For organisations that have chosen Amazon Web Services (AWS) as their cloud provider, our go-to recommendation is AWS Control Tower. This managed service is based on the Well-Architected Framework, so it always reflects the latest in cloud best practice.

Naturally there are pros and cons to using a managed service versus creating a custom-built landing zone. Your decision should be based on your own circumstances, and AWS outlines some key considerations in this document. However, we generally find that the integral guardrails, default compliance policies and centralised dashboarding of AWS Control Tower outweigh any benefits of a custom build. A big part of cloud adoption is making that mindset-shift from ‘build it and own it’ to the managed services model. It’s about understanding and navigating the various trade-offs to achieve your target outcomes. By taking a managed services approach with the landing zone you can start as you mean to go on.

While AWS Control Tower is an out-of-the-box solution, it can be customised to meet specific needs. So, if you operate in a highly regulated industry with strict data requirements, its guardrails and blueprints can be adapted accordingly. Similarly, large enterprise organisations can use it to ensure cloud activity is consistent and compliant while allowing developers to work autonomously.

The Account Factory feature of AWS Control Tower simplifies this process, but also gives you an additional level of fine grain control.

Cloud Security and Compliance

AWS Control Tower supports a multi-account framework, which forms the cornerstone of a robust approach to security and compliance. Setting up multiple accounts gives you greater ability to isolate resources for more strategic and straightforward management of cloud assets. This is critical for large organisations or any companies that operate in sectors such as healthcare or financial services.

If you need to limit the visibility of workloads or isolate sensitive information for administrative or auditing purposes, using multiple accounts makes things much easier. The same is true for organisations where teams have different responsibilities and resource needs. Users are simply granted access to the relevant accounts, reducing the need for complex permission protocols within accounts. Implementing a landing zone that is geared towards the multi-account approach will set you up for success in this regard.

Identity Management

AWS IAM Identity Center will be your starting point to enable multi-account, single sign on. Previously called AWS Single-Sign On (SSO), IAM Identity Centre centralises authentication in a single place. It uses either a local set of users, or connects to an Identity Provider (IdP), such as Okta, or any other SAML 2.0 compatible service. Additionally, System for Cross-domain Identity Management (SCIM) can be used, with its REST and JSON-based method to ensure identity provision within IAM Identity Center is in sync with your IdP. This enhances landing zone security because on- and off-boarding can happen on the IdP side, with access revoked automatically on AWS.

Once your central source for authentication is set up, users can be assigned ‘Permission Sets’ to access relevant accounts. In this way, access and privileges can be limited according to their requirements and wider security needs.

This approach makes it easier to enable multiple accounts with security segregation implemented across multiple levels. During the recent creation of a customer landing zone, we connected Okta authentication into IAM Identity Center using SAML 2.0 and SCIM. From here, we separated their account structure to include security, core network, shared services, production, test, and development accounts. Very quickly we were able to assign permissions to these accounts and ensure separation of workload. This aligned with well-architected best practice for ‘Organising your AWS Environment using Multiple Accounts’. While certain accounts, (security, core network, shared services) are almost always required for landing zones, their layout and any additional accounts should be determined by customer needs.

Here is an example of a multi-account landing zone deployed for a customer:

Implementing Controls

Landing zones can also be furnished with pre-configured rules for governance, identity management, logging, monitoring and network design. The way these guardrails are customised should reflect the organisation’s current and future needs. Principles such as user separation, protection of data in transit, supply chain security and asset protection should be carefully examined to ensure they are properly accounted for.

For example, AWS Control Tower’s control categories cover objectives, services, and frameworks, and each category offers many control options. Control objectives cover high level requirements for your landing zone, such as ensuring encryption at rest and enforcing least privilege. Controls for specific services provide much finer grained possibilities. Control frameworks are based around a larger base of known controls, such as the CIS Framework, PCI DSS, and NIST. At the time of writing, there are 362 controls, with more added every day. Each of them can be enabled in groups, and then individually controlled or disabled.

Cost Management in the Cloud

Managing cloud spend can be a complex issue for organisations that are accustomed to using a CAPEX model for IT. It’s easy for costs to escalate if you don’t take a rigorous approach to the management of cloud assets. A cloud landing zone can establish good practice here by ensuring all deployments meet cost optimisation requirements.

A well-architected landing zone can also facilitate a DevOps-led approach which may quickly results in cost savings. One of our clients immediately reduced infrastructure spend by more than 70 percent for instances involved in proof-of concept migrations that we handled. This was achieved by automating applications’ scalability while enabling them to interact more effectively and securely, while keeping the blast radius of any issues within the account. Additionally, we ensured proof-of-concept workloads were sized correctly (using the most appropriate AWS Managed Services) then properly maintained. We used Transit and NAT gateways, according to well-architected guidelines, meaning security was enhanced while costs were reduced.

A well-architected landing zone also provides access to consolidated billing and a wide range of tooling that offers greater visibility. With an appropriate tagging strategy, AWS Cost Explorer can be used to drill down into the usage of the entire estate. This provides fine grained reporting, budget alerts, and recommendations on savings plans, reserved instances, and right sizing to get the most from the cloud.

Colin Barker

As a Lead Consultant with almost a decade’s experience in cloud, Colin has extensive knowledge of DevOps, IT Operations, and Cloud technologies. He is generous about sharing his expertise and is recognised as an AWS Certification Lead Subject Matter Expert, an AWS Community Builder, and an AWS Ambassador.