6

We're spinning up infrastructure inside of an AWS VPC via CloudFormation.

We're using auto-scaling groups to bring up VPC-EC2 instances (so, we don't bring up instances directly; ASGs manage that).

Inside of a PVC, EC2 instances only have a private IP; they cannot see the outside world without further work.

When these instances spin up, we have some bootstrap tasks that require talking to the various AWS APIs. We also have some ongoing tasks that require AWS API traffic.

How are you tackling this apparent chicken-egg problem?

We've read about:

  • NAT instances - but don't like this so much because it's another layer to our stack.
  • assigning elastic-IPs to each VPC instance that needs to talk - but a) they all do, and b) since we're using ASGs, we don't know which instances to assign EIPs to at provision-time, and c) we'd need to set up something to monitor those ASGs and assign EIPs when instances are terminated and replaced
  • spinning up an instance (actually, a load-balanced pair, probably spanning AZs) to act as an AWS-API proxy for all API traffic

I guess I'm wondering whether there's some kind of back-door we can open that allows our VPC EC2 instances access to the AWS API endpoints, but nothing else, for cheap-complexity setup, that doesn't add another network-hop layer to our infrastructure for serving requests.

Peter Mounce
  • 1,253
  • 5
  • 16
  • 29

2 Answers2

3

You have covered the main ways to get a VPC instance in a private subnet to talk to the outside world.

  1. Have the Internet traffic for the private subnet be routed out of a VPN tunnel connected to your office, which can then provide access to the rest of the internet. Not ideal since it requires an always on VPN tunnel and an extra hop through your office.

I would suggest using NAT instances, this is the recommended setup for getting Internet access to machines inside private subnets. They are configured per subnet, so your machines do not need to have any knowledge of their configuration when being launched. Just be sure to use an m1.large or larger instance to get the higher network throughput (vs m1.small)

Flashman
  • 1,321
  • 10
  • 9
  • That's another option, except our office infrastructure is decidedly less resilient than AWS, so we don't want to rely on it. – Peter Mounce Jul 30 '12 at 11:14
2

As of April 2015, AWS now offers a straightforward solution to this problem: VPC Endpoints

A VPC endpoint enables you to create a private connection between your VPC and another AWS service without requiring access over the Internet, through a NAT instance, a VPN connection, or AWS Direct Connect. Endpoints are virtual devices. They are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in your VPC and AWS services without imposing availability risks or bandwidth constraints on your network traffic.

Steve Jansen
  • 443
  • 4
  • 6
  • Note that this only applies to S3 for the time being. And knowing how slow Amazon is with rolling out much requested features, other AWS endpoints might not be available for quite some time. – lobi Jun 08 '15 at 17:59
  • Update - No longer applies to just S3. Applies to other services [listed here](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints.html). I opened an enpoint for the EC2 API and my private instance was perfectly able to access to the API. Perfect! – Luke Jul 22 '18 at 06:35