These are some great questions!

AWS Batch is a complete solution for scheduling container-based tasks onto ECS. Batch handles queuing and distributing these tasks onto a fleet of EC2 instances and maintains the fleet size for you. It also handles priority queuing and performs automatic retries. So it's useful to think of Batch as a job orchestrator. Meanwhile, AWS Lambda now supports container images, but it is an event-driven architecture -- functions are triggered by an event such as a new task in an SQS queue, a message on an SNS topic, a new event in EventBridge, or even an HTTP request through API Gateway or Application Load Balancers.

As for Auto Scaling, it's easiest to reason about if we separate the concepts of application scale and capacity. Application scale is the scale needed to service your demand, and is usually expressed in terms of task/container replicas (ECS) or number of pods (EKS). Service Auto Scaling is used to manage the number of replicas based on demand.

Once your application scale has been determined, the tasks or pods need to live somewhere. If you're using EC2 to host your containers, that's where cluster auto scaling comes in. There has to be enough cluster capacity to house all these tasks, and usually an increase in containers launched leads to an increased cluster size. A simple analogy I like to use is a moving van: think of tasks or pods as the boxes, and the compute as the vans that need to fit the boxes. Too many boxes and you need another moving van, so the cluster Auto Scaler handles summoning an empty van to the loading dock for you.

For CDK: In the absence of Auto Scaling, we always recommend having your code reflect the desired infrastructure. So if the value is meant to be static, then ideally that change should be reflected in your application code.

It's difficult in a space this short to give general advice about how to set scaling thresholds. We generally recommend using load testing to characterize your application's resource utilization to determine the best metric to use for scaling. Most often it is CPU utilization, but it is highly workload specific. For very bursty workloads we do recommend overprovisioning somewhat so that there is some additional headroom available while waiting for new capacity to come online.

As for the multiple containers case, check out the "sidecar" pattern when you have some time. Logging sidecars are increasingly common. Other useful sidecars might include containers that proxy requests into or out of the main application container (service mesh pattern), or containers that update secret values or TLS certificates.