I have a feeling a huge chunk of the projects we see here are run on AWS. Duckduckgo runs on AWS. For getting things started quickly at a low initial cost, it's usually more viable to use a hosted solution (AWS, RackSpace, Digital Ocean, etc.)

However once you get big enough, the cost savings usually start falling the other way. Several companies I've been at have moved from using hosting to running their own boxes, either co-located or in their own data center (the CTO like to call this, "moving to our own private cloud" or some other marketing bullshit). Even then, careful decisions are made on to what to host locally and what to keep on a managed service due to cost.

Having this on AWS is perfectly fine. I even think it's viable to look at Hyper.sh as an alternative to Elastic Container Service, even though both are being hosted on AWS. But if it's hosted on AWS, it's important that people actually know that. If someone wants to build a highly reliable system, and they pick 2 resources -- let's say Hyper.sh and AWS ECS as the most likely candidates for that -- it's pretty important for the customer to know that both resources they're relying on are on the same service, and even possibly in the exact same data center, as that affects how effective their redundancy actually is.

As another side of the same point, hyper on AWS shifts the balance of costs for me as if I want to store my data in S3 it changes whether or not I've got to pay for network egress.

There are plenty of big companies that stay on AWS. Netflix is the obvious example. Companies like Zynga and Activision are moving gradually from self hosted to AWS (from what I hear).

Once you are big enough to be able to negotiate prices that are nowhere near the published prices for AWS, it clearly can start becoming cost-competitive...

Another thing to remind you is, E5-2630v4 was released in Q1 2016, which is not an old CPU

http://ark.intel.com/products/92981/Intel-Xeon-Processor-E5-...

Not on aws at all.

The hyper.sh API address is us-west-1.hyper.sh, which looks like the AWS style, however, it is not an AWS address and it is located in an independent IDC around Los Angels.

Edit: Tried it and confirmed it's indeed not on AWS, updated my previous comment.

Original: Not on AWS at all doesn't seem possible

The docs for Floating IPs [1] list 52.68.129.19 as an example, which is an AWS Elastic IP.

The docs for the API [2] says "Hyper.sh API signature algorithm is based on AWS Signature Version 4", and then proceeds to explain the differences, which is variable names. The API Domain is us-west-1.hyper.sh, which is the same URL schema as AWS (us-west-1 is also AWS's North California region).

Maybe the containers themselves are somehow not on AWS? Sure. But not on AWS at all doesn't seem to be the answer.

1. https://docs.hyper.sh/Feature/network/fip.html 2. https://docs.hyper.sh/Reference/API/2016-04-04%20[Ver.%201.2...

Based on AWS v4 does not means aws v4 is employed, on the contrary, the docs explains the signature of hyper, which uses different literatures.

At last, you can try it. Then you will found it is totally different from AWS.

You can try the api address us-west-1.hyper.sh

Resolves to 65.255.36.153 and 65.255.36.154, which don't have reverse DNS, but Maxmind Geolocates to China.

In Los Angels

I don't think AWS allows you to do nested virtualization. Perhaps they have a hack?