With the AWS Cloud revolution in full swing, everyone seems to be diving headfirst as to not be left behind. However, with everyone rushing to move their workloads to the cloud, there are more and more customers that require connecting their cloud tenants with the tenants of other customers. Luckily, AWS offers many solutions to assist – the only problem is what are they and when is the best time to use them?
AWS PrivateLink
What is it? PrivateLink provides the ability to allow other AWS tenants network layer access to your services. It essentially allows you to expose designated ports of an ENI (behind a Network Load Balancer for high availability) in other VPCs without those VPCs connected by other means. These VPCs can even be in different accounts.
- Pros
- Security First – no need to expose large portions of your network to allow access. Only expose the ports you want for the ENI that you want.
- UDP and TCP supported
- Highly available
- Traffic traverses AWS Backbone
- Can share with other accounts
- Cons
- Not free. Pay for data transfer and the life of the network load balancer.
- Inaccessible from other CSPs (without Layer 1 connectivity)
- To consume, other networks must have an account in AWS.
- Use Cases
- Sharing web services
- Allowing other accounts to RDP/SSH to your instances
- Forest Level trusts between multiple Active Directories
Final word: AWS PrivateLink is great for allowing other VPCs or other AWS accounts access to your internal services without exposing your entire network. Limited use cases but perfect when it’s what you need.
VPC Peering
What is it? VPC Peering allows connecting VPCs to allow resources in each to access each other.
- Pros
- Easy to configure
- Free
- Cons
- No transitive routing – only able to communicate with directly peered VPCs.
- Not easily scalable
- Use Cases
- Expand CIDR blocks of VPCs.
- Connecting existing VPCs.
- Establish network connectivity with external accounts
Final word: VPC Peering was a great option early in AWS’s history. However, every one of its use cases has been replaced by a new feature in AWS that is much more robust. Only use in very simple network sharing scenarios.
Transit Gateway
What is it? AWS Transit Gateway is a cloud-based virtual routing and forwarding (VRF) service for establishing network layer connectivity with multiple networks.
Pros
- Ability to create multiple virtual routing domains
- Transitive routing – allow attached network resources to community with each other
- Very scalable
- Shareable with other accounts
- Connects with S2S VPNs and Direct Connect
Cons
- Pay for each attachment and for data transfer.
Use Cases
- Great with Landing zones – allow Management, Security and other VPCs to connect seamlessly
- Use custom routing domains to control network traffic of certain resources.
Final word: Transit Gateway is one of AWS’s newer networking solutions. Its scalability and its abilities to leverage multiple routing domains make it a great resource for networking as well as security.
VPC Sharing
What is it? VPC Sharing is a new approach that allows sharing individual subnets in your VPCs with other accounts to allow them ability to create and manage resources in it. Resources may include: EC2 instances, RDS, Redshift, Lambda, and other VPC-hosted resources.
- Pros
- Delegation of tasks – allow other accounts to create resources
- No additional routing rules needed.
- Allows for account separation while simplifying deployments.
- Accounts only have access
- No need for cross-account IAM roles
- Reference security groups of other accounts (as long as they are in same VPC)
- Cons
- Will require complex NACLs and security groups if security requirements call for higher level of network separation.
- Use Cases
- Allow accounts with your organization to deploy resources to designated subnets with Console or CLI.
- Great for IP address management
Final Word: VPC sharing is a great option when simplifying network architecture is a priority. Accounts only have access to the resources they create still allow for role-based access.
VPC Sharing vs. Transit Gateway?
Between the two, what is the better option when you need to share AWS networks with other accounts?
There’s no reason why you couldn’t leverage both. Consider the following AWS accounts which are all a part of an AWS organization:
- Windows Team
- Linux Team
- Networking Team (Creates Dev, Test and Production VPCs)
- Security Team
The networking team could share their VPCs with the Windows and Linux teams, allowing each to create their own resources in the pre-defined networks. Perhaps there are SCPs on each account that prevent the creation of unauthorized resources (Windows team can’t create Linux and vice versa, only networking team can create and edit networking resources). The security team needs the ability to scan all the resources across VPCs and has their appliances (e.g. Splunk, Nessus, Sonarqube) in a separate VPC. All the VPCs are attached to Transit Gateway. The Dev, Test, and Production VPCs however are placed in separate routing domains to prevent them from communicating with each other.
This way the networking team only has to worry about networking, the Windows and Linux team doesn’t have to worry about which subnet or security group select, and the security team can watch over your network all within clearly defined roles.
