Amazon AWS Reviews

Our primary use case is a corporate web page with e-payment eCommerce and personalized functions for digital marketing and other functions.  

Rapid implementation using tools that I specifically know: Python Django Mezzanine and several other libraries are compatible with these technologies.

IaaS with easy management, but training is required in a more personalized way. There should be required free training from the vendor and more personalized.

More complete, specific training for many of the technologies, specifically with Python Django and the CMS (Mezzanine).

Our primary use case is to use the solution for running many relatively small instances for back office applications and various other business important applications.

It did not improve our organization.

There are no particular 'features' which stand out. 

The pricing could be adjusted to provide more advantages versus current on-premise solutions for business applications.

AWS is much too expensive compared to current on-premises solution for this type of work. AWS IaaS is a very generic service, which is extremely overpriced.  

Web server hosting of a simple LAMP setup using Linux, Apache, and MySQL. Quick, cheap proof of concept solutions. 

No need for an on-premise infrastructure. It provides immediate access to vast resources at a relatively low cost and allows for setting up cheap PoCs.

For testing, it is a cheap alternative to having to build your own labs.  Provisioning and resource administration include billing dashboards, which are very extensive.

Not enough experience to really comment on this. 

In some areas, more transparency on what is persistent towards novice users. 

In recent years, we have use AWS primarily for its serverless capabilities. It has the ability to scale up from one to 10,000 vCPUs for a few brief seconds. The vCPUs perform intensive calculations with deep learning (artificial intelligence calculations), which is not possible via traditional computing approaches.

AWS helped us reduce costs from CapEx to OpEx. Some of the introduced one-year and three-year reservations helped us reduce costs early on. With time, we learned how to minimize our at REST capacity, allowing us to scale up and scale down in near seconds. 

Serverless computing: This can be more cost-efficient just regarding computing resources than renting or purchasing a fixed quantity of servers, which involves periods of underutilization or nonuse. It can even be more cost-efficient than provisioning an autoscaling group, because even autoscaling groups are typically designed to have underutilization to allow time for new instances to start up.

Also, a serverless architecture means developers and operations specialists do not need to spend time setting up and tuning autoscaling policies or systems. The cloud provider is responsible for ensuring that the capacity meets the demand.

AWS Marketplace: Somehow Amazon associated their marketplace as a place to find images of various installs (preconfigured software) and was late in the game enabling and promoting SaaS-based solutions. Thus, the AWS marketplace has near zero awareness in the mind of the prospect to find solutions to various problems plaguing them. 

No stability issues.

No scalability issues.

They are mainly generalists without access to the operating system. As such, they can provide container level insights,not necessarily at the application level.

I have used AWS for the last eight years since 2010. Previously, we used various VPS, dedicated servers, and Amazon's solutions, which were crude but a promise for something beyond the traditional infrastructure options. 

It was straightforward.

No vendor team was necessary.

We are reducing costs year-over-year.

Much faster than other solutions at a super low cost.

One of the best-kept ways to reduce costs is to develop it on serverless technologies with AWS Lambda, SNS, DynamoDB, and S3. Business example: By deploying our websites on Amazon S3 instead of the traditional Apache web servers, we eliminated many of the compute costs. Our WordPress site is served by a static S3 bucket. One of the benefits of this is our sites are superfast, especially with CloudFront. CloudFront makes the S3 hosted sites available across the world in milliseconds, reducing network hops and costs similar to that of Akamai. 

Just imagine the headaches associated with Apache web servers, MySQL databases, and Nginx reverse proxies? 

We hosted our website in the Amazon AWS. This is very easy to use and the user-friendly dashboard. 

Amazon AWS has improved our organization. It has all the features which we need. We can spin up the server anytime and have root access to it. We built our website and hosted the Amazon server. We also set up the RDS database, which has the capability to help the MySQL queries. The user interface is very user-friendly, and you can assign Elastic IP anytime. Overall, this is the best IaaS for hosting the website and the database.

1. Spin up the server when we need it: We can spun up the new server. 
2. Elastic IP: Sometimes, our website gets hacked with malware and it is easy to change the IP of the Instance.
3. Snapshot: We can easily create a snapshot in Amazon AWS, then restore it.
4. RDS: Manages all the database queries.
5. Instance upgrade and downgrade: We can easily upgrade and downgrade the Instance.

Technical support: It has the technical support features, but they need to be improved. It has lots of users, but they need to be managed accordingly.

One of the best things in Amazon AWS is you are billed for the service you use. 

To access systems of partner/vendor companies, we maintain an instance to transfer data to our instance, then privately back to us. Basically, a BRAS, B-RAS or BBRAS device.

It improves the speed for us to access vendors, etc. AWS is extremely slow over the internet. Where we have GigE fiber over dedicated OC48 links, and when ping times to Dallas, TX from San Francisco is 30ms RTT on average, AWS is always 20ms higher. To AWS East, it is 70-110ms RTT, and the data transfer almost seems throttled. So I spun up an instance, made a BRAS image, like how DSL customers access the internet, and set up a peer with AWS to transfer data privately, then publicly from our instance to the AWS IP of our vendor, or partner and it has improved response times dramatically. The average API access latency was 250ms, horribly slow - already authenticated, etc. 

We also use it for our Amazon Seller Account and Amazon Vendor Account, where Amazon's systems run. Amazon recently moved their systems to CloudFront, but AWS DNS is awful slow. So the BRAS helps with the DNS as well.

Bidding on instances with dynamic pricing. So, I can do something that is not critical in terms of speed, like a production system, but testing and bid at an uber low price, and I will usually get what I want.

The network is way overloaded. Comcast is overloaded. So between the two, it sucks.

I am used to Level (3) or Verizon/Alter.net AS701 with fabulous ping times and throughput, where I click something and it works. 

It is the problem with the nomenclature of SDN [software defined networking] as engineers today do not understand networking, TCP/IP, or anything. I was 18 during the .com bust, but I remember accessing tools, as I worked for a Global ISP NTT, which owned Verio, the largest webhost at the time. We had Dual OC-3's to our office, when our office was just a remote NOC, but we had cloud computing before it was nomenclature. We accessed customer data, and had tools to do things quickly, instead of logging into routers, IDS, IPS, switches, and server. If it was a repetitive task, it would be via a browser, and the browser accessed a txn server rather than run cron jobs every 15 minutes. I will say that AWS for API, or Seller Central, is no improvement from what we had (our internal tools we designed to update accounts, change customer network profiles, monitoring, MRTG graphs, etc), when AWS should be blazing. 

Accessing apps on AWS via my iPhone is awful. Apple is behind the times in speed, battery, and even the screen, but it is aesthetically pleasing, so it wins. Android devices by Samsung are superior, but I use iPhone because that is what we use in Silicon Valley, which is on Verizon's LTE Advanced (LTE-X is their coined term) network, and the latency is great, 20-30ms, speeds of 40 Megabits/s, symmetrical are quite common, and sometimes I see 150/150 Megabits/s.  

When they first moved Amazon Seller Central to AWS CloudFront from AWS, I would see connections to Hong Kong and Singapore. Maybe I was sent there because the USA East was overloaded. I do not know. So, we started using Verisign for recursive DNS, and to host our own domain name(s), and I noticed, it fixed the problem. Every ISP and DNS server, either Unicast like Level(3) 4.2.2.1-4.2.2.6, Google 8.8.8.8, NTT was the best performer 129.250.35.250/251, Comcast was garbage, while on Comcast network 75.75.75.75, Verizon was good (FiOS [consumer and SMB], and Enterprise which is what we have aka MCI aka UUNET/Alter.net AS701/AS702/AS703), and SprintLink AS1239 was good.  However, we just tested Sprint, and Verizon. Verizon provides backup services for us, actually tertiary, we provide our own secondary.  So I signed us up with Verisign with DDoS protection, made Verizon secondary, and the feed server from us, feeds VeriSign and Verizon. That fixed the AWS CloudFront location issue, which to me, shows how poor AWS DNS is.

We would get responses that are AWS Hong Kong, even when they moved to CloudFront to speed up Seller Central (I complained to corporate via a letter FedEx'ed to Amazon). I asked for a private MPLS link, which we would pay for, and we were told it would be worked on. During peak times, it would lag and time out, it was awful. It still lags, but I route as much as we can via the BRAS setup. 

I have pushed clients towards Microsoft Azure. I have bugged Microsoft to add links to their network in the BNA region, BNA to Atlanta (additional link), BNA to MCI aka Kansas City, BNA to Chicago, BNA to WDC, and BNA to Dallas, TX to improve access for things at BNA. It is not critical. It is just the only facility that is 30ms slower than others. Azure in Chicago, Wyoming, Bellevue, Silicon Valley, Los Angeles, or Texas is very low latency. 

I have also pushed clients to IBM Bluemix, as their partnership with Akamai makes API access is really fast. Azure with Verizon CDN/Terremark is fabulous.

I have to add this. AWS sucks, even though I am a customer.

AWS's innovations are incredible.

You can migrate complex environments to AWS Cloud reducing costs, improving performance and scalability.

I have used AWS for five years.

Yes, every platform has problems, but they are very fast at solving the problems.

Yes, every platform has problems, but they are very fast and they are always working to improve.

No, I never encountered any issues with scalability.

Their priority is the customers.

The technical support is the best.

No. I tried to use Azure, but I can't.

Yes, the initial setup is not so straightforward. The concept changes and you will need to understand this.

AWS provides a lot of solutions to design secure, elastic and serverless software architectures.

More than 30 BBVA Group web pages are working without servers, saving costs and reducing security problems, with AWS services like CloudFront, WAF, S3, Lambda, SQS, and API Gateway.

All our infrastructure is defined in JSON files, thanks to CloudFormation, which makes maintenance and creation of new clone environments easier.

Lambda@Edge, for example, it's new and has a lot of room for improvement.

Four years.

It is usual with new functionalities, but AWS does resolve stability issues quickly.

With CloudSearch; the service finally autoscales but in excessive time. You never lose information, but you can't access new data when there are peaks of requests for creation of new documents.

Seven out of 10.

Yes, I used OVH and other cloud providers like Azure or Google. AWS is much better. It is a complete platform.

Required some service, but in general there is a lot of documentation and there are training courses.

AWS is appropriate for professional solutions. For other types of projects it's a bit expensive.

Azure, Google Cloud. AWS is years ahead of its rivals.

Think "serverless". With AWS you can design your architecture, thinking distinct and oriented to events, decoupling processes, solving possible errors, multi-region or Multi-AZ.