TIL about the existance of the F.I.P.S. compliance and it’s requirement for the AWS DynamoDB service.

F.I.P.S. stands for Federal Information Processing Standards and the latest version as of now is F.I.P.S. 140-2.

I was curious to know what the requirements were and they seem to be based on the security aspect (which makes sense) and more in-line with the cryptographic rigidity.

I asked Perplexity Agent to summarize the requirements for F.I.P.S. 140-2 for me because native searching led me to serveral PDFS with a lot of data to process and I didn’t want to spend hours going through each module and I believe this was just for my acquintaince with the idea not deep research requirement.

Anyways, here’s the link to the conversation with the perplexity agent.

This entire rabbit hole started with me looking into the Recent AWS US-EAST-1 Outage that happpend on 20th October 2025, the DynamoDB incident.

Also dropping a link to that here . This postmortem report is well-written.

And generally speaking, if we overlook the billions of dollars of missed revenue to all the entities affected by this, we will get to a better engineered product or service at the end of all this.

The AWS team, suffix the postmortem write-up, with the following statement (and more):

We are making several changes as a result of this operational event. We have already disabled the DynamoDB DNS Planner and the DNS Enactor automation worldwide. In advance of re-enabling this automation, we will fix the race condition scenario and add additional protections to prevent the application of incorrect DNS plans.

For NLB, we are adding a velocity control mechanism to limit the capacity a single NLB can remove when health check failures cause AZ failover.

For EC2, we are building an additional test suite to augment our existing scale testing, which will exercise the DWFM recovery workflow to identify any future regressions. We will improve the throttling mechanism in our EC2 data propagation systems to rate limit incoming work based on the size of the waiting queue to protect the service during periods of high load. Finally, as we continue to work through the details of this event across all AWS services, we will look for additional ways to avoid impact from a similar event in the future, and how to further reduce time to recovery.