41–50 of 79 posts
"Cross-region IPv6 frontend IP configurations aren't supported." -- sigh.
It would be an interesting experiment to see what is the cheapest set of VM-like workloads that can be spun up in every region...
Earlier quoted context omitted.
Cloudfront caches content at edge locations near users whilst Accelerator routes requests to the nearest endpoint to the user.
If I am understanding it correctly, Cloudfront can use Accelerator to find the nearest edge location to cache, right?
GA is similar, but more like a global anycast routing layer/load balancer. You can have multiple backends, different regions etc, use a single public GA endpoint, and GA will route the request to your nearest backend.
You could use a GA endpoint as an origin for Cloudfront, I guess, to keep all traffic as near to the client as possible.
It is 2021, and AWS Global Accelerator still does not support IPv6. Google Cloud has supported this on their global anycast load balancers since September 2017.
Full disclosure, I work at Fly.io now. This exact setup is easier on Fly.io - our proxy layer runs in 20 regions worldwide with anycast, so your requests hit the nearest region and quickly terminate TLS there. You can also run any Docker container, and either choose regions to run them in, or just set the min/max and ask us to start and stop containers in whichever region has demand, so your deployment follows the su…
I really like Fly and would love to move some side project workloads to it, the only thing holding me back is the Postgres product which seems to be a little bit 'not ready for production'. I'm referring to point-in-time recovery and ease of backup restoration mostly. The product looks too good to be true, and when you dig into a little deeper it seems like it isn't totally 100%. Amazon RDS is something that I really…
Their response was this: > Our goal in life is to solve managed postgres in the next few months. Either us managing, or with someone like Crunchy Data running on top of Fly. So “hold tight” might also be good advice.
But what are the costs and scalability? EC2s in many regions + Global Accelerator is a completely different pricing model to pay as you go serverless (and, depending on your use case and usage patterns, more or less expensive), and scaling is entirely up to you. It's cool to optimise for latency, but it would have been nice to have resulting costs and downsides (scaling).
3x t3a.small @ $13.72/month. = $41.16/month.
A 3 region single node web app could be done for under $60, dropping to around $43 with instance reservations. With a config this small there is no need for regional LBs, and even if you have multiple instances per region, GA has configurable internal flow hashing.
The dominant cost for any real site will likely continue to be bandwidth. GA pushes egress pricing up substantially in many cases, from 1.5c/GiB to as much as 10.5c/GiB, but this is unlikely to be a concern unless you're serving heavy images or video.
Autoscaling works the same as anywhere else. You can use spot instances, or even front ALBs with GA and build your whole app out of Lambda functions (although this would assuredly completely negate any latency benefit gained by using GA in the first place!).
I read the first six paragraphs and still really had no idea what this is talking about. Can anyone help me understand?
The author likes AWS Global Accelerator. The author likes GA mainly because it uses BGP anycast, which means that the packets drop into AWS' network at the closest AWS point-of-presence, instead of traversing the internet. The author's experience is that this feature of GA, when combined with always-on VMs that do not need to cold start, provides him low latency for a particular service he is running. The author also…
Full disclosure, I work at Fly.io now. This exact setup is easier on Fly.io - our proxy layer runs in 20 regions worldwide with anycast, so your requests hit the nearest region and quickly terminate TLS there. You can also run any Docker container, and either choose regions to run them in, or just set the min/max and ask us to start and stop containers in whichever region has demand, so your deployment follows the su…
Correct me if I am wrong: fly's anycast has its limitations compared to Global Accelerator (GA) though: On ocassion, it breaks UDP protocols that are "connection oriented" (like QUIC and WireGuard, though both have built-in capabilities to recover). There is no way to pin traffic to VMs (route / client affinities) or shape traffic. 100+ locations with GA, and two Anycast IPs (in two distinct "zones"). --- Alternative…
> On ocassion, it breaks UDP protocols that are "connection oriented" (like QUIC and WireGuard, though both have built-in capabilities to recover).
Yes, and no, in that QUIC and WireGuard do work consistently, it's not that they break. But Fly doesn't currently offer UDP flow hashing or sessions or pinning.
> There is no way to pin traffic to VMs (route / client affinities) or shape traffic.
No, but the system is built to obviate the need for this — you can choose which regions your app runs in and Fly will balance them for you based on the strategy you choose. I'm not sure what benefit is being missed out on by not having it — if there is a clear benefit that's not achievable under the current design we can make a case for building it.
> 100+ locations with GA, and two Anycast IPs (in two distinct "zones").
Fly lets you allocate and buy more IPs under Anycast, so more than two should be possible. Regarding the 100+ locations, that's technically true but irrelevant — GA doesn't serve requests, so they still need to hit apps deployed on one of the AWS regions (usually provisioned and managed separately). With Fly your app is running on the edge regions pretty much automatically.
The closest alternative to Fly on AWS would be (1) Global Accelerator pointing at (20) Application Load Balancers in every region, each backed with (1+) Fargate containers maybe? Would also need Lambda triggers to turn off traffic to a region if it wasn't worth running containers there, and turn them back on again.
Full disclosure, I work at Fly.io now. This exact setup is easier on Fly.io - our proxy layer runs in 20 regions worldwide with anycast, so your requests hit the nearest region and quickly terminate TLS there. You can also run any Docker container, and either choose regions to run them in, or just set the min/max and ask us to start and stop containers in whichever region has demand, so your deployment follows the su…
I really like Fly and would love to move some side project workloads to it, the only thing holding me back is the Postgres product which seems to be a little bit 'not ready for production'. I'm referring to point-in-time recovery and ease of backup restoration mostly. The product looks too good to be true, and when you dig into a little deeper it seems like it isn't totally 100%. Amazon RDS is something that I really…
Ultimately, we think devs are better off if managed database services come from companies who specialize in those DBs. First party managed DBs trend towards mediocre, all the interesting Postgres features come from Heroku/Crunchy/Timescale/Supabase.
So we're "saving" managed Postgres for one of those folks. For the most part, they're more interested in giving AWS money because very large potential customers do. At some point, though, we'll be big enough to be attractive to DB companies.
Earlier quoted context omitted.
If you don't know, DNS are cached at multiple layers, including ISP.
This is technically correct but don’t rely on caching to solve this problem. Unless you’re getting a ton of widespread traffic you’ll probably be getting more cache misses than you expect - every time I did client-side monitoring, the DNS 90th percentile was quite notably higher than the 50th.
Servers that use geo DNS (EDNS-Client-Subnet) also cause considerable cache misses since the caching becomes very granular.