Deploying a CloudFormation stack

Now that you have defined a CloudFormation template, you can deploy the resources in your template in the form of a CloudFormation stack.

You can deploy a stack using the AWS console by choosing Services | CloudFormation, which will open the CloudFormation dashboard. Before you continue, ensure that you have assumed the admin role in your account and have also selected US East N. Virginia (us-east-1) as the region:

If you click on the Create new stack button, you will be prompted to select a template, where you can either select a sample template, upload a template, or specify an S3 template URL. Because we defined our stack in a file called stack.yml, select the option to upload a template and click the Choose file button to select the file on your computer:

After uploading the template, the CloudFormation service will parse the template and ask you to specify a name for the stack and also provide values for any parameters in the stack:

In the preceding screenshot, the value t2.micro is set by default for the EC2InstanceType parameter, given you set this as a default value in your template. Because you specified AWS::EC2::Subnet::Id as the type of the SubnetId parameter, the Create stack wizard automatically finds all of the subnets in your account and region and presents them in a dropdown. Here, I have selected the subnet from the default VPC that is created with every new AWS account that is located in the us-east-1a availability zone. 

You can determine which availability zone each of the subnets belongs to by either selecting Services | VPC | Subnets in the AWS console, or by running the aws ec2 describe-subnets AWS CLI command with a JMESPath query:

> aws ec2 describe-subnets --query 'Subnets[].[SubnetId,AvailabilityZone,CidrBlock]' \
    --output table
-----------------------------------------------------
| DescribeSubnets                                   |
+-----------------+--------------+------------------+
| subnet-a5d3ecee | us-east-1a   | 172.31.16.0/20   |
| subnet-c2abdded | us-east-1d   | 172.31.80.0/20   |
| subnet-aae11aa5 | us-east-1f   | 172.31.48.0/20   |
| subnet-fd3a43c2 | us-east-1e   | 172.31.64.0/20   |
| subnet-324e246f | us-east-1b   | 172.31.32.0/20   |
| subnet-d281a2b6 | us-east-1c   | 172.31.0.0/20    |
+-----------------+--------------+------------------+

At this point, you can click Next and then Create in the Create stack wizard to commence deployment of your new stack. In the CloudFormation dashboard, you will see that a new stack called cloud9-management is created, which initially has a status of CREATE_IN_PROGRESS. An interesting behavior associated with deploying Cloud9 environments via CloudFormation is that a separate child CloudFormation stack is automatically created via the AWS::Cloud9::Environment resource—this is somewhat unusual as for every other type of CloudFormation resource you will create, you will not see this type of behavior. Once deployment is complete, the status of the stack will change to CREATE_COMPLETE:

In the preceding screenshot, you can click on the Events tab to display events associated with stack deployment. This will show you the progress of each resource as it is deployed, and will indicate if there are any failures.

Now that you have successfully deployed your first CloudFormation stack, you should have a brand new Cloud9 IDE environment available for you to use. If you select Services | Cloud9 from the AWS console menu bar, you should see a single environment called cloud9-management-station:

If you click on the Open IDE button, this will open a new IDE session which includes an integrated terminal with AWS CLI installed. Note that the session has all of the permissions associated with the user that created the Cloud9 environment—in this case, this is the assumed admin role, hence you can perform any administrative task from the terminal. The Cloud9 environment is also running within your VPC, so if you deploy other resources such as EC2 instances, you can manage them locally from this environment, even if your other resources are deployed in private subnets without internet connectivity: