cfn-python-lint VS awslogs

Now the first 3 options are pretty straight forward. The template itself is a bit more complicated. In my example I used an inline template, I did this for the sake of this blog. But you can also reference an existing object on S3. This way you can use linting tools like cfn-lint on your conformance pack. This will reduce errors during deployment as you can catch them before you commit and push your code.

Automate testing and validation: Before deploying your templates, it's important to test and validate them to ensure that they will work as expected. Use tools like AWS CloudFormation Linter and Azure Resource Manager Template Tester to automate this process.

Honestly I've had good luck writing clean Cloud Formation. It's AWS only. But Nested Stacks can help keep things pretty clean and tools like cfn-lint do a pretty good job of preventing you from going too crazy with spaghetti code. Additionally, as it's all json/yaml, you can parse it to look for common problems your organization wants to enforce. So you can ensure things like specific tags your roles/vpc etc..., or usage of an "approved" set of AMI, requiring an EKS/RDS cluster to be split across availability zones; they're all just a test in your CI pipeline away.

CodeBuild will run a linting check against the CloudFormation Template using cfn-lint and will then run cfn-nag to check for patterns that indicate insecure resources within the CloudFormation template.

A linter for our AWSCloudformation stack called cfn-lint

cfn-lint and cfn_nag or other tools of that nature to check as you write so you don't need to continually try to deploy only to find that you've done something dumb.

https://github.com/aws-cloudformation/cfn-lint as mentioned will do what you've explicitly called-out.

cfn-lint can do basic validation and rule-based linting. Highly recommend using it even if it doesn't solve your problem.

To help validate your AWS CloudFormation templates you can use a tool called cfn-lint.

Using the official CLI (aws logs get-log-events) or https://github.com/jorgebastida/awslogs is pretty close to SSH-ing and grepping.

cw is a native executable targeting your OS, and not needed external dependencies such as pip and npm. Compared to awslogs which is famous helpful tool for CloudWatch Logs1, cw is written in golang and faster.

Its a command line tool but some people I know also use awslogs

Not a full solution, but when I was doing this I really got to love the awslogs utility:

https://github.com/jorgebastida/awslogs

It allows you to stream Cloudwatch logs from the command line, so you can grep them, save them to files, etc... (The web based Cloudwatch interface is terrible.)

Another suggestion is to try to modularize the core business logic in your lambda such that you separate the lambda-centric stuff from the rest of it. Obviously, though, if "the rest of it" is hitting other AWS services, you're going to hit the same testing roadblock.

Or you can try mocking, which may or may not provide much value for you. There's a python library for that, (moto), but it's not 100% up to date wrt AWS services/interfaces, last I had checked. Might be worth a try though.

https://github.com/spulec/moto

Cloudwatch Logs is pretty meh visually, but awslogs can give you a pretty good `tail -f`-like experience, and Insights is pretty good. Cloudwatch Metric Filters give you a 'StatsD'-like experience, in that you can log out a certain message or code and then use its appearance as a metric.

Check out https://github.com/jorgebastida/awslogs , you can define a `--start`, and it also has a `--watch`, and can be piped the `grep` or whatever you want. It's a pretty flexible tool.

📖 awslogs - a simple command-line tool for querying groups, streams, and events from Amazon CloudWatch logs.