An AWS landing zone for RISE with SAP
RISE arrives as a finished environment you have to connect to. That single task decides whether the system is reachable from your network on day one, or whether you spend the first month raising tickets. Here is the architecture, taken apart.
A RISE with SAP contract covers the environment the system runs in. It does not cover the network that system uses to talk to the rest of your world, the data centre, the surrounding systems, the warehouse, the reporting tools. That network sits on your side of the line, and you have to build it.
AWS calls it a landing zone and recommends it explicitly as the way to connect to RISE. Below we take the architecture apart and show what actually has to happen before go-live.
Why this is not just one link
The simplest picture, the one that circulates in sales decks, looks like this: there is RISE, there is your data centre, and a link between them. If SAP were the only system in the company, that picture would be enough.
In practice an SAP landscape talks to a dozen things at once: systems in the data centre, SaaS products, other clouds, a data warehouse, reporting tools. Build each of those connections separately and after a year you have a tangle nobody can draw. And at audit time somebody has to.
A landing zone reverses the order: the network skeleton and the rules come first, then things get plugged into it. RISE is one of those things, not an exception.
The thing easiest to miss on that diagram: the RISE account does not belong to your AWS organization. SAP Enterprise Cloud Services runs it. You will not log into it, you will not see its bill, you will not change a security group in it. You see it only from the network side, as something attached to your Transit Gateway.
That has a practical consequence: anything you want to control has to sit on your side. The firewall, the traffic logs, the separation of environments, the egress points to the internet.
The accounts, and what each is for
A landing zone is first of all a split into accounts. Not for tidiness, but because an AWS account is the hardest boundary the platform offers, harder than any permission rule.
| Account | What it is for |
|---|---|
| Management | Organizations, organizational units, service control policies |
| Network | Transit Gateway, Direct Connect, VPN, network firewall |
| Log archive | CloudTrail and Config from every account, write-only |
| Security | GuardDuty, Security Hub, review tooling |
| Shared services | DNS, directory, things everyone uses |
| Workload | Separate ones for production, development, analytics, GenAI |
The log archive account deserves its own sentence. Its purpose is that nobody working in the other accounts can delete their own traces. If the logs live in the same account as the system, a serious incident can take both.
Transit Gateway instead of a tangle
Without a hub every connection is its own pair: production to the data centre, test to the data centre, production to RISE, warehouse to RISE. At five endpoints that is already ten pairs, each with its own route table.
Transit Gateway turns that into a star. Every account attaches once, to the hub, and route tables decide who may talk to whom, one place instead of ten.
For RISE this matters more than usual, because SAP attaches to exactly that hub. Add another account later and RISE will see it with no change on the SAP side.
Two roads: Control Tower or Landing Zone Accelerator
AWS offers two ways to build the same thing.
AWS Control Tower is the console route. You click, you get the account structure, a set of controls and baseline guardrails. It works when you want to move quickly and have no exotic networking requirements.
Landing Zone Accelerator is the same thing expressed in configuration files. It extends Control Tower with infrastructure as code, so the whole environment can be rebuilt, reviewed in a repository and moved to a second region.
Choosing between them comes down to one question: do you have a team that will maintain the configuration files. If yes, LZA pays for itself at the first significant change. If not, Control Tower is enough, and it is better than building something nobody will touch afterwards.
We work in infrastructure as code ourselves, so we recommend LZA, but not when it would mean that the only person who understands the configuration leaves in six months.
What has to be done, in order
The full list in the AWS documentation runs to fourteen steps. In practice they fall into four groups:
- Requirements. Security, compliance, the way you work. At this stage you review the connectivity questionnaire from the SAP ECS team, it states what SAP needs from you.
- Design. Number of accounts, network layout, addressing, controls. Spend longer on addressing than you want to: a range collision with the data centre or with RISE is very expensive to fix later.
- Build. Control Tower, shared accounts, network, Transit Gateway, firewall, permissions, logging and monitoring.
- Attach RISE. You hand SAP your Transit Gateway details, accept the attachment request, configure routing and test, including failover to the backup link.
That last step is the only one that depends on the other party. Everything before it you can do on your own schedule.
When to start
AWS says it plainly: six to eight weeks before the planned go-live.
That number is not caution. Direct Connect has a lead time measured in weeks and depends on a carrier, not on you. The connectivity questionnaire comes back with questions. Addressing needs agreement from people who are usually busy with something else. Failover testing happens once, and that is exactly when you discover the return path does not come back the way it should.
If the go-live date is fixed and the landing zone does not exist yet, this is the first thing to do, ahead of everything else.
What this architecture does not solve
A landing zone solves connectivity and governance. It solves nothing above the network layer.
Still on your side of the line: authorizations and segregation of duties in SAP, integration with surrounding systems, change procedures, backups of whatever the contract does not cover, and the day-to-day operation of all of it. That is a separate scope and a separate conversation, but it is worth knowing that the network is the start of the list, not the end.
One note if you are looking at AWS Managed Services
The AMS multi-account landing zone documentation is a good source of architectural patterns and worth reading. It carries a notice that is easy to miss, though: AWS ends support for AMS Advanced on 30 June 2027.
The patterns remain valid. But if someone proposes basing your operating model on that service, this is a question to ask before signing.
Sources
- Connecting to RISE using a shared AWS Landing Zone. SAP on AWS documentation
- MALZ network architecture, network architecture of the AMS multi-account landing zone
- Guidance for Building an Enterprise-Ready Network Foundation for RISE with SAP on AWS, validated architecture patterns
- Landing Zone Accelerator on AWS, the solution and its configuration files
The diagram above is our own drawing, based on the architecture described in the documents listed here.