Top 4 Networking considerations for Mergers, Acquisitions, and Divestitures

This blog is co-authored by Parrish Gamarra, Principal Network Architect, Johnson & Johnson

Introduction

Mergers, Acquisitions (M&A), and divestitures are part of many enterprises’ journeys, driven by evolving business goals like expanding into new geographies or to spin off a line of business. Refer to this post for checking your general readiness for M&A with AWS Well-Architected Framework.

M&A use cases open up considerations for secure connectivity, and IT assets integration of the merging enterprises. Similarly, divestitures require IT teams to create a strategy for splitting IT assets.

Additionally, for divestitures, the two companies might require secure connectivity for a transitionary period while there are technical dependencies between the IT stacks of the two enterprises.

In this post, we’ll discuss these top four AWS Networking considerations for M&A and divestiture use cases:

1. IP address management
2. Defining the right connectivity model for post M&A or divestiture
3. Network Security
4. DNS resolution across enterprises

For simplicity, we’ll focus on single or two Region deployments. The considerations and recommendations apply to any deployment size and Regional span.

Prerequisites

We assume that the readers are familiar with AWS Networking constructs like Amazon Virtual Private Cloud (Amazon VPC), routing tables, AWS Transit Gateway, AWS Direct Connect, AWS Direct Connect Gateway, and Amazon Route 53.

Consideration-1: IP Addressing

Understanding the IP addressing scheme of the merging or divesting companies will help you plan your prefix summarization and create your routing design.

M&A use case: Network administrators often use RFC1918 to vend out subnets to application teams. This poses the risk of overlapping IP CIDRs in the merging enterprises. The process of discovering each subnet’s CIDR allocation can be extremely time consuming. For AWS workloads, you can use the VPC IPAM service to discover CIDRs allocated to each VPC. Once you have the CIDR data for both of the merging enterprises, you can export it into a CSV file, and run a simple Excel function to find if there are any overlapping CIDRs.

The following figure shows an M&A use case where Enterprise-1’s and Enterprise-2’s VPC-1 have an overlapping CIDR. The network administrators within each of the enterprises can use VPC IPAM feature to visualize their existing IP allocation scheme and discover any overlaps.

Figure 1: Merger use case – overlapping CIDRs

If you discover IP overlaps, then see how to connect networks with overlapping IP addresses.

Divestiture use case: Once you identify all of the departments/VPCs/workloads that must be divested, the next step is to collect the CIDRs for each of the corresponding subnets. Having a neatly summarizable IP addressing space for these workloads will make the divestiture easy from a networking perspective. Consider the example shown in Figure 2.

Figure 2: Divestiture use case – intra AWS routing with summarizable CIDRs

This example uses Transit Gateway cross-account intra-region peering to provide private connectivity between ACME Corp. and New Corp. VPC-1 and VPC-2 must move to New Corp, and they have CIDRs that can be cleanly summarized. VPC-3 and VPC-4 must stay within Acme Corp and these VPCs also have contiguous and summarizable CIDRs. With this model, you can use static summary routes in ACME Corp’s and Enterprise-2’s Transit Gateway routing tables to provide IP connectivity between the two enterprises.

The following figure builds on top of the example above, and shows connectivity back to on-premises data centers. Each Transit Gateway advertises corresponding summary routes over the Direct Connect Gateway association.

Figure 3: Divestiture use case – AWS to on-premises routing with summarizable CIDRs

If the divesting departments’ VPC CIDRs weren’t cleanly summarizable, then each Transit Gateway would potentially need static routes for each VPC’s CIDR to provide east/west connectivity from ACME’s VPCs to New-Corp’s VPCs. Additionally, the Transit Gateways would must also advertise these prefixes to on-premises data centers over the Direct Connect gateway association. This IP scheme would make the configuration complex, and it would augment the risk of running into routing table limits. See the documentation for Transit Gateway limits and quotas.

Divestitures are usually not at the top of mind while vending out CIDRs to departments, and in these cases, it’s impossible to have a clean summary for all divesting IT assets. For these situations, you can consider using an overlay solution like Transit Gateway Connect over Direct Connect. With this model, you can use BGP over GRE between the Transit Gateway and your on-premises routers, as well as advertise up to 5000 routes to on-premises data centers.

Figure 4: Divestiture use case – AWS to on-premises routing with BGP over GRE for non-summarizable CIDRs

In case you decide to terminate the GRE tunnel on a hardware firewall on-premises, check firewall’s support for BGP-over-GRE. In our testing, we discovered that certain hardware firewall models pinned multiple GRE tunnels on the same CPU. This had an adverse impact on the total throughput over the GRE tunnels.

Consideration-2: Defining the right connectivity model for post M&A or divestiture

In this section, we’ll look at M&A and divestiture use cases from a network connectivity perspective. Network Connectivity layer is the glue that holds an enterprise’s entire IT ecosystem together. Furthermore, creating the right connectivity model is a critical step toward planning your M&A or divestiture.

M&A use case: The following figure shows a sample M&A use case, wherein each of the merging enterprises have a hybrid network, or a network that spans AWS and on-premises data-centers:

Figure 5: Connectivity for M&A use case

There are three major networking considerations for M&As:

1. Connectivity within AWS (or VPC-to-VPC connectivity): You can connect the AWS ecosystems of merging enterprises either over the internet, or use any of the private connectivity mechanisms described in AWS documentation.
2. Hybrid Connectivity: For an M&A use case, creating private connectivity between Enterprise-1’s AWS workloads and Enterprise-2’s on-premises data-centers may be desirable. There are three ways of achieving this:
   • You can leverage multi-account support for Direct Connect Gateways to extend connectivity directly from Enterprise-1’s AWS account to Enterprise-2’s data center. You should consider this connectivity model if you’re planning to support latency-sensitive applications for the hybrid-connectivity use case. See the documentation for more details.
   • You can create a Transit Gateway peering between the two enterprises’ Transit Gateway. In this case, the traffic flows from Enterprise-1’s AWS account to Enterprise-2’s AWS account, and then on to Enterprise-2’s data center. This is discussed in the following figure.

Figure 6: Transit Gateway peering for hybrid access from Enterprise-1 to Enterprise-2

1. • Use IPSec VPNs between Enterprise-1’s Transit Gateway and Enterprise-2’s on-premises data center. Note that the VPN can use the Internet as the underlying transport, or you can use VPN over Direct Connect. See the documentation for more information.

3. Connectivity between on-premises environments: You can leverage the SiteLink feature of Direct Connect for providing connectivity between each enterprise’s data-centers. Alternatively, you can use technologies like MPLS to provide private connectivity between the data-centers.

You can use SiteLink and MPLS backbones together to enable the M&A use case, and create active/active or active/backup routing topologies. Refer to the SiteLink architecture post for more details.

Divestitures: There are two connectivity patterns when it comes to divestitures:

1. Service-Provider and Service-Consumer model: The original enterprise, Acme Corp, retains ownership of critical IT assets like databases, and the divested enterprise consumes these services. The New-Corp can be thought of as a net-new deployment with this model as no workloads must move between the two enterprises. The following figure shows connectivity between the two enterprises using Transit Gateway intra-region peering. However, you can connect the two enterprises using connectivity models as explained in the documentation.

Figure 7: Divestiture – service-provider, service-consumer model

2. Workloads migration model: In this model, the necessary workloads must be moved from the original enterprise to the divesting enterprise, as shown in the following figure. The workloads that must be moved are marked with an orange dot.

Figure 8: Divestiture use case – workloads migration model

Workloads in AWS can be deployed inside of VPCs from an AWS Account. Multiple AWS Accounts can be grouped together as an Organizational Unit (OU), and multiple of these OUs make up the entire AWS Organization for the enterprise. The easiest way to enable the divestiture would be to transfer all of the accounts that deployed VPCs marked with an orange dot from Acme Corp’s Organization to New Corp’s Organization, and then connect the two enterprises using the private connectivity methods discussed previously.

See the migrating accounts from a networking perspective post for more details on migrating networking constructs to a different organization.

In case it’s impossible to move AWS accounts between the two Organizations, you must create new VPCs and create new workloads in New Corp’s AWS Accounts.

Consideration-3: Network security

After an M&A or divestiture is complete, a common requirement is to provide an additional level of security for data flowing between the two enterprises by inserting inline firewalls. To achieve this, you can use AWS Network Firewall, or Gateway Load Balancer with 3^rd party firewalls. The Network Security considerations provided in this section apply to both M&A and divestiture use cases.

If each enterprise has their own firewall deployment, then any given data flow that requires inspection will go through two sets of firewalls. Figure-9 shows bidirectional data-flow when workloads in VPC-3 in Acme Corp must communicate with workloads in VPC-1 in New-Corp. The arrows in orange depict the forward direction of the flow, and the arrows in blue depict the return traffic.

Figure 9: Regional double firewalling for data between enterprises

We recommend testing your network inspection deployment with real application traffic before finalizing the network-security architecture. For latency sensitive workloads, you may choose different methods of security traffic, such as application level-authentication. For these cases, you can use Transit Gateway routing tables to make sure that traffic is forwarded directly to the application VPC in ACME Corp, as shown in Figure-10 below. However, with this model, ACME Corp won’t be able to inspect any incoming traffic from New-Corp that is destined to VPC-3’s CIDR, and this may be a security concern. Another option is to make sure that New Corp performs the necessary inspection locally before sending any data to ACME corp. However, this requires tight co-ordination between the security teams of the two enterprises.

Figure 10: Single firewalling for data between enterprises

Consideration-4: DNS design

DNS is the de-facto way how users connect to applications, and also how various components of an application may communicate with each other. The DNS considerations in this section apply to both M&A and divestiture use cases.

The following figure shows a sample deployment, where both enterprises have public/private DNS zones hosted in both AWS and their data-centers. A common requirement in M&A and divestiture use cases is to provide private DNS resolution between the enterprises during the transitionary period.

Figure 11: DNS use case for merging or divesting enterprises

In this section, we’ll focus on inter-enterprise DNS resolution, and assume that each enterprise already has full DNS resolution between their AWS footprint and on-premises workloads. Refer to the documentation for information on how to set up DNS resolution in a hybrid setup.

Here are the steps that you can take to make sure that all DNS resolutions across enterprises are private:

1. Create a conditional forwarding rule for enterprise2.com in the on-premises DNS server in Enterprise-1. Point it to the Inbound Route 53 Resolver endpoints deployed in Enterprise-2’s VPC.
2. Create a conditional forwarding rule for enterprise1.com in the on-premises DNS server in Enterprise-2. Point it to the Inbound Route 53 Resolver endpoints deployed in Enterprise-1’s VPC.
3. Create a forwarding rule in Enterprise-1 for com, and point it to the on-premises resolver inside Enterprise-2
4. Create a forwarding rule in Enterprise-2 for com, and point it to the on-premises resolver inside Enterprise-1
5. Associate Enterprise-1’s private hosted zones with Enterprise-2’s VPCs, and vice versa.

The scenario listed in this section requires that the underlying connectivity between the enterprises is already set up. See this post for multi-region DNS considerations.

Conclusion

Network connectivity is a common consideration for both M&A and divestiture use cases. AWS offers networking services that help you tackle your M&A or divestiture activities. In this post, we discussed the top four Networking considerations for any M&A or divestiture use cases. For more information on AWS networking services, visit the documentation page.

About the Authors