High-level architecture of a network

The following diagram provides a high-level architectural view of a sample network in your Power Virtual Server environment and illustrates how various subnets and components are connected. The diagram includes different virtual machines (VMs) such as web servers, database servers, and an application server. The network also includes components such as subnet ranges, jump hosts, transit gateway, and private endpoints (DNS and Secrets Manager).

The network components that are depicted in the high-level network architecture diagram are explained in the following table:

Network address groups and CIDR members

The following table lists the network address groups (NAGs) and the associated Classless Inter-Domain Routing (CIDR) members that are used as examples in this topic. A NAG simplifies the NSG rule implementation by using logical groups instead of individual IPs. For more information about NAGs, see Network address groups.

Network address group and network security group layout

The following diagram illustrates the NAGs and NSGs layout and how the traffic flows in the network.

The following table lists the NAGs and NSGs used in the NAG and NSG layout diagram, and explains the purpose of each component in the layout:

Traffic flow across network components

The following table outlines the expected traffic flows among various network components by using different protocols and its purpose, as depicted in the NAG and NSG layout diagram.

For more information about how network traffic and security rules are processed and prioritized when NSG is implemented in a Power Virtual Server workspace, see Network traffic rules and precedence in NSG.

Defining NSG rules for web servers

This section outlines the rules that can be defined in an NSG to control what traffic is allowed or denied to the Web Servers. Consider the following requirements:

• Deny SSH traffic between the other web servers.
• Allow HTTP from the ALB.
• Allow SSH access from the jump host.
• Allow all traffic from the web servers.
• Allow return DNS packets from IBM resolvers.
• Allow return HTTPS packets from the Secrets Manager.
• Allow return HTTP packets from the application server.
• Define an implicit deny rule to restrict all the other unspecified traffic.

Based on these requirements, you can create an NSG and define the security rules with the following configurations. Each row in the following table represents an individual security rule.

Defining NSG rules for the application server

This section outlines the rules that can be defined in an NSG to control the traffic that is allowed or denied to the application server. Consider the following requirements:

• Allow HTTP traffic from the web servers.
• Allow SSH from the jump host.
• Allow all traffic from the other application servers.
• Allow return DNS packets from IBM resolvers.
• Allow return HTTPS packets from the Secrets Manager.
• Allow return packets from the database servers.
• Define an implicit deny rule to restrict all other unspecified traffic.

Based on these requirements, you can create an NSG and define the security rules with the following configurations. Each row in the following table represents an individual security rule.

Defining NSG rules for database servers

This section outlines the rules that can be defined in an NSG to control the traffic that is allowed or denied to the database servers. Consider the following requirements:

• Allow MySQL traffic from the application server.
• Allow SSH traffic from the jump host.
• Allow all traffic from the other database servers.
• Allow return DNS packets from IBM resolvers.
• Allow return HTTPS packets from the Secrets Manager.
• Allow return database packets from the replication server.
• Define an implicit deny rule to restrict all other unspecified traffic.

Based on these requirements, you can create an NSG and define the security rules with the following configurations. Each row in the following table represents an individual security rule.

For more information about setting up, configuring, and managing NSGs, see Setting up network security groups in a workspace.