The only parameter that is required for this template is the VPC ID to target. We specifically target a VPC to turn on flow-logging for because it gives us the most bang for buck. While you can enable flow-logs for subnets and Elastic Network Interfaces (ENIs) individually, if you enable them on a VPC, you get flow-logs for all the networking resources contained in that VPC, which includes subnets and ENIs.

In the Resources section, we start by explicitly defining the log group to hold the flow-logs. If you don't create the log group yourself (and specify it in your flow-log resource configuration), a log group will be created for you. This means that you will still be able to use flow-logs, but the log group won't be managed by CloudFormation and will have to be maintained (for example, deleted) manually. We have also set a deletion policy of delete for our log group. This means that it will be deleted if the CloudFormation stack is deleted.

Next, we define the IAM role to use. Via the AssumeRolePropertyDocument value, we give the AWS flow-logs service permission to assume this role. Without this access, the flow-logs service cannot access the account. In the Policies property, we give the role permission to create and update log groups and streams.

Finally, now that we have created the dependent resources, we define the flow-log resource itself. You don't need to define the resources in order of dependencies, but it is usually easier to read if you do. In the resource, we also define a DependsOn relationship to the log group that we defined earlier so that the log group is ready to receive the flow-logs when it is created.

The final step is to launch the template that you have created, passing the VPC ID as a parameter. As this template creates an IAM role to allow the VPC service to send logs to CloudWatch Logs, the command to create the stack must be given the CAPABILITY_IAM flag in order to signify that you are aware of the potential impact of launching this template.