Scalability & Reliability of the Permission Model
Scaling the IAM Design
IAM design decisions that work for one user and one instance break down at scale if they were made carelessly. This section addresses how the model you have built scales.
The group-based approach for human operators scales linearly. Adding a new auditor means creating a user and adding them to document-auditors. The policy does not change. Removing access means removing the user from the group or disabling the user. There is no risk of policy drift from user-level attachments.
The role-based approach for EC2 scales through the instance profile. Any number of EC2 instances can share EC2DocumentProcessorRole. If the processing requirements change — say, the instances also need to read from a third bucket — you update the policy attached to the role once, and all instances immediately reflect the change. Contrast this with the access key model, where you would need to rotate credentials on every instance individually.
Where this model does not scale without modification is cross-account access. If a second AWS account (e.g., a staging account) needs to assume EC2DocumentProcessorRole, you would need to add that account as a trusted principal in the role’s trust policy and then grant the staging account’s IAM entities permission to call sts:AssumeRole. This is the standard AWS cross-account delegation pattern and it requires no long-lived credentials.
The failure mode to understand: if the role attached to an EC2 instance is deleted while the instance is running, the instance loses access to AWS services on the next credential rotation cycle (within 15 minutes under normal operation). Applications should handle AccessDenied errors gracefully and surface them clearly so that an operator can diagnose a permission problem without needing to inspect the instance directly.
In this section, I confirmed:
0 of 3 completed