aws-ecs

We have Docker-based ECS services where once the process is up, it needs to synchronize application state before it is ready to start serving requests. This can take some time (a number of seconds after the process starts). When using ECS Services, changing the task definition version triggers a rolling replacement of the tasks (good), but it does it too quickly. Once a task reaches a RUNNING state, the next task is killed. But RUNNING just means the process is started, it doesn't mean it's met all its own internal requirements to be ready to do work... in this case, not ready to serve

I was trying to get answers on my question here and here , but I understood that I need to know specifically Fargate implementation of vCPUs. So my question is: If I allocate 4 vCPUs to my task does that mean that my single-threaded app running on a container in this task will be able to fully use all this vCPUs as they are essentially only a portion of time of the processor's core that I can use? Let's say, I assigned 4vCPUs to my task, but on a technical level I assigned 4vCPUs to a physical core that can freely process one thread (or even more with hyperthreading). Is my logic correct for

I use a computing environment of 0-256 m3.medium on demand instances. My Job definition requires 1 CPU and 3 GB of Ram, which m3.medium has. What are possible reasons why AWS Batch Jobs are stuck in state RUNNABLE ? AWS says: A job that resides in the queue, has no outstanding dependencies, and is therefore ready to be scheduled to a host. Jobs in this state are started as soon as sufficient resources are available in one of the compute environments that are mapped to the job’s queue. However, jobs can remain in this state indefinitely when sufficient resources are unavailable. but that does