anchor.diff:  title: Setting Up your IaaS for BOSH
   ---
   
  -Before you deploy BOSH (including MicroBOSH), make sure that your IaaS is properly set up as described below.
  -
  -**Note**: Deploying BOSH is supported on the VPC flavor of AWS, but not on the EC2 flavor.
  -
  -## <a id="hardware"></a> Choosing Suitable Hardware ##
  -
  -What hardware is most suitable for your deployment depends on your intended use of BOSH.
  -
  -* If you plan to deploy a large number of applications, for example, you should opt for greater amounts of
  -disk space, because BOSH needs room to store the releases it deploys.
  -* If you expect a large number of active users, more RAM is a good idea.
  +Before you deploy BOSH or MicroBOSH, complete the following steps to set up your IaaS:
  +
  +1. Allocate hardware resources
  +1. Restrict inbound network traffic
  +1. (AWS Only) Complete your IaaS setup
  +1. Validate your IaaS instance
  +
  +**Note**: BOSH supports the VPC flavor of AWS, but not the EC2 flavor.
  +
  +## <a id="hardware"></a> Step 1: Allocate Hardware Resources ##
  +
  +Your intended use of BOSH determines what hardware resources you should allocate
  +in your IaaS.
  +For example:
  +
  +* BOSH needs room to store the releases it deploys.
  +Larger applications or larger numbers of them require more disk space.
  +
  +* Larger numbers of active users require more RAM.
  +
  +Use the UI that your IaaS provides to allocate hardware for your BOSH deployment.
   
   ### <a id='aws'></a> AWS ###
   
  -AWS describes hardware in terms of [instance types](http://aws.amazon.com/ec2/instance-types/).
  -The **m2.medium** instance type is a reasonable instance type to try for your BOSH deployment.
  +AWS describes hardware in terms of  [instance types]
  +(http://aws.amazon.com/ec2/instance-types/).
  +Most deployments can start with the **m2.medium** instance type.
   For MicroBOSH, **m1.small** is fine for testing but could be inadequate for production.
   
   ### <a id='openstack'></a> OpenStack ###
   
  -OpenStack describes hardware in terms of [flavors](http://docs.openstack.org/trunk/openstack-ops/content/flavors.html).
  +OpenStack describes hardware in terms of [flavors]
  +(http://docs.openstack.org/trunk/openstack-ops/content/flavors.html).
   Choose a flavor with at least three gigabytes of RAM.
   
   ### <a id='vsphere'></a> vSphere ###
   
  -vSphere describes hardware in terms of RAM, CPU, virtual disk, and the other typical specs.
  -As a starting point for deciding what hardware to use, see the documented [hardware requirements for Cloud Foundry](../deploying/vsphere/hardware_spec.html).
  -
  -## <a id="inbound"></a> Restricting Inbound Network Traffic ##
  -
  -Configuring Security Groups is required to deploy BOSH on AWS and OpenStack.
  -Configuring multiple networks is recommended for vSphere.
  -You do this to restrict incoming network traffic to the BOSH VM or VMs.
  +vSphere describes hardware in terms of RAM, CPU, virtual disk, and other specs.
  +Refer to the [hardware requirements for Cloud Foundry]
  +(../deploying/vsphere/hardware_spec.html) topic for help deciding what hardware to use.
  +
  +## <a id="inbound"></a> Step 2: Restrict Inbound Network Traffic ##
  +
  +To deploy BOSH on AWS or OpenStack, you must configure security groups.
  +For vSphere, we recommend configuring multiple networks.
  +The goal in all cases is to restrict incoming network traffic to the BOSH VM or VMs.
   
   ### <a id='aws'></a> AWS and OpenStack  ###
   
  -Set up two security groups, `ssh` and `bosh`, as specified in the following tables.
  +Set up two security groups, **ssh** and **bosh**.
  +The settings in the following tables are generic; adapt them to your production
  +needs.
  +
  +**Note**: In OpenStack Grizzly, there are settings for both `INGRESS` and `EGRESS`
  +control.
  +The instructions here apply to `INGRESS` only.
  +The tables reflect the fact that OpenStack automatically adds port UDP 68 to all
  +security groups.
  +For AWS, add this port manually.
   
   #### <a id='ssh'></a> ssh Security Group  ####
   
  
positive.code:   <tr><td>TCP</td><td>25777</td><td>25777</td><td>0.0.0.0/0 (CIDR)</td><td>BOSH Registry</td></tr>
    </table>
  
  **Note About OpenStack**: Port UDP 68 was automatically added to all security groups.
  In OpenStack Grizzly, there are settings for both **INGRESS** and **EGRESS** control.
  The instructions here apply to **INGRESS** only.
  
  ### <a id='vsphere'></a> vSphere ###
  
  With vSphere, a common practice is to configure multiple networks,
  then put BOSH on one network and the software that is deployed with BOSH on
  a separate network or networks.
  
  Security groups as such is not a vSphere feature.
  
  ## <a id="network"></a> Further Setup for AWS ##
  
  For AWS, there are special BOSH CLI commands to set up your infrastructure.
  This section explains how to install the plugin that provides the commands,
  and then use them.
  
  ### <a id='plugin'></a> Install the AWS plugin to the BOSH CLI ###
  
  Ensure that you Ruby 1.9.3 and git (1.8 or later) installed.
  Then install the `bundler` RubyGem:
  
  <pre class="terminal">
  $ gem install bundler
  </pre>
  
  Create a directory for your planned deployment.
  `cd` into that directory, which is where all the commands in this topic
  should be run.
  
  1. Create a file named `Gemfile` with the following contents:
  
  	<pre class="terminal">
  	source 'https://rubygems.org'
  
  	ruby "1.9.3"
  
  	gem "bosh_cli_plugin_aws"
  	</pre>
  
  1. Run the `bundle install` command.
  
  ### <a id='domain-prep'></a> Prepare a domain ###
  
  First, pick a DNS domain name for the environment you plan to deploy.
  If you pick *cloud.example.com*, your applications become available as
  *app-name.cloud.example.com*.
  
  Create an AWS Route 53 Hosted Zone for your domain at the
  [Route 53 control panel](https://console.aws.amazon.com/route53).
  Delegate DNS authority for your domain to the addresses in the
  "delegation set" that appears in the control panel.
  
  For example, if your domain is *cloud.example.com*,
  create an NS record in the DNS server for *example.com*
  for each address in the delegation set.
  
  ### <a id='set-env'></a> Set environment variables ###
  
  Next, set environment variables required for deploying to AWS. Create
  a file called `bosh_environment` and add the following, changing the
  value for each line to suit your configuration:
  
  ~~~
  export BOSH_VPC_DOMAIN=example.com
  export BOSH_VPC_SUBDOMAIN=cloud # Pick something more unique than 'cloud' to work around a temporary shortcoming of the tool
  export BOSH_AWS_ACCESS_KEY_ID=AWS_ACCESS_KEY_ID
  export BOSH_AWS_SECRET_ACCESS_KEY=AWS_SECRET_ACCESS_KEY
  export BOSH_AWS_REGION=us-east-1
  export BOSH_VPC_SECONDARY_AZ=us-east-1a # see note below
  export BOSH_VPC_PRIMARY_AZ=us-east-1d   # see note below
  ~~~
  
  **Note:**
  The values shown above correspond to the earlier Route 53 example of
  **cloud.example.com**.
  `BOSH_VPC_DOMAIN` and `BOSH_VPC_SUBDOMAIN` must correspond to the
  DNS domain name you set up when configuring Route 53.
  
  The only supported value for `BOSH_AWS_REGION` is `us-east-1`.
  
  Choose availability zones that are listed as "operating normally" on
  the [AWS Console Status Health Section](https://console.aws.amazon.com/ec2/v2/home?region=us-east-1)
  for your region.
  
  Use `source` to set them for the current shell:
  
  <pre class="terminal">
  $ source bosh_environment
  </pre>
  
  Run the `bosh aws create` command to generate the receipt files that you use
  when deploying software with BOSH (`aws_rds_receipt.yml` and `aws_vpc_receipt.yml`).
  `bosh aws create` also creates a VPC Internet Gateway, VPC subnets,
  three RDS databases, and a NAT VM.
  The NAT VM is for use with Cloud Foundry.
  You can remove it if you plan to deploy software other than Cloud Foundry.
  
  **Note:** RDS database creation may take 20+ minutes to finish.
  
  <pre class="terminal">
  $ bundle exec bosh aws create
  Executing migration CreateKeyPairs
  allocating 1 KeyPair(s)
  Executing migration CreateVpc
  . . .
  details in S3 receipt: aws_rds_receipt and file: aws_rds_receipt.yml
  Executing migration CreateS3
  creating bucket xxxx-bosh-blobstore
  creating bucket xxxx-bosh-artifacts
  </pre>
  
  
  ## <a id="validate"></a> Validating Your IaaS Instance ##
  
  There are at least two aspects of your IaaS instance that you can validate: hardware, and
  functionality (for example, communication between VMs).
  
  There is also the question of how far you can or want to go towards automating validation.
  
  If you are using OpenStack, you can run the [validation procedure](../deploying/openstack/validate_openstack.html) which appears in
  the Cloud Foundry documentation but applies to the present context as well.
  
  If you are using AWS or vSphere, you can consider adapting the parts of the OpenStack
  procedure that make sense for your IaaS.
  
  You can use the appropriate APIs for performing and automating validation:
  
  * [VMware vSphere API](https://www.vmware.com/support/developer/vc-sdk/)
  * [Amazon EC3 API](http://docs.aws.amazon.com/AWSEC2/latest/APIReference/Welcome.html)
  * [OpenStack APIs](http://api.openstack.org/)
  
negative.code:   <tr><td>TCP</td><td>1</td><td>65535</td><td>bosh</td><td>Members of the bosh Security Group.</td></tr>
    <tr><td>UDP</td><td>53</td><td>53</td><td>0.0.0.0/0 (CIDR)</td><td>Inbound DNS requests.</td></tr>
    <tr><td>UDP</td><td>53</td><td>53</td><td>0.0.0.0/0 (CIDR)</td><td>Inbound DNS requests.</td></tr>
    <tr><td>UDP</td><td>68</td><td>68</td><td>0.0.0.0/0 (CIDR)</td><td>BOOTP/DHCP</td></tr>
    <tr><td>TCP</td><td>4222</td><td>4222</td><td>0.0.0.0/0 (CIDR)</td><td>NATS</td></tr>
    <tr><td>TCP</td><td>6868</td><td>6868</td><td>0.0.0.0/0 (CIDR)</td><td>BOSH Agent</td></tr>
    <tr><td>TCP</td><td>25250</td><td>25250</td><td>0.0.0.0/0 (CIDR)</td><td>BOSH Blobstore</td></tr>
  