copilot-cli VS cfn-python-lint

AWS Copilot CLI is an open source command line interface for running containers on AWS App Runner, Amazon Elastic Container Service (ECS), and AWS Fargate.

sudo curl -Lo /usr/local/bin/copilot https://github.com/aws/copilot-cli/releases/latest/download/copilot-linux && sudo chmod +x /usr/local/bin/copilot

Check out AWS Copilot CLI: https://aws.github.io/copilot-cli/

This is by far the best way to deploy compute into AWS in containerized workloads.

The abstraction you want is Jobs: ttps://aws.github.io/copilot-cli/docs/concepts/jobs/

Building this any other way on AWS would require provisioning multiple artifacts. The Copilot Jobs abstraction basically encapsulates the provisioning of those artifacts into one repeatable pattern.

AWS Copilot CLI is a tool that lets you deploy production-ready, scalable services on AWS from a Dockerfile in one command.

and here is the copilot page if you are interested https://aws.github.io/copilot-cli/

For larger high availability required things, AWS ECS with RDS, ElastiCache, CloudFront, S3, etc.. Really like Copilot for deployment/env/secret/sidecar management (probably needs a rename now): https://aws.github.io/copilot-cli/

We are spending about 60% less. Workload has actually lessened since AWS is so much more stable. Getting to a similar DX as Heroku was quite the lift, but once it's done, it's done. These days we generally only have outages when we screw something up ourselves. I recommend https://github.com/aws/copilot-cli for starting out on ECS.

I'd recommend checking out AWS Copilot (https://aws.github.io/copilot-cli/)

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.