AWS here. I have a simple app server that is running on EC2 instances that are in an autoscaling ("target") group that are fronted by an application load balancer (ALB). The ALB's domain name is CNAME-mapped in DNS to my dev subdomain, say, dev.myapp.example.com. Hence I can use curl, wget, PostMan, etc. to fire HTTP requests at http://dev.myapp.example.com and get responses from it, and those requests get load-balanced across whatever EC2 instances are sitting behind the ALB (in the autoscaling group).
The app server running on those EC2 instances needs to connect to a 3rd party Database-as-a-Service. We'll call this cloud DB "MyCloudDB" for the purposes of this question.
When I provision an EC2 instance manually and deploy my app server there, in order to get it talking to MyCloudDB, I need to log into the MyCloudDB web console and access list the EC2 instance's public IP with a /32 subnet (honestly not sure why on the /32 subnet). So for example if AWS assigns a public IP for the instance as, say, 1.2.3.4, then I need to log into MyCloudDB and add a access list entry for 1.2.3.4/32. Then and only then can the app server (running on the new EC2 instance) connect to MyCloudDB.
I am trying to figure out how to make this allow/access list setup compatible with my ALB and its autoscaling group. Obviously, the EC2 instances in the autoscaling group are ephemeral and will spin up and tear down depending on my autoscaling rules. Since we need this to be dynamic/elastic, I need a way to tell MyCloudDB to "trust" any requests coming from EC2 instances behind my ALB. And obviously, not relax security so much that I create headaches for myself.
The MyCloudDB offers 3 types of network access options:
- IP Access List (_what I'm currently using right now, exclusively)
- VPC Peering
- this allows peering my app VPC with the
MyCloudDBVPC
- this allows peering my app VPC with the
- Private Endpoint
- allows AWS PrivateLink to connect to
MyCloudDB
- allows AWS PrivateLink to connect to
- Management REST API
- allows me to manage the IP Access List but via RESTful (web service) API
- so I could create a EC2 instance lifecycle hook to run a script that adds the instances IP address to the
MyCloudDBIP Access List viacurlor some other tool
So from an automation standpoint, the 3 options I have are really: VPC Peering, Private Endpoint (PrivateLink) or API calls. I can tease apart the pros/cons of the API call option, but I'm struggling to "see the forest through the trees" on the VPC Peering vs PrivateLink option.
A major call out here is: eventually I will have CloudFormation templates managing the rollout of this ALB to new (ephemeral) environments. So not only do I need this connection solution to work for EC2 instances sitting behind ALB, I need it to work with ALBs that will be provisioned via CloudFormation.
Given my situation, context and needs, what are advantages/disadvantages of VPC Peering vs PrivateLink?
Best Answer
This is pretty much exactly what PrivateLink was made for. They effectively put a network interface in your VPC, you access it. On their side it hits an NLB then goes to their database. This is least priviliedge and is what I would do.
VPC peering opens up more of your network to more of their network. If your IP ranges clash it becomes more difficult. I don't see any advantages here in this situation.
If IP Access List was the only option you would need static IPs for your autoscaling group. Creating a NAT Gateway in each subnet and whitelisting their elastic IPs would achieve this.