API key rotation for AI providers only stays downtime-free when you treat it as a two-key window: point every client at one key, regenerate the idle second key, migrate clients across to it, then repeat for the first. AWS allows a maximum of two access keys per IAM user, and Azure issues the same pair per resource, so the platforms themselves assume exactly this choreography. This guide turns that mechanism into a runbook you can paste into an ops ticket.
Why rotation still matters
Most production model traffic still authenticates with long-lived bearer keys: a provider secret in an environment variable, an AWS access key pair for a Bedrock client, or the two keys attached to an Azure AI services resource. Those credentials leak into CI logs, shell history, laptop dotfiles and support tickets, and none of those copies expires on its own. Rotation is the control that puts an expiry date on every copy that escaped. Leaked provider keys are also the cheapest attack path: no exploit, no social engineering, just one signed request billed to your account.
For teams in Portugal and the wider EU, the pressure is not hypothetical: security questionnaires, ISO 27001 audits and SOC 2 reviews routinely ask for evidence of scheduled credential rotation, and a key that has not changed since launch is an easy finding. Rotation also caps the blast radius of a leak, because a stolen key is only useful until its next regeneration. If your concern is interception on the network path rather than key theft, pair this runbook with VPC endpoints for AI APIs so provider traffic never crosses the public internet.
The dual-key rotation window
The technique rests on one provisioning detail. Microsoft provisions two API keys per AI services resource specifically so that one key can be regenerated while the other keeps serving traffic. On the AWS side, the IAM cap is likewise two keys per user, which is exactly the overlap an in-place rotation needs. Neither platform offers a third slot, so the procedure has to be strictly serialized.
The second detail that shapes the runbook is how regeneration behaves. In Azure, once a key is regenerated, the old value stops working immediately and clients still holding it receive 401 access denied errors. There is no grace period, no dual-validity interval and no rollback: the moment you press the regenerate button, every consumer of that key is on a clock. That is why the safe pattern is drain, regenerate, refill — never regenerate a credential that is still in active use.
The zero-downtime runbook
This procedure generalizes the documented Azure rotation flow to any two-key provider, including AWS IAM keys used by model-serving clients:
- Inventory consumers before touching anything: every service, cron job, notebook and developer laptop that reads the credential, plus the config service or secret store each one reads from.
- Pin the fleet to key 1. Ship a config change so every consumer resolves only key 1, then wait out your longest cache — say a 15-minute in-process secret cache — before continuing.
- Verify single-key usage in provider logs. CloudTrail or Azure diagnostic settings should show zero authenticated calls signed with key 2; if any caller remains, find it now, not after an outage.
- Regenerate key 2, distribute the new value through the same delivery path, and roll consumers in batches, watching 401 rates as each batch lands.
- Once key 2 serves the entire fleet, repeat the drain-regenerate-refill cycle for key 1.
- Close the loop: confirm in logs that the retired key IDs appear in no successful call, then record the rotation date as audit evidence for the next review.
Retire keys where possible
Rotation is the fallback, not the goal. AWS itself recommends temporary security credentials such as IAM roles instead of long-term access keys, and role sessions expire on their own — which turns rotation into an automatic property of the auth model instead of a scheduled chore. The Azure equivalent is keyless authentication with Microsoft Entra ID for AI services resources, removing the static secret entirely.
Where a static key is unavoidable — most third-party model APIs still require one — put rotation on the same operating calendar as capacity and model changes. Teams that already track model deprecation windows for API retirements can reuse that calendar: a quarterly provider review is a natural moment to drain and regenerate every outstanding credential.
Rotation readiness checklist
| Check | What good looks like |
|---|---|
| Every consumer inventoried | The config service or secret store is the only delivery path; no hard-coded keys in images or notebooks |
| Dual keys available | The provider identity holds two independent keys; the runbook never needs a third |
| Telemetry before rotation | Per-key usage visible in provider logs for at least one full business cycle |
| Rollback defined | The previous key value stays retrievable from secret-store history until the final audit |
| Audit trail kept | Rotation date, operator and retired key IDs recorded for the next review |
Score the table before scheduling the rotation, not during it. Every failed row is either a discovery task or a signal to move that consumer onto role-based or keyless authentication first; both are cheaper than an incident review after a botched regeneration takes inference traffic down.