There's lots on https://aws.amazon.com/vpc/, and talks on youtube (https://www.youtube.com/watch?time_continue=4&v=3qln2u1Vr2E is a fav). But the TLDR is this: VPC stands for "Virtual Private Cloud" and it gives you your own virtual data center on AWS. You get a private network that uses whatever IP range you'd like, and you can connect to it privately via VPN or Direct Connect (physical links). You can also connect it to the internet with Elastic IP Addresses.
VPCs are free and you can create and edit them programmatically (add subnets, change routes, manage ACLs and security groups) - so they're a useful way to manage an environment of things like EC2 instances, containers, Elastic Load Balancers, RDS databases, Lambda functions, and more, without needing to worry as much about them being exposed to things you don't control.
With this latest PrivateLink feature, it's now possible to offer services between VPCs. So you can build a service in its own VPC, and map into other ones, securely.
Interesting seems like it will be very useful for providing SaaS offerings to servers that you want to keep extra secure by fully restricting internet access (Private VPC without NAT).
Not 100% clear if it is possible to enable bi-directional access for things like vulnerability scanning, but still seems very handy for a certain target audience.
PrivateLink is used to provision Endpoints, which can accept TCP connections, but not originate them. It's designed for services such as webservices, web sites, databases, e-mail, and so on.
VPC peering does allow you to do full bi-directional communication between two VPCs, though the IP ranges have to be unique and de-conflicted across the two networks, unlike with PrivateLink.
To do vulnerability/pen testing, you’ll want to use a purpose built AMI to spin up an instance in a VPC and emit its data to an external C/C system. PrivateLink isn’t built to poke a hole and reach into a VPC.
When you are a large company, you outgrow the limits of a single AWS account per environment pretty quickly, and you start splitting out functional areas or services into their own accounts.
These endpoints solve the last piece of the puzzle, for having components communicate. Until now, we've had to do public ELB's with restricted security groups, or VPN tunnels.
It is not. Some services don’t currently support IAM segregation. We have hundreds of AWS accounts all within AWS Orgs, based on organizational units and SDLC phase.
Orchestrating infrastructure across that many accounts poses some interesting (and fun!) challenges.
With the exception of S3, the services you listed require an IGW or a NAT gateway (with RDS it depends if you are talking about the control plane, or the database itself). The list of AWS services that work with PrivateLink is here [1] and we are working on adding more.
13 comments
[ 4.4 ms ] story [ 38.4 ms ] threadVPCs are free and you can create and edit them programmatically (add subnets, change routes, manage ACLs and security groups) - so they're a useful way to manage an environment of things like EC2 instances, containers, Elastic Load Balancers, RDS databases, Lambda functions, and more, without needing to worry as much about them being exposed to things you don't control.
With this latest PrivateLink feature, it's now possible to offer services between VPCs. So you can build a service in its own VPC, and map into other ones, securely.
Not 100% clear if it is possible to enable bi-directional access for things like vulnerability scanning, but still seems very handy for a certain target audience.
VPC peering does allow you to do full bi-directional communication between two VPCs, though the IP ranges have to be unique and de-conflicted across the two networks, unlike with PrivateLink.
These endpoints solve the last piece of the puzzle, for having components communicate. Until now, we've had to do public ELB's with restricted security groups, or VPN tunnels.
The other thing to think about is scaling for people. Do you really want 100+ teams in one account?
What about cost tracking ? Etc etc.
Lots of reasons to have an account per team, or ideally, an account per service.
Orchestrating infrastructure across that many accounts poses some interesting (and fun!) challenges.
1: it's not clear... can I now access S3, SES SQS RDS from my VPC Lambda functions without a NAT gateway?
2: how do you make those screenshots with the torn off effect?
[1] https://aws.amazon.com/blogs/aws/new-aws-privatelink-endpoin...
"For example, one customer told us that they plan to create hundreds of VPCs, each hosting and providing a single microservice"
At first glance, that sounds pretty neat, but looking at VPC pricing shows that PrivateLink pricing is 1 cent per hour and 1 cent per GB.
It'd be nice to discuss pricing before suggesting we partition microservices into separate VPCs. Or after. Somewhere :-)
That pricing can add up if you're making "hundreds of VPCs"!