Configuration Requirements
Scope
Applies to DynamoGuard. Platform requirements are in Platform Reliability.
Reliable policy enforcement depends on settings in two places: the deployment, and the application that calls the analyze endpoint. This page lists both, with the reason each one matters. Work through it before a deployment is treated as production-ready.
Integration Contract
These are properties of the analyze API that a calling application must handle. They are stable behaviour, not defaults you can change, so build for them.
| # | Behaviour | What your application should do |
|---|---|---|
| C1 | The response reports which policies were applied, in appliedPolicies | Compare appliedPolicies against the identifiers you sent, and treat a shortfall as a failed evaluation. A policy identifier that does not resolve is omitted and the request still succeeds. See Failure Behavior |
| C2 | A request naming no policies evaluates nothing and returns a final action of NONE | Validate that policyIds is non-empty before sending, so an empty request is never mistaken for a clean result |
| C3 | The platform returns an error rather than deciding what happens to unchecked content | Choose your posture explicitly. Treat every non-2xx from analyze as a block wherever unchecked content is unacceptable |
| C4 | A request is evaluated as a unit: every policy in it succeeds, or the request fails | Split policies across separate requests where a partial result is acceptable, and keep the ones that must travel together in one call |
| C5 | A successful analyze returns 201 | Check for a 2xx range. Equality with 200 fails |
C1 and C3 are the two that most often surprise an integrator. Together they decide whether an unevaluated request can reach a model, and that decision sits in your application rather than in the platform.
Availability Settings
| # | Setting | Why |
|---|---|---|
| A1 | Provision the policy store for high availability | The policy set is read on every request, so the store is on the hot path |
| A2 | Configure loggingControl to match your audit requirements | The moderation log write precedes the response. Where an audit record is mandatory, keep it on; where availability matters more, the setting lets a log store outage stop failing requests. See Failure Behavior |
| A3 | Retry in the calling application, with a budget | The moderation path does not retry on your behalf |
| A4 | Set replicas on built-in guardrail models | A disruption budget is created automatically at two or more. Custom policy models run a single replica, set by the platform |
| A5 | Give the model servers a startupProbe, and a short readinessProbe delay | A replacement pod is otherwise withheld from rotation for the full readiness delay, which is usually much longer than the model takes to load. On a small classifier those differ by minutes |
| A6 | Constrain guardrail placement through node pools, and verify it after deployment | The model resource does not carry topology spread, so replicas can land in one zone unless the pool prevents it |
| A7 | Size guardrail capacity for peak | Replica counts are set rather than derived from load, and a model that is loading is not yet serving |
Observability Settings
| # | Setting | Why |
|---|---|---|
| O1 | Set the OTLP endpoint in every region | Metric export is gated on it. An empty series means the export is unconfigured, not that the guardrail path is idle, so a failover signal built on these metrics needs the endpoint set first. See Monitoring And Targets |
| O2 | Probe /v1/health/status | It is the endpoint that checks every dependency. The others check fewer, and two check none |
| O3 | Detect degraded enforcement from request metrics | A failed evaluation writes no moderation log entry, so a bad period appears in the log as an absence of traffic |
| O4 | Derive per-policy request rates from the moderation log | Counters are exported per guardrail type. Custom policies have no per-policy counter |
Multi-Region Requirements
| # | Requirement | Why |
|---|---|---|
| M1 | Enable artifact sync in every region, and verify the objects land under the prefix the model resources reference | A region without the weights cannot serve the policy, and the sync reports success whichever prefix it writes to |
| M2 | Provision custom policies in each region that must serve them | A custom policy is a trained artifact rather than configuration, so it cannot be recreated by copying settings. Train in both regions, or promote the artifact |
| M3 | Compare the policy set between regions before a cutover | Enforcement parity is not asserted automatically, and a standby with a stale set answers requests while enforcing less |
| M4 | Run the bundled object store in distributed mode, and back it up | Single instance is the default and carries no redundancy. See Object Storage |
| M5 | Operate the health-checked load balancer that withdraws a failed region | The platform does not withdraw itself. See Traffic Routing |
What This Page Does Not Cover
Properties of a specific deployment, such as the availability zones your node pools span or the tier of your managed datastores, are covered by Platform Prerequisites, where each requirement pairs with a command that verifies it.
Related
- Failure Behavior: what a request returns when a dependency is unavailable
- Verifying A Standby: confirming a second region can serve
- Reliability Overview: which strategy covers which failure