Running a Stack in a VPC

You can control user access to a stack's instances by creating it in a virtual private
cloud (VPC). For example, you might not want users to have direct access to your stack's
app
servers or databases and instead require that all public traffic be channeled through
an
elastic load balancer.

The basic procedure for running a stack in a VPC is:

Create an appropriately configured VPC, by using the Amazon VPC console or API, or
an
AWS CloudFormation template.

Specify the VPC ID when you create the stack.

Launch the stack's instances in the appropriate subnet.

The following briefly describes how VPCs work in
AWS OpsWorks Stacks.

Important

If you use the VPC Endpoint feature, be aware that that each instance in the stack
must be able to complete the following actions from Amazon Simple Storage Service
(Amazon S3):

Install the instance agent.

Install assets, such as Ruby.

Upload Chef run logs.

Retrieve stack commands.

To enable these actions, you must ensure that the stack's instances have access to
the
following buckets that match the stack's region. Otherwise, the preceding actions
will
fail.

For Chef 12 Linux and Chef 12.2 Windows, the buckets are as follows.

Agent Buckets

Asset Buckets

Log Buckets

DNA Buckets

opsworks-instance-agent-sa-east-1

opsworks-instance-agent-ap-south-1

opsworks-instance-agent-ap-northeast-1

opsworks-instance-agent-ap-northeast-2

opsworks-instance-agent-ap-southeast-1

opsworks-instance-agent-ap-southeast-2

opsworks-instance-agent-ca-central-1

opsworks-instance-agent-eu-central-1

opsworks-instance-agent-eu-west-1

opsworks-instance-agent-eu-west-2

opsworks-instance-agent-us-east-1

opsworks-instance-agent-us-east-2

opsworks-instance-agent-us-west-1

opsworks-instance-agent-us-west-2

opsworks-instance-assets-us-east-2

opsworks-instance-assets-us-east-1

opsworks-instance-assets-ap-south-1

opsworks-instance-assets-ap-northeast-1

opsworks-instance-assets-ap-northeast-2

opsworks-instance-assets-ap-southeast-1

opsworks-instance-assets-ap-southeast-2

opsworks-instance-assets-ca-central-1

opsworks-instance-assets-eu-central-1

opsworks-instance-assets-eu-west-1

opsworks-instance-assets-eu-west-2

opsworks-instance-assets-sa-east-1

opsworks-instance-assets-us-west-1

opsworks-instance-assets-us-west-2

opsworks-us-east-2-log

opsworks-us-east-1-log

opsworks-ap-south-1-log

opsworks-ap-northeast-1-log

opsworks-ap-northeast-2-log

opsworks-ap-southeast-1-log

opsworks-ap-southeast-2-log

opsworks-ca-central-1-log

opsworks-eu-central-1-log

opsworks-eu-west-1-log

opsworks-eu-west-2-log

opsworks-sa-east-1-log

opsworks-us-west-1-log

opsworks-us-west-2-log

opsworks-us-east-2-dna

opsworks-us-east-1-dna

opsworks-ap-south-1-dna

opsworks-ap-northeast-1-dna

opsworks-ap-northeast-2-dna

opsworks-ap-southeast-1-dna

opsworks-ap-southeast-2-dna

opsworks-ca-central-1-dna

opsworks-eu-central-1-dna

opsworks-eu-west-1-dna

opsworks-eu-west-2-dna

opsworks-sa-east-1-dna

opsworks-us-west-1-dna

opsworks-us-west-2-dna

For Chef 11.10 and earlier versions for Linux, the buckets are as follows. Chef 11.4
stacks are not supported in regional endpoints outside the US East (N. Virginia) Region.

For AWS OpsWorks Stacks to connect to the VPC endpoints that you enable, you must
also
configure routing for your NAT or public IP, as the AWS OpsWorks Stacks agent still
requires
access to the public endpoint.

VPC Basics

For a detailed discussion of VPCs, see Amazon
Virtual Private Cloud. Briefly, a VPC consists of one or more
subnets, each of which contains one or more instances. Each
subnet has an associated routing table that directs outbound traffic based on its
destination IP address.

Instances within a VPC can generally communicate with each other, regardless
of their subnet.

Subnets whose instances can communicate with the Internet are referred to as
public subnets.

Subnets whose instances can communicate only with other instances in the VPC
and cannot communicate directly with the Internet are referred to as
private subnets.

AWS OpsWorks Stacks requires the VPC to be configured so that every instance in the
stack, including
instances in private subnets, has access to the following endpoints:

Any package repositories that your operating system depends on, such as the
Amazon Linux or Ubuntu Linux repositories.

Your app and custom cookbook repositories.

There are a variety of ways to configure a VPC to provide this connectivity. The
following is a simple example of how you could configure a VPC for an AWS OpsWorks
Stacks app server
stack.

This VPC has several components:

Subnets

The VPC has two subnets, one public and one private.

The public subnet contains a load balancer and a network address
translation (NAT) device, which can communicate with external
addresses and with the instances in the private subnet.

The private subnet contains the application servers, which can
communicate with the NAT and load balancer in the public subnet but
cannot communicate directly with external addresses.

Internet gateway

The Internet gateway allows instances with public IP addresses, such as
the load balancer, to communicate with addresses outside the VPC.

Load balancer

The Elastic Load Balancing load balancer takes incoming traffic from
users, distributes it to the app servers in the private subnet, and returns
the responses to users.

NAT

The (NAT) device provides the app servers with limited Internet access,
which is typically used for purposes such as downloading software updates
from an external repository. All AWS OpsWorks Stacks instances must be able to communicate
with AWS OpsWorks Stacks and with the appropriate Linux repositories. One way to handle
this issue is to put a NAT device with an associated Elastic IP address in a
public subnet. You can then route outbound traffic from instances in the
private subnet through the NAT.

Note

A single NAT instance creates a single point of failure in your
private subnet's outbound traffic. You can improve reliability by
configuring the VPC with a pair of NAT instances that take over for each
other if one fails. For more information, see High Availability
for Amazon VPC NAT Instances. You can also use a NAT
gateway. For more information, see NAT in the
Amazon VPC User Guide.

The optimal VPC configuration depends on your AWS OpsWorks Stacks stack. The following
are a few
examples of when you might use certain VPC configurations. For examples of other VPC
scenarios, see Scenarios for
Using Amazon VPC.

Working with one instance in a public subnet

If you have a single-instance stack with no associated private
resources—such as an Amazon RDS instance that should not be publicly
accessible—you can create a VPC with one public subnet and put the
instance in that subnet. If you are not using a default VPC, you must have
the instance's layer assign an Elastic IP address to the instance. For more
information, see OpsWorks Layer Basics.

Working with private resources

If you have resources that should not be publicly accessible, you can
create a VPC with one public subnet and one private subnet. For example, in
a load-balanced automatic scaling environment, you can put all the Amazon EC2 instances
in the private subnet and the load balancer in a public subnet. That way the
Amazon EC2 instances cannot be directly accessed from the Internet; all incoming
traffic must be routed through the load balancer.

The private subnet isolates the instances from Amazon EC2 direct user access,
but they must still send outbound requests to AWS and the appropriate Linux
package repositories. To allow such requests you can, for example, use a
network address translation (NAT) device with its own Elastic IP address and
then route the instances' outbound traffic through the NAT. You can put the
NAT in the same public subnet as the load balancer, as shown in the
preceding example.

If you are using a back-end database such as an Amazon RDS instance,
you can put those instances in the private subnet. For Amazon RDS
instances, you must specify at least two different subnets in
different Availability Zones.

If you require direct access to instances in a private
subnet—for example, you want to use SSH to log in to an
instance—you can put a bastion host in the public subnet that
proxies requests from the Internet.

By default, AWS OpsWorks Stacks displays subnet names by concatenating their CIDR
range and
Availability Zone, such as 10.0.0.1/24 - us-east-1b. To make the names
more readable, create a tag for each subnet with Key set to
Name and Value set to the subnet
name. AWS OpsWorks Stacks then appends the subnet name to the default name. For example,
the
private subnet in the following example has a tag with Name set
to Private, which OpsWorks displays as 10.0.0.1/24
us-east - 1b - Private.

You can launch a VPC template using the AWS CloudFormation console with just a few
steps. The
following procedure uses the example template to create a VPC in US East (N. Virginia)
Region. For
directions on how to use the template to create a VPC in other regions, see the note that follows the procedure.

Copy the template file to your system, select the appropriate region in the
AWS CloudFormation console, and
use the Create Stack wizard's Upload a template
to Amazon S3 option to upload the template from your
system.

The example template includes outputs that provide the VPC, subnet, and load balancer
IDs that you will need to create the AWS OpsWorks Stacks stack. You can see them by
choosing the
Outputs tab at the bottom of the AWS CloudFormation console window.