Designing a SAP-on-AWS landing zone: a working checklist

An AWS landing zone for SAP is not a generic Control Tower template with HANA-shaped boxes dropped in. Several SAP-specific concerns drive the foundational choices: account boundaries, network topology, storage class, IAM strategy and FinOps controls. This is a working checklist in the order the decisions usually get made, with the rationale behind each.

Before opening the AWS console

Three decisions shape the rest of the design and are best taken before anyone provisions an account.

• Operating model. Will you run SAP yourself, with a partner, or via RISE? The landing zone for a fully self-hosted estate differs from one where some SAP runs on RISE alongside.
• HA and DR posture. Recovery objectives by system class. Productive HANA with a four-hour recovery target needs a different topology from the same HANA with a 24-hour target.
• Regulatory posture. Data residency, audit retention, customer-managed key requirements. Encryption and residency are cheaper built in from day one than retrofitted.

Multi-account structure

A single-account "all SAP" topology is easier in week one and harder by month six. The standard pattern uses AWS Organizations with Control Tower as the foundation and per-environment accounts for SAP workloads. Account creation should go through Control Tower Account Factory and a Service Catalog rather than by hand, because the guardrails are easy to miss when accounts are created manually.

Network topology

Per SAP account, one VPC per region, with a tiered subnet layout so the database never sits where it can reach the internet:

Use three Availability Zones in regions that have them, but verify first, because some HANA-certified EC2 families are not in every AZ in every region. Connectivity follows a standard pattern: Direct Connect for production with VPN as backup, a Transit Gateway for inter-VPC and inter-region routing, and Route 53 Private Hosted Zones for SAP hostnames, federated to corporate DNS via Resolver endpoints.

Compute and EC2 family selection

SAP publishes a certified-family list for HANA that changes periodically, so check the current list against your sizing rather than hard-coding a family name. As a starting map:

Productive HANA also benefits from On-Demand Capacity Reservations in the AZs your HA pattern depends on, so a region-wide capacity squeeze doesn't leave you unable to restart a failed-over instance.

Storage choices

Storage choices stay with you for a long time. Two paths are common, and the right one depends mostly on your development-refresh cadence:

FSx costs more per line item, but the savings on development-refresh time can pay for it. For shared filesystems such as /sapmnt and /usr/sap/trans, FSx for OpenZFS or EFS are the usual choices depending on the POSIX semantics your transports need. For Backint backup destinations, S3 with lifecycle rules into Glacier and Deep Archive is the standard pattern, but store those backups in a different account from HANA itself (see the mistakes below).

High availability and disaster recovery

Within a region, the usual pattern is HANA System Replication between two AZs, managed by a Pacemaker cluster on SUSE or Red Hat. Validate the specific resource agents against your OS and HANA versions because they evolve, and use overlay IPs through Route 53 Resolver for virtual hostnames so failover doesn't change how the application sees the cluster. Across regions, the choice is HSR async to a DR region versus Backint restore from S3, decided by your recovery objectives. Either way, run the DR drill on a schedule: an untested DR posture is a hope, not a control.

IAM and KMS

IAM Identity Center is the right starting point for human access, federated to your existing IdP, with Permission Sets per role (SAP-prod-readonly, SAP-prod-operator, SAP-prod-admin, and the QAS/dev equivalents). For agents and SAP hosts, use EC2 instance profiles with tightly-scoped roles rather than long-lived IAM users: HANA Backint to S3, HANA to KMS, host to Secrets Manager, all through instance profiles. Keep KMS keys per environment to bound blast radius; make production HANA backup encryption a multi-region key so cross-region DR needs no re-encryption, and audit Decrypt events into the central log archive.

FinOps controls

Cost drift is silent. The controls are not exciting but they matter.

• Cost allocation tags on at least Environment, SID, Owner, CostCenter, enforced with an SCP that blocks resource creation without them.
• Compute Savings Plans for steady-state usage; Reserved Instances for HANA-class instances where Savings Plans don't apply.
• Instance Scheduler for non-production auto-shutdown; S3 Storage Lens + lifecycle so backups older than a year sit on Deep Archive.
• Cost Anomaly Detection wired to your alerting channel, and a quarterly review of what's idle, over-provisioned, or orphaned.

Monitoring and audit overlay

The landing zone gives you AWS-side visibility through CloudWatch, CloudTrail and GuardDuty. It does not give you SAP-side visibility: SM50, SM37, ST22, HANA traces, RFC checks, sapcontrol audit. That needs an overlay. Farrenio runs an outbound-only collector agent per SAP host; the agent polls the platform for its configuration and pushes telemetry over the same channel. The security page covers credential handling and the audit model; the platform consolidates SAP-side telemetry across systems and customers and writes an attributed audit record for every privileged action.

A 90-day review

1. Did the DR drill complete within the recovery target? If not, where's the blocker?
2. Are cost allocation tags consistent across resources?
3. Any long-lived IAM users still in use that shouldn't be?
4. Has the production HANA capacity reservation been exercised in an unplanned failover, and did it work?
5. What do the GuardDuty and Security Hub finding counts look like? Burn down high-severity items; document accepted risks.
6. Is the audit archive receiving CloudTrail, Flow Logs and Config history without gaps? Sample-verify.

Common mistakes

• Skipping the log-archive/audit account at the start. It rarely gets added later.
• Single-AZ HA on QAS. QAS becomes production-during-cutover at the worst possible time.
• Using the default VPC for SAP. The CIDR will overlap with something, so use custom VPCs from day one.
• Storing HANA backups in the same account as HANA. Account-level credential compromise loses both.
• EFS for /hana/data. Not certified.

If you'd like a design review on your draft landing zone, or help bridging from RISE or on-premises to self-hosted on AWS, write to contact@farrenio.com. As an AWS reseller for SAP, that is the work we do.