Amazon EC2 Reviews

Our primary use case for Amazon EC2 is for front-end and back-end deployment.

What we have found most valuable is that we have not lost stability in the program. 

I think the pricing needs to be adjusted and security improved.

I have been using Amazon EC2 for a couple of months.

My data science team is using TensorFlow.

I like the setup with Azure more than Amazon EC2 because I am more comfortable there.

I would recommend any solution that helps solve the needs assessment. I would rate Amazon EC2 a seven out of ten.

I build solutions in the infrastructure of my clients. I use Amazon EC2 in their AWS cloud. 

With EC2, there are many different operating systems that you can use. If we were to talk about the size, I use the T2 and T3 instances and central apps for production and for Windows.

The Key Management Service (KMS) feature is very helpful for security. It encrypts the data that is being saved. Cloud storage is also very helpful, and it could be AWS S3, which a lot of people use.

They should fix the key pair name functionality and provide the ability to assign multiple key pair names to an EC2 instance. It is a key pair feature, and it provides you the ability to actually log into the server. It is basically like a password.

In terms of new features, it should have the ability to increase and decrease the instance size based on certain times of the day. We should be able to do this without turning off the EC2 instance. Currently, you have to turn it off and then turn it back on. It should also have HTTPS or SSL integration. 

I have been using this solution for five years now.

It is a very powerful platform. I feel very comfortable and confident while deploying on this platform. I also feel confident in telling my clients that it is very stable and very reliable.

I know it can scale. I have no doubts about its scalability.

I have used their technical support, and I would say that they are pretty responsive and helpful.

EC2 was the first service that I used. If we are talking about cloud platforms, I actually started with Azure eight years ago. I went for the AWS platform because it had a maturity of services over Azure in the past, that is, a year or two ago. If I were to do it over again, I would choose Azure based on what the customer needed at that point in time.

I am pretty technical, so I kind of knew how to do it. I also use Hydra. When comparing both platforms, I would say that AWS is just a bit more confusing or complex. 

I would recommend identifying the active directory configuration of your clients. The majority of client type integrations will have some active directory involved, and they also have Office 365 now. Getting a better understanding of that configuration will help the solution implementer in using the AWS platform.

I would rate Amazon EC2 a nine out of ten. 

We've been using the solution basically for provisioning our development in a less production-heavy environment. 

It's been quite easy for solutioning. 

It's easy to manage. 

There's a lot of support from the built-in framework.

The integration has been great.

The solution is very stable. We haven't had any issues in that regard.

The user interface is great.

The built-in monitoring is great. The reporting and analytics are pretty decent.

All of my lower maintenance overheads are taken care of. I don't have to worry about it.

There's great documentation available. 

The issue that I have seen, earlier, not now, maybe around 2014, was that the ports that we wanted to deploy to weren't all open. In general, we need to have a specific request made to get these ports opened. We had to go through a little bit of analysis and it was not quite straightforward. We needed to raise a request to open such ports. That was the only problem I've not seen it in a long time, and that was with AWS in a special case. However, these days, I don't have any such port issues right now. We don't have any custom ports used at this point in time. 

Technical support could be more helpful when it comes to dealing with integration issues.

I've been dealing with the solution for three or four years now.

The solution is pretty stable. We haven't had any issues with it per se. It's not buggy or glitchy. It doesn't freeze.

We build department dashboards for schools in the United States, so there are a number of users using it at any given time. It's likely in the hundreds of users.

Support is okay. I'm not talking about the support from the team perspective, but rather from the framework. It's the mission framework side of it. The framework has got a lot of features, which supports the monitoring, and other things. It's all how you configure it.

If a person does need help troubleshooting, there's great documentation available for them. 

Technical itself could be a bit more helpful, especially when it comes to integration assistance. When we talk to the technical team, often it's some issue with integration and they'll tell us to talk to the other company. Often, the other company will look at everything and not see an issue from their end and then we are at an impasse.

The technical support teams should understand how to give some pointers with their experience due to the fact that AWS is huge and vast and spread across different industries, and different regions. They should have some kind of knowledge or insights. We can't be the only clients facing these issues. I'm not sure if this is an issue across the board, or just a problem with the current team we're dealing with.

In the end, in a specific example, we were trying to use Monitor with AWS and we really tried to make it work. However, it did not. AWS did not help us, and from iMonitor's side, everything should have just worked.

As long as you are prepared with the groundwork, the implementation is okay. You need to have the specifications ready in terms of what kind of environment you want to create. 

Once you know what kind of environment you want to create it takes about five to ten minutes. That's all.

We only have one person that handled the deployment and maintenance. It was a pretty easy build, so it doesn't even really take up a person's full time.

We don't even really have any maintenance overhead. For us to actually deploy one particular individual or a resource for a full FTE isn't necessary. This is due to the fact that the infrastructure, the framework commission, has a lot of things that are already taken care of from a maintenance perspective and from a monitoring perspective. It's an easy job that isn't time-consuming.

We'll continue to use the solution in the future. We may expand its usage.

We did not get someone to help us with the implementation. We handled the solution in-house.

The pricing is fine. It's not too expensive.

That said, if you don't have the right model in place, then the cost factor could be one thing that people need to think about because it's based on usage. For example, how long the server is up and running will contribute to the cost.

The model needs to be very concrete and work on how we want to use it. Based on that, if these factors are not known and if you don't take care of this, then the cost factor might go up as so it'll only take that one week to take care of any issues. We've never faced such a scenario because we are very clear on how we want to use it every time.

We're just a customer.

I'd recommend this solution to others.

Overall, on a scale from one to ten, I'd rate it at a nine.

Basically, whatever we're trying to do with physical VMs on-premise, we can directly replicate them on Amazon EC2.

The solution's most valuable features are the virtual applications and the scalability.

The customization and configuration could be simplified.

Updates could be automated and simplified.

I've been using the solution for four years.

The solution is very stable.

The scalability of the solution is fantastic. It's one of our favorite features.

We've never had to contact technical support.

Previously we were using VMware. We decided to use the current solution to take advantage of its ability to scale.

The initial setup was simple. Deployment was fast. We could do it in about 75 minutes. It might even take as little as five to ten.

We have about five people handling deployment and maintenance. Mostly, they're architects.

We handled the implementation ourselves.

We're charged depending on the run time, but there are other costs as well, including costs for transactions and storage.

We also evaluated all of the other VM's.

We use the cloud deployment model.

I'd advise others to understand the costs involved before implementing the solution. There are transaction and storage costs as well as running costs.

I'd rate the solution nine out of ten.

One way we have used AWS EC2 is to be able to orchestrate the creation and termination of temporary instances used for training and demo purposes. Instead of having to wait on limited internal resources to become available, we can easily create multiple instances for use and terminate them as soon as we’re done.

The ability to quickly spin up instances on demand with zero upfront costs or infrastructure is the most valuable for me. This significantly reduces the time it takes to onboard projects or quickly create POV environments. It also enables a low entry point for users to begin development without significant expertise.

Built-in and/or integration with other services to proactively identify potential failures before they occur. For example, if capacity is low in an availability zone, recommend placements in another zone, or return capacity status before launching new instances.

Yes. Issues with stability have occurred. In some cases, we have seen where instance performance has degraded significantly to the point where they have to be destroyed and recreated. There are ways to mitigate stability issues through the use of multiple availability zones.

Yes. Issues with scalability have occurred occasionally, due to low capacity of specific instance types in some regions.

Technical support via email has been fairly responsive. A response is usually received within 24 hours.

Local VMs were being used before switching to AWS EC2. Local resources were not scalable and increased operational complexity. They were also costly to maintain.

Setup was fairly straightforward. Using the console provides an easy to understand graphical user interface. The command-line and API options tend to be slightly more difficult to use due to the learning curve.

EC2 pricing is somewhat transparent, in that AWS provides pricing for all instance types. However, the number of pricing options can be confusing, i.e., on demand vs reserved vs spot vs dedicated. It would be great if AWS provided a real-time calculator that displayed your estimated usage for a period of time, then notified you before you exceeded your estimated costs. Licenses for some instance types can be included or use BYOL, depending on the vendor.

No.

Take note of usage costs for all related services being used. For example, running an EC2 instance with vendor software may require paying for EBS volumes, Elastic IPs, Snapshots, and other software licenses. Enable Billing notifications to be alerted whenever costs exceed a certain threshold. Lockdown instances to only provide access via tightly controlled security groups. Use public key authentication, whenever possible, and restrict direct access to superuser accounts.

EC2 is an excellent IaaS service enabling quick deployment of applications.

It has helped to reduce costs with infrastructure.

Scalability, reliability and easy to use settings. These features are essential for our company.

The services our company offers to our users require high scalability. We need to scale our infrastructure horizontally to meet our users' demands and Amazon can offer this type of elasticity with total reliability.

An advantage of Amazon is that it offers a wide range of infrastructure services with an easy way to configure them.

Price and availability.

I think Amazon could offer lower costs for customers who have a high use demand, as in our case. Nowadays, the cost for little use is attractive, but when your company needs more computing power, costs can be very high.

I believe that a significant improvement to contribute to cost reduction would be a wizard that allows the migration of a certain infrastructure configuration for another solution, such as switching EC2 + RDS instances with a LightSail or Elastic Beanstalk.

Regarding availability, a noticeable improvement would be the possibility of more load balancing configurations and the deployment of more datacenters, mainly in Latin America.

We did not encounter any issues with stability yet.

We did not encounter any issues with scalability yet. One of the greatest advantages of Amazon AWS is the ability to grow on demand.

The technical support is very nice and fast, even for unpaid support.

We've used Google Cloud Platform. We switched because Amazon AWS offers more services and a lot more settings.

Initial setup is always a little bit complex, because we use many services, such as database instances, DNS zones, load balancing setup between multi-zones and so on.

Price is attractive, but at a large scale not so cheap, especially if you use many services. Regarding licensing, we don't have any issue with it.

We were using Google Cloud Platform before using Amazon AWS. We've also analyzed DigitalOcean and a Brazilian datacenter named Locaweb.

You have to consider some factors, like scalability of the services offered by your company. If you need to be online 24/7, then you need a powerful and reliable infrastructure.

Our company, Drivver, uses a wide range of services offered by Amazon AWS, from computational instances to artificial intelligence services, so we need a cohesive and concentrated infrastructure in a single IaaS provider.

As our infrastructure work is outsourced, it's not easy provisioning servers. Even virtual servers take time. Using serverless architectures means no need to involve the infrastructure team.

The serverless architecture solutions are most valuable, and the ability to start with little cost, and then expand as needed.

I think the whole AWS stack is very disconnected from each other. in the .NET space, everything just works nicely together. In the AWS stack, there is a lot of head scratching. Demos appeared easy, however, once you sit down and build a solution its gets very tricky quickly, and as it's a new technology stack, it's much harder to find best practices for common problems.

In terms of EC2 instances, we did notice a handful of times servers were terminated by AWS due to "health checks." Besides that, I think there were one or two major outages that affected a number of AWS systems for a few hours.

No, the serverless stack is actually extremely impressive with how well it scales.

My experience with technical support from AWS has not been good. It all depends on who is assigned as your solutions architect. In terms of finding ways other developers solved issues or best practices in Google searches, as it's a relatively new technology stack, typically I find many people asking same questions and not many answers.

Prior to the AWS stack, we were mostly a .NET stack. Our company partnered with AWS, and looking at their offerings, seemed just using their EC2 offering would be a waste. Having said that, I think using the Azure platform may have provided a better end-to-end solution.

Starting up an EC2 instance is easy, starting an API gateway is also easy, so is setting up a lambda function and a dynamo store. The problem is, what you have just done, from looking at AWS presentations and tutorials, is a bad way of doing things in AWS. You pick up quickly that ideally everything should be scripted using cloud formations, or beanstalk, or serverless, or swagger, etc., and here is where the complexity lies. To do anything properly for an enterprise company, currently its very difficult. What tools do you use? Will they still be around in six months?

Pricing appears to be cheap, however, it is extremely difficult in calculating what something will cost. Someone accidentally starting a EC2 server could end up costing you notable dollars. Also once you start using services, let's say serverless architecture, you may quickly find you need to build dirty solutions just to keep the price down, or even go back to server based solutions due to costings.

For some services like API Gateway, we did look at some other options, however, the serverless architecture concept was new and not available as a stack with any other company at such a competitive price. Now Microsoft has also joined the concept, and while I have not used the Microsoft offering, based on my other experience with the .net platform, i think it may be a better platform.

For small startups it makes perfect sense. For large organizations with R&D team/budget, it may make sense. For medium-size companies, where they just need solutions built quickly, I am not convinced about AWS at the moment. Looks promising, but it's a very new platform, with issues that come with a new platform.

I believe that cloud solutions are better than physical servers. 

I am concerned about the tool's data security. 

I am using the product for an year. 

I would rate the tool's stability a ten out of ten. 

The solution is fully scalable. We have five to six clients who use the tool. 

The tool's setup is a bit complicated. You need to have some amount of technical knowledge to install it. The deployment gets completed within three months. We need to first connect to the instance and generate a token. Post that we need to connect to the additional server and then to the cloud. 

I would rate the tool a nine out of ten.