This managed policy grants the permissions that Systems Manager managed EC2 instances need to communicate with Systems Manager and complete managed-instance operations. It should be attached only to instances that are intended to be managed that way. Review whether the instance actually needs these capabilities, and avoid reusing the policy on roles that also need unrelated privileges.
What this AWS managed policy actually does
AmazonSSMManagedEC2InstanceDefaultPolicy is an AWS managed policy for EC2 instances that are meant to be managed by Systems Manager. Its purpose is not broad admin access, but the minimum set of permissions needed for the instance to talk to Systems Manager and complete managed-instance operations. That means the policy is about instance management, command execution, inventory, patching, and related control-plane interactions, not application data access.
The practical question is always whether the instance truly needs to be a managed instance. If the workload does not need Systems Manager features, attaching the policy adds unnecessary access surface. If it does need those features, the policy belongs on the instance role, not on unrelated roles that might inherit extra privileges by accident.
Where the permissions fit in an EC2 role design
This policy belongs in the instance profile attached to the EC2 host, because the host needs to authenticate to AWS as the instance itself. That is why it is operationally different from a human admin policy or an application role. The policy should support the managed-instance trust boundary, while the rest of the role remains tightly scoped to the workload’s actual duties.
In AWS terms, the safest pattern is to keep the Systems Manager role separate from application permissions and from any role used for deployment, observability, or data access. When a single role accumulates unrelated permissions, the managed-instance path becomes a convenient credential carrier for broader access than the instance really needs. For the broader IAM role-design context, see AWS IAM Policies and Roles Guide.
That separation matters because the policy’s value is functional, not expansive. It lets the instance register with Systems Manager and perform management tasks, but it should not become a default attachment for every EC2 role. If you are right-sizing cloud permissions or reviewing effective access, the policy should be evaluated as part of the instance’s full entitlement set, not in isolation. The Cloud PAM and CIEM Guide is a useful companion for that review.
What to check before you attach or keep it
Before attaching the policy, confirm that the instance is intended to be managed by Systems Manager and that the workload owner understands the operational consequences. If the instance only needs occasional remote access, a different access model may be more appropriate. If the instance needs ongoing lifecycle actions such as run command, inventory collection, patch orchestration, or automation through Systems Manager, the policy may be justified.
After attachment, verify that the role does not also carry unrelated high-value permissions. A managed-instance role should not quietly double as a deployment role, secrets reader, or data-plane administrator. If you later discover the role is shared across multiple instances or environments, treat that as a design smell and split the role before the permissions drift further. The Privileged Access Management Guide covers the separation and review discipline that helps prevent that kind of role sprawl.
For an AWS-specific workload identity perspective, it is also worth validating that the instance is using the expected role-assumption path and not a reused credential pattern. Managed EC2 access should be based on instance identity and short-lived AWS credentials, not on shared static secrets. The Cloud Workload Identity Guide explains the design pattern behind that model. For the broader vendor reference, the OWASP Non-Human Identity Top 10 is relevant because the same overprivilege and secret-handling issues often show up in machine roles.
Risk and Threat Considerations
The main risk is not that the policy exists, but that it becomes a convenient default for instances that do not actually need managed-instance capability. Once attached, it can expand the operational reach of the instance and increase the blast radius if the host or its role is compromised. The same permission set that enables legitimate Systems Manager operations can also be abused to extend access into the AWS control plane.
Failure mechanism: Overbroad instance-role attachment, shared role reuse, or weak role scoping turns a management policy into a privilege multiplier. If an attacker obtains the instance role or the host is misused internally, the permissions intended for Systems Manager can be leveraged for broader cloud actions or for persistence through trusted management paths.
Impact: The outcome can be unauthorized management activity, wider access than intended, and a larger incident footprint than the workload itself should ever have. In practice, the control failure is usually entitlement sprawl, not a flaw in Systems Manager itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | EC2 instances authenticate as services or workloads to AWS APIs. |
| AC-6 — Least Privilege | The policy should grant only the permissions required for Systems Manager operations. | |
| IA-5 — Authenticator Management | Managed-instance access depends on controlling role credentials and their lifecycle. | |
| Recommendation — Apply IA-9 to ensure the instance role is scoped to service-to-service authentication needs. Use AC-6 to right-size the instance role and remove unrelated permissions. Use IA-5 to manage the lifecycle of credentials used by the instance role. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | A managed EC2 role can become overprivileged if reused for unrelated duties. |
| NHI-07 — Long-Lived Secrets | Machine access patterns should avoid static secrets and rely on short-lived credentials. | |
| Recommendation — Review the instance role for excess permissions and split unrelated access. Prefer short-lived instance credentials and eliminate static secrets where possible. | ||
Practitioner Guidance
What to prioritise: Confirm whether the instance genuinely needs Systems Manager features, then review the attached role for any unrelated permissions before assuming the AWS managed policy is harmless.
Decision rule: If the instance is meant to be managed through Systems Manager, keep the policy narrowly on that instance role; if not, remove it and choose a smaller access pattern.
What to verify: Check for role sharing across environments, extra data-plane permissions, and any automation that reattaches the policy by default during provisioning.
Practitioner takeaway: Treat this policy as a workload-management enabler, not as a generic EC2 default, because the real security question is whether the attached role matches the instance’s actual management need.
Related resources from NHI Mgmt Group
- What permissions does the AWS AmazonEC2FullAccess managed policy grant?
- What permissions does the AWS AmazonECS_FullAccess managed policy grant?
- What permissions does the AWS AmazonGuardDutyFullAccess managed policy grant?
- What permissions does the AWS AmazonGuardDutyReadOnlyAccess managed policy grant?