Homepage
Serverless Rules are a compilation of rules to validate infrastructure-as-code template against recommended practices. This currently provides a module for cfn-lint and a plugin for tflint.
You can use those rules to get quick feedback on recommended practices while building a serverless application, as part of an automated code review process, or as guardrails before deploying to production.
Public preview
This project is currently in public preview to get feedback from the serverless community. APIs, tools, and rules might change between the beginning of public preview and version 1.
Current modules and plugins¶
- The
cfn-lint
module supports checking CloudFormation and Serverless Application Model (SAM) templates. It also supports templates defined with the AWS Cloud Development Kit (CDK) and the Serverless Framework by synthesizing to CloudFormation. - The
tflint
plugin supports checking Terraform configuration files.
If you would like native support for other frameworks, please consider adding a đź‘Ť reaction to the corresponding comment in this GitHub issue.
Usage¶
To learn how to use Serverless Rules, see the detailed usage guide for each plugin:
Frequently asked questions¶
Can I ignore some of the rules in this project?¶
Serverless Rules is a set of recommended practices.
We recommend you to keep Error-level rules enabled. Non-error rules, for example Lambda Tracing, contain detailed scenarios on when it’s safe to ignore them.
When needed, you can ignore any specific rule that doesn’t match your environment.
How is this different from cfn-lint
or tflint-ruleset-aws
?¶
cfn-lint
and tflint
main goals are to find possible errors in templates and configuration files before you try to deploy resources to AWS. By comparison, Serverless Rules goes one step further by providing prescriptive guidance based on the AWS Well-Architected pillars.
For example, you can define AWS Lambda functions without tracing enabled, which is valid for both CloudFormation and Terraform. This project adds a rule on Lambda tracing as a recommended practice for Operational Excellence.
Why use cfn-lint
instead of cfn-guard
or cfn_nag
?¶
cfn-guard
provides developers with a simplified language to define polices and validate JSON- or YAML- formatted documents. You can use that tool to create your own rules that match your compliance needs or internal recommended practices. cfn_nag
provides a set of default rules with a strong focus on security. You can extend it in ruby to create custom rules.
By comparison, cfn-lint
provides a set of default rules focused on validating templates against the CloudFormation resource specification and you can create your own rule with Python modules.
For Serverless Rules, using a programming language like Python or Ruby gives more flexibility when defining complex rules integrating multiple resources, such as checking if a Lambda function has a log group with retention configured.