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 affect 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 is different from the landing zone for a hybrid where some SAP runs on RISE.
• HA and DR posture. The 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 recovery target.
• Regulatory posture. Data residency, audit retention, customer-managed key requirements. It is cheaper to build encryption and residency in from day one than to retrofit later.

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.

A typical account structure includes a management account at the root, separate accounts for production, QAS and development SAP workloads, a shared services account for things like SAP Router and Transit Gateway, a networking account for the central VPC and DNS, a logging account for CloudTrail and VPC Flow Log aggregation, and a security tooling account for GuardDuty, Inspector and Security Hub aggregation. A DR account is sometimes worth separating depending on the recovery model.

Account creation should go through Control Tower Account Factory and a Service Catalog rather than being done by hand. The guardrails are easy to miss when accounts are created manually.

Network topology

Per SAP account, one VPC per region. Inside each VPC:

• Small public subnets for load balancers in front of SAP web dispatchers. No SAP application server should run here.
• Private application subnets for SAP application servers and sapcontrol-managed services.
• Private data subnets for HANA database hosts. No outbound NAT unless there is a specific justification.
• Endpoint subnets for VPC endpoints so SAP does not need NAT egress for AWS service traffic.

Use three Availability Zones in regions that have them. Some HANA-certified EC2 families are not in every AZ in every region; verify before committing.

Connectivity follows a fairly standard pattern: Direct Connect for production workloads with VPN as a backup path, a Transit Gateway for inter-VPC and inter-region routing, and Route 53 Private Hosted Zones for SAP hostnames, federated to your corporate DNS via Route 53 Resolver endpoints.

Compute and EC2 family selection

SAP publishes a list of certified EC2 families for HANA. The list changes periodically, so the right approach is to check the current list against your sizing rather than to hard-code a family name. In general:

• For HANA up to a few terabytes, the latest general-purpose memory-optimised families are usually a good fit.
• For larger HANA workloads, the bare-metal "u-" family or the larger memory-optimised families come into play.
• For SAP application servers, the general-purpose memory-balanced families are the usual choice. Graviton-based families have growing SAP support; verify the specific kernel patch level your landscape runs.
• Stop non-production instances overnight using AWS Instance Scheduler. The savings are substantial.

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

Storage choices

Storage choices stay with you for a long time. Two paths are common.

EBS-only. Provision gp3 volumes for HANA data with explicit IOPS and throughput, and io2 Block Express for the log volume. Simpler operationally, with no shared-filesystem dependency. Good fit for single-host HANA up to medium sizes.

FSx for NetApp ONTAP. SAP-certified for HANA, supports HANA System Replication, and allows fast cloning of HANA filesystems for development refreshes. Good fit for larger HANA, multi-host scale-out, frequent dev refreshes from production, or customers who want to mirror an on-premises NetApp story.

The line-item cost of FSx is higher, but the savings on development refresh time can pay for it. The right answer depends on your refresh cadence.

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. Multi-AZ S3 by default, and cross-region replication where the DR pattern needs it.

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. Use overlay IPs through Route 53 Resolver for virtual hostnames so failover does not change how the SAP application sees the cluster.

Across regions, the choice is between HSR async to a DR region and Backint restore from S3. The decision depends on 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 identity provider. Permission Sets per role keep the model maintainable: SAP-prod-readonly, SAP-prod-operator, SAP-prod-admin, and the equivalents for QAS and dev.

For agents and SAP hosts, use EC2 instance profiles rather than long-lived IAM users. HANA Backint to S3, HANA to KMS, SAP host to Secrets Manager: all through instance profiles with tightly-scoped roles.

KMS keys are best kept per environment to limit blast radius. Production HANA backup encryption is a good candidate for a multi-region key so cross-region DR does not require re-encryption. Audit KMS Decrypt events into the central log archive; anomalous patterns are worth paging on.

FinOps controls

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

• Cost allocation tags at a minimum on Environment, SID, Owner and CostCenter. Enforce with an SCP that blocks resource creation without them.
• Compute Savings Plans for the steady-state portion of usage. Reserved Instances for HANA-class instances where Savings Plans do not apply.
• Instance Scheduler for non-production auto-shutdown.
• S3 Storage Lens and lifecycle policies so backups older than a year sit on Deep Archive.
• Cost Anomaly Detection wired to your alerting channel.
• A quarterly FinOps review of what is idle, what is over-provisioned and what lost its workload but did not get cleaned up.

Monitoring and audit overlay

The landing zone provides AWS-side visibility through CloudWatch, CloudTrail and GuardDuty. It does not provide SAP-side visibility: SM50, SM37, ST22, HANA traces, RFC checks, sapcontrol audit. An overlay covers that.

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 attributed audit records for every privileged action.

A 90-day review

What to check three months in:

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

Common mistakes

• Skipping the 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. Custom VPCs from day one.
• Storing HANA backups in the same account as HANA itself. Account-level credential compromise loses both.
• EFS for /hana/data. Not certified.

If you would 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.