如何组织成云模板？

Question

What is the best practice to organize the Cloud Formation templates?

For example, imagine that I have a security group that is shared between my other projects. (Eg a sg that only accepts connection on port 80 e 22).

Is it a best practice maintain a SG for each project? OR create a single cloud formation template that only manages SG?

Answer 1

Whether to share security groups between projects is a trade off between simplicity and isolation. Having one security group shared between projects allows you to have smaller templates for each project, and to administer them together. Having one per stack allows you to change settings for one project without affecting others.

I prefer to have a small number of security groups shared across projects. I put them in a CloudFormation stack for resources shared across the account. It includes stuff like:

• EC2 security groups (I have one for SSH only access and one for SSH and HTTP/HTTPS)
• a VPC with subnets, routing, gateways
• an S3 bucket, since many AWS resources require resources in S3 for initialization
• IAM roles and policies
• an SNS topic for alarms
• CloudTrail configuration

This stack is depended on by everything else and maintained separately. When I create a project template, the outputs from the global stack are passed in as parameters.

Answer 2

A good resource is the AWS CloudFormation Best Practices [1] guide.

It is best to create nested stacks as described on that page. A security group that is used by multiple projects should exist in a lower-level stack probably along with the VPC, subnets, and routes. Projects can exist in higher-level stacks that build upon the resources described in the lower stacks. To help determine this consider the lifecycle of each resource - can resource X exist without resource Y? If not, then resource X should probably be defined in a lower-level stack.

If you have multiple teams that's a consideration, too. Your security/network team may need access to resources that the DevOps team does not need.

[1] http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html

Answer 3

Specifically regarding the security groups, it is best to isolate them as much as possible.

A good example to showcase the risk of having a shared security group would be:

Let's assume your Dev and Prod environments share a security group. In order to troubleshoot something, you open an insecure port. But this will automatically open your Prod environment too to a huge security risk.

You can organize your templates with nested stacks and external parameter files. Then you have the flexibility easily add/remove resources as well as replicate the stack in multiple environments just by changing the parameter file:

You can find more details in the following blog post and the corresponding Git repository.

https://medium.com/cloud-life/organize-cloudformation-templates-with-external-parameters-file-7998098f1b8d

https://github.com/thilinaba/eks-cloudformation