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?
Readit Newsocdnix commented on How NAT Traversal Works (2020) tailscale.com/blog/how-na... · Posted by u/hhthrowaway1230
ocdnix commented on What's the fastest EC2 instance CPU? runs-on.com/reference/ben... · Posted by u/crohr
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.
ocdnix commented on Amazon Elasticsearch Service Is Now Amazon OpenSearch Service aws.amazon.com/blogs/aws/... · Posted by u/daigoba66
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?
ocdnix commented on Normalizing AWS IAM Policies for use in automated analysis steampipe.io/blog/normali... · Posted by u/dboeke
Reminds me of Lyft's thing from a couple of months ago: https://news.ycombinator.com/item?id=25000950
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?
ocdnix commented on Slack Incident Jan 4 2021 Root Cause Analysis [pdf] devopsish.com/pdf/Slack-I... · Posted by u/sciurus
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.
ocdnix commented on AWS NLBs and the mixed up TCP connections niels-ole.com/cloud/aws/l... · Posted by u/nielsole
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
ocdnix commented on AWS Tagging Best Practices cloudforecast.io/blog/aws... · Posted by u/toeknee123
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.
ocdnix commented on Designing a scalable API on AWS spot instances blog.adapty.io/designing-... · Posted by u/iwitaly
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.