211–220 of 284 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
I take code from stack overflow all the time and there’s like a 90% chance it can work. What’s the difference here?
Earlier quoted context omitted.
> I can't talk about it, but I've yet to see an accurate guess at how Glacier was originally designed. It feels odd that this is some sort of secret. Why can't you talk about it?
I signed NDAs. I wish Glacier was more open about their history, because it's honestly interesting, and they have a number of notable innovations in how they approach things.
(And if Amazon is making unreasonable length NDAs I hope they lose a lot of money over it.)
> Glacier restores are also no longer painfully slow. I had a theory (based on no evidence I'm aware of except knowing how Amazon operates) that the original Glacier service operated out of an Amazon fulfillment center somewhere. When you put it a request for your data, a picker would go to a shelf, pick up some removable media, take it back, and slot it into a drive in a rack. This, BTW, is how tape backups on times…
I can't talk about it, but I've yet to see an accurate guess at how Glacier was originally designed. I think I'm in safe territory to say Glacier operated out of the same data centers as every other AWS service. It's been a long time, and features launched since I left make clear some changes have happened, but I'll still tread a little carefully (though no one probably cares there anymore): One of the most crucial t…
Earlier quoted context omitted.
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 re…
And the traffic never even reaches the public internet. There's a mismatch between what the billing is supposedly for and what it's actually applied to.
> do you expect AWS to show you different meters for billed and not-billed traffic, but performance still depends on the sum total of the traffic (S3 and Internet egress) passing through it?
Yes.
> How is that not confusing?
That's how network ports work. They only go so fast, and you can be charged based on destination. I don't see the issue.
> It's also besides the point that not all NAT gateways are used for Internet egress
Okay, if two NAT gateways talk to each other it also should not have egress fees.
> some kind of implicit built-in S3 gateway violates assumptions
So don't do that. Checking if the traffic will leave the datacenter doesn't need such a thing.
Earlier quoted context omitted.
I recommend S3 Gateways for all VPCs that need to access S3, even those that already have routes to the Internet. Plus they eliminate the need for NAT Gateway traversal for requests that originate from private subnets.
> I recommend S3 Gateways for all VPCs that need to access S3, even those that already have routes to the Internet. Fascinating. What's the advantage of doing that?
Earlier quoted context omitted.
Gateway endpoints are free. Network endpoints (which are basically AWS-managed ENIs that can tunnel through VPC boundaries) are not free. S3 can use either, and we recommend establishing VPC Gateway endpoints by default whenever you need S3 access. (Disclaimer: I work for AWS, opinions are my own.)
Why don't you have gateway endpoints for all your APIs?
Earlier quoted context omitted.
If you're aware of changes, then explain that there were changes over time, that's it
You say this, someone challenges you, now you're on the defensive during an interview and everyone has a bad taste in their mouth. Yeah, that's how it goes.
Earlier quoted context omitted.
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.
There’s nothing brave in this. It generally works the way it should and even if it doesn’t - you just go back to see what went wrong. I take code from stack overflow all the time and there’s like a 90% chance it can work. What’s the difference here?
If you don't do that will you necessarily notice that you accidentally leaked customer data to the world?
The problem isn't the LLM it's assuming its output is correct just the same as assuming Stack Overflow answers are correct without verifying/understanding them.
Earlier quoted context omitted.
It's designed to be a declarative DSL, but then you have to do all sorts of filters and maps in any group of resources and suddenly you are programming in yaml with both hands tied behind your back
Yeah it’s just terrible. If Amazon knew what was good they’d just replace it with almost anything else. Heck just got all in on terraform and call it a day.
Also that have CDK which is a framework for writing IaC in Java/TypeScript, Go, Python, etc.