Ironically, the passphrase for the encryption wouldn't be encrypted in this scenario as claims can be decoded from the token payload if intercepted. It would also probably be stored as-is server side as well. Claims aren't designed as secrets.
Perhaps you could authorise a request to an actual secrets manager via oidc though, allowing the volume to be unlocked.
Did you see the external libraries options?
"Global" services like CloudFront and Route53 are really us-east-1 under the hood with replication to other regions.
Are you sure there's a significant difference between RISC and CISC after instructions are decoded?
The assembly in RISC is just an abstraction of the machine code, as it also is in CISC. If the underlying CPU has the same capabilities then it doesn't really matter what the assembly looks like?
Of course, the underlying CPUs aren't the same and that's the real point of differentiation.
This isn't completely true. Even a basic instruction like ADD has multiple implementations depending on the memory sources.
For example, if the memory operand is in RAM, then the ADD needs to be decoded to include a fetch before the actual addition. RISC doesn't change that fact.
It doesn't really make much of a difference on modern CPUs as instructions are broken down into RISC-like instructions even on CISC CPUs before being processed to make pipelining more effective.
You're not arguing against anything I've said given I said blame, as in, scapegoating AI for mismanagement and fundamental changes.
I remember talking about this at the time. It did get some attention, although the industry was quick to blame other things instead, like AI.
Sometimes being kind doesn't necessarily mean being nice.
A fall-back to the current way of unlocking the volume would probably be a good idea. It wouldn't be fun to lose access to something because a cloud service went down or access to it was lost etc.