Right, but they add quite a bit of margin from what I see. Correct me if this comparison is not fair:
Fly.io, 8 vCPUs, 32GB RAM (dedicated-cpu-8x): $398/mo
AWS, 8 vCPUs, 32GB RAM (t3.2xlarge, us-east-2): $240/mo
So, 65% more expensive. Quite steep.
Fly.io, 8 vCPUs, 32GB RAM (dedicated-cpu-8x): $398/mo
AWS, 8 vCPUs, 32GB RAM (t3.2xlarge, us-east-2): $240/mo
So, 65% more expensive. Quite steep.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstabl...
> The EC2 burstable instances consist of T4g, T3a and T3 instance types, and the previous generation T2 instance types.
Your point still stands.
Here's a m6g.2xlarge with 32GiB of memory and 8 vCPUs (AWS Graviton2 Processor / arm64):
https://instances.vantage.sh/aws/ec2/m6g.2xlarge?min_vcpus=8...
Monthly cost: $224.84
Fly compares better on the low end of scale.
AWS t3a.nano 512MB (2vcpu but 1h12min burst only, you can normally only consume 5% of that!) is $3.431/mo
Fly shared-cpu-1x 512MB 1vcpu $3.19/mo
When you consider ARM vs AMD vs Intel vs current-gen vs last-gen, AWS sells several 8-core 32-GB machines that have wildly varying performance characteristics.
It used to be that the manner of virtualization impacted performance, too. I think that might be less the case now.
To know if you're getting good value, you really need to try a few different vendors and benchmark then, either with real workloads or synthetic ones.
This is actually a benefit of AWS and other large public clouds. You have a choice due to their size.
If AWS's investment in Gravitron design works well for your workload, it's a ~30% cost savings. They're able to invest in designing and producing the chips due to their size. A company like fly.to is limited in selection and heavy R&D.
The OP was asking what was "most comparable" to Fly's offering. I assumed they meant "what would similar performance cost elsewhere".
By switching from Intel to ARM, they're buying something fundamentally different. Maybe it's a better fit overall! But I didn't understand that to be what they were asking.
I wasn't sure what the dedicated instances for fly.io were running on (can't find it on this page: https://fly.io/docs/about/pricing/#plans). To truly do an apples / apples compare there's networking capabilities, storage, and other considerations also.
They're charging you more for the convenience of `flyctl region add lhr` or whatever it is vs figuring out the routing & VPCs for example in AWS yourself.
It's not all roses though, I find the docs a bit lacking (good on networking - bad on security & storage) and the price of that convenience (aside from literal price) is that it is limiting - as soon as you think 'well I just want a very simple firewall/security group wall' or 'what's the equivalent of allowing only this x to y with an IAM policy', nope, can't do it.
Surely the amortized costs of the Fly.io platform don't scale linearly with the power of the VMs you rent from them. A 64GiB server won't be twice as expensive to maintain as a 32GiB one. So why not create a model that e.g. consists of a cost per VM/autoscaling group/etc plus whatever the VMs cost?
I'm genuinely interested, I could very well be missing something.
It's not just RAM, though, our physical servers have a consistent ratio of RAM/CPU/disk available. You're basically just buying slivers of hardware we've already paid for.
That said, our pricing isn't far off of AWS. They have much better economies of scale than we do, and can afford to do Graviton, but you get pretty close horsepower per dollar for comparable instances.
I used it in above comment as a shorthand for the fact that such an API/functionality exists that you can just say to Fly.io (whether via CLI or ~better~ other means) 'hey stick this in a second region too'.
flyctl is a reasonably simple GraphQL client. They haven't really documented the GraphQL API (see e.g. https://fly.io/docs/app-guides/custom-domains-with-fly/#grap... for one slice of it), but that's all flyctl does.