Amazon Elastic Container Service Reviews

We use the solution for a web application like an e-commerce or a basic site. I have a business site.

EC2 is an initial level with a nominal cost. As a customer, we need to approach an EC2 tool. Additionally, other instances are available at slightly higher costs. Hence, once the business is established and running smoothly, we can upgrade to another instance.

We use the EC2 for testing purposes or as a starting point.

We need RAM, CPU, and install cPanel. cPanel is a separate third-party tool. If we install an EC2 tool, it would be an interface for managing files and databases, making it easier to maintain them.

I have been using Amazon EC2 Container Service as a customer and a partner for two to three years.

The product is stable. We need to skip the unnecessary servers or sometimes enable the autoscaling group feature to adjust based on conditions automatically.

I rate the solution’s stability an eight-point five out of ten.

We can increase the RAM, CPU, and hard disk for scalability.

We have used different hosting from different companies.

The initial setup is easy.

The solution's pricing is nominal. Also, it manages all the servers, mainly when certain servers might experience slowdowns. Amazon EC2 offers features that don't affect the website or application's performance.

If a customer requires a low-cost server, we suggest considering different options from various companies. Otherwise, we recommend exploring the offerings provided by Amazon EC2.

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

I am using AWS ECS combined with AWS Fargate in order to orchestrate our containers. To explain what that means, I will give an example. Suppose you are running a microservices architecture in which you have multiple containers within multiple services. ECS is the tool that helps you orchestrate all of that, by providing you with the ability to scale up / down your containers and monitor them. Also, with ECS, you can identify any problems or bugs with your containers.

We had a microservices architecture operating in this manner, and we needed some kind of solution to help us manage and orchestrate all our containers. Here we had a choice between something like Kubernetes or ECS, and we chose to use ECS because we didn't have a very large or complex architecture with many containers. Instead, we only have a few containers, yet they still needed orchestration in many ways, which ECS was able to provide.

For me, the best feature of ECS is Fargate because I don't have to manage anything. Instead, everything is managed by AWS and all I have to do, in essence, is configure my containers and deploy them.

That said, whether this feature is appropriate for everyone depends on the sensitivity of your data. I was able to make good use of Fargate since I do not have especially sensitive data running on the containers.

Visualization is an important factor for me, and I don't think that the visuals within ECS are good enough because it doesn't show you all the details you might need to see at a glance.

Another aspect that could be improved is that our monitoring within ECS depends on other services like CloudWatch, for example, and with this arrangement you have to constantly switch between screens when navigating around. Because of this, it's difficult to take a look at your monitoring data, or even just to set up, and it can be very frustrating.

Perhaps it would be possible to improve this situation by having the ability to include everything on one status page. For example, if there is a service or container that is exhibiting a bug or is in some type of loopback mode, when I click on it, I could be shown the screen with all the errors displayed right there.

I didn't see any issues, especially in regards to ECS with Fargate. There are two ways you can run ECS; one way is with EC2 (Elastic Cloud Compute) and the other is Fargate. When you run ECS with EC2, it means that you manage your own servers and your own containers. However, with Fargate, AWS manages all the servers and containers behind the account. For some people, it might be the case that when you're using ECS with EC2, your issues are more related to your own management methods rather than anything to do with AWS itself.

I contacted support one time when I needed to find some information related to launching containers. I wanted to find out how to access certain container data, such as container ID and so on. Once I reached their support, they managed to help me find this information.

The quality of support you receive depends on your subscription because when you have an enterprise subscription, their response is very quick. However, when you are not part of an enterprise, they might not help you right away. Regardless, when we're talking about how well they help, they are indeed able to offer technical solutions and they are straightforward about it. 

Positive

The setup is not that hard. When I began using it, I found that it's not very intuitive, but at the same time it's not difficult.

I would suggest, however, that AWS offer more courses or tutorials on how to use it. I know that they teach how to use ECS through their certifications, but even a few two to three minute tutorials on their YouTube channel would help people a lot. Personally, I had to look through many resources to find good knowledge on it, but when you eventually find the solution, it gets more intuitive. 

When it comes to how long it takes to deploy your containers within ECS or their orchestration tools, this really depends on your architecture, and how you have set things up. If you have set everything up properly, it takes only a matter of minutes to have your application up and running.

I don't know the exact amount we were charged for our use of ECS, but I do know that it can be costly, especially when there is a bug or an error caused by default configurations. When you configure your containers to be launched with special configurations, such as with CloudWatch events, sometimes they fail to launch and they enter into a locked state. Each time this happens, all the configuration behind the container creates itself again, making it such that the costs can quickly go up if you have any bugs in your configuration.

Besides that issue, I would say it's not that expensive, but can still be costly in a way.

We considered using Kubernetes instead of ECS, but we went with ECS because our architecture and amount of containers did not warrant the complexity of using Kubernetes.

My advice, first of all, is to do your research, and do it in detail. Verify that ECS really satisfies all your requirements, especially when you are also using Fargate because with Fargate you are not managing the servers yourself. A good tip is to watch some tutorials that already exist online, so you can start your process with that.

To be honest, using a tool like Kubernetes to orchestrate your containers can be a very difficult process, especially when setting up Kubernetes clusters, and there are a lot of small things that you need to do and understand. However, compared to Kubernetes, ECS is very intuitive and extremely quick to learn. This is why I would definitely recommend ECS over Kubernetes if you don't have a highly complex microservices architecture and you simply need to set up your containers quickly.

I would recommend ECS mainly for its stability and its ease-of-use in helping to manage containers, despite that there are some improvements that they could make, such as better visualization and other improvements to the technology itself in order to orchestrate even more complex architecture.

Overall, I would rate AWS ECS a six out of ten.

We use the solution as a docker service to run the containers.

We use ECS whenever there are multiple programs to run. We can containerize the programs without worrying about the versions of the applications.

The solution's most valuable feature is its ability to run the containers directly on the cloud.

The solution could provide more reliability. There could be an option for the customers to manage the services. Also, there need to be more custom features that would allow customers to access the ECS containers and deploy them.

We have been using the solution for two years.

I rate the solution's stability a six out of ten.

The solution is scalable. I rate its scalability an eight out of ten.

The solution's technical support is good.

Positive

The solution's initial setup process is straightforward.

Even if the solution is costly, you will definitely see ROI if you have many applications.

The solution's cost could be reduced.

The solution has multiple versions. You can choose a version compatible with your system. I rate it a seven out of ten.

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.

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. 

We deploy applications inside the EC2.

The solution has good performance. 

I would like fewer updates.

I have been using this solution for six months. We use the latest version.

I would rate the stability a ten out of ten. 

I would rate the scalability a ten out of ten.

The initial setup is straightforward. 

I deployed the solution myself. One might require engineers and developers for the deployment process. 

Overall, I would rate the solution a ten out of ten. All the current features are perfect.

I would definitely recommend using the solution.

I like Amazon EC2 Container Service's elasticity. 

The solution needs to improve backup and pricing. 

I have been working with the solution for five years. 

The solution is stable. 

The product is very scalable and we have around 400 users for it. 

The tool's setup is easy and I would rate it a ten out of ten. The tool's deployment is fast and takes around one day to complete. If deployment is for an enterprise, then you need to go through the architecture. You need to go to the dashboard and put in all the required details to deploy it. 

Amazon EC2 Container Service is priced high. 

Amazon EC2 Container Service is a good platform since you can run multiple things on it. I would rate it a ten out of ten. 

We use Amazon EC2 Container Service to host a variety of applications for our clients. We use ECS to test machines, production machines, and other environments.

The security is good with 24/7 availability along with location. The cloud services are readily available. For example, if all three or four servers hosted in the cloud fail at once, the service will be transferred to other machines. This is one of the things that makes me most likely to use this cloud service.

Amazon EC2 Container Service's security can be improved. For example, ECS should be integrated with multiple teams and cloud providers to make it more accessible and secure. Additionally, AWS should provide more security policies for ECS resources to prevent unauthorized access. Support could also be improved.

I have been using Amazon EC2 Container Service for more than two years. We are using the latest version of the solution.

The product is stable. The security line has been deployed. I have never experienced any instability. I rate the solution’s stability an eight out of ten.

The solution is scalable.

Some people are good and are helping us.

Neutral

The initial setup is easy. Generally, everything is written in clear and understandable language. If you know English, you can clearly understand all of these things. You can also change the language, so it's not too complex.

The solution is expensive, but not too much.

Overall, I rate the solution an eight out of ten.