India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Landing Zone Implementation for Migration-Ready AWS, Azure and GCP
Landing zone implementation builds the cloud foundation that migrated workloads land in: account or subscription structure, identity and access, hub-and-spoke networking, guardrail policies, central logging and infrastructure as code. NTSPL builds it with the provider's reference pattern, sized for the migration plan, in Indian regions, and hands over the code so new environments are created in minutes.
Delivered on
In scope
What Goes Wrong When Migrations Land Without a Foundation
Teams that skip the landing zone pay for it in the second wave. The first servers land in one account or subscription with a default network, admins share a root login, logs stay wherever each service puts them, and nobody can say which cost belongs to which business unit. Fixing this after 200 servers have moved means re-IP'ing networks, moving resources between accounts and rewriting access, often with downtime the business did not plan for.
NTSPL builds the landing zone as code before the first production wave, from AWS Control Tower with Landing Zone Accelerator, Azure Landing Zones, or the Google Cloud foundation blueprint. We size address space for five years of growth, set guardrails for Indian regions and encryption, centralise logs with 180-day retention, and connect on-prem through the hub. New accounts, subscriptions or projects are vended from a pipeline.
When to Build the Landing Zone Before Moving Anything
Signals you need Landing Zone Implementation
- A migration of 50 or more servers is planned and no multi-account or multi-subscription structure exists.
- Existing cloud use is in one account with shared admin credentials and default networks.
- Several business units or group companies need separate billing and access in one cloud.
- Auditors ask for central logs, region restrictions or evidence of guardrails.
When to choose something else
- If a well-run landing zone exists and only policy compliance reviews are needed, use Cloud Governance Operations under Managed Cloud Services.
- For a single small workload with no growth plan, a simple secured account or subscription is enough.
Hierarchy, Identity, Network, Guardrails and Logging
Resource hierarchy
Organisation units, management groups or folders by environment and business unit, with account or subscription vending.
Identity and access
SSO from Entra ID, Google or another IdP, role sets per persona, break-glass accounts and MFA.
Hub network
Hub-and-spoke or transit design, on-prem connectivity, DNS resolution, egress inspection and IP plan.
Guardrails
Policies for allowed regions, encryption, public access blocks, tagging and restricted services.
Logging and security baseline
Central log archive, security tooling enablement and 180-day retention in India.
Layered Landing Zone Built as Code
Layered Landing Zone with Vending Pipeline
An organisation hierarchy holds security, shared network and workload accounts or subscriptions, each vended by a pipeline. Guardrails and central logging apply from the top, and the hub connects on-prem and inspects traffic.
Select any component
Layered Landing Zone with Vending Pipeline: click any of its 7 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Landing Zone Reference Patterns on Each Cloud
Control Tower sets up the multi-account structure and region deny controls; Landing Zone Accelerator adds network, logging and compliance configuration as code.
The Azure Landing Zones accelerator deploys management groups, policy assignments and connectivity with Bicep or Terraform modules.
Google Cloud's setup guidance and the Terraform foundation blueprint create folders, Shared VPC hosts and log sinks; VPC Service Controls add data perimeters.
Landing Zone Design Choices That Are Hard to Change Later
How to split accounts or subscriptions
Split by environment first, production and non-production, then by business unit or application group where billing or access must differ. Avoid one account per server group. A mid-size enterprise typically needs 8-20 accounts or subscriptions at the start. Regulated workloads, such as payment or patient data, get their own to narrow audit scope.
IP address plan
Reserve address space for five years. Allocate a /16 per region for cloud, avoid overlap with on-prem and branch ranges, and leave room for a second Indian region for DR. Re-IP'ing after migration is one of the most expensive fixes, so check every existing range, including partner VPNs, before allocation.
Where network inspection sits
Centralise egress inspection in the hub with a managed firewall for most estates. Add east-west inspection between spokes only where policy requires it, such as between payment and general workloads, because it adds cost and latency. Use private endpoints for managed services instead of routing them through the firewall. Log all denied flows.
Preventive versus detective guardrails
Use preventive policies for a short list of non-negotiables: allowed regions, no public storage, encryption required, no root or owner use. Use detective policies for everything else, such as tagging and sizing, so teams are alerted rather than blocked. Too many preventive rules early slow migration waves and push teams to request exceptions.
Landing Zone Build Sequence
Design workshop and IP plan
Hierarchy, personas, network, guardrails and IP plan agreed.
Core foundation build
Hierarchy, identity, log archive and guardrails deployed as code.
Hub network and connectivity
Hub, firewall, DNS and on-prem links built and tested.
Vending pipeline and first spokes
Pipeline creates migration target environments.
Validation and handover
Policy tests, access reviews, runbooks and team training.
What you receive
Foundation Readiness Measures
| KPI | Typical target |
|---|---|
| Time to create a new environment | Under 30 minutes |
| Foundation resources managed by code | 100% |
| Resources outside allowed regions | Zero |
| Accounts with central logging enabled | 100% |
Landing Zone Shortcuts That Cost Later
| Risk | How NTSPL prevents it |
|---|---|
| Overlapping IP ranges with branches or partners break connectivity later. | Every known range is collected in the IP plan workshop and checked before allocation. |
| Too many preventive rules block migration waves. | Preventive rules are limited to non-negotiables; others start as detective alerts. |
| The foundation is changed by hand and drifts from code. | Console changes are restricted and drift detection runs weekly. |
Provider's landing zone accelerator or a custom build?
Start from the provider's accelerator in almost every case: AWS Control Tower with Landing Zone Accelerator, Azure Landing Zones, or Google's foundation blueprint. They encode tested patterns, are updated by the provider, and auditors recognise them. Customise on top for your IP plan, guardrails and naming. Build fully custom only when you have strict requirements the accelerator cannot meet and a platform team to maintain it. A custom build without a team to own it ends up as a one-time setup that drifts within a year.
Key facts: Landing Zone Implementation
Landing Zone Implementation in Practice
2 Landing Zone Implementation scenarios, from Hospital pathology services and Tea plantation and trading group, plus related platform case studies.
Pathology lab network builds a patient-data perimeter before moving its LIS
Tea estate group gives five companies separate AWS accounts under one foundation
Health-tech SaaS moves patient data behind KMS and Identity Center ahead of DPDP
IT services firm brings 43 Azure subscriptions under one policy hierarchy
Landing Zone Implementation: Frequently Asked Questions
How long does a landing zone take to build?
Six to seven weeks for a typical enterprise, from design workshop to handover. A minimal migration-ready zone can be ready in three to four weeks if the design is simple and on-prem connectivity is already ordered. Link provisioning lead times are often the longest item.
What does landing zone implementation cost?
Usually INR 12-35 lakh in services, depending on the number of business units, network complexity and compliance needs. Running cost for shared services such as firewalls, logging and connectivity is often INR 1.5-5 lakh a month and should be planned in the migration business case.
How does the landing zone support CERT-In and DPDP Act 2023?
Central logging keeps audit and security logs for 180 days or more in Indian regions, as CERT-In requires. Region guardrails keep resources in India, and data classification tags help identify where personal data sits for DPDP accountability and breach response.
Can we add a landing zone to an existing cloud account?
Yes. We build the new structure, then move existing resources into the right accounts or subscriptions in planned steps. Some resources can be moved directly; others need recreating. We plan these as small migration waves. Downtime, where needed, is booked like any wave.
Who runs the landing zone after it is built?
Your platform team or a managed service provider. We hand over the code repository, pipelines, runbooks and an exception process, and train the team to vend accounts and change policies through pull requests. Optional managed support is available for the first quarter.
Do we need a landing zone in a second region?
Plan for it even if you do not build it on day one. Reserve IP space and design the hub so a second Indian region, such as Hyderabad, South India or Delhi, can be added for DR without redesign. It costs little to plan early.