Amazon AWS Reviews

We were not a "born in the cloud" company. Our email server solution was first deployed as on-premise, then as a hosted service on bare metal in a data center and then has been ported to AWS.

The main reason to move from hosted bare metal to AWS was the flexibility in adding storage on demand. However, as we worked with Amazon we realized that it could help improve the scalability and availability of our SaaS offering with the other Amazon services.

Using AWS services has allowed us to have a more atomized architecture, which is allowing us to build scale into each service.

We have deployed a variety of services from AWS. Most commonly EC2, EBS, S3, Lambda, Elastic Search, RDS and NFS Gateway.

The cloud storage based on S3 is one the most valuable services we have deployed since it allows us infinite scale in storage and extremely high durability.

AWS is innovating at a very fast pace. They are very customer focused. They keep up and exceed customer expectations.

There was some new learning in terms of IOPS on the EBS storage. The concept of burstable IOPS was new and we did have a few outages when we ran out of IOPS. After moving to provisioned IOPs for the EBS we have not faced any issue.

Once the IOPs are used up, it takes a long time for the burst balance to be filled up. The only option is to move the data to another disk. This causes downtime. It would be better if we could continue to use at the baseline IOPs.

We did not have scalability issues.

Technical support is responsive, accurate and helpful. Right in line with their philosophy of customer obsession.

We have hosted our SaaS offerings on various data centers in India and the USA prior to moving all the workload on to AWS.

The setup itself was not complex. However, it was an involved exercise moving the email data of all our customers from the data centers to AWS without much downtime.

If you want to move all production loads to AWS, the fastest way forward is lift and shift (which is what we did). However, this may prove to be more expensive than bare metal until the time the solution is updated to use the different AWS services. For example, when we shifted the load to AWS we paid a high cost as the mail stores were hosted on EBS. The storage cost drastically reduced after moving to S3.

We did look at Microsoft Azure, but found that AWS had far more flexibility, options and ease.

There can be a tendency to get excited by all the options available. We advise to start small and focus on the services which solve your core problems.

In fact this is the very strength of the AWS cloud platform; easy and rapid experimentation, start small and scale on demand. The flexibility and malleability of the cloud platform has been an all new experience for us.

• ECS (EC2 Container Services)
• EC2
• RDS
• Route 53

At this point, we have been testing applications that are managed by third-parties. The benefit we see at this stage is mainly cost. We are now starting to see the benefits that the platform has to offer.

At this stage, we have found the services we are using are meeting our needs. We have been asked by management to incorporate high-security (encrypted email and data volumes) on all services. Some of the security features require extra configuration to achieve that.

I have been using Amazon AWS for about seven months.

At this point, there have been no stability issues.

Scalability has been good using services like ECS, ECR Load Balancing, and Auto Scaling features.

We have not had a need to engage support for any assistance.

Our previous solution was supported by a third-party. We saw the opportunity to reduce cost by managing it ourselves, in-house.

The setup was easy at first, because a lot of the services are wizard driven. We found as we needed to customise the services further, we had to do most of this manually to get the desired result.

Pricing has been quite surprising, since we are running both DEV and UAT platforms simultaneously. It is definitely cheaper than the solution that has been managed by the third-party.

We did not evaluate other options. This was the one that management had chosen. I do not believe this was based on a technical viewpoint. I just think it was decided.

You have to be able to not think as if on-premises systems are sitting in a data centre. Everything, and I mean everything, is a service that is launched by a script. We are able to run up a platform, say UAT, entirely in about an hour. The plan will be to do this entirely by scripts.

Elastic Load Balancer: AWS completely manages ELB with less configuration from the users' side. Setting up the load balancer manually is really a headache.

Deploying to the elastic cloud is much easier now with AWS. This makes the go-live process easy.

Billing: They should make billing more simplified. It would be great if they could explain how deploying to elastic cloud is much easier now with AWS. Elastic beans command line interface [eb cli]: You can easily deploy code straight from your code IDE.

The billing calculator has lot of options which confuses the user. If they could provide some template for billing and directly execute those template, that would be great.

For example, the billing template for the standard WordPress Server with Load Balancer and S3 Connectivity: Users could just change the parameters inside the template and execute to see their estimated billing.

We have been using this solution for three years.

I did not encounter any issues with stability.

I did not encounter any issues with scalability.

We were using only AWS.

The setup was straightforward in all ways.

Free tier is always there for demo and testing. Pricing is based on the usage.

We evaluated Microsoft Azure.

AWS is good for any kind of requirements.

Auto Scaling and CloudWatch Logs are the most valuable features. With just a few criteria to scale in/out of, you can save the life and time for DevOps.

The CloudWatch Logs feature provides many plugins, so that we are able to manage various types of logs centrally.

In the era, we used private clouds as network virtualization must be controlled by the IT division, server rooms were in the remote branches and DevOps were distributed in various areas. Now, we can use the same API and the same workflow without considering to centralize the logs.

IaaS is sometimes way too complicated to complete one task.

I have used this solution for around eight months.

So far, the VPC is sometimes not that reliable. Therefore, we have to set up a redundant VPC to make sure the connection is always available.

We do not have any scalability issues until now.

I have never used technical support.

Previously, we surveyed OpenStack. However, due to the time, budget and manpower limitations, building a private cloud is not practical in our case.

Managing IaaS was very difficult in the beginning, i.e., tons of jargon to get up and I struggled for months.

Try the Google Cloud Platform (GCP). It is yet another good choice because sometimes, what you need is just a platform and not to build a platform from the infrastructure.

When your division grows to a certain scale and you really need DevOps, then you could move either to a private/public cloud. Otherwise, it is a waste of time and money.

For one of the clients I worked with, it has provided excellent storage solutions and infrastructure for deploying Java and PHP based applications.

It has helped reduce the cost by rationing the computing power and paying only on a per usage basis, instead of provisioning unneeded, idle, or unutilized computing power that is used only at 20% of its capacity or time.

Additional funds saved can be used to develop applications that add value to the business. Also, its features, such as auto-scaling help to manage capacity automatically.

Another feature that we are fond of is the Cloud Formation tool. It helps to test and develop a working technical environment and replicate and modify it as necessary across various regions, clients, and business units.

Features such as EC2, S3, EBS, Auto Scaling, Elastic Load Balancing, VPC (Virtual Private Cloud), RDS (Relational Data Service), Cloud Front, Cloud Formation, Elastic Bean Stack, etc., have been useful for the following reasons:

• EC2: Supports various operating systems, CPU configurations, helps to produce flexible computing power at affordable, customizable rates. You pay for only what you use. No need to pay for unused extra capacity. Build only what you need and pay for only what you use. It can help save tons of dollars in infrastructure cost.
• S3: Low cost, affordable, yet modern storage solution from Amazon.
• EBS: Low cost, yet fast storage solution. It helps to store the needed data in the quickly accessible storage. Also, it helps defending against DDOS attacks.
• Auto Scaling: Helps to quickly scale up, or scale down the capacity as needed. This would help in adding and/or removing computing capacity as per the need and helps reduce cost, yet provide a quick response as needed.
• Elastic Load Balancing: Helps to build redundant, waiting systems for which the demand can be routed as needed.
• VPC: Helps to define our own private cloud with marked input and output ports. Also helps in reducing the electronic footprint and defend against DDOS attacks. Helps to define the private cloud which will provide the needed security and privacy.
• RDS: Helps to dynamically manage the database services. Helps to independently select and/or switch among various database providers such as Oracle, SQL Server, MySQL, etc. RDS helps to free up administrators' time by automating tasks such as backup, maintenance, applying patches, scaling, and replication.
• CloudFront: Helps to define cache of data across various locations and helps to improve the latency of applications.
• Cloud Formation: This is the much needed tool for technical architects. Here one can define the technical architecture they need and play around with it until they get a working architecture. Then the working architecture can be copied, reutilized among different regions, business units, clients, etc. This saves cost and time, reduces errors, and improves efficiency. A much needed tool for administrators and architects.
• Elastic BeanStalk: Helps to rapidly deploy applications across various platforms such as Java, .NET, PHP, Ruby, Python, Docker, etc. It also handles load balancing, auto-scaling, and application health monitoring.

Many of our clients prefer in-house cloud rather than the application data sitting in the infrastructure owned and managed by Amazon. They prefer in-house/hybrid cloud environments.

We did not encounter any issues with stability.

We did not encounter any issues with scalability.

We have not used the technical support much. For the initial solution designing and PoC preparation, we contacted the sales and marketing team from Amazon. They were available and provided the necessary support.

We have used Azure and some other applications. We will continue to use them. We like keeping 2-3 vendors to have a healthy competition and see improvements in the products.

The initial setup was complex, as we needed to build the infrastructure from scratch. It would also require expertise in networking and security.

It is very important to safely manage the keys, as otherwise this would lead to costly security breaches. Some amount of playing around with the setup and replicating it via cloud formation will be needed until your architect becomes perfect with the tool.

It is decently priced. The competition is also bringing its own cloud offerings, such as from Oracle.

We evaluated Azure, Apprenda, and Pivotal Cloud Foundry.

Some of our established clients are going with Azure, especially the ones who had established .NET VB environments. Those who need private in-house cloud are going with Apprenda or Pivotal Cloud Foundry. For small to medium customers, AWS offers a good choice and savings.

It depends upon the requirements and the regulatory compliance issues of the customer. For small to medium customers, AWS is a good choice. For Java, PHP based applications, AWS is a good choice. If you need to have your own private, in-house cloud, there are other options.

Everything is moving into the cloud and AWS is the leader. Not understanding puts a person behind.

I've worked with charities so the ability to host a static website in an S3 bucket at very low cost is great. Also, the ability to scale up and down, depending on project and funding status is ideal for the charity sector.

Glacier storage means files that need to be kept for legal purposes (7 years) - but accessed infrequently - can be stored cheaply in Glacier.

• S3 storage buckets
• Glacier storage
• EC2 instances
• Cloud Trail API log storage

Amazon are as innovative as they are able to deliver. Areas that need improvement are dealt with pretty quickly so I have no complaints. Perhaps the fact that they are innovating so quickly can be seen as a problem for organisations that don't invest in their staff?

None. Amazon's cloud is more stable than any infrastructure you will have in your own server room.

It's very easy to spin up virtual machines and deploy load balancers.

Customer Service:

For free support, their forums cover almost every problem encountered by users on AWS. For one-to-one problems, I found their customer service people to be good.

Technical Support:

Technical support is excellent.

I used to use Rackspace but AWS's innovation and range of products meant I swapped over.

It can be daunting because of the number of AWS products there are. It doesn't take long to skill yourself on the basics of what each one does (in the beginning you will probably be using S3, EC2, and IAM and there are lots of short courses or guides to read).

AWS is scalable depending on your needs so pricing is dependant on what you use. Just be careful not to leave VMs running as you can find your next monthly bill a little higher than normal - AWS did cover that with billing alarms so it's not all bad news.

The price point and ease of use are the most valuable features. The cost per GB per month has always been reasonable. 

It is easy to set up buckets and upload files using the AWS Console.

The ease with which you can move files from short-term (S3) to long-term storage (i.e., Glacier) via a dashboard. With the introduction of Glacier as a long-term storage option, having some type of function key to simplify the transfer of files between the S3 and Glacier environments would be beneficial and increase efficiency. Perhaps it could be incorporated as an option when using the S3 Service or Glacier service; i.e., a "Transfer to Glacier" and "Transfer to S3."

I have been using AWS S3 since 2007 or 2008.

We have not had any stability issues.

We have not had any scalability issues.

We previously used in-house data storage (HD and NAS).

The initial setup was easy and straightforward, as opposed to some other solutions.

I cannot speak to the licensing questions, but the pricing per GB/month is reasonable and competitive.

We didn’t look at alternatives, as it was the first cloud platform solution on the market at the time, at least that I was aware of.

There are a plethora of options, but it certainly should be given primary consideration.

I have been providing consulting services around the cloud solution for the past four to five years, during which AWS was the market leader and the de facto cloud service. AWS definitely helped me to help my customers adopt a cloud strategy smoothly and in a timely manner.

Elasticity has always been AWS's mandate. The flexibility of their platform from a systems perspective lives up to its claims.

• I would have hoped that their networking model was a little more network oriented and flexible, as is their systems model.
• The networking models used in AWS, while functional, do have room for improvement. This is especially the fact, considering that they are built/presented from a systems perspective.
• More granular control of networking, as well as a richer set of networking features, could really go a long way in building globally scalable infrastructures.
• The Identity and Access Management (IAM) authentication model could use some work as well. The fact that it isn't very straightforward/streamlined to authenticate applications that are not running on AWS infrastructure can complicate things when trying to use different (non-AWS) environments for specific activities. A simple and common example of this is working in a development environment, and having code that relies on interacting with AWS services. Being forced to store sensitive key information in your codebase isn't a very secure manner of operations.
• Given the recent surge of adoption and interest in containers and container orchestration, Amazon ECS is seen as a proprietary Amazon service. This makes it impossible to use Amazon ECS on other platforms, whether for development purposes, or for rolling out multi-cloud types of deployments. If you use an alternative, such as Kubernetes, this can easily be configured and ported to any environment, as it is an open-source project.

I have not had any issues with stability on AWS. However, it is worth noting that they did have uptime issues in the past. While there weren't many issues, they still did happen.

The only issue that I faced with scalability was due to the soft limitations that AWS applies on the allowed number of resources, e.g., the number of VPCs per account, the number of EIPs per VPC, etc.

I do not have much experience working with AWS's technical support. However, their forums are vast and pretty full of useful information.

AWS was sort of the first of its kind, so I did not use a different solution previously. However, today I find myself a lot more invested in the Google Cloud Platform, as oppose to AWS.

It was relatively straightforward to install. I have read reviews of others facing issues with getting their accounts approved. However, I never faced such issues.

Be careful with your consumption, especially when you are testing things. Costs can creep up on you relatively fast, without even noticing.

As mentioned earlier, since AWS was the first of its kind, I didn't really have many other options at the time. I remember one of the other players at the time was Rackspace, but they were considerably more expensive than AWS.

Picking a cloud platform is not a process that should be taken for granted. The leading cloud service providers today each have their pros and cons. It's best that you assess your options, and start with the cloud platform that best suits your needs. After that, your next step would be to start considering a multi-cloud strategy.