../ Interconnecting SAP, On-Premises and AWS

This post is handwritten, no LLM's were used to write and mock this up.
 Lately, I have been working on projects that involve connecting on-premises data centers with SAP RISE/ECS.
Although there are multiple approaches to achieving this, if your business case allows it, introducing a third player into the equation (Using an AWS account as a router mimicking a hub-and-spoke model [1]) can provide the following benefits:

However, it can also introduce challenges, such as: Keep in mind that this topology has been discussed by AWS previously [2]. Having said this, let me deepen into the stated points above.

[+] Govern the network communication, making it easier to solve network problems.

Having control of the network gives you more flexibility when diagnosing errors. Once the communication between your on-premises infrastructure and AWS is established and proven functional, you can focus on troubleshooting the other parts. By narrowing down the issue in this way, you simplify the resolution process.


[+] Seamlessly introduce new cloud services (e.g., RDS, Lambda, etc.) empowering your business outcomes.

Introducing new cloud services into your on-premises workspace becomes easier when you already have part of your business operating in the cloud. This setup allows you to reduce costs associated with legacy servers and take advantage of a pay-as-you-go model, which may be more cost-effective for your organization.

From my personal experience, I have observed clients implement Amazon S3 and significantly reduce costs for data that required a considerable retention period. While the specifics can vary from business to business, all organizations can benefit from moving some of their workloads into the cloud, ultimately leading to improved outcomes.


[+] Easily route or introduce other third-party services without disruption.

Similiar to the point above, if you have more than one data center (e.g. country-based data centers), this topology model makes it easier to include any new components. Enabling you a much more faster time-to-market.


[-] Adding a new component to the network architecture requires skilled personnel to maintain, update, and manage it effectively.

That is the main purpose of this tech post, building this topology effectively and updating it as changes come, requires you to have skilled personnel. This can be your starting point or can help you decide if you want to go with this approach.

Feel free to email me: [g5o] at [lockedinspace] dot [com]
if you have more technical questions. Will answer as soon as possible.


Having said this, let's begin the technical approach to make this work

Putting things in place

Having a diagram helps understanding where each piece goes, for this topology we will have three actors. Agents in the topology
Each square in the diagram represents one component in the topology.
  • For on-premises, the range depicted (192.168.1.0/24) refers to the data center CIDR block.
  • AWS services are contained in a Virtual Private Cloud (VPC [3]), and the range 10.1.0.0/16 refers to our account VPC.
  • For SAP's side, we will provide the range through a formulary, the provided range must not collide with our VPC's range.

    • SAP has various methods of establishing the connection, for this tech post, we will stick with the Transit Gateway [4] method.
    Using AWS VPN Site-to-Site [5] will enable us to establish a connection between our data-center and AWS.

    The resulting diagram would be: AWS Services in the topology Let's separate the diagram in two parts, so we can explain in more details each section.
    On-Premises to AWS (and vice-versa)
    This part involves in allowing your On-Premises data center to communicate with your AWS account. In the example depicted above, this is done through a VPN Site-to-Site [6] tunnel. Before establishing the connection, keep in mind the following prerequisites: Once the prerequisites are met, you will need to create a Transit Gateway (TGW) [7] in your AWS Account and attach it to your VPC.
    Next, define a Customer Gateway (CGW) [8] in AWS representing your on-premises endpoint.
    VPN Connection: Once the TGW and CGW are configured, establish a VPN connection between them. You can choose static or dynamic (BGP) routing.

    A high level overview of how a connection between your On-Premises and AWS looks like:
    AWS Services in the topology
    Keep in mind that in this example we are creating a VPN tunnel, which essentially travels the public internet through an encrypted connection. If your busienss case does not allow this you can use a Direct Connection.
    Also note that we are using a TGW (Transit Gateway) instead of a VGW (Virtual Private Gateway) on the AWS side, going for this approach makes the infrastructure much scalable, enabling you to easely connect multiple accounts VPCs into the equation.

    Once everthing is set up, you can test the reachability with a simple test. Issue an ICMP request from one of your On-Premises servers and ping an EC2 instance in AWS.
    If the Security Group in AWS allows inbound connections from the 192.168.1.0/24 CIDR range (same for On-Premises firewall), servers from both ends will see each other.

    AWS to SAP RISE / ECS (and vice-versa)
    As for 2024, you will need to share with SAP some details through an excel file. SAP will demand the following AWS information:
    They will also demand some information for your VPN setup:
    Some important notes:
    Next steps once provided details are valid
    You will need to share your TGW using Resource Access Manager (RAM) [9] to the provided SAP HEC AWS account.

    Once SAP accepts your share request, they will modify the TGW route table to propagate their infra CIDR (10.15.0.0/22 ) with yours (On-Premises and AWS, 192.168.1.0/24 and 10.1.0.0/16 CIDR's).
    After they verify everything, you will allow SAP's CIDR range (10.15.0.0/22) into your firewalls (SG, and Sophos router).

    With that, you should be able to query SAP nameservers from both your On-Premises and AWS servers.

    Conclusion

    Analyze if your business can take advantage of the cloud, if that's the case, you can kill two birds with one stone. Gaining the governance of the network communications and take foot into the cloud and progessively migrate your workloads there.

    This will enable your organization to leverage on plenty AWS services such as Lambda for your day-to-day operations and boost your On-Premises workforce.

    As always, if you feel stuck or need some guidance on how to tackle this scenario (or similar), feel free to e-mail me with your concerns.

    References

    date: 2024-10-05
author: "[g5o] at [lockedinspace] dot [com] "