VPC Subnet Zoning Patterns for SAP on AWS, Part 2: Network Zoning

This post is by Harpreet Singh and Derek Ewell, Solutions Architects at Amazon Web Services (AWS).

In part one of this article series on VPC subnet zoning patterns, we described possible ways in which SAP applications may be accessed, and then discussed Amazon Virtual Private Cloud (Amazon VPC) subnet zoning patterns for internal-only access in detail. In this second article in the series, we’ll discuss how traditional application network zoning can be mapped to AWS.

In a traditional on-premises deployment model, applications are segregated into various network zones:

• Restricted zone: This is the most secure zone, and it hosts confidential data. For example, databases for finance and HR solutions, content repositories, and file servers may reside here.
• Intranet zone: This zone is meant for application servers that access databases in the restricted zone. For example, SAP Advanced Business Application Programming (ABAP) or Java Central Services, or SAP application servers may reside here. End users’ devices, when connected to the corporate network, are also in this zone.
• Extranet zone: Middleware like SAP Process Orchestration (PO) or SAP Process Integration (PI), SSH File Transfer Protocol (SFTP) servers, or SAP TREX reside in this zone.  This zone acts as the intermediate zone between the external and internal zones.
• External zone: This zone hosts applications and appliances that are directly Internet facing, and acts as the entry or exit point for your applications in the internal zone. Network access translation (NAT) instances, reverse proxies, and SAProuter are examples of some of the solutions that belong in this zone.
• Management / shared services zone: Applications like Active Directory, monitoring servers, SAP Solution Manager, or DNS servers, which are required by all the zones described above, are hosted in this zone.
• Internet zone: You do not control this zone, but you interact with it when you access applications hosted by your business partner, SaaS provider, etc.

Figure 1: Network zones

In the traditional world, the flow of traffic between zones is controlled by defining firewall rules. On AWS, you control traffic flow by using network access control lists (ACLs), which are stateless firewalls at the subnet level; security groups, which are stateful firewalls at the instance or elastic network interface level; and route tables, which are sets of rules that determine where traffic is directed.

So how do these zones fit into a deployment on AWS?

In the architecture we described in the previous blog post, we implicitly defined zones and separated the applications at the subnet level. We covered all zones except for the extranet zone.

Figure 2: Network zone mapping with subnet-level separation

However, subnets aren’t the only option for separating applications on AWS. You can also confine an application by using different VPCs for different zones. For example, you can have a dedicated VPC for the management zone, and connect it to other zones (which reside in their own VPCs) by using VPC peering. However, we don’t recommend splitting closely related components, such as SAP application servers, and databases, into separate VPCs.

Which criteria can help you decide whether to use multiple VPCs or multiple subnets within a single VPC for separation?

There is no rule of thumb, and the choice is generally driven by ease of management and segregation of duties in your organization. For example, in your organization, you might have other applications besides SAP that use services from the management zone, such as Microsoft Active Directory (for SAP user single sign-on and user management), email, and anti-malware. These shared applications may be managed by separate teams, and may require completely different change management processes, due to their wider impact. So, you may decide to create a separate VPC for shared services.  You can also manage this shared access through a multiple AWS account strategy such as AWS Organizations.

Let’s see how the architecture from the previous article would look, if we decide to host the external zone and the management zone in separate VPCs, while keeping the intranet zone and the restricted zone together in one VPC.

Figure 3: Network zone mapping with multiple VPCs

We’ll need to make a few configuration changes to accommodate this design:

• Use separate VPC CIDRs for each VPC planned. For example, we had only 10.0.0.0/16 as the VPC CIDR, but now we’ll need:
  • 10.0.0.0/16 – Single VPC CIDR for intranet zone (subnet 10.0.1.0/24) and restricted zone (subnet 10.0.2.0/24)
  • 10.2.0.0/16 – VPC CIDR for external zone (subnet 10.2.1.0/24)
  • 10.3.0.0/16 – VPC CIDR for management zone (subnet 10.3.1.0/24)
• Use VPC peering to establish connections with other VPCs.
• Make adjustments to network ACLs, route tables, and security groups, to route traffic from one VPC to another, as needed.

What’s next?

In this post, we mapped traditional network zones to equivalent constructs in the AWS Cloud. In an upcoming blog post, we’ll conclude this series with our take on subnet zoning patterns for SAP applications that require internal and controlled or uncontrolled external access.

We would like to hear from you about your experiences setting up VPCs on AWS for SAP applications. If you have any questions or suggestions about this article series, feel free to contact us.

Next article in this series: VPC Subnet Zoning Patterns for SAP on AWS, Part 3: Internal and External Access