VPC Endpoints for Your Own Applications and Services(aws.amazon.com)
aws.amazon.com
VPC Endpoints for Your Own Applications and Services
https://aws.amazon.com/blogs/aws/aws-privatelink-update-vpc-endpoints-for-your-own-applications-services/
6 comments
Is IAM not sufficient for separating things within an organization?
You run into all kinds of hard and soft limits when you have thousands of instances.
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.
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.
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.
Orchestrating infrastructure across that many accounts poses some interesting (and fun!) challenges.
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.
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.
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.
From the post:
"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"!
"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"!
Does this work across regions? Endpoint in a vpc in one region connected to service running in another region...
I am new to this VPC thing. Is there an overview that explains why I want it and how it works?
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.
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.
Jeff - two questions:
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: 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?
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.
[1] https://aws.amazon.com/blogs/aws/new-aws-privatelink-endpoin...
[1] https://aws.amazon.com/blogs/aws/new-aws-privatelink-endpoin...
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.