Amazon AWS Reviews

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.

Amount of services, fully-managed services, and the power of Infrastructure as code (deployment and automation). AWS has many atomic services (Lambda, SNS, SQS. and so on…).

Migration of On Premise Data Center to AWS to allow cost optimization, and full operational automation to focus on experimentation and innovation.

Cross account possibilities for a big IT organization (user management, resources management, etc.).

It would be nice to be able to test Direct Connect without having to pay a line. Also, the possibility to use VPC Peering with one point VPN Gateway (for the moment, impossible).

More than one year.

Not yet.

Not when we know scalability optimization and processes.

I have not call AWS support yet, but it seems to be very fast according to the various returns I had.

Switched to be more global (AWS Region) and more to the way of a serverless paradigm.

Very simple, an e-mail address, a credit card, and the account is open.

The Free Tiers program is great for testing solutions.

Their terms of licencing and reserved instances are very efficient (like Spot Instances for identified workloads).

Not really, I fell in love with AWS right away: their services, quality and quantity of documentation. With the various testimonies that I received, I had no doubt.

The Cloud Adoption Framework and the Well-Architected on AWS documents are a must read.

• RDS: Because of its auto-scaling, multi-zone availability, and its quick spin up of database servers.
• EC2 Servers: For the agility of server provisioning and the AMI automations.
• Lambda: Because of AI capabilities by writing functions that trigger on events.
• Route 53: For traffic engineering.
• WAF: For security and multiple other features of AWS.

Rolling deployments, quick time to market;

From one day deployment time, it came down to 15 minutes.

Easy provisioning means quick time to market when a new environment is required.

The console's UI could be a little better, a fluid User Experience is missing.

For example, in order to see the instance details properly, we have to scroll the description part up or down, which is not a recommended way of doing it.

Three years.

Just once, when MongoDB infrastructure could not mount to EBS.

No.

Excellent. 10 out of 10 for this.

IBM Softlayer and Azure. Both are not automated to the level that AWS is automated.

Straightforward.

Pay per use.

Yes, RedHat OpenShift.

Migrate to AWS for speed and agility, combined with its security features.

The valuable features for us are scalability and flexibility.

Regarding scalability, we have specific days of the week that the traffic in our system exceeds more than twice the load system. So with the scalability, I can support this load. If I need to perform a specific marketing action, my system will respond to the request easily.

Before AWS, the time for availability of a new server would be more than a week, and currently, it can be measured in minutes.

Failover also wasn’t easy to configure and wasn’t safe.

It has helped our engineers to improve our performance both financially and in terms of traffic generated.

I see some applications, like AWS Deploy for example, require usage of other applications. This and other issues should be better explained in the documentation.

We have been using the solution since May 2012.

In the beginning, during the implementation, we had problems with stability, especially in S3.

We did not encounter any issues with scalability.

We don’t pay for professional support. However, the support forum helps us with most problems.

For cloud solutions, during our research, we searched the best quality service inside our budget.

The setup was very straightforward.

Unfortunately, the price is high. The pricing and licensing is explained well in the documentation.

We evaluated other options, including Rackspace, Google Cloud, MS Azure, etc.

Pay attention especially to costs.