VPC Peering with AWS: Architecture, Use Cases and Guidance

Overview An AWS VPC is an isolated (private) portion of the Amazon Cloud with its own networking environment and gateways to the Internet. VPC Peering enables the creation of one-to-one networking connections between two or more VPCs in the same AWS Region, and even between different AWS accounts.

As per AWS documentation: AWS uses the existing infrastructure of a VPC to create a VPC peering connection; it is neither a gateway nor a VPN connection and does not rely on a separate piece of physical hardware. There is no single point of failure for communication or a bandwidth bottleneck. At a high level, peering offers an AWS managed solution for connecting VPCs and can be viewed as a logical first choice. Additionally, there is a school of thought that encourages customers to create multiple AWS accounts for the purpose of separation, either at the environment level, production/stage/development level or between business functions such as ecommerce, ERP and finance. Isolation of accounts offers many benefits and separate accounts are one of the methods used to separate environments or business functions. In this article, we will review some use cases for VPC peering, its limitations and considerations from a design perspective. Peering Use Cases At a high level, peering provides connectivity between VPCs. Use cases include:

• A specific security need that requires separation of function using a VPC construct, but that also requires private connectivity to other environments (e.g. a Logging VPC).
• Common server or services (e.g. an account with a deploy VPC or a separate deploy VPC in the same account, that controls the build/deployment across different AWS accounts).

Peering Considerations Limitations

• You cannot create a VPC peering connection between VPCs in different regions. This may change in future releases.
• VPC soft limit of 50 peering connection applies. Ref: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Appendix_Limits.html. This is actually a good limit to adhere too, as often requiring more than 50 peers indicates a design issue in the first place.
• Until recently, you could use security groups from the peer VPC as a source or destination for rules in your security group.
• An instance's public DNS hostname will not resolve to its private IP address across peered VPCs. You will have to rely on public IP addresses or manage DNS separately in a private zone or similar environment.
• This limitation extends to other AWS services like internet gateway, VPC endpoint to S3 and Direct Connect connection. Essentially, you cannot access these over the peering connection. You can read more about these in this AWS peering guide.

Design Considerations

• Unicast Reverse path forwarding (RPF), which is used for the purposes of ensuring loop-free forwarding of multicast packets in multicast routing (and to help prevent IP address spoofing in unicast routing) is not supported. This can present both security and routing issues if there is a misconfigured routing table. If you have overlapping or matching CIDR blocks, you need to ensure your routing tables are configured to avoid sending response traffic from your VPC to the incorrect VPC.
• The peering VPC should avoid having the same CIDR blocks. This does not prevent the peering, but as you would expect, it prevents connectivity between the overlapping CIDR blocks. If you have several accounts, you will also need to maintain an authoritative, external database of subnets. If the accounts have already been created, this may become a challenge to fix and keep separate.
• No support for transitive peering. In the case where there are three or more VPCs, every VPC must pair with each other. A better design pattern in such a setup would mean not relying on transitive peering, and instead using a hub-and-spoke model where a central VPC only peers into the others.
• There is no support for encryption. Traffic between instances in peered VPCs remains private and isolated, similar to how traffic between two instances in the same VPC is private and isolated. But there is no encryption undertaken by AWS. If this is required, you will have to rely on application level encryption like HTTPS/TLS or IPSEC level encryption using VPN appliances.
• If overused, peering can become very difficult to manage at scale. Architecturally it can limit your flexibility when introducing newer VPCs or accounts. Because of the non-overlapping CIDR requirement, you will need to take that into account every time you add a subnet or inherit another AWS account with already-defined subnets.
• Operationally, it can be complex to troubleshoot issues, especially if the VPC or accounts are managed by different teams and groups.
• AWS VPC sizes cannot be changed. You will need to delete and create a new VPC.
• Data transfer between peering connections are charged per normal EC2 data transfer rates.
• Bandwidth limitations are the same as connections between EC2 instances.

https://youtu.be/17BjtTb47RM Peering Alternatives Peering in most cases can be solved by finding other network flow options.

• In the world of cloud, where we are already consuming services via API and REST, and, looking to build independent micro-services, HTTPS-based access between accounts might suffice. You switch the paradigm to use point-to-point connections or consider push/pull models to avoid peering.
• Site-to-Site VPN is always an option in such use cases. It provides the added benefits of encryption and security but also introduces operational overhead for managing VPN appliances or VPN services on EC2. You will also solve for the single points of failure by having more than one VPN endpoint. This will increase your total cost because of the need for additional appliances or OpenVPN on EC2 instances.
• If the solution is large enough and warrants the use of AWS Direct Connect, routing back through their corporate network or a provided network will work. This might introduce additional latency and may not work in all use cases. Typically in such setups, the network management tasks can be offloaded to the actual network team already managing routing and the CIDR database. DirectConnect is going to be the most expensive option and you won't use it to for only peering. If this has already been implemented for other performance reasons, it can be leveraged here.

Conclusion VPC peering should be carefully planned, taking into account the limitations and considerations, and, it's not always the most flexible solution in the long run. References and Links More on Unicast RPF: http://www.cisco.com/c/en/us/about/security-center/unicast- reverse-path-forwarding.html VPC FAQS: https://aws.amazon.com/vpc/faqs/ http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html http://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/peering- configurations-partial-access.html https://aws.amazon.com/about-aws/whats-new/2016/03/announcing-support-for- security-group-references-in-a-peered-vpc/