Search code examples
amazon-web-servicesamazon-ecsaws-fargate

Host Multiple applications in one container in AWS ECS(Fargate)

We have a product which is set of following .Net5 applications:

  1. Front-end web app for customers
  2. Admin Tools - for administrative activities
  3. Web API
  4. Worker Service - for background jobs

Right now we are using two AWS EC2 VMs(load balanced with AWS Load balancer) to host these application on IIS. Also we have 5 different vendors(will be more in future). So We deployed these 4 applications for each vendor i.e. we hosted 20 applications on IIS on each VM.

Now there is a requirement to move to server less Container service like AWS Fargate. Can anyone expert here suggest to proceed with any of following way:

  1. 20 container images, 20 Task definitions and 20 Services in the cluster
  2. 20 container images, 5 Task definitions( each with 5 container definitions) and 5 Services in the cluster
  3. 5 container images(4 applications in each container- if possible), 5 Task definitions and 5 Services in the cluster

I am not an expert in container services, So it is possible that the 3 ways I mentioned above are totally imaginary, in that case please suggest the appropriate way. My end goal is to find out the possibility of hosting these application in more scalable(auto-scaling) and cost effective way in comparison to EC2 VMs.

Thanks

Solution

  • Consider that a Task is an atomic unit of management and scaling. It's comprised of 1 (typically) or more containers (when needed). If your application has clear boundaries, it needs to scale separately from other modules and it has its own life cycle that is different from the other modules/applications ... then it needs to be its own task. In that task you may need to have more than one containers if that is your atomic entity. For example in a scenario where you have a front end, an appserver, an index service, a backend service, etc…. Each of these modules need to be their own task. Each of these tasks could be one or more containers depending on how your module is built.

    A Service it’s just a construct that allows you to tell ECS “take that task and always run x instances of it”. That x could be a fixed number or you can tell ECS to scale the service in and out (in terms of number of tasks) based on the workload.

    Based on what you say above it looks like your application is comprised of 4 modules (website, tools, API and worker). That means you probably are looking at 4 task definitions. Given I understand your application is not multi tenant you probably need to have dedicated services for specific users (“vendors” in your case?).

    So assuming you have 5 vendors you are probably going to have 5 x ECS services for the web module, 5 x ECS services for the tools module, 5 x ECS services for the API module and 5 x ECS services for the worker module. Assuming you can customize each module with environment variables for the different vendors, you are probably good with only 4 task definitions that get personalized at run-time when you start them. If this is not possible, than you have to have a task definition per module AND per vendor.

    This is at the high level how you should look at it. If you are new to ECS perhaps a better approach would be to use either the Docker/ECS integration we built with Docker or the Copilot CLI that simplifies a lot of the concepts described above.

    HTH