Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lastweekinaws.com

Post reply on HN
Print view View original

261–270 of 284 posts

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

#261

Post by saghm »

jagged-chisel wrote: post #247
saghm wrote: post #154

Earlier quoted context omitted.

My understanding is that there isn't actually any "overriding" in the sense of two rules conflicting and one of them having to "win" and take effect. I think it's more that an enabled rule always is in effect, but it might overlap with another rule, in which case removing one of them still won't remove the restrictions on the area of overlap. It's possible I'm reading too much into your choice of words, but it does s…

If one rule explicitly restricts access and another explicitly grants access, which one is in effect? Do restrictions override grants? Does a grant to GroupOne override a restriction to GroupAlpha when the authenticated use in is both groups? Do rules set by GodAdmin override rules set by AngelAdmin?

It's possible I'm making the exact mistake that the article describes and relying on outdated information, but my understanding is that pretty much all of the rules are actually permissions rather than restrictions. "Block public access" is an unfortunate exception to this, and I suspect that it's probably just a poorly named inversion of an "allow public access" permission. You're 100% right that modeling permissions like this requires having everything in the same "direction", i.e. either all permissions or all restrictions.

After thinking about this sort of thing a lot when designing a system for something sort of similar to this (at a much smaller scale, but with the intent to define it in a way that could be extended to define new types of rules for a given set of resources), I feel pretty strongly that the best way for a system like this to work from the protectives of security, ease of implementation, and intuitiveness for users are all aligned in requiring every rule to explicitly be defined as a permission rather than representing any of them as restrictions (both in how they're presented to the user and how they're modeled under the hood). With this model, veryifing whether an action is allowed can be implemented by mapping an action to the set of accesses (or mutations, as the case may be) it would perform, and then checking that each of them has a rule present that allows it. This makes it much easier to figure out whether something is allowed or not, and there's plenty of room for quality of life things to help users understand the system (e.g. being able to easily show a user what rules pertain to a given resource with essentially the same lookup that you'd need to do when verifying an action in it). My sense is that this is actually not far from how AWS permissions are implemented under the hood, but they completely fail at the user-facing side of this by making it much harder than it needs to be to discover where to define the rules for something (and by extension, where to find the rules currently in effect for it).

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

#262

Post by indigodaddy »

viccis wrote: post #100

>In EC2, you can now change security groups and IAM roles without shutting the instance down to do it. Hasn't it been this way for many years? >Spot instances used to be much more of a bidding war / marketplace. Yeah because there's no bidding any more at all, which is great because you don't get those super high spikes as availability drops and only the ones who bid super high to ensure they wouldn't be priced out a…

Re: SG, yeah I wasnt doing any cloud stuff when that was the case. Never had to restart anything for an SG change and this must be at least 5-6 years..

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

#263

Post by andrewmcwatters »

reactordev wrote: post #259
pas wrote: post #218

Earlier quoted context omitted.

That's just the taste of iron from the blood after the duel. But this is completely normal after a formal challenge! Companies want real cyberwarriors, and the old (lame) rockstar ninjas that they hired 10 years ago are very prone to issuing these.

I don’t want to go to war, I just want a quiet house in the mountains and a career that allows me to think about things.

Amen.

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

#264

Post by JoshTriplett »

donavanm wrote: post #216
JoshTriplett wrote: post #165

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. Fascinating. What's the advantage of doing that?

It's a much more direct/efficient connection from the EC2 instance to the S3 storage servers through the virtual network layer. It reduces the network path/length through the AWS network _and_ removes the number of virtual network functions/servers (ala "LB") that your connections will traverse.

That's helpful to know, thank you! I'll take a look at that and see if it improves S3 performance.

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

#265

Post by happytoexplain »

amenghra wrote: post #29
nbngeorcjhe wrote: post #24

Earlier quoted context omitted.

> People who are price insensitive will not invest the time to fix it This just sounds like a polite way of saying "we're taking peoples' money in exchange for nothing of value, and we can get away with it because they don't know any better".

Price segmentation happens all the time in pretty much every industry.

Must be un-criticizable then?

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

#266

Post by hinkley »

donavanm wrote: post #244
mappu wrote: post #122

Earlier quoted context omitted.

My understanding is some AWS products (e.g. RDS) need very fast disks with lots of IOPS. To get the IOPS, though, you have to buy +++X TB sized SSDs, far more storage space than RDS actually needs. This doesn't fully utilize the underlying hardware, you are left with lots of remaining storage space but no IOPS. It's perfect for Glacier. The disks for Glacier cost $0 because you already have them.

Since ~2014 or so the constraint on all HDD based storage has been IOPs/throughput/queue time. Shortly after that we started seeing "minimum" device sizes that were so large as to be challenging to productively use their total capacity. Glacier type retrieval is also nice in that you have much more room for "best effort" scheduling and queuing compared to "real time" request like S3:PutObject. Last I was aware flash/…

There’s a really old trick with HDDs where you buy a big disc and then allocate less than half of it. There’s more throughput on the first half of the disk, more tracks per cylinder so fewer seeks, and never having to read half the disk reduces the worst case seek time. All increase IOPs.

But then what do you do with the other half of the disk? If you access it when the machine isn’t dormant you lose most of these benefits.

For deep storage you have two problems. Time to access the files, and resources to locate the files. In a distributed file store there’s the potential for chatty access or large memory footprints for directory structures. You might need an elaborate system to locate file 54325 if you’re doing some consistent hashing thing, but the customer has no clue what 54325 is. They want the birthday party video. So they still need a directory structure even if you can avoid it.

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

#267

Post by wiether »

no_wizard wrote: post #250
wiether wrote: post #208

Earlier quoted context omitted.

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…

>business logic should be cloud agnostic In practice I found this to be more burden than it’s worth. I have yet to work somewhere that is on Azure, GCP or AWS and actually switch between clouds. I am sure it happens, but is it really that common? I instead think of these platforms as a marriage, you’re going to settle in one and do your best to never divorce

Part of my job is to do migrations for customers, so, to me at least, it's not uncommon.

Using all the bells and whistles of a provider and being locked-in is one thing. But the other big issue is that, as service providers, they can (and some of them did more often than not) stop providing some services or changing them in a way that forces you to make big changes in your app to keep it running on this service.

Whereas, if you build your app in a agnostic way, they can stop or change what they want, you either don't rely on those services heavily enough for the changes required to be huge, or you can just deploy elsewhere, with another flavor of the same service.

Let's say you have a legacy Java app that works only with a library that is not maintained. If you don't want to bear the cost of rewriting with a new and maintained library, you can keep the app running, knowing the risks and taking the necessary steps to protect you against it.

Whereas if your app relies heavily on DynamoDB's API and they decide to drop the service completely, the only way to keep the app running is to rewrite everything for a similar service, or to find a service relying on the same API elsewhere.

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

#268

Post by hnlmorg »

mdaniel wrote: post #257
hnlmorg wrote: post #225

Earlier quoted context omitted.

There's a lot wrong with Terraform but I don't think you're being at all fair with your specific critisims here: > 1. I need a goddamn CLI to run it (versus giving someone a URL they can load in their tenant and have running resources afterward) CloudFormation is the only IaC that supports "running as a URL" and that's only because it's an AWS native solution. And CloudFormation is a hell of a lot more painful to wri…

> CloudFormation is the only IaC that supports "running as a URL" Incorrect, ARM does too, they even have a much nicer icon for one click "Deploy to Azure" https://learn.microsoft.com/en-us/azure/azure-resource-manag... > and as a concrete example (or whole repo of them): https://github.com/Azure/azure-quickstart-templates/tree/2db... > > All IaC requires live cloud credentials. It would be impossible for them to wor…

> Incorrect, ARM does too, they even have a much nicer icon for one click "Deploy to Azure"

That’s Azure, not AWS. My point was to have “one click” HTTP installs you need native integration with the cloud vendor. For Azure it’s the clusterfuck that is Bicep. For AWS it’s the clusterfuck that is CF

> I don't need a state file for CF nor Bicep.

CF does have a state file, it’s just hidden from view.

And bicep is shit precisely because it doesn’t track state. In fact the lack of a state file is the main complain against bicep and thus the biggest thing holding it back from wider adoption — despite being endorsed by Microsoft Azure.

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

#269

Post by hnlmorg »

mdaniel wrote: post #258
hnlmorg wrote: post #231

Earlier quoted context omitted.

Is there any IaC solutions where you can “simply switch between cloud providers”? This isn’t a limitation of TF, it’s an intended consequence of cloud vendor lock in

I believe the usual uninformed thinking is "terraform exists outside of AWS, so I can move off of AWS" versus "we have used CF or Bicep, now we're stuck" kind of deal Which is to say both of you are correct, but OP was highlighting the improper expectations of " if we write in TF, sure it sucks balls but we can then just pivot to $other_cloud" not realizing it's untrue and now you've used a rusty paintbrush as a scre…

I don’t think that expectation exists with anyone with even the slightest understanding of IaC and systems.

But maybe I’ve just been blessed to work with people who aren’t complete idiots?

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

#270

Post by jp57 »

jp57 wrote: post #108

> 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 think folks have missed what I think would have been clever about the implentation I (apparently) dreamt up. It's not that "it's just a tape library", it's that it would have used the existing FC and picker infrastructure that Amazon had already built, with some racks containing drives for removable media. I was thinking that it would not have been some special facility purely for Glacier, but rather one or more regular FCs would just have had some shelves with Glacier media (not necessarily tapes).

Then the existing pickers would get special instructions on their handhelds: Go get item number NNNN from Row/shelf/bin X/Y/Z and take it to [machine-M] and slot it in, etc.

Post reply on HN