Least privilege service identities
Reuse permission patterns without sharing every service's identity
Templates can reduce maintenance while preserving separate authority. One universal role saves configuration work by concentrating unrelated access.
In this article
Separate repetition from shared privilege
Several workers may all need to read one input location and write their own outputs. A reusable policy module can express that pattern with explicit resource parameters.
They do not necessarily need the same identity. Separate roles preserve attribution and allow one worker's access to change or be revoked independently.
Avoid a template that accumulates every exception from every consumer. That recreates a broad shared role behind a more elaborate configuration interface.
Measure the maintenance burden honestly
More identities require naming, ownership, policy review and retirement. Automate those lifecycle tasks through the platform's supported infrastructure management rather than treating them as reasons to grant universal access.
Use a small set of understandable patterns and keep exceptions close to their workload. A new operator should be able to identify the purpose of a role without reading a sprawling generated policy.
Track policy-related incidents and review time. Complexity that makes effective access impossible to explain can undermine the intended control.
Account for credential delivery and renewal
Temporary credentials reduce long-lived secret distribution but still need reliable acquisition and renewal. Test the supported SDK path under representative concurrency and deployment conditions.
Do not build a custom credential cache merely to avoid a presumed performance cost. Measure the platform mechanism first and follow its documented behaviour.
For external workloads, include the identity-provider or federation dependency in availability planning. A service unable to renew credentials may fail even while its target data service remains healthy.
Compare the cost of a compromised workload
A shared broad identity can force a larger incident response because the team cannot easily isolate one service's authority. Separate identities make containment and attribution more precise.
Use realistic scenarios rather than invented loss estimates. Ask which other datasets or deployments would require review if the report worker were compromised.
The operating choice should balance manageable policy structure with independent, justified access. Reuse code and review patterns where useful, while keeping the authority granted to each workload tied to its actual job.
Primary sources
AWS: IAM security best practicesReferences checked 11 September 2026.