How to survive the most common pitfalls and take advantage of this service, without too many headaches.<\/h2>\n

\n

\n

\n

Who hasn\u2019t had problems with\u00a0AWS CloudFormation?<\/strong><\/p>\n

Sadly, it is commonly known that AWS CloudFormation is as powerful of a tool as it is frustrating; this short article will highlight the most common pitfalls and the most annoying situations, as well as, obviously,\u00a0ways to avoid them.<\/strong><\/p>\n

We begin our journey by\u00a0describing the service:<\/strong><\/p>\n

\u201cAWS CloudFormation provides you with a common language for describing and provisioning all infrastructure resources in your cloud environment. With CloudFormation you can use a simple text file to model and implement provisioning, in an automated and secure manner, of all resources needed for your applications on all regions and all accounts. Such file will be the only source of your cloud environment.<\/p><\/blockquote>\n

CloudFormation is available at no additional cost; you are only charged the cost of AWS resources needed to run the applications.\u201d<\/p><\/blockquote>\n

One of the main advantages of using AWS CloudFormation is precisely to have\u00a0a template of your own infrastructure, which can be versioned, revised, and easily replicated<\/strong>\u00a0as often as necessary.<\/p>\n

There are problems, however, right from the description of the service.<\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n

<\/div>\n

\n

\n

#1 An (in)complete modeling<\/h3>\n

Although the AWS service presentation page explicitly states that AWS CloudFormation offers complete cloud infrastructure modeling, this, in fact, does not happen.<\/p>\n

At least, not always; in fact,\u00a0there are many configurations and\/or resources that cannot be specified in an AWS CloudFormation template.<\/strong><\/p>\n

To date, for example, it is not possible to:<\/p>\n

\n
• Define the settings related to Cognito UserPool for federation with an external IDP<\/li>\n
• Add a route to a routing table that points to a Transit Gateway<\/li>\n
• Implement SSH key provisioning for EC2 (probably for security reasons)<\/li>\n<\/ul>\n

  Our advice is<\/strong>\u00a0to make sure that all the necessary services and configurations can be truly modeled with the current version.<\/p>\n

  Almost all services are supported, although for some it is necessary to wait a considerable amount of time between the release and official support of AWS CloudFormation.<\/p>\n

  There is also a way to\u00a0extend the capabilities of AWS CloudFormation<\/strong>using custom resources. In fact, they allow the deployment of a Lambda function and execute it as a \u201cCustom Resource\u201d at a given time during the creation of the stack.<\/p>\n

  Here is the official documentation of this feature.<\/a><\/p>\n<\/div>\n<\/div>\n<\/section>\n

  \n

  <\/div>\n

  \n

  \n

  #2 Waiting time<\/h3>\n

  If it is true that once the template is packaged, the execution is faster than the manual one, the template production process is a long process based on trial and error.<\/p>\n

  It is not possible to 100% check a template locally,<\/strong>\u00a0it is only possible to be certain of syntactic correctness without first executing it.<\/p>\n

  Which means that prior to arriving at a working version, you have to go through numerous attempts, each having long execution times.<\/p>\n

  To make life easier we can count on the following features:<\/strong><\/p>\n

  The first is the\u00a0ValidateTemplate<\/a>\u00a0API which does a much more thorough check than just a linter.<\/p>\n

  Another way is the extensive use of\u00a0changesets<\/a>, which allow you to have a preview of the actions that will result in changes to a template.<\/p>\n

  It is also advisable to\u00a0proceed by making small and rapid changes: f<\/strong>irst, it is best to create all the resources that require a low provisioning time, then, only at the end, add the most time-consuming resources to the stack, such as EC2 instances, RDS and the like. This will allow all resources\u2019 waiting and validation times that are probably required by provisioning services to be shorter.<\/p>\n<\/div>\n<\/div>\n<\/section>\n

  \n

  <\/div>\n

  \n

  \n

  #3 Unintelligible errors<\/h3>\n

  Error messages are often meaningless, misleading, useless, or simply wrong.<\/p>\n

  One can only be certain that the stack has failed.\u00a0What has actually failed and why is as useful to know as it is difficult to find out.<\/strong><\/p>\n

  The only way to quickly find the reason for failure is to\u00a0analyze the execution log<\/strong>\u00a0to see exactly on which resource an error is found, and when the provisioning for that resource occurred.<\/p>\n<\/div>\n<\/div>\n<\/section>\n

  \n

  <\/div>\n

  \n

  \n

  #4 Cloudformation drift detection<\/h3>\n

  AWS CloudFormation\u2019s drift detection was loudly requested by many users, and consists of the ability to\u00a0automatically detect if changes were made to the configuration of the stack resources outside CloudFormation<\/strong>\u00a0via the AWS management console, the CLI and the SDK<\/p>\n

  This is a very useful feature, unfortunately, in practice, it gives many false positives. In general, it indicates that it is likely that something has been modified externally and, therefore, that the stack can no longer be updated automatically.\u00a0Unfortunately, it does not indicate that the stack is not actually editable.<\/strong><\/p>\n

  It is best not to consider it as a reliable indication, at least for now.<\/p>\n<\/div>\n<\/div>\n<\/section>\n

  \n

  <\/div>\n

  \n

  \n

  #5 Hard limit to 200 resources per stack<\/h3>\n

  It is not possible to create more than 200 resources in a single stack.<\/p>\n

  Many argue that this is not a problem at all and that it is easily circumvented with common sense. After all, why should you create more than 200 things at a time?<\/p>\n

  The problem lies in what is defined as a \u201cresource\u201d;<\/strong>\u00a0in fact, there are many objects that are normally invisible while creating resources from the web console. When creating a simple infrastructure with a dozen lambdas, an API Gateway with relative policies, and some additional resources,\u00a0the hard limit can be easily reached.<\/strong><\/p>\n

  The microservices should be small, and a complex application should, therefore, consist of multiple CloudFormation stacks\u2026<\/strong>\u00a0however, even having many stacks becomes burdensome from an organizational and management point of view, thus\u00a0it is better to measure the amount of resources to be included in a single template<\/strong>\u00a0well, and to develop a strategy to partition a complex architecture.<\/p>\n<\/div>\n<\/div>\n<\/section>\n

  \n

  <\/div>\n

  \n

  \n

  These are the \u2018top 5\u2019 reasons<\/strong>\u00a0for not using AWS Cloudformation. Well, at least these are five reasons not to use it regardless of the belief that it can solve everything without creating headaches.<\/p>\n

  In conclusion, AWS CloudFormation is powerful but insidious, better to plan ahead when starting a new project in order to avoid the most common mistakes.<\/p>\n

  Tell us your experience,<\/strong><\/a>\u00a0comment with the most insidious error you have detected. The best stories will be featured in a forthcoming article on AWS CloudFormation pitfalls.<\/p>\n<\/div>\n<\/div>\n<\/section>\n","protected":false},"excerpt":{"rendered":"

  How to survive the most common pitfalls and take advantage of this service, without too many headaches. Who hasn\u2019t had […]<\/p>\n","protected":false},"author":8,"featured_media":644,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[242],"tags":[276],"class_list":["post-642","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops-en","tag-aws-cloudformation-en"],"yoast_head":"\n