copilot-cli VS terraforming

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/)

Terraforming

I would also strongly recommend an iterative triage process: don't feel that you need to solve everything all once. It's a huge amount of progress if you can get to a stage where you understand the relationships between services, have enough monitoring to identify failures, and can iteratively move services to more granular IAM policies even if it's all still running in one big account. Simply using a tool like terraformer or terraforming to move the manual configuration into an IaC workflow is an accomplishment, especially since it helps you both make changes more confidently and identify where new changes are still being made. Depending on the politics, that last part might be important: you'll be unpopular if you take away everyone's rights but you'll probably have better luck first nudging people to make them using a sensible flow rather than by hand.

Haven't tried this but if I ever find myself in your situation I'll give it a spin https://github.com/dtan4/terraforming

There are a couple of tools to automate creating terraform configuration and prepopulate state from existing resources, like terraforming, terraformer or cf-terraforming. But it is still cumbersome and laborious and in my experience, it's usually way easier to just recreate everything within terraform from scratch wherever that's possible.

🧪 Terraforming export existing AWS resources to Terraform style (tf, tfstate).