# The AWS Landing Zone for SAP

*Part 2 of a 4-part series on SAP Landing Zones in the cloud. Part 1 covers why this still matters and the seven-attribute framework this Part applies concretely. Client details anonymised: a global life-sciences/diagnostics manufacturer running SAP across four global regions.*

* * *

## Abstract

Part 1 of this series established why SAP landing zones still matter and laid out a seven-attribute framework. This paper applies that framework concretely to AWS, using an account structure and network topology that have run live SAP workloads across four global regions. It covers the real account hierarchy (including a deliberately isolated backup account built to prevent the exact failure mode behind a ransomware recovery described elsewhere in this series), the network topology and a real inter-region routing mistake worth learning from, a requirements-driven approach to disaster recovery with real RTO/RPO targets, and the identity, security, governance, and cost mechanisms that complete the picture — closing with a design-to-implementation checklist mapping every attribute to a concrete AWS construct and IaC target.

* * *

Part 1 laid out seven attributes every SAP landing zone needs to answer. This Part shows what a real, production answer looks like on AWS, built from an account structure and network topology that have run live SAP workloads across four regions.

![Figure 1: Organisation Structure](https://cdn.hashnode.com/uploads/covers/6a4cf82b1a55ad22dd20cb89/f6581041-382e-4ca1-852d-8076badc04aa.png align="center")

## Account structure

Five OUs sit under Root. **Security** holds audit and log archive, isolated from anything that could tamper with incident evidence. **Infrastructure** holds the global, shared-once accounts — networking, orchestration, IAM, and regional encryption accounts. **SAP Workload** is where the regional pattern repeats identically across all four regions. **Policy Staging** and **Suspended** round it out: a safe place to test governance changes before they go live, and a clean landing spot for decommissioned accounts.

![Figure 2: Global and Regional Accounts](https://cdn.hashnode.com/uploads/covers/6a4cf82b1a55ad22dd20cb89/99f98c1c-b590-4b71-bedb-f742cf09dd69.png align="center")

**Global accounts are built once and shared by the whole estate.** Payer and network sit together, since billing and core connectivity are both estate-wide concerns. **Break-glass IAM** is a dedicated emergency-access account — an IAM admin user and switch-role path for the moment primary federated access is unavailable or compromised, which is exactly when you can least afford to discover your recovery path doesn't work.

**Regional accounts repeat identically per region:** Production, Non-prod, Shared services, Sandbox, and Encryption. The sixth, **ICE storage** (in case of emergency), is worth pausing on — a deliberately isolated backup account, separated from production so a compromise of production can't also compromise its own backups. This is the architectural answer to a failure mode I've written about elsewhere: a ransomware attack that wiped both a client's production SAP systems and their EBS snapshots, because the backups lived inside the same trust boundary as what they protected. Recovery only worked because AWS Support found deleted snapshots in an account recycle bin — luck, not design. ICE storage is that safety net built on purpose.

## Network topology

![Figure 3: Network Topology](https://cdn.hashnode.com/uploads/covers/6a4cf82b1a55ad22dd20cb89/5237b349-e5bb-4362-9ce5-6a9639351561.png align="center")

A Transit Gateway sits at the centre of every region — and it's genuinely regional: Figure 2 shows one region's hub, each of the four regions has its own. Here's what lives in each spoke:

| **VPC / spoke** | **Purpose** | **Key components** |
| --- | --- | --- |
| **Corporate DC connectivity** | Hybrid link back to on-premises | Two Direct Connect VIFs per region for redundancy — HQ runs two in a primary region and two in a secondary region — plus site-to-site VPN as fallback; BGP handles automatic route switching |
| **Shared services VPC** | Internal cross-tier tooling, not internet-facing | Backup, Windows and Linux patching, endpoint protection, jump hosts, centralised SAP services — Solution Manager where still used, HANA Cockpit, internal Web Dispatcher, load balancers |
| **SAP DMZ VPC** | Every internet-facing SAP component, isolated from the internal network | SAProuter, external-facing Web Dispatcher, SAP Cloud Connector, mail gateway |
| **Workload & access VPCs** | Environments and remote access | Production, QAS, DEV, Sandbox; Client VPN for third parties; PrivateLink for AWS-native services without touching the public internet |
| **WAF firewall VPC** | Enforced outbound chokepoint and controlled inbound path | Inbound: SAP Support to SAProuter, Fiori traffic through the load balancer and Web Dispatcher. Outbound: every other spoke's only internet route. |
| **DNS** | Private name resolution estate-wide | Route 53 private hosted zones and resolver rules, resolver endpoints attached via a per-region Service VPC inside the global Network account |

Four things worth flagging outside the table.

**SAP Cloud ALM doesn't appear in Shared services** — it's a BTP service, not something deployed in your own VPC, and the modern replacement for Solution Manager where an organisation has moved to it. That's a Part 4 topic.

**MSP connectivity has more than one valid pattern.** This build routed MSP access through the corporate DC path — the default choice, since it gives the customer visibility and control over that traffic. A direct VPN from the MSP into the TGW, or an overlay network solution like NetFoundry, are equally plausible; which one's right depends on how much the customer needs to see and gate that traffic versus how directly the MSP needs to reach the estate.

**Centralising PrivateLink endpoints is a real trade-off, not a free win.** Interface endpoints (everything except the S3 gateway endpoint, which works differently) were centralised in the Shared services VPC rather than deployed per-VPC, to avoid paying for the same endpoint six times over. That saved on endpoint costs but added complexity and pushed more traffic — and cost — through the Transit Gateway itself. AWS's own guidance on this trade-off \[1\] is worth reading before defaulting to centralisation.

**Inter-region connectivity was a choice worth learning from, not repeating uncritically.** Rather than peer the regional TGWs directly over the AWS backbone, this build routed inter-region traffic through the existing on-premises global network. It caused real problems: on-premises firewalls blocked some traffic types outright, and the VPN links introduced packet fragmentation that degraded performance and dropped connections. TGW peering over the AWS backbone — bypassing on-premises infrastructure for inter-region traffic entirely — is the pattern I'd default to now.

## DR and resilience

DR design follows requirements, not a template — availability target, RTO, and RPO determine the mechanism, not the reverse. This build's targets were 99.9% availability, a 2-hour RTO, and a 15-minute RPO, which is why the choices below look the way they do.

Two tiers, scoped deliberately: **in-region DR across all four regions**, **cross-region DR for the HQ region only**.

**In-region was cross-AZ.** HSR in *asynchronous* mode covered every HANA database — asynchronous because a 15-minute RPO allows for it; a zero-RPO requirement would call for synchronous replication instead. Everything else used backup/restore.

**Cross-region, at HQ, used that same backup/restore process for every layer** — not a different mechanism, the identical one, applied more broadly. Servers restore from AMIs and EBS snapshots; databases restore the last full backup, then roll transaction logs forward to the latest available point.

Hitting the 2-hour RTO across roughly 60 servers needed more than manual backups — N2WS Cloud Protection Manager automated and compressed recovery time to fit the window. Failover itself stayed manual, not because automation wasn't possible, but because a 2-hour window comfortably accommodates a manual trigger plus CPM-orchestrated execution — automating the failover decision would have solved a problem this requirement didn't have.

**Where different requirements would change the design:** 99.99%+ availability and a tighter RTO would call for Windows and Linux Pacemaker clustering with automatic failover instead. There, SAP DB and Central Services instances (with enqueue replication) sit in clusters; application servers, being stateless, just distribute across both AZs rather than clustering. Automated HANA failover via Pacemaker is a pattern I've built in a separate SAP-on-AWS migration; SQL Server's HSR equivalent — Always On Availability Groups plus Windows Failover Clustering — is one I've implemented in another.

ICE storage (Figure 1) is where this whole posture lives — the AMIs and EBS snapshots above are stored there, isolated from the production account they protect.

## Identity and access

Federation and least-privilege roles are the default: day-to-day access runs through federated identity into workload accounts, with roles scoped tightly enough that broad standing access is the exception. Break-glass IAM is the deliberate exception to that default. For the Windows fleet, Active Directory sits as a separate layer — replicated from the on-premises domain controller, or stood up fresh via AWS Directory Service where no on-premises AD relationship needs preserving. SAP's own user, role, and SSO model layers on top of both.

## Security baseline

Centralised logging isn't a manual setup — Control Tower configures it by default, every account's CloudTrail and Config logs landing in the Log Archive account from the moment the account is vended. Centralised monitoring lives in the Audit account, via Security Hub's delegated administration.

Encryption gets its own dedicated account per region, separating key management from the workloads it protects — the same logic as ICE storage, one layer earlier. Encryption in transit runs off a defined PKI strategy: an internal CA for east-west traffic that never leaves the estate, a trusted external CA wherever a certificate faces a browser or third party.

The rest of the baseline is on by default, not opted into per-workload:

| **Service** | **Role** | **Managed from** |
| --- | --- | --- |
| Security Hub | Central findings aggregation | Delegated administrator: Audit account |
| GuardDuty | Threat detection | Delegated administrator: Audit account |
| IAM Access Analyzer | Unused/external access findings | Per account, reviewed centrally |
| Inspector | Vulnerability scanning | Per account, reviewed centrally |

## Governance and policy-as-code

Control Tower enforces three tiers of control: **mandatory** (can't be disabled), **recommended** (default, adjustable), **elective** (available where a workload's risk profile calls for it) — AWS's control reference \[2\]. The global service catalog account backs this with the practical mechanism: teams provision through pre-approved patterns rather than configuring by hand each time.

A naming convention and tagging strategy, decided once and centrally, is what makes the rest of this work. Where tagging needs enforcing rather than encouraging, AWS Organizations tag policies are the direct mechanism — alongside or instead of SCPs \[3\].

## Cost management

The Master Payer structure gives consolidated billing with genuine per-account, per-OU visibility — more useful for SAP than tagging alone, given how large a share of the bill SAP systems typically represent. The governance section's tagging strategy is what makes that visibility usable rather than theoretical.

| **Tool** | **Role** |
| --- | --- |
| Cost Explorer | Per-account, per-tag spend analysis |
| Trusted Advisor | Flags idle/oversized resources, unattached volumes |
| Savings Plans | Committed-use discounting for the predictable baseline — Production and Non-prod qualify; Sandbox generally doesn't |

## From design to implementation

Every element above needs to become something an IaC pipeline can target — a design that only exists as a diagram isn't a landing zone yet.

| **Attribute** | **AWS construct** | **Typical IaC target** |
| --- | --- | --- |
| Account structure | Organizations, OUs, accounts | Control Tower account factory / Terraform account vending |
| Network topology | Regional TGWs, VPCs, subnets, inter-region path, centralised or per-VPC endpoints | Terraform network modules per VPC type, plus peering — evaluate TGW peering vs. existing WAN, and centralised vs. per-VPC endpoints, before defaulting |
| DR and resilience | HSR (sync or async per RPO); cross-AZ/cross-region backup-restore via CPM; Pacemaker/SQL AlwaysOn if tighter RTO/availability required | Backup/DR Terraform module, CPM recovery scenario config, tested restore runbook |
| Identity | IAM federation, least-privilege roles, break-glass roles, Active Directory | IAM/SSO Terraform module; AWS Directory Service or AD replication scripts |
| Security baseline | Log Archive (Control Tower default), Security Hub/GuardDuty delegation, KMS, ACM/PKI, IAM Access Analyzer, Inspector | Security Hub/GuardDuty delegated-admin module; KMS + ACM modules |
| Governance | Mandatory/recommended/elective controls, Service Catalog products, tag policies | Policy-as-code repo, versioned Service Catalog products, enforced tag policy |
| Cost management | Payer account, cost allocation tags, Cost Explorer, Trusted Advisor, Savings Plans | Tagging policy via SCP/tag policy; budgets module; Savings Plans reviewed per account tier |

## Where this goes next

Same seven attributes, same discipline, different platform. Part 3 asks these same questions of Azure.

## References

1.  AWS Whitepapers — [Building a Scalable, Secure Multi-VPC Network Infrastructure: Centralized Access to VPC Private Endpoints](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html)
    
2.  AWS Control Tower — [Control Behavior Reference](https://docs.aws.amazon.com/controltower/latest/controlreference/control-behavior.html)
    
3.  AWS Cloud Operations Blog — [Implement AWS Resource Tagging Strategy Using AWS Tag Policies and Service Control Policies (SCPs)](https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/)