Container orchestration platforms exist to make container use a whole lot easier. Running any application on a container will make it portable. However, when the time comes to scale or add services, you’re going to run into problems without a platform to manage and stitch it all together, and it will quickly become too difficult to handle.

When it comes to AWS, there are three main options – each with pros and cons. The choice you make will ultimately come down to your business needs and ongoing maintenance capabilities.

To help you decide, here are the pros and cons of each managed service:

ECS: the native choice

Elastic Container Service (ECS) was AWS’ first offering for managed container orchestration. For many, this is the easiest option, and it certainly has the least amount of components to get familiar with.

As a heavily integrated orchestration platform, it’s a great choice for anyone happy with the AWS ecosystem and who wants the benefits and familiarity of AWS services and support. It’s also cost-effective, as you don’t have to pay for the control plane and can use the built-in AWS code tools as well as enjoy fine-grained identity and access management (IAM) for Services and Tasks.

When your business wants to deploy an application onto ECS, the operations can be defined for each application individually, dictating for example which containers have access to S3 and which don’t.

When is ECS not the best choice?

As a proprietary AWS solution, cloning your applications to a different cloud vendor won’t be a simple task if you go with ECS. In addition, the orchestration platform has limited support for routing, currently supporting only path-based routing, and not host-based or header-based routing. Another factor to consider is that ECS is slower to respond to state changes than the others in the Big Three, so if you’re looking to a highly performant solution – it’s not going to be the right fit.

Who is ECS good for?

If you are looking for simplicity with good value for your investment, and these factors aren’t deal breakers for you, ECS is a great beginners option, and perfect for any business without experienced DevOps to operate their orchestration. I recommend it if you have a limited amount of services (<10) to deploy on the cloud. Without the bells and whistles which make the solution more complex, you might find ECS to be preferable for your company.

EKS: the Kubernetes choice

EKS is AWS’ offering of Kubernetes, the open-source container orchestration platform that has become popular. As EKS is a managed service by Amazon, this eliminates a lot of the hassle that comes with the initial installation and maintenance of Kubernetes going forward. Amazon EKS runs upstream Kubernetes. It’s not a different flavor, so you get the same functionality as if you created your own Kubernetes cluster, which makes the platform easy to clone if you want to run multi-cloud in the future.

As an open-source platform, EKS has the benefit of thousands of developers that are working on its technology constantly, actively contributing to functionality and new features. Unique selling points worth mentioning include namespace isolation, where you can split your cluster with logical boundaries, for example limiting developers to using a specific amount of resources of the cluster. Moreover, it provides the ability to run cron jobs and stateful workloads.

EKS offers a much faster deployment time than ECS, with results in a few seconds, allowing you to deploy several times a day and feedback fast for changes. Everything can be declared using the kubectl command line tool, and there are plenty of integrations. These include service-to-service communications and native scaling of both Pods and Worker Nodes, enabling your developers to focus on their business logic and deliver new features. I’d also highlight Helm, a package manager that provides the ability to bundle together several applications or business logic for deploying and updating a whole unit in one piece.

What should you watch out for with EKS?

It’s important to realize that Kubernetes isn’t the right choice for everyone. Your business will have the added cost of the control plane each month, and there is a much steeper learning curve than you would experience with ECS, and currently fewer integrations with AWS overall. Unlike ECS, the IAM to AWS is not built-in, so your developers or DevOps will need to install additional tools for this functionality.

The other serious limitation is pod density, a unique issue to EKS. Every container (pod) is bound to a certain private IP in your VPC, and if your application utilizes many replicas or microservices your cluster will scale but not due to the fact that your instance ran out of CPU or memory, rather that your instance ran out of IPs to allocate to the worker nodes.

This results in additional costs, and can be limiting as your developers will have limited IPs for smaller size instances used by the worker nodes. If your microservices scale quickly and by high volume, this is an important factor to consider.

Who is EKS right for?

The critical question here is, once the installation is complete, who is going to be responsible for taking ownership of it? Managing and maintaining EKS needs dedicated specialists, and if you don’t have the manpower, another option might be a better fit.

Fargate: The container on-demand choice

With Fargate, it’s a whole new game. You don’t have to create your own control plane or instances, there are no clusters needed, no need for infrastructure upgrades or maintenance. Instead, you specify how many resources you want to use, and pay as you go. This gives you the opportunity to focus on the design and build of your applications, rather than spending time worrying about the underlying infrastructure.

The best thing about Fargate is rapid horizontal scaling, the ability to scale on demand. Developers simply create containers and deploy to the Fargate service. Easy set-up, no learning curve.

Fargate is not suitable for stateful workloads, requiring your application to be stateless, which is one of the main reasons why some companies wouldn’t choose Fargate. Additionally, although the ability to scale to tens of thousands in no time is exciting, in reality not many businesses need this functionality, making the cost harder to justify.

Who would be a good fit for Fargate?

Only you can know if your budget suits choosing Fargate rather than investing in a DevOps team, and if the benefits of scaling on demand are worth the higher cost. This is most likely if you have just a handful of services.

For many, Fargate works well as a hybrid solution, allowing your applications to scale where necessary for on-demand tasks rather than using it 24/7. Another consideration is to isolate those workloads with sharp surges in resource usage and run them on Fargate to minimize the impact on the performance of your ECS or EKS clusters.

In closing, EKS is an increasingly popular choice for container orchestration, but that doesn’t mean it’s the right solution for your business needs. Remember, the more features and functionality there are, the more complexity it introduces, and the more resources you will need to manage your ecosystem. It’s in your best interest to make sure that you actually need the bells and whistles before choosing the shiny new thing.

Read more: AWS, Azure or Google: Do the differences between cloud providers really matter?

Interested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.