Cloud Landing Zone Design

A cloud landing zone is the structured foundation that isolates environments, enforces organizational policies, and provides a repeatable starting point for workload deployment. It matters when an organization needs to multi-account, multi-region, or multi-team deployments without accidental overlap, compliance gaps, or unmanaged cost drift. This page maps the design decisions and operational patterns you need to get a landing zone from concept to a defensible, observable state, organized by the concrete tasks a reader faces rather than a product taxonomy.

1. Define network and identity boundaries

Design pattern

Isolate CIDR blocks per account or region, segregate DNS namespaces, and apply organization-wide guardrails that restrict which principals may provision resources in which address space. The goal is to prevent accidental routing leakage and to make identity boundaries explicit enough to be audited.

Concrete example

List all namespaces with their environment and team labels to verify segmentation:

kubectl get namespace --show-labels -o custom-columns=NAME:.metadata.name,ENV:.metadata.labels.env,TEAM:.metadata.labels.team

Validate a principal’s assigned address space against the landing zone plan via a control‑plane API:

curl -sS -H "Authorization: Bearer $AUDIT_TOKEN" https://control-plane.example.com/v1/identity-boundary-check \
  --data '{"principal":"arn:aws:iam::123456789012:user/deployer"}'

The response indicates whether the principal’s allowed CIDR set overlaps with the target environment’s range.

Sharp edges

• Overlapping CIDRs between staging and production cause return traffic to be routed to the wrong environment, often without immediate error‑logs; connectivity appears functional until packet traces are run.
• IAM role names that are unique per account can collide in shared services DNS when accounts are merged or peered, leading to authentication failures that are difficult to trace.
• Service‑account tokens harvested from a permissive environment and reused in a restricted one bypass intended boundary SCPs, because the token’s embedded permissions are not re‑evaluated at the boundary.

2. Enforce resource naming and tagging

Design pattern

Codify naming conventions as code‑review gate checks and enforce tag schemas that cost‑allocation and automation tools can consume. Treat the naming policy as a version‑controlled artifact so that all teams update in lockstep.

Concrete example

A pre‑commit hook that validates resource filenames against the org convention <env>-<team>-<seq>:

#!/usr/bin/env bash

changed=$(git diff --cached --name-only)
echo "$changed" | grep -E '^(infrastructure|networking)/' | while read -r path; do
  if ! echo "$path" | grep -qE '^(infrastructure|networking)/[a-z]{2}-[a-z]{2}-[0-9]{3}$'; then
    echo "ERROR: Resource name does not match org convention: <env>-<team>-<seq>"
    exit 1
  fi
done

Apply a consistent tag set to all resources at creation time using a Terraform variable or Helm values file that enforces required keys such as environment, owner, and cost-center.

Sharp edges

• Tag keys reserved by the cloud provider (e.g., kubernetes.io/role or kubernetes.io/cluster-lookup) silently override user‑defined tags, causing cost reports to misattribute spend.
• Naming conventions that include the environment name as a prefix can cause accidental resource deletion when a broad kubectl delete all -l environment=prod is run across accounts.
• Tags applied after provisioning via patches are not retroactively reflected in billing files until the next cost‑aggregation cycle, which may be 24 hours or more behind real usage.

3. Centralize logging, metrics, and tracing

Design pattern

Deploy a log‑forwarding agent (DaemonSet or sidecar) that ships container stdout, node metrics, and custom application traces to a central collector over a TLS‑verified endpoint. Ensure the forwarder’s configuration is stored in version control so changes are auditable.

Concrete example

Check the health of a Fluent Bit forwarder:

systemctl status fluent-bit

Push a test log entry directly to the ingestion endpoint:

curl -X POST https://telemetry.example.com/ingest \
  -H "Content-Type: application/json" \
  -d '{"level":"info","source":"landing-zone","env":"prod","msg":"bootstrap-complete"}'

Sharp edges

• When the forwarder’s TLS certificate expires, logs silently drop until the pod is restarted or the certificate is renewed; no error appears in the agent’s own output, only a gap in the central store.
• High‑cardinality metric labels (e.g., a unique request‑ID per pod fill the time‑series database, causing query timeouts and increased storage costs.
• Both a sidecar injector and a DaemonSet configured to forward the same container logs produce duplicate entries, which inflates apparent throughput and can trigger false‑positive anomaly alerts.

4. Codify guardrails with policy‑as‑code

Design pattern

Store Rego policies in a Git repository alongside manifests. Run the policies in CI on every pull request and enforce them at admission time via a Kubernetes validating webhook. This creates a feedback loop that catches misconfigurations before they reach production.

Concrete example

Run the policy suite against the staged manifests:

opa test ./guardrails/ --data ./k8s-manifests/ -f pretty

A minimal Rego rule that rejects namespaces missing the environment label:

# ensure-resource-tagged.rego
package landingzone.v1

deny[{"msg"}] {
  input.resource.kind == "Namespace"
  input.resource.metadata.labels.environment == ""
}

msg := "Namespace is missing required label: environment"

Sharp edges

• A syntax error in any policy file causes opa to exit non‑zero, blocking all CI merges until the error is fixed; teams sometimes bypass the gate by using --skip-policy-check flags that are not centrally audited.
• Admission webhook timeouts (default 30 seconds) cause kubectl apply to hang, leading developers to retry or escalate, which can mask the underlying policy misfire.
• Policies that check for resource existence at admission time can race with concurrent creates, allowing a brief window where a non‑compliant resource is live before the webhook evaluates the request.

5. Automate validation and drift detection

Design pattern

Integrate schema validation, policy testing, and drift comparison into a single CI step that gates merges. Compare the declared state in version control against the live cluster state using kubectl dry‑run and tool‑specific drift detectors.

Concrete example

A Bash snippet that runs three checks and fails the build on any error:

#!/usr/bin/env bash
set -euo pipefail

# Schema validation
kubeconform -strict ./charts/**/templates/*.yaml || exit 1

# Policy check
opa test ./guardrails/ --data ./charts/**/templates/ || exit 1

# Drift detection via client‑side dry‑run
kubectl apply --dry-run=client -f ./charts/prod/ > /dev/null

Sharp edges

• kubeconform strict mode may produce false positives when alpha or beta APIs are used, forcing teams to relax flags and potentially miss real schema violations.
• opa test evaluates policies against the static manifest data; it does not reflect runtime side‑effects (e.g., dynamic admission responses), so policy‑passing manifests can still produce non‑compliant clusters.
• kubectl apply --dry-run=client validates only against the local kubectl configuration; it does not contact the API server, so drift between the CI environment and the production cluster goes undetected until the next sync cycle.

This page was rewritten on 16 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.