AWS Fargate Reviews

I use AWS Fargate mostly for running Docker containers that are web applications, different APIs, or websites.

The best thing about AWS Fargate is that I don't need to worry about the proper provisioning of infrastructure for my task, and it's very fast in terms of scaling my containers; it's much faster than other solutions.

From using AWS Fargate, I see benefits such as scaling speed and no headache about the infrastructure provisioning.

There could be improvements for AWS Fargate regarding cost as it is expensive compared to running on EC2.

AWS Fargate is pretty straightforward for simple tasks and it should remain this way; an additional feature would make it complex and possibly not so stable.

I have been using AWS Fargate for a few years, and sometimes projects migrate from it or we set up new ones.

AWS Fargate is very easy to use; it's easy to spin up everything from the UI wizard and start using it in a few minutes.

The initial setup for AWS Fargate is also straightforward.

I would recommend AWS Fargate to other people.

My advice for people about AWS Fargate is to be aware of the cost of using this solution.

On a scale of one to ten, I rate AWS Fargate a nine.

In my current organization, we deployed all our applications using AWS Fargate.

What I find best about AWS Fargate is that compared to deploying containers on EC2, where we need to check everything manually such as uptime, error logs, and other issues, AWS Fargate manages all these aspects automatically. If a container goes down, it automatically restarts it, and according to our requirements, it handles scaling up and down of all containers. This feature is really amazing.

They need to improve some UI-based interaction.

I have been using AWS Fargate for nearly six to seven months.

I do not face any issues while using AWS Fargate.

I do not face any issues while using AWS Fargate.

I have not connected with the customer support team from Amazon. We manage all errors from our side or find help to resolve the issues. For pro support, AWS charges additional fees, and in our plan, we did not take the AWS support plan, so we manage all errors independently.

Negative

The initial setup for AWS Fargate is busy.

Using AWS Fargate is becoming easier as the platform improves. On a scale of 1-10, I rate AWS Fargate a 7.

We process data mostly by scraping from retail chains on behalf of our customers, and then we homologate and clean that data for our customers to use in analytics displays and decision-making tools. The original architecture was very basic as we used applications such as Pentaho for all ETL workloads running on just fixed VMs from EC2, and then we moved these workloads into AWS Fargate. We didn't use any sophisticated Kubernetes clustering integration, so it was very basic in that case.

Currently, we are deploying workloads because this company has been going through a lot of merging and acquisition strategies. The company I am speaking of was a Mexican company that had 100% of the infrastructure over AWS, but as we integrated to manage the other companies we bought, we had to manage a different set of AWS services, such as Redshift and so on.

In our case, the workloads were not oriented to micro-services with AWS Fargate, just servers. The ETL flows we moved into Fargate using Pentaho weren't designed for micro-service architecture. The front end was very monolithic rather than micro-services oriented, and we had some simple API services, but not a formal micro-service architecture, so we didn't use AWS Fargate for that.

One of the best features of AWS Fargate is that it was useful for us because we didn't require to run container workloads and we didn't need to deal with the management of a Kubernetes cluster directly, and the ability to run those workloads just in a scheduled manner is also a great feature. Additionally, we reduced costs because the distribution over time of our workloads was not the whole day, so we had fixed VMs and some capacity that we weren't using.

AWS Fargate has definitely impacted our organization positively because before that, we couldn't accommodate the workload requirements as flexibly as we can with Fargate. We were able to process all the workload in a shorter time as we could increase the number of containers processing data by schedule. We provided operations because, in some cases, they required special workloads processed outside the schedule, and we offered some automations for them to just go to an internal application and configure their schedule and the amount of horsepower they require to increase in AWS Fargate, and it worked very easily. I understand that this could be accomplished with the auto scaling capabilities of Fargate, but as mentioned, the DevOps were just learning to use AWS Fargate and chose a simpler approach they considered less risky.

Currently, I think that the program is great the way it is, and maybe we use less than 50% of the current features of the platform. For example, we have been evaluating Dask with Python to work with distributed processing, and I don't know if AWS Fargate could be used to build Dask clusters, which would be great because there are many people on our team working with Python workloads. Having something that can manage distributed processing using Dask in a containerized deployment could be valuable. For a company that does not require complexity or managing Kubernetes clusters, AWS Fargate is a great way to go with the use of containers in a simple way, providing the power of containers and scalability without the complexity of going into Kubernetes.

I started to use AWS Fargate about two to three years ago because we had some loads on fixed virtual machines, and we needed to scale based on a schedule.

I would rate AWS support more than perfect because when I started working with the Mexican company, which was 100% AWS, we weren't that big so we didn't qualify as high-value customers, but even so, the AWS team in Mexico gave us special attention that went beyond our service level agreement. Even though we didn't contract support, every two weeks I had a 30-minute meeting with a cloud architect from AWS to help our team use different products of AWS, especially with SageMaker for a forecasting algorithm we were developing.

Positive

The pay-as-you-go pricing model of AWS Fargate was one of the major drivers for us to move there because we reduced costs while increasing the quality of the processing services by about 30%.

My team hasn't used AWS Fargate's capability for automatic scaling in our applications, even when they knew about it; they were very new to using these features.

AWS Fargate's security features weren't the most important criteria or value we got from AWS Fargate.

I would recommend AWS Fargate to others; I would use it myself if I were in a startup or a medium-sized team because of the simplicity it offers without having to manage Kubernetes clusters. As we started using Kubernetes, I found it complex and only justified when you have a larger team that can manage certified cloud architects and cloud engineers. For a small team, I would go blindly using AWS Fargate if I want to take advantage of containers in a scalable way.

I rate AWS Fargate overall as 10 out of 10. I don't have any regrets using it. We have never had any problem using it, even when we used it with very basic knowledge of the cloud.

Positive

I use AWS to manage all AWS services, including load balancing, scalability, availability, monitoring, and support for all services. I use it to buy minutes, buy a house, or buy a movie, and to make an estimation of the price. It also allows me to make comparisons with different AWS services.

All AWS services allow me to manage a wide range of applications and services. For example, deployment and management during deployment and monitoring are handled without any problems on the platform. 

I can set up my processes and manage my issues efficiently with AWS services. It offers me the responsibility to manage and solve different aspects and includes the time to decide on platform solutions, providing solutions in quizzes as the number one in the world. 

It serves as a guide to facilitating applications without limitation. AWS provides a good solution for cloud requests.

There are features that could be added or enhanced. I am still trying to figure out what can be improved in Fargate. 

I use AWS outside of Lambda or Cloud Watch, however, I focus on the most significant aspects of all AWS services.

I find AWS has different functionalities.

AWS causes me to decide to study the platform, considering various factors such as the number of requests.

I use AWS outside of Lambda or Cloud Watch, however, I focus on the most significant aspects of all AWS services.

Neutral

There are features that could be added or enhanced. I am curious if there is anything missing in Fargate.

As a client using Fargate, I may see a return on investment through time savings or reduced infrastructure maintenance costs.

It might also be more cost-effective than other solutions.

We simply looked at AWS.

The overall product rating is ten out of ten.

We are a venture builder company, and if we select AWS for our product. Our design is based on a serverless architecture model. ECS Fargate is the most convenient way in terms of scalability, integration, and cost control.

Thanks to the serverless model and easy integration features, a few customers have been able to onboard easily on our platform. We can handle a high volume of customer load and set up users to automatically raise requests within the platform, which ultimately provides a great experience.

AWS Fargate automatically scales to meet demand, making it ideal for applications with variable workloads. Its integration with other AWS services enhances utility in diverse environments. It's also cost-efficient since we don't need to maintain server management.

Challenges include higher costs for smaller clients, limited control over underlying infrastructure customization, and potential latencies during task startup. There's also the need for comprehensive monitoring to manage costs effectively.

I've used AWS for years.

AWS Fargate has a stability level dependent on configuration. With proper configuration, it can reach nine out of ten.

With AWS Fargate, scalability is high—nine out of ten. Its auto-scaling features, including dynamic and task-based scaling, are very effective.

AWS technical support is proactive, connecting with us as per our support model and their SLA. It's nine out of ten in effectiveness.

Positive

I have used ECS with EC2 and AWS Lambda. We switched because Lambda operates on limited functionalities and doesn't support full-grown applications like ECS does.

The setup was dependent on our project architecture model. If considering only scalability, I rate it nine out of ten. With additional considerations like cost and integration with other AWS services, it is seven out of ten.

We deployed using an automated presence with CI/CD and Terraform for our ECS infrastructure. We use a different CI/CD pipeline for code deployment that builds all applications with Docker images.

We achieved a good return on investment due to a seamless customer experience with the serverless model, auto-scaling, and easy integration features.

AWS Fargate is considered to have more costly resources, particularly for smaller startups or companies with limited cost capacity.

Before using AWS ECS Fargate, identify the business use case to determine whether a serverless solution is needed. Also, consider your scaling mechanism and security best practices to avoid misconfigurations that may impact cost and performance.

I'd rate the solution eight out of ten.

We host our solutions, providing workflow management for companies running on Fargate. We create legal documents for them using expert systems and deliver business intelligence throughout the entire process. 

Additionally, everyone from our company uses Fargate since the deployment process is automated. After configuring the CI/CD process, no one needs to manage, only monitor.

Fargate is awesome for scalability and its serverless nature, managing the scalability automatically when used with ECS. We have workloads with only two instances running, and when needed, we can see services spawning ten new instances while everything continues running. When the workload decreases, the instances are automatically reduced.

Fargate is beneficial for hosting our solutions and providing workflow management, creating legal documents, and delivering business intelligence. All AWS solutions using containers, particularly those for horizontal scaling, are supported by Fargate. Its scalability and serverless nature make it a perfect hosting solution as it manages the scalability automatically when used with ECS, especially with the consistent process for deploying new solutions.

There is a tool named Compose that helps in converting the Docker Compose file into a Kubernetes file. For ECS and Fargate, AWS reads a Dockerfile and helps with conversion. 

However, I am uncertain if it's ready for deployment after conversion. Despite this, manual configurations are very easy, and we manage to get by the process.

I have not faced any blocking challenges in Fargate.

The scalability is seamless, spawning necessary instances automatically with ECS when the workload increases and reducing instances when it decreases.

I have not needed to deal with AWS support directly for Fargate.

Neutral

We also use Azure Container Service, which is similar to AWS ECS. ACS is the same solution with different names due to trademarks, offering a similar experience.

The initial setup is straightforward. We have a well-established process of deploying new solutions using OpenAPI specifications and Elastic Container Registry, making it easy for the infrastructure team.

We have a well-defined deployment process where the backend team delivers a configurable image in the Elastic Container Registry (ECR), and the infrastructure team deploys these images.

Fargate is billed based on the amount of processing and storage required for the solution to run, and the pricing is very fair.

We also evaluated Azure Container Service, which offers a similar experience.

I rate Fargate ten out of ten. 

The most significant advantage is the unified configuration for all containers deployed by ECS, allowing seamless integration with services like OpenAI or Google Gemini and secure handling of access keys and secrets.

AWS Fargate is a serverless compute engine for containers that works with Elastic Container Service (ECS) and Elastic Kubernetes Service (EKS). We use it for running containers without managing the server or cluster of Amazon Web Services EC2 instances. It allows us to focus on applications instead of managing infrastructure.

Fargate allows horizontal or vertical auto-scaling which affects businesses by enabling easy scaling up and down of applications in response to changes in demand. This capability becomes particularly beneficial when there is increased traffic, as it utilizes auto-scaling and allows setting maximum and minimum limits for instances, improving efficiency. Additionally, it offers cost savings through its serverless model by optimizing AWS serverless costs, especially when using Lambda functions.

Fargate is better if you need more flexibility or are on a budget. It allows for focusing on applications instead of managing infrastructure. We can also store images inside ECS or create a container using that image. It lets us integrate with load balancing, unifying storage volumes to improve instances' launch time, making it highly beneficial for various projects.

I would like to see enhanced faster application scaling and better integration with the elastic file system to unify storage volumes and improve the launch time of instances. 

It requires enhancements to orchestrate containers more effectively and handle resource limits like CPU and memory constraints, particularly when load balancing, as it affects the auto-scaling configurations.

I have been working with the AWS platform, including Fargate, for one year while exploring new features. I am also blogging about it and creating short videos.

Fargate is stable because it uses Lambda functions that can be triggered as needed, which adds to its reliability.

Fargate is scalable. It works with auto-scaling, allowing applications to scale up and down based on demand changes, making it versatile for various business operations.

I have interacted with technical support through emails and ticket management systems like Jira. That said, there is room for improvement. I would appreciate better direct contact with clients regarding pre-requisites and specific uses of resources.

Neutral

I am also engaged with Azure Compute Services on a project involving a CI/CD pipeline as a DevOps engineer.

The initial setup involved defining CPU, memory, volumes, and images required for Fargate. It requires familiarity with CPU architecture, subnets, DNS, contained images, and resource definitions.

Currently, three to four people in my team are working as cloud engineers with me, and within the larger organization, there are about 11 to 20 employees working on it.

I have worked with Azure Compute Services for managing an e-commerce website project with front-end, back-end, and database management using CI/CD pipelines and microservices.

I recommend using AWS Fargate as it offers serverless computing capabilities with integration into load balancing, making it a good and beneficial solution.

I'd rate the solution six out of ten.

We use Fargate in order to scale data processing for retail data. The company I am working for processes data for retail customers like consumer packaged goods producers that sell through Walmart,  and other retail chains. 

The company I work for processes sales, inventory, and order data from those retail chains. We use Fargate to scale the data processing for those kinds of files.

For microservices, we mostly use a combination of Fargate within Lambda.

Previously, we had this kind of processing in Docker containers deployed on EC2 instances. To scale that, the operation was pretty hard. So, we made a change in the architecture, and instead of deploying those containers on EC2 instances, we deployed them on Fargate. So, the application scales pretty easily. 

The application autoscaling within Fargate simplifies the application scaling process. 

The application is pretty simple, so we're not using any complex or added integration features. We're just using it to deploy the containers. We trigger the processes by directly calling the services already exposed by the container. The only service we integrated with Fargate was Amazon EventBridge to ensure we have both on-demand and scheduled capacities to handle peak hours. That's pretty much it. We do not integrate it with SQS or any other queuing system.

The most valuable feature of Fargate is that it's self-managed. You don't have to configure your own clusters or deploy any Kubernetes clusters. This simplifies the initial deployment and scaling process. 

For example, using Spot Instances with AWS after configuring a Kubernetes cluster might make sense. But Fargate's approach is pretty straightforward. My team, including certified cloud engineers, can deploy containers using ECR and Fargate without any issues.

If there are any options to manage containers, that would be good. That relates more to the cost point.

For example, over the next three months, I'll be making a comparison between solutions like CAST AI and other software-as-a-service platforms that offer Kubernetes management with an emphasis on cost reduction. 

Instead of deploying in private, you can use CAST AI with any Kubernetes provider and any cloud, for example. This may solve scaling problems. So, if it allows you to reduce costs by four percent or more of your processing expenses, that AI-assisted Kubernetes-managed solution is something to consider.

After saving on scaling using containers with a self-managed cloud cluster, I think the next step is to use an additional approach. Cloud providers may help you reduce some costs, but a specialized service focused on optimizing your Kubernetes resources in relation to your container usage could be beneficial.

For example, this kind of solution allows you to not only auto-select the instances for cluster nodes based on the current processing load but also define containers that can be spot instances in terms of fault tolerance.

In those cases, the solution will deploy your containers on spot instances, distribute your spot-tolerant processes across the cluster, and potentially achieve additional cost reductions. 

You cannot do that with something like Fargate. That's the next step for a company that needs to scale its processes to another level. Maybe that's worth considering.

I have been using it for two years. 

We currently do not have any paid support from AWS as adding customer support would increase our monthly costs by about 10%. 

However, due to the strategic alliance with AWS, we enjoy the support our account managers provide. I don't need support for troubleshooting or operational issues, as we haven’t had any. 

But especially when starting to use a new service, we have a cloud engineer or cloud architect available from our account manager to assist us.

So, considering that, I would rate the customer care from AWS for Fargate highly. Although my account is very small, with just eight servers, I'm still treated well as a customer.

Positive

I've used EC2, S3, Lambda, Fargate, API Gateway, Step Functions, etc.

For security, particularly with container security, we use Azure Patch Manager and AWS Inspector to inspect all our containers, ensure that all necessary patches are applied, and manage any risks associated with the libraries we are using. But I don’t see that as a security feature of Fargate; rather, it is security that stems from the AWS ecosystem.

We perform a scalable monthly review of all the containers and apply the patches that are recommended by those automated tools.

Because Inspector does not automatically apply the patches, we have to do it manually over the ECR containers.

Initially, we noticed some impact on our billing, but it wasn't significant in our overall infrastructure costs. We spend more on fixed EC2 instances and on databases, as we have a large database cluster for our big data applications.

Our main focus isn't cost; it's about being agile and providing a serverless, scalable solution for data processes like ETL—extraction, transformation, and loading. Thus, cost was not our primary concern.

The maturity you have in deploying serverless capabilities is crucial. For example, if your process takes less than 15 minutes, then you should consider AWS Lambda or other cloud function services. If your process may take longer than that, then Fargate is the way to go, especially when you are starting to deploy. 

Your first goal is to provide scalability to your business, particularly to your commercial areas. Once you achieve scalability, you can then focus on cost efficiency. 

If cost becomes a significant factor as you scale up, you might consider managing a Kubernetes cluster with an auto-scaling service to simplify Kubernetes management. When you need that level of scalability, cloud services like Fargate or even Lambda may not provide the cost efficiency you require. That's my current perspective on this.

Overall, I would rate the solution a ten out of ten. 

AWS Fargate is a fully managed service provided by Amazon. When using any application, we have services that we need to manage. Instead of managing it ourselves, AWS takes care of it. We just need to create a cluster, do normal patching, and everything is managed by AWS.

AWS Fargate is a fully managed service, and it's very easy to use compared to other services like Elastic Beanstalk Service (EBS). AWS provides the necessary resources so we don't have to do much ourselves; we just need to create a cluster. This makes patching and management straightforward. 

AWS also offers great integration with other AWS services, like using Aurora Serverless for database management, which eliminates the need to manage a database server. 

Overall, if we, as enterprise customers, are using Fargate for our applications, we should not face any problems.

As I have not worked with Fargate extensively, I do not have any specific improvements.

I have knowledge of Fargate but have not worked with it extensively. I mention having a new project in the pipeline where I plan to use Fargate.

Currently, my organization is using Elastic Beanstalk Service (EBS), however, we plan to switch to AWS Fargate in a new project.

AWS Fargate is costly compared to AWS EBS. However, it is worth the money, especially for enterprise customers.

AWS Fargate is easily manageable. We just need to create a cluster and focus on our infrastructure. Customers do not need to take downtime since everything is managed by AWS with no downtime. 

Overall, I would rate it as nine out of ten.