DynamoGuard Reliability
DynamoGuard runs on the shared platform and inherits its availability. Everything on this page is what DynamoGuard adds on top: serving guardrail models, and what a moderation request does when part of the path is unavailable.
Read Platform Reliability first. A guardrail policy cannot be more available than the API, datastores and object storage beneath it.
What Is Different About Guardrail Serving
Three properties separate a guardrail policy from an ordinary stateless workload.
| Property | Effect |
|---|---|
| Each policy is served by its own model process | Replica counts, placement and recovery are per policy, not per deployment |
| A model must load weights before it can answer | A replacement pod is not immediately useful, and the weights come from object storage |
| A custom policy is a trained artifact | It cannot be recreated in a second region by copying configuration |
The Question That Matters
For the platform, the reliability question is whether a request gets a response. For DynamoGuard it is whether a request was actually governed. Those come apart: a moderation request can return success with fewer checks applied than were asked for.
That distinction drives how this section is organised.
| Page | Answers |
|---|---|
| Guardrail Serving Across Zones | What a policy needs to survive a node or zone loss |
| Failure Behavior | What a request returns when a dependency is unavailable |
| Configuration Requirements | What a deployment and a calling application must set |
| Verifying A Standby | Confirming a second region can serve, rather than reporting that it can |