Expanding SAP Systems with AWS - Part II

Previously, we discussed the different architectures needed to extract data from your SAP system. Along with the benefits these types of architectures provide your business. This blog post will discuss how we securely and cost-effectively established a connection with an on-premise system.

Establishing Communication

There are several methods of establishing communication between AWS and on-premises systems. Direct Connect can be used to link your internal network to AWS over a standard Ethernet Fibre-optic cable. Traffic is transported from your data centre directly to AWS, bypassing the public internet. Though, while this service has its use cases it can be costly and time-consuming to configure. We decided to stick with AWS Site-to-Site VPN for this PoC. Site-to-Site VPN enables access to remote networks by creating a site-to-site connection. Routing can then be configured to pass traffic through the connection. Each site-to-site connection includes two IPsec VPN Tunnels which can be simultaneously used for high availability.

To establish our site-to-site connection the first step was to correctly configure our AWS account. This entailed creating a new Virtual Private Cloud (VPC). It is important to note that when creating this VPC both “DNS hostnames” and “DNS resolution” should be enabled. The subnets in this VPC must be created in at least 50% of the availability zones in your selected region. This setup will be useful later when we must provision Network Load Balancers in these subnets, to cover 50% of the availability zones. Provisioning, your subnets and network load balancers in this configuration offers, high availability, lower latencies, and better fault tolerance.

Now that our VPC is configured correctly we can deal with configuring the AWS Site-to-Site VPN connection. Details on configuring this service can be found via the AWS VPN Site-to-Site Documentation. The entire process of setting up the Site-to-Site VPN can be broken down into seven steps:

1. Create a customer gateway.

2. Create a target gateway.

3. Configure routing.

4. Update your security group.

5. Create a Site-to-Site connection.

6. Download the configuration file.

7. Configure the customer gateway device.

Upon, completion of the AWS documentation the VPN tunnels should now show as “Up”. If the tunnels continue to remain in a “Down” state do not proceed until this has been corrected.

Note that AWS provide two tunnels for a reason. Due to this being a PoC, I thought one tunnel would be sufficient. After a couple of days, the tunnel returned to a ‘Down’ state. AWS described this issue as a momentary lapse in redundancy. This lapse in redundancy can be brought on by software upgrades, customer-initiated modifications and when underlying hardware is retired. While it was not exactly clear what caused the tunnel to return to a ‘Down’ state – the solution was clear. The first modification was to connect both tunnels simultaneously. Then the tunnels setting were reviewed. Dead Peer Detection (DPD) timeouts were increased, and start-up actions were modified. Enabling IKEV negotiations from within the AWS VPC. This ensured that the architecture remained highly available even if a momentary lapse in redundancy was encountered.

We hope you have enjoyed the second blog in this series and follow along as we continue the process of helping you add value to your data housed in SAP.

If you or your colleagues have further questions or queries, please do not hesitate to contact us at william.hadnett@seaparkconsultancy.com