Hello, and welcome to this lecture, where I will be discussing various network and VPC architectures for SAP on AWS. By the end of this lecture, you’ll be able to describe the networking components and design patterns for different VPC architectures supporting SAP deployments on AWS. You’ll also be able to identify different strategies for facilitating access to AWS Cloud-hosted SAP environments from your on-premises networks. So let’s get started by discussing the various networking components you can use when architecting an SAP deployment on AWS.

To create an SAP deployment on AWS, one of the first things you’ll need to do is configure your VPC. So again, VPC stands for Virtual Private Cloud, which is your own isolated virtual network within the AWS Cloud. And a little later, you’ll see how to connect your on-premises network to your VPC and even how to connect your VPC to other VPCs in the AWS Cloud to facilitate different SAP configurations.

So to start, you’ll need to create your VPC in a particular AWS region and assign a range of IP addresses to it. And when you assign this IP range, you’ll want to ensure that the range you use for your VPC is different from the range you’re using in your on-premises network. Now there are a couple of things that can impact your choice of AWS region for your VPC. You’ll want to choose a region that is geographically close to your user base in order to reduce latency. But you may also need to consider things like laws and regulations pertaining to data residency and compliance, so keep that in mind as well.

So once you’ve created your VPC, inside that VPC is where you will provision all of the infrastructure you need to support your SAP resources, so everything from public and private subnets to EC2 and database instances. Now you’re going to want to place your public-facing servers in public subnets. So for SAP, this would include things like your SAProuter, Web Dispatcher, and other public-facing SAP applications. And remember that anything in your public subnets can then access the internet via an Internet Gateway in your VPC. You’ll probably also want to stand up a Bastion Host within your public subnet to act as a “jump box” that allows you to securely access your backend servers, which you’ll place in a private subnet. So keep in mind your private subnets are for any servers that do not need public access via the internet, so things like your SAP instances and SAP databases should always reside in a private subnet.

However, you can still allow the instances in your private subnets to have outbound access to the internet by placing a NAT Gateway inside of a public subnet and then configuring a route from your private subnet to the NAT Gateway. And this is useful when you need to allow the instances in your private subnet to connect to the internet to do things like download patches and updates, while still preventing any inbound connections from being initiated to these instances via the internet. And of course, you should still configure security groups and network ACLs (or NACLs) to further restrict and control inbound and outbound traffic by port and protocol at both the instance level with security groups and at the subnet level with NACLs.

So now that you’ve seen how to set up a VPC within AWS, let’s talk about how to connect to that VPC from your on-premises environment. So you have a couple of options here. You can leverage your existing internet connection and create an AWS Site-to-Site VPN, or Virtual Private Network. And VPNs are useful for a couple of reasons: one, since they leverage your existing internet connection, they can be set up fairly quickly. And two, they enable you to create an encrypted connection so even though the traffic between your on-premises network and AWS is passing over the public internet, it’s still secure.

So to set up a Site-to-Site VPN, you first need to provision what’s called a Virtual Private Gateway in the VPC from which you want to create your VPN connection. You’ll also need a Customer Gateway, which can be either a physical device or a software appliance that resides in your on-premises network. And this device is what’s responsible for bringing up the tunnels for your VPN connection.

Now your other option is to use AWS Direct Connect, which is a dedicated connection between your network and AWS. And Direct Connect does not pass over the public internet at all, so it’s much more reliable than a VPN. It can also offer much faster speeds, all the way up to 100 Gbps. And while there’s definitely more up-front work involved when it comes to setting up a Direct Connect connection, it’s a much better option for organizations that are looking for higher bandwidth connectivity to AWS with lower latency than a VPN.

So what we’ve seen so far is a fairly basic single VPC setup for our SAP deployment with either a Direct Connect or Site-to-Site VPN connection between your on-premises network and AWS. But there are many options when it comes to designing a VPC architecture to support different types of SAP deployments. And any of these options might work for your organization depending on its unique requirements.

So let’s start by taking a closer look at the architecture we’ve been building so far: once you’ve established a connection between your on-premises network and AWS, you might have your public-facing servers and bastion host live in a public subnet, while your backend instances are in private subnets. This is a fairly traditional solution architecture that gives you the ability to publicly expose only those resources that you need to, while also giving you the flexibility to be able to connect to internal and external resources using public and private connections.

Now if you only need to access your SAP deployment from your internal network and nothing needs to be public-facing or connect to any external systems, you can simplify this architecture by removing the public subnets, NAT Gateway, and Internet Gateway, and deploying all of your resources into one or more private subnets. And this is a very secure architecture, as now nothing at all is accessible via the public internet. Now you could choose to configure multiple private subnets if you wanted to separate your development, testing, and production SAP environments. Or you could create separate private subnets for your SAP systems, your databases, and your other business applications.

So the different architectures we’ve seen so far have involved just a single VPC. But you may want to leverage multiple VPCs. And one reason for this might be to further separate your production and non-production systems. So in the last example, we talked about creating separate private subnets within the same VPC for your development, testing, and production systems. But you could actually separate these private subnets out across multiple VPCs. And suppose you still needed to communicate between these VPCs.

In that case, you could use VPC Peering, which is a networking connection between two VPCs that enables you to route traffic privately between them, even if those VPCs are in two different regions, or as we’ll see in a moment, two different AWS accounts.

So you can take the previous architecture a step further by separating your VPCs across multiple AWS accounts. And many organizations do this in order to streamline billing and have finer-grained control when granting access to different environments. So you may have an AWS account in your organization exclusively for SAP, or even separate accounts for SAP development, SAP testing, and SAP production. And just like I mentioned in the previous single AWS account example with multiple VPCs, you can still set up VPC peering connections between VPCs in different AWS accounts, even across different regions.

Now I just talked about VPC peering as a way to connect two VPCs and allow them to communicate with each other. But VPC peering is not transitive, so every time you want to add a new VPC that communicates with all of your other VPCs, you’ll need to set up new VPC peering connections between each pair of VPCs. And as you can imagine, this approach drastically increases the complexity of your network topology. So a more scalable alternative is to use an AWS Transit Gateway instead.

An AWS Transit Gateway acts as a central hub that allows for communication between all of your VPCs and on-premises networks. So when you add a new VPC into an architecture that uses an AWS Transit Gateway, you only need to connect that VPC to the transit gateway and then update your subnet’s route table for it to be able to communicate with your other VPCs.

And if your VPCs span across multiple regions, you can create transit gateway peering connections between regions as well. So hopefully this has given you a greater understanding of the different networking and VPC connectivity options you have when deploying SAP on AWS.