I too want simplicity, but Fargate still requires a load balancer in most cases. Further, you’ll probably need a database (we’ll assume something like Aurora so you needn’t think about sharding or scale so much) and S3 buckets at some point, and security obligates you to create good IAM roles and policies. You’ll need secret storage and probably third-party services to configure. Things are starting to get complex and you’re going to want to be able to know that you can recreate all of this stuff if your app goes down or if you simply want to stand up other environments and keep them in sync with prod as your infra changes, so you’re going to want some infra-as-code solution (Terraform or CloudFormation or Pulumi etc). Further, you’ll probably want to do some async work at some point, and you can’t just fork an async task from your Fargate container (because the load balancer isn’t aware of these async tasks and will happily kill the container in which the async task is running because the load balancer only cares that the connections have drained) so now you need something like async containers, lambdas, AWS stepfunctions, AWS Batch, etc.

While serverless can address a lot of this stuff (the load balancer, DNS, cert management, etc configuration could be much easier or builtin to Fargate services), some of it you can’t just wave away (IAM policies, third party servic configuration, database configuration and management, etc). You need some of this complexity and you need something to help you manage it, namely infra-as-code.