Live data from Hacker News

AWS in 2025: Stuff you think you know that's now wrong

lastweekinaws.com

201–210 of 284 posts

Re: AWS in 2025: Stuff you think you know that's now wrong

#201

Can no longer login to my AWS account, because I never set up MFA. Want to set up MFA ... login required to request device. Yes, I know, they warned us far ahead of time. But not being able to request one of their MFA devices without a login is ... sucky.

Talk to support: https://support.aws.amazon.com/#/contacts/one-support?formId...

I did. That's just an AI, which says this:

> I understand your situation is a bit unique, where you are unable to log in to your AWS account without an MFA device, but you also can't order an MFA device without being able to log in. This is a scenario that is not directly covered in our standard operating procedures.

The best course of action would be for you to contact AWS Support directly. They will be able to review your specific case and provide guidance on how to obtain an MFA device to regain access to your account. The support team may have alternative options or processes they can walk you through to resolve this issue.

Please submit a support request, and one of our agents will be happy to assist you further. You can access the support request form here: https://console.aws.amazon.com/support/home

That last URL? You need to login to use it ...

Re: AWS in 2025: Stuff you think you know that's now wrong

#202

Earlier quoted context omitted.

This is the intended use case for S3 VPC Gateway Endpoints, which are free of charge. https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpo... (Disclaimer: I work for AWS, opinions are my own.)

I think they know it. They are complaining it's not enabled by default (and so do I).

I've been testing our PrivateLink connectivity at work in the past few weeks. This means I've been creating and destroying a bunch of VPCs to test the functionality. The flow in the AWS console when you select the "VPC and more" wizard does have an S3 Gateway enabled by default

Re: AWS in 2025: Stuff you think you know that's now wrong

#203
post #43

Earlier quoted context omitted.

Fair point, and valid for S3 (the topic at hand) and DynamoDB. Other AWS services, though, don't support gateway endpoints.

https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-e... ~~I get the impression there are several others, too, but that one is of especial interest to me~~ Wowzers, they really are much better now: aws --region us-east-1 ec2 describe-vpc-endpoint-services | jq '.ServiceNames|length' 459 If you're saying "other services should offer VPC Endpoints," I am 100% on-board. One should never have to traverse the Inter…

Those are VPC endpoints, not gateway endpoints.

Re: AWS in 2025: Stuff you think you know that's now wrong

#204

I haven’t used AWS in the last 5 years. Is IPv6 still somewhat of an issue? I remember some services not supporting it at all and making it impossible to manage as a IPv6-only network.

You'll be glad(sic) to know they have specialized hostnames for IPv6 control plane endpoints, because AAAA records scare the olds https://github.com/aws/aws-cli/blob/2.28.14/awscli/botocore/...

We enabled ipv6 for our APIs at work. Nothing broke immediately, but we've had a steady stream of unreachable host errors related to ipv6 since then.

Turns out there're many incorrect implementations of Happy Eyeballs that cancel the ipv4 connection attempts after the timeout, and then switch to trying the AAAA records and subsequently throwing a "Cannot reach host" error. For context, in Happy Eyeballs you're supposed to continue trying both network families in parallel.

This only impacts our customers who live far away from the region they're accessing, however, and there's usually a workaround - in Node you can force the network family to be v4 for instance

Re: AWS in 2025: Stuff you think you know that's now wrong

#205
post #81

Some good stuff here. I wish AWS would just focus on these boring, but ultimately important, things that they’re good at instead of all the current distractions trying to play catch up on “AI.” AWS leadership missed the boat there big time, but that’s OK. Ultimately AWS doesn’t have the right leadership or talent to be good at GenAI, but they do (or at least used to) have decent core engineers. I’d like to see them g…

Leadership is looking to provide infrastructure for anyone to just pick a model and get on doing things without the hassle of setting things up.

Re: AWS in 2025: Stuff you think you know that's now wrong

#206
post #168

Earlier quoted context omitted.

For truly write once read never data tape is the optimal storage method. It is exactly what the LTO standard was designed to do and it does it very well. You can be confident that you will be able to read every bit of data from a 30 year old tape, probably even 50 years old. It has the lowest bit error rate of any technology I am aware of. LTO-9 is better than 1 uncorrectable bit error in 10^20 user bits, which is 1…

Call it bad luck, but I’ve never had a fully successful restore. Drives eat tapes, drives are damaged and write bad data, robot arms die or malfunction. Tapes have NEVER worked for me. SANs and remote disk though, rock solid. That said, I don’t miss any of that stuff, gimme S3 any day :)

You do realized that that isn't normal at all? LTO tape is still used by thousands of companies to backup many exabytes of data. I know it once saved Google from permanent loss of gmail data from a bug. You should really get a refund for your tape drives.

Re: AWS in 2025: Stuff you think you know that's now wrong

#207

Earlier quoted context omitted.

For truly write once read never data tape is the optimal storage method. It is exactly what the LTO standard was designed to do and it does it very well. You can be confident that you will be able to read every bit of data from a 30 year old tape, probably even 50 years old. It has the lowest bit error rate of any technology I am aware of. LTO-9 is better than 1 uncorrectable bit error in 10^20 user bits, which is 1…

Aren't LTO formats only backward compatible with the immediate prior version?

They can write to one version back and read two version back. for really long term data storage you have to also store the read/write hardware.

Re: AWS in 2025: Stuff you think you know that's now wrong

#208

I think there is more of us who kind of degenerated from doing it the AWS way - API Gateway, serverless lambdas mess around with IAM roles until it works, ... - to - Give me EC2 / LightSail VPS instance maybe an S3 bucket let's set domain through Route53 and go away with the rest of your orchestrion AWS.

At what point is AWS worth using over other compute competitors when you’re using them as a storage bucket + VPS. They’re wholly more expensive at that point. Why not go with a more traditional but rock solid VPS provider? I have the opposite philosophy for what it’s worth: if we are going to pay for AWS I want to use it correctly, but maximally. So for instance if I can offload N thing to Amazon and it’s appropriate…

I agree that using them as a VPS provider is a mistake.

If you don't use the E(lasticity) of EC2, you're burning cash.

For prod workloads, if you can go from 1 to 10 instances during an average day, that's interesting. If you have 3 instances running 24/7/365, go somewhere else.

For dev workloads, being able to spin instances in a matter of seconds is a bliss. I installed the wrong version of a package on my instance? I just terminate it, wait for the auto-scaling group to pop a fresh new one a start again. No need to waste my time trying to clean my mess on the previous instance.

You speak about Step Functions as an efficient and cost effective service from AWS, and I must admit that it's one that I avoid as much as I can... Given the absolute mess that it is to setup/maintain, and that you completely lock yourself in AWS with this, I never pick it to do anything. I'd rather have a containerized workflow engine running on ECS, even though I miss on the few nice features that SF offers within AWS.

The approach I try to have is:

- business logic should be cloud agnostic

- infra should swallow all the provider's pills it needs to be as efficient as possible

Re: AWS in 2025: Stuff you think you know that's now wrong

#209
post #110
post #79

Earlier quoted context omitted.

There's very real differences between NAT gateways and VPC Gateway Endpoints. NAT gateways are not purely hands-off, you can attach additional IP addresses to NAT gateways to help them scale to supporting more instances behind the NAT gateway, which is a fundamental part of how NAT gateways work in network architectures, because of the limit on the number of ports that can be opened through a single IP address. When…

My objections here are in terms of how this manifests in billing. Especially when you consider the highway robbery rates for internet egress.

Again, you are dealing with low-level primitives. You can provision an EC2 VM with multiple GPUs at high cost and use it to host nginx. That is not a correct configuration. There are much cheaper ways available to you. It's ridiculous to imply that AWS shouldn't send you a higher bill because you didn't use the GPUs or that AWS shouldn't offer instances with GPUs because they are more expensive. You, the user, are responsible for building a correct configuration with the low-level primitives that have been made available to you! If it's too much then feel free to move up the stack and host your workloads on a PaaS instead.

Re: AWS in 2025: Stuff you think you know that's now wrong

#210
post #153
post #7

S3: "Block Public Access is now enabled by default on new buckets." On the one hand, this is obviously the right decision. The number of giant data breeches caused by incorrectly configured S3 buckets is enormous. But... every year or so I find myself wanting to create an S3 bucket with public read access to I can serve files out of it. And every time I need to do that I find something has changed and my old recipe d…

This is exactly what I use LLMs for. To just read the docs for me and pull out the base level demo code that's buried in all the AWS documentation. Once I have that I can also ask it for the custom tweaks I need.

This could not possibly go wrong...

You're braver than me if you're willing to trust the LLM here - fine if you're ready to properly review all the relevant docs once you have code in hand, but there are some very expensive risks otherwise.

Post reply on HN