Cloud initiatives are the present and future of modern business, but they aren’t inherently destined to succeed. To extract real value from your cloud journey, you need to start with a rock-solid foundation: a secure, reliable, high-performing cloud landing zone. When done right, this will massively reduce the chances of failures further down the line.
A successful cloud landing zone can be delivered on AWS, Azure or GCP, but creating a solid foundation requires skilled guidance. Based on extensive experience, the ten tips below highlight key principles and practices that will give you the best chance of producing a landing zone that is secure, fit for purpose and delivers real value to the business.
But first… what is a landing zone?
A landing zone is a set of standard building blocks (services, processes, etc.) that allow you to automatically create accounts, infrastructure and environments that are pre-configured in line with security policies, compliance guidelines and cloud native best practices. This allows end users to easily consume these basic cloud resources (e.g. get a cloud account, deploy workloads, use services) in a quick, secure and effective manner so they can get on with their work.
How IT operations can be more tied to end-user experience
How to prepare your landing zone
1. Keep a clear focus on desired business outcomes
Always clearly define why your landing zone is being built. A landing zone should be a means to an end. If you don’t focus on delivering a business outcome (the end), then there is a danger that the landing zone itself ends up becoming the sole delivery objective — an end in itself, rather than a means.
2. Assemble the right team
Determine the right skills and team structure that you need and manage these on an ongoing basis. There should be a core team responsible for developing and testing the landing zone code, but this could be augmented with people focused on delivering the business requirements, for example.
Align your team structure with landing zone components. Each member should be clearly responsible for certain components with minimal overlap. Rotate people between delivery functions to avoid creating silos.
It may seem obvious, but ensure that there is someone in your team with experience delivering a landing zone!
3. Choose and execute a ‘lighthouse’ project
One of the best ways of focusing a landing zone implementation is to have a ‘lighthouse’ or ‘pathfinder’ project. This will be the first application or service to use accounts created by the landing zone process. Getting this done quickly helps to drive progress and feedback.
Get support for the lighthouse project early on and ensure the team understands its value. Do not wait until every landing zone ticket is resolved before getting the project out there. Launch as soon as possible to get early feedback.
4. Take a cloud native approach
It is common for businesses to try to emulate their existing on-premise infrastructure in the cloud. This is a mistake. In order to get the most out of the flexibility and scalability of the cloud, you must change how you work to match how the cloud works.
The same applies when delivering a Landing Zone. Timelines can be seriously affected if the delivery becomes dependent on services and resources that may not operate on the flexible cadence that is demanded by an infrastructure-as-code initiative.
5. Clearly define and scope discrete delivery objectives
In the cloud, you can always do ‘more’. You might never finish implementing your landing zone unless you scope and prioritise clear delivery objectives.
Be vigilant as to what constitutes the ‘core’ of your landing zone. Review any new requirement or service carefully to properly ascertain which part of the solution it belongs to and view the ‘business-specific requirements’ components as landing zone features or extensions.
Can businesses exist if they are not in the cloud?
How to deliver your landing zone
6. Automate everything
Embed an automation-first culture for agility and efficiency. The first thought on the delivery of any service or function, whether it be part of the landing zone or beyond into application delivery, should be “how can this be automated?”.
A general rule should be: if you can’t automate it, don’t use it! But, if there really is no choice but to use a service or tool that is not automatable, then ensure that these are reviewed regularly, as services and tools often evolve to allow automation where it was not previously possible
7. Build a test landing zone
Your landing zone is a critical piece of infrastructure and needs to be tested the same as any other mission-critical IT component.
The landing zone extends its security and compliance baseline to all accounts. So, your test landing zone should build accounts that are representative of those in your production landing zone.
Perform regular build/destroy lifecycles on the test landing zone. Doing so will expose any broken dependencies that may have been introduced during enhancement, extension and fixing.
8. Track, measure and demonstrate your security and compliance framework
Regulated businesses have to be able to demonstrate and report on specific security and compliance controls both to internal and external audiences. The key to success here is to make the controls you have in place as transparent and accessible as possible.
Keep the tracking document as simple and concise as possible, and under regular review and share the compliance documents widely for feedback from across the business
9. Go green and stay green
Keep on the right side of technical debt by immediately dealing with any security and compliance alerts as they arise.
Create a security- and compliance-aware culture. Ensure your teams understand how having a robust and well implemented set of security and compliance rules should be an enabler in driving delivery forward, and deal with issues as they arise.
10. Watch the costs
With metered-cost cloud, you only pay for what you use — but also what’s created and remains unused.
There are three main causes of cost overrun: abandoned or forgotten resources left running; poor data retention management; and incorrectly sized resources.
Design a simple resource tagging policy and enforce its usage for cost reporting; tear down and recreate resources daily to allow resources to be removed out of hours and recreated when required; and regularly review resource utilisation and adjust if appropriate.
