Amazon Elastic Container Service Reviews

ECS is flexible and easy to use. AWS, itself manages the work nodes, scaling, and monitoring. It includes handling alerts for infrastructure and clusters.

I rate the platform's stability an eight out of ten. It easily dies. 

I rate Amazon Elastic Container Service's scalability an eight out of ten.

The technical support services are good. I contact them for troubleshooting purposes.

Positive

The initial setup is easy compared to EKS.

I rate Amazon Elastic Container Service an eight out of ten. If you are beginning to use cloud services, ECS is the best and easy-to-use product you can go for.

We host our production application on EC2. We host the application and take regular backups to create mirrors for our customers. We also use the solution’s firewall to save us against any threat.

The most valuable feature of the tool is its ease of usage. We spin off new servers and host our applications on those servers. The best thing I like about the product is hosting. It is super easy. Features for creating a server and hosting it is all builtin within the solution. I don't have to build a backup service. It is already available. I don't have to build a database as well. It is already built. I can just use any existing DB and then connect it directly to the DB instances and use it. Everything is ready to use.

We’ve been hosting our production application on the product. The most important criterion for us is downtime. In seven years, we have not faced a single second of downtime. It is the greatest thing. We have had zero downtime in the last seven years. Nothing can be better than that.

Billing is extremely complex. The whole concept of billing is so complicated that we never understand it. There is an upfront cost, and there is a network cost. It is impossible for me to calculate the cost, understand it, and inform the client about it.

We are never sure of our end cost. Sometimes the cost blows up and ends up being five times more than what we calculated. There is no way to understand the cost. I want the solution to have a better billing system and dashboard to understand the billing.

The solution could be more intuitive. If I'm using a service and my backup has gone down, there should be a notification or suggestion to help me understand what I can do. It should explain how I could have avoided the issue. EC2 is huge, and we'll never know all its services. The tool should have a way of suggesting to me what I can do better.

It can be through notifications, tutorials or through their customer service team. The product could provide CI/CD services in the future.

I have been using the product for seven years.

The tool’s stability is perfect.

The tool is scalable. It can be scaled according to our needs. I rate the scalability a ten out of ten. In our company, more than 100 people use the solution.

The technical support team is pretty good. The response time is very quick.

We have used Azure, and it provides similar services. However, we do not have a lot of experience in Azure.

The initial setup is super simple.

I rate the pricing a five out of ten.

The billing is really painful. The product must provide some intuitive notification to inform us if we are not doing something the best way. Overall, I rate the solution an eight out of ten.

We use Amazon EC2 Container Service for Kubernetes and hosting sites. 

Amazon EC2 Container Service is a flexible product from Amazon. You can put it in the Auto Scaling group for high availability. There are also a lot of choices for pricing. 

The product can become expensive if you don't choose what you want. 

I have been using the product for two years. 

I rate Amazon EC2 Container Service's stability a nine out of ten. 

I rate the tool's scalability a nine out of ten. 

Amazon EC2 Container Service's deployment is easy and takes three minutes to complete. 

I rate Amazon EC2 Container Service an eight out of ten. 

Our services are relatively straightforward to manage. We have a limited number of servers compared to some others. When it comes to billing, our plan is flexible, but it may not be the most suitable option for medium-sized enterprises.

They handle the backup process quite well. They automatically encapsulate it, including container backups, without relying heavily on the client's involvement. This is a significant advantage compared to other providers where clients often need to manage the process more independently. It's a feature that I find suitable and beneficial.        

For instance, we've opted for a fixed monthly fee, which covers us for a broad range of data usage. However, with Amazon, the billing tends to increase exponentially as data usage grows, which poses some financial challenges for us. We've also integrated AWS and Synchronoss services into our setup.

I also believe there are limitations in terms of upgrading. The software has the concept of dedicated servers that you can manage. However, an issue arises when you can't match one operating system with another that you've already purchased. You can't simply merge them; instead, you have to buy a completely new one. This limitation has caused some challenges for us.

I have been using Amazon EC2 Container Service for two years.

Initially, we operated our servers on-premises. However, as we aimed to improve the quality of service for our clients, managing local infrastructure became challenging. To address this, we made the decision to move to cloud providers. We chose providers like OVH, where we procured Bandwidth servers and Ultra servers. These providers offer a flat-rate billing plan, which includes servers with specific resources like RAM, processors, and databases. You configure your setup, and they provide you with a monthly bill. On the other hand, Amazon's billing system is more dynamic. It adjusts the billing based on the demand and usage of the server. This dynamic billing approach has posed certain challenges.

There are no specific issues with the service itself; it's quite good. The only concern we have is the billing structure, which may not be the best fit for medium-sized enterprises like ours. The service is more aligned with the needs of larger corporations.

My advice would be for them to stay up-to-date with the current market trends, especially in the cloud services sector. While Amazon is a leader, it should be open to adapting and being competitive in the evolving market. The flexibility in server configuration is crucial, and the billing plan can remain as it is. However, most cloud server providers tend to have similar billing plans based on the server's performance and usage, so it's essential to align with these industry standards.

I rate the overall solution a six out of ten. 

It has helped our organization greatly and especially on weekends because we have many transactions as our users are buying some kind of tools and paying online.

The solution is easy to use. When you have nodes like Python, it's easy to plug and play.

The documentation and usage for the users can be better because for new users it can be very hard to understand and use the solution. They can add small images and accessories.

I have been using the solution for two years.

It is a stable solution. I rate it eight out of ten.

It is not a very scalable solution. I rate it five out of ten.

The technical support team is good but if you are looking for any documentation then it is not very helpful.

The initial setup is easy and it is deployed on the cloud. 

I have seen ROI with the product's use. 

The pricing is good.

I rate the solution an eight out of ten.

We are using the solution to run our apps and services. We make use of Docker to run our API services. So, we use ECS as the container service to run all of our Docker images.

Its most valuable feature is the ability to work with Docker images. We just have to give it a Docker image and run some parameters. It keeps the process going for us. It's been great. We don't have to worry about where and how it gets deployed. We just know that it's going to run and we can contact it at a particular address. It integrates perfectly with AWS's service mapping feature and allows one ECS container to contact any other ECS container using a service name. It's almost like an internal DNS thing. If we want to expose it to the internet, we just put a load balancer. It passes requests from the load balancer to the relative ECS services. It also helps for scaling–we just have to add one in a new container. That's pretty cool.

I see they have changed the console a bit to make it easier to use. Probably, they should include automated graphing, and monitoring solutions. Currently, I have to set up all of those by myself.

We have been using the solution since October 2021.

The whole engineering team of six people at our organization uses the solution.

There were some issues with the setup. It wasn't the easiest to get going as opposed to something like SFTP Gateway. It's a learning curve. You need to learn what a cluster is, what a task is, and what a service is. There are no industry standard concepts that could be applied to different technologies. You need to learn ECS-specific concepts. It's similar to Docker Swarm or other resource management technologies like Kubernetes. They have similar concepts, so if you come from that world, you might understand it a bit easier. There is some AWS-specific stuff that you just need to learn. Once you get over that learning curve, then it works pretty nicely. I would rate the setup procedure as a four out of ten.

The price of ECS is not bad. It is based on usage. It works on a per-hour pricing model.

I would definitely recommend the solution. Once you get the procedure right and set a pattern, it just works. I have used different use cases, languages, and frameworks. Everything works nicely once you get the pattern right. The solution scales by itself, and you can set the threshold of how to scale it. Once it goes to 80% of CPU for five minutes, it scales up automatically, and then if the CPU usage goes down, it scales down. You don't have to pay for that upscale cost over time. You need not have to worry about servers or machines. You just have to worry about your containers. It's great.

Also, deploying to ECS is pretty easy via whatever CI you use. It's generally quite easy. It also integrates with Amazon's ECR service, which holds the Docker images used for the services and containers. It works nicely with the ECS.

If you have credentials or secrets that you might want to use as environment variables in your applications, you could inject them at run time into your containers. ECS caters to this with a pretty easy task definition like syntax. You just have to specify the secret name in the task definition and ECS will know when it starts, and when it needs to pull this secret into the container at run time. Thus it's not vulnerable to an attack where someone can snoop on your task definition. It's not in plain text and it only works if you give your container explicit permission to pull the secret.

I would rate the solution as an eight out of ten.

The solution is to compute instances. Basically, it's a debit. It's a host. For example, if you need a computer that you want to install your enterprise application, instead of buying a server on-premise, you can spin up an instance online.

I like the per-second billing. Every second I use is billed. Any other time I am not using it, it's not billed, so it's better. It’s cheaper. It's good.

It’s easy to set up.

The solution is stable.

The solution can still be expensive, even with per-second billing.

We’ve used the solution for the last year.

The solution is extremely stable and reliable. There are no bugs or glitches. it doesn’t crash or freeze.

It is very scalable.

We started with AWS this year. We have one client so far.

Technical support is perfect.

The solution is very straightforward. The initial setup is very cheap also.

It's very easy to replace. You don't need a lot of teams to do it. One person can do everything.

We are integrators and can handle the initial setup.

You pay for only the time you have used the on-demand service. For example, if you are using software that does a lot of computation or analyzing your data for your company, you only pay for that time spent analyzing that data. The rest of the time, you don't pay for it.

Although I like the per second billing, the cost of it, even if you are being billed per second, it is still higher than competitor products.

We are integrators. We use a lot of Amazon products.

I would rate the solution eight out of ten.

I would recommend a competitor's product. I would recommend, for example, Oracle Compute Instances or Oracle Cloud. I wouldn't recommend AWS EC2 due to the cost. It can get out of control. For example, once I left my EC2 on for a few days with some services running, and in three days I lost a thousand dollars. It's quite costly if you are not very careful.

I have set up Container Service environments for various clients using different cloud providers, including AWS. I have used the Amazon Elastic Container Service in this capacity.

One of my clients from Israel is running web-based applications that are using PostgreSQL as the backend database connection. I think that it is a user-learning software, and they provide it to big companies to give KT sessions for new employees.

They use the Totara application and for that, we have set up the infrastructure including VBA and database applications. We also manage their Amazon Route 53, and we have set up Jenkins for CICD purposes.

They use EC tools for AWS and try to save on costs through the various savings plans and through the RX solution.

From time to time, their solution has problems due to the failure of the underlying hardware. When they deprecate older hardware, for example, sometimes it causes the production environment to be affected. This is the main cause of their problems. In response, we moved them to the ECS solution, after which we get a highly-available environment with minimal billing on a monthly basis.

This solution is a good deal for our clients.

Using this Container Service is a very cost-effective solution. We can use this service with minimal costing.

The production environment is highly available, which nowadays is a requirement for all of the big companies. There is a 99% uptime with this Amazon ECS.

This is a fully-managed product and we don't have to be concerned with problems related to the underlying hardware or configuration management.

The problem with containerization technology is that many businesses do not trust it right now, and only use it in their development environment. For example, if you spin down the container then all of the data inside it gets deleted. From our perspective, we think that this technology is good, and it is really an issue of awareness. I am very much excited by this technology and am okay with it. I think that it would help if the vendor provided more use cases and explanations as to how ECS can be utilized.

As part of my experience, I have been working with this cloud-based technology for the past four years.

Based on the experience that I have had throughout my career, I find that this product is very stable. The only problem it has is with awareness, where businesses need to better trust it.

It's predetermined that ECS is scalable. There are two types of scalability, which are horizontal scaling and vertical scaling. If you upgrade your container from a resource perspective, that is horizontal scaling. If you upgrade the core device, where suppose that you have one container and after that, you have created multiple containers to distribute the nodes, then that is vertical scaling. ECS already covers these in the scaling policy, so we have nothing to worry about in this regard.

Our client with the Totara application has thousands of users that they are managing in ECS.

We have not used the Amazon technical support, although some of our clients have already purchased it. We rarely raise issues that are the result of the underlying hardware. That cannot be resolved from our side because it is managed by AWS.

In 99% of the cases, we solve issues through support that we provide to our clients.

Prior to ECS, we used Docker and Swarm. This is an open-source technology but there are some issues with that solution, which is why we have chosen the dedicated service by AWS. We always try to take the easiest approach.

When you use Swarm, you are responsible for managing the application. There is the possibility of failure because of a version mismatch or some of the other dependencies. But, if you are going to use the ECS service provided by AWS then they manage the infrastructure and all of the underlying hardware, as well as configuration management. We don't need to care about any of these things. Rather, we only have to set up the infrastructure and support it. This is a benefit to using ECS.

When I first started working with ECS, my feeling was that it was complex. However, after working on it for a longer time, I now feel that it's very simple. It took me six months of working on it, and now I am very happy.

Essentially, it depends on how much experience you have. With more experience, you feel it is very simple, whereas if you do not know the solution, then you will feel it is complex.

If you start with a container that is 500MB or 800MB in size, it will take about 30 minutes to deploy on the production server. We follow a deployment plan and implementation strategy that is specified in our corporate documentation. We generally follow this when we deploy in a production environment.

Our strategy for new release and deployment begins with backing up the currently-running solution. We take a backup of the current artifact because whenever we deploy a new release in the production environment, there is a change that we will experience a failure. We also keep a backup of the older releases.

The next step is that we test it from the various environment test stages, including beta and staging. We prefer to deploy to various environments.

There is also an issue of authentication that is mandatorily applied. Only release managers or release administrators can deploy any changes to the production environment. It is not possible for developers to perform this task.

After the deployment to the staging area, there is a QA to who we give ownership for testing. Once QA approves the release, the deployment will take place on the production server.

There are a few more steps in our process, but this is a summary of our strategy.

We normally use the AWS deployment tool, although sometimes, we use an open-source deployment tool. Price-wise, it is always best to use open-source technology because it will reduce your costs.

The deployment and maintenance are done for the client by our in-house team. We have a team of between four and five members, and I am the senior person who is leading them right now. My engineers work on projects and I guide the various steps. If they face any issue or there is any doubt, then I provide guidance. I am a solution architect, as well, and I always try to meet the project deadline so that the client will always be satisfied.

We provide technical support for our clients, as well. The first step is that we need to understand the infrastructure. We need to know how the infrastructure has been set up and what the configuration details are. We need to know which applications are running in the container. Basically, we need the infrastructure details. If you provide the infrastructure diagram, that will be helpful input for us. Essentially, we have to become familiarized with the infrastructure so that we can easily troubleshoot any issue. This way, if the business is negatively affected then we can give a solution shortly.

Our client was paying up to $2,000 USD per month for 20 to 22 servers before implementing ECS. Nowadays, they pay $400 to $500 per month, which is a huge difference in the yearly billing.

Our client is paying between $400 and $500 USD per month for this service.

My advice for our clients is that before creating the infrastructure, take steps to analyze your needs, and gather the requirements. You want to know what the requirements are, and what resource utilization you have. Suppose, for example, that your requirements are for two CPU cores and one terabyte of RAM. If you are not aware of the actual requirements of the application and the user then you work with the unknown and run the risk of setting up an infrastructure with a high level of resources. This will be costly.

Our approach is to take some time to understand the application and the resource requirements before the setup. After analyzing, we draw the diagram to prepare the plan and then set up the infrastructure.

The biggest lesson that I have learned from using this product is that it is highly available, cost-effective, and reliable. I get all three of these benefits from this technology.

I would rate this solution a nine out of ten.