Amazon EC2 Reviews

I installed the Windows server using EC2, and I set up some product programs. 

The product is easy to use.

It can scale up.

The product is easy to set up. 

There is no need to have physical space to set up a server in. 

If the solution was cheaper, if the price was less, it would be better. 

I've used the solution for three or four years. 

It is quite a stable, reliable product. There are no bugs or glitches. It doesn't crash or freeze. 

The solution scales very well. People can expand easily.

I'm not sure how many people use the solution. 

I've never contacted technical support. Other colleagues may have; however, I haven't.

We only ever used an on-premises solution. We've never used anything cloud-related. 

The setup is very easy. It's not overly difficult. 

I'm part of the setup and support team. 

We'd like the solution to be cheaper. 

We pay a monthly fee for licensing. I'd rate the pricing five out of ten. 

I'd recommend the solution to other users and companies. 

I'd rate the solution eight out of ten. 

We're primarily using the solution for deploying our application.

We like that the cloud features are manageable. We don't need to do anything to manage them.

We don't have to worry about scalability issues or maintenance or security. It's all taken care of.

It's a powerful product, and we can do everything in just a few clicks. 

They could try to improve everything incrementally. They're working on improvements all the time. It would be ideal if they could continue to refine the product so there were fewer and fewer things customers would have to worry about. They could improve their own people so that things like security continue to get better and better. 

They could improve their images. They're working on doing that now. 

The solution is pretty expensive.

I've been using the solution in my current project. It's been more than six months. 

It's a stable product. There are no bugs or glitches, and it doesn't crash or freeze it is reliable. 

Most of the cases are using Amazon EC2 in our production deployment, so maybe most of the people are using Amazon EC2 with other features for containers. There are about 90 people on the product right now.

I've never dealt with support. If someone needs to reach out to support, it would be my supervisor, not me. Therefore, I can't speak to how helpful they would be. 

We go right to Amazon and create a machine. It takes ten to 20 minutes, so the process is pretty fast in terms of setting up. 

The cost varies from machine to machine. When we create a machine, they estimate how much it will cost. It is more expensive than other products.

We're an Amazon partner. 

I'm not sure which version of the solution I'm on. 

If a new user wants to use Amazon EC2 for their professional work or their deployments, then they need to think about the cost. The cost of the cloud is a bit higher compared to other things. They need to also consider the settings and functionality in Amazon EC2. They really need to look at their use case and scenario. However, it is something worth trying for testing purposes.

I'd rate the solution eight out of ten. It's made out life easier. We don't have to worry about scalability or maintenance any longer. It also offers good load balancing and other kinds of features. 

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 have a lot of use cases. Some of our customers have deployed their SIEM solutions on EC2 instances. Our company has also deployed a couple of business applications on EC2 instances.

The product is very mature and organized. I haven't had any issues with any of the AWS services.

The GUI used to deploy EC2 must be improved. Azure’s GUI is more guided compared to EC2’s GUI.

I have been using the solution for five to six years.

If I buy only one EC2 instance with fewer resources but use it for many resources without putting it in the Auto Scaling group, the tool will not be stable. If I deploy the solution according to AWS's best practices and recommendations, it will be scalable. If I deploy it under Load Balancing or Auto Scaling, it will automatically go up and down as per the demand, and we have to pay for only what we use. I rate the stability a nine out of ten.

The product is very scalable. The scalability depends on the deployment architecture. Our clients who have big infrastructures are using the product. They have multiple accounts. My own organization is also using the solution. We are planning to increase the usage.

The support is very quick. Everything is guided pretty well. AWS’s support is always very good.

The initial setup is easy. The product is cloud-based. If I am buying the solution for many CPUs, it might take two to three hours. It will take four to five hours if I'm deploying with fewer resources.

The deployment process is pretty simple. We can go to the EC2 dashboard and create an instance if we have an AWS account subscription. The product would guide us with the help of dropdowns. It will ask us how many resources we want, how much storage we want, which security group we want to integrate, and what kind of Access Control we want to integrate. There’ll be a lot of questions, and we just need to select the answers.

EC2 is like a virtual machine. It doesn’t require a whole team for deployment. The number of people required for deployment depends on the complexity of the deployment.

We need to pay a monthly license fee for the product. The pricing also depends on the type of instance we use. Reserved Instances are dedicated to a single user and cost more. If we use Spot Instances, we must pay for what we use. It will be added to our monthly bill. It is not an expensive solution.

Azure uses Sentinel, which is dedicated to security information and event management. However, AWS does not have a centralized solution for SIEM. AWS is using security hubs like GuardDuty, but it is for different purposes. We have to log in to these dashboards separately. AWS needs to have a centralized SIEM solution.

People who want to use the product must consider the future predictability and decide whether they need a single EC2 instance or a Load Balancing or Auto Scaling infrastructure deployment and deploy accordingly.

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

We typically use the solution for the web server.

The solution can scale. It's very easy.

It offers excellent value.

The product is easy and quick to set up.

We have found it to be stable and reliable.

The support could be more responsive.

I’ve used the solution for four years. It's been a while. 

It’s a stable product. There are no bugs or glitches and it doesn’t crash or freeze. It is reliable.

The solution is scalable.

We have at least 20 people on the solution currently.

Technical support is better if the customer signs up for the support package. If they do not have a support package, getting help takes longer.

The initial setup is very straightforward.

The deployment typically takes about two days. It does not take long. It can be handled by one department. We run it 24/7 and have it at about five financial institutions.

We handled the initial setup in-house. We did not need any outside assistance.

The cost of the product is reasonable. It’s not overly expensive.

We are encouraging our customers to go to the cloud. It’s aligned with our business.

I would recommend the solution. I’d rate it eight 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.

We use the solution to host our backend servers.

The most valuable feature is autoscaling.

I would like the ability to connect SMS to EC2 using the VPC endpoint. Currently in the autoscaling process if we have multiple issues we are not able to connect some of the VPC through the SMS.

I have used the solution for two years.

The solution is very stable.

The solution has an autoscaling feature making it very scalable.

The technical support is good.

The initial setup is straightforward. We follow an internal document for deployment and it takes around 15 minutes to implement.

The implementation was completed in-house.

We are using a pay-as-you-go model.

I give the solution a nine out of ten.

We require two people for deployment and maintenance.

I recommend the solution to others.

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.