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.
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?
I would love to get answers to questions like "which users have access to resource X, including implicitly through one or more assume-role jumps, across these N accounts, including stuff like iam:PassRole, even including tag-based policies?". Add a time dimension too, like "who had access to X between Jun and Aug 2020?", and you'd have a winner. Would such queries be possible here?
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.
I was expecting this to be about the NLB's strange "lag" in updating its flows, wreaking havoc when it comes to changes in the target group, and possibly also relating to weirdly long delays before starting health checks of newly registered targets. I'm bewildered why this hasn't been more of a problem for others, and also why AWS seem to have kind of silently acknowledged the issue (by not closing them), while not coming up with a fix, even after a year. Am I the only one seeing this problem? Ref: https://github.com/aws/containers-roadmap/issues/470 and https://github.com/aws/containers-roadmap/issues/469
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.
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.
I'd like to have metadata about the materials used in the lenses, specifically info about wetting agents. My go-to lens is Acuvue Moist, which has the "Lacreon" wetting agent, aka polyvinylpyrrolidone. When my lens store stopped carrying Moist, I had a hard time figuring out which other brand would have an equivalent gradual moisture release effect, given the jungle of proprietary material names. I'm not saying I'd like to see the chemical formula for each lens (although that would be nice too), but some physical parameters beyond brand name and type of lens would be useful.