Cloud Agentics Talk to an engineer

Landing zone

Your AWS platform, built layer by layer.

A landing zone is the foundation of an AWS estate: the accounts, the network, the security controls and the capacity that every workload uses. Scroll to take the platform apart. Each layer answers one question your board will ask.

Scroll

01Governance

Landing zone

Who owns what?

Every team, environment and project gets its own AWS account. Each account inherits the same guardrails, central logging and single sign-on on the day it is created. Cost is visible per team, and a mistake in one account cannot reach another.

  • New environments in a day, with the controls already in place.
  • One login for every engineer, with access that matches the role.
  • Spending reported by team and by environment.

02Connectivity

Network

How does traffic move?

One hub connects every environment and your offices. Internet traffic leaves through a single inspected path, and internal traffic never crosses the public internet. Growth adds a spoke to the hub, not a redesign.

  • Private connections to your data centres and branch offices.
  • One inspected exit to the internet instead of one per application.
  • Room for new environments without new design work.

03Protection

Security

What is allowed in?

Each tier accepts traffic only from the tier in front of it. Web traffic is filtered before it reaches your applications, threats are detected across every account, and secrets are stored outside the code. Evidence for audits is collected continuously.

  • A web application firewall in front of every public entry point.
  • Threat detection and findings in one place for every account.
  • Encryption keys and secrets managed centrally, with rotation.

04Compute

Workloads

What runs, and how does it scale?

Capacity follows demand. Servers scale out at peak and back at night. Part of the fleet runs on spare capacity at a fraction of the price, and functions run only when events arrive. You pay for what the business uses.

  • Automatic scaling for web tiers, containers and databases.
  • Spare-capacity instances for work that can be interrupted.
  • Serverless functions for work that runs on events.

Overview

Four layers. One team that runs them.

We set up each layer with your team, migrate your workloads into it, hand over the code and the documentation, and optimize the estate as it grows.

Setup and migration

How a landing zone engagement runs

Three stages, each with a written result and an acceptance test your team signs off. We can execute every stage, or your team executes with our review.

1Discovery

Your estate and your constraints

We read the current accounts, networks, identities and workloads with read-only access, and we interview the teams that own them. You receive the findings and the target account structure.

2Roadmap

Target architecture and migration order

We agree the four layers, the order in which workloads move, the rollback plan for each move, the scope and the price. Setting the scope and the contract takes one to two working days.

3Build and migrate

Layer by layer, environment by environment

The landing zone is built as code. Workloads move one environment at a time, each with a test before the cutover. You receive the Terraform code, the documentation and a handover session.

Deliverables

What you receive

The platform

  • A multi-account AWS organization with guardrails, central logging and single sign-on.
  • A hub-and-spoke network with one inspected internet exit and private links to your sites.
  • Security controls in every account: web application firewall, threat detection, managed keys and secrets.
  • Compute that scales with demand, with spare-capacity and serverless options where they fit.

The hand-over

  • Terraform code for every layer, in your repository.
  • Architecture documentation and runbooks for the operations your team will run.
  • An acceptance test per stage, signed off by your team.
  • A handover session with the engineers who built it.
Plan a landing zone