anchor.diff:    <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>TCP</td><td>68</td><td>68</td><td>0.0.0.0/0 (CIDR)</td><td>BOOTP/DHCP</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>
  
positive.code: 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.
  
  ### <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.
  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).
  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.
  
  ### <a id='aws'></a> AWS and OpenStack  ###
  
  Set up two security groups, `ssh` and `bosh`, as specified in the following tables.
  
  #### <a id='ssh'></a> ssh Security Group  ####
  
  
negative.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>
  
  ### <a id='vsphere'></a> vSphere ###
  
  vSphere does not support security groups.
  Instead, a common practice is to configure multiple networks.
  Use one network for BOSH and one or more separate networks for the software
  that you deploy with BOSH.
  
  ## <a id="network"></a> Step 3: (AWS only) Complete your IaaS Setup  ##
  
  This section explains how to install and use the BOSH CLI commands for setting up AWS infrastructure.
  
  ### <a id='plugin'></a> Install the AWS plugin to the BOSH CLI ###
  
  1. Ensure that you have installed Ruby 1.9.x, which is a prerequisite for installing the BOSH CLI. (Ruby 2.x is not supported.)
  1. Create a directory for your planned deployment and navigate to it.
  1. Install the BOSH CLI and its MicroBOSH plugin:
  
      `gem install bosh_cli bosh_cli_plugin_micro bosh_cli_plugin_aws`
  
      **Note**:  To view the BOSH CLI help, run:
  
      `bosh help --all`
  
  1. **(Optional)** If you are using the rbenv Ruby environment manager, refresh its list of gems:
  
      `rbenv rehash`
  
  
  ### <a id='domain-prep'></a> Prepare a domain ###
  
  1. Choose a DNS domain name for your deployment.
  If you pick **cloud.example.com**, services that you later deploy using BOSH become
  available as **service-name.cloud.example.com**.
  
  1. Use the [Route 53 control panel](https://console.aws.amazon.com/route53) to
  create an AWS Route 53 Hosted Zone for your domain.
  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 ###
  
  Set environment variables required for deploying to AWS.
  
  1. 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 domain name
      you set up when configuring Route 53.
      The only supported value for `BOSH_AWS_REGION` is `us-east-1`.
  
  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.
  
  1. Set the new environment variables for the current shell:
  
      `source bosh_environment`
  
  1. Create your AWS infrastructure:
  
      <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>
  
  The `bosh aws create` command generates the receipt files `aws_rds_receipt.yml`
  and `aws_vpc_receipt.yml`, a VPC Internet Gateway, VPC subnets, three RDS
  databases, and a NAT VM.
  
  **Note**: RDS database creation may take longer than twenty minutes to finish.
  
  You can remove the NAT VM if you do not plan to deploy Cloud Foundry.
  
  ## <a id="validate"></a> Step 4: Validate your IaaS Instance ##
  
  You can validate at least two aspects of your IaaS instance: hardware and
  functionality (for example, communication between VMs).
  
  For OpenStack, consider running the [validation procedure]
  (../deploying/openstack/validate_openstack.html) described in the Cloud
  Foundry documentation.
  
  For AWS or vSphere, 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/)
  
  