ocdnix

Fascinatingly effective, but maybe I'm the only one getting the heebie-jeebies when someone suggests implementing this in production corp networks. Sure it's super convenient, but the thought of bypassing all traditional NATs and firewalls, and instead relying solely on a software ACL, seems super risky. Maybe I just don't understand how it works, but it seems that a bad actor getting access to a stray VM with Tailscale on it in, say, your AWS testing env, essentially has an clear path all the way into your laptop on the internal corp network, through the kernel, into user space and into the Tailscale ACL code as the sole arbiter of granting or blocking access. Would I even know someone unauthorized made it that far?

This lists r7iz at the top, and AWS says they run at 3.9 GHz. Dunno where this leaves the m5zn and x2iezn family (at 4.5 GHz), or even the z1d (at 4.0 GHz). Frequency isn't everything, but seems strange that they're not to be found in the table.

What pain points do you see with Amazon ES, if I may ask? I'm considering migrating to it.

How do 32 and 64ths look if you swing on 16ths? Do they end up on a sine-like interpolated curve of sorts, or do changes in velocity happen instantaneously like a square wave?

That cloud provider should be AWS, no? There's no corresponding incident on AWS' status page, which seems a bit strange.

With AWS Route 53's 10 000 records/zone, 400 values/record 255 chars/TXT and base64's ~35% overhead, you have a bit over 600 megabytes of binary value storage.

This doesn't cover other interesting uses, like tag-based automation. Random examples: Tagging DynamoDB tables to identify which should be backed up and at which frequency (when you don't quite trust the built-in backup); tagging dev RDS databases with a shut-down schedule for nights/week-ends; tagging Elastic IPs and Auto Scaling Groups with a "IP pool ID", and a Lambda that re-assigns EIPs to ASG instances as they are recycled; using a "data flow ID" tag on resources that are in the hot-path of data flows that are subject to high-volume bursts, so you can easily list them and scale them up before known events.

Turns out this is about EC2 spot instances for ECS. How would it compare to ECS Fargate spot these days?

I'm also missing a discussion about designing for interruption, either by not keeping state, or by being able to shed state quickly, to be picked up by other instances.

Also, if you set up EC2 spot with a launch template or ASG with very differently-sized instance types (to reduce risk of running out), is there a way to even out the load coming through an ALB? The least-connections scheduling can help in some cases, but a connection might not map 1:1 to one unit of load. The ALB can use weighted balancing, but on the target group level. Dunno how easy it would be to allocate different instance sizes to different target groups and weigh them accordingly.

If I were to do it again, I'd consider either that or building it directly on EC2, preparing the AMI with Packer or something, and handling scaling with an autoscaling group.

I really hope it can replace PgBouncer. We've spent way too much time getting it running in ECS, mostly due to us needing a separate PgBouncer service for the primary and replica RDS instances. And then a third ECS service running HAProxy in TCP mode to load balance between the PgBouncer services, to provide a read-only endpoint that balances between the primary and replica. Add issues like: having to patch in HAProxy TCP keep-alive parameter support (it only allows enabling/disabling it, leaving params up to the OS, which you can't control on ECS Fargate, _and_ the AWS NLB having a 350-second TCP flow idle timeout - good luck with long-running queries); AWS NLBs having horrible timing issues when handling target group changes... it was not a great experience.

Yes, for about a year now, both in the console (alacritty) and vscode, and I think it's great. Granted, I mostly ignore it, which is a good thing.

I frequently change the term emulator font size, and each size oddly changes the "aspect ratio" – for lack of a better term – of both Plex and any other monospace font. I find it weird, but it does sometimes help to have a somewhat narrower variant of Plex, especially for side-by-side terminals.

This looks like it an interesting alternative to Gravitational Teleport.

Do you run into problems with Lambda's 5-minute maximum execution time for those kinds of operations? I'd like to do something similar to this for both RDS and DynamoDB, but the execution time will often surpass 5 minutes, meaning I'd have to run a Step Functions worker on EC2 or ECS. That opens up a whole bunch of complexity with managing the worker code and its deployment, which I'd rather avoid if possible.