EC2AccessDeniedException
AWS EC2AccessDeniedException means Lambda needs additional permissions to configure VPC settings for the function invoke path (HTTP 502).
Last reviewed: February 15, 2026|Editorial standard: source-backed technical guidance
What Does EC2 Access Denied Exception Mean?
Lambda cannot attach or manage VPC networking for the function because required EC2 permissions are denied, so invokes or updates fail before runtime execution.
Common Causes
- -Lambda execution role lacks required EC2 permissions for VPC networking (for example ENI operations).
- -Permission boundary, SCP, or explicit deny overrides apparently valid role allow statements.
- -Role trust or condition keys prevent Lambda service from using the role as expected.
- -VPC-related role policy updates have not propagated before function invocation/update.
How to Fix EC2 Access Denied Exception
- 1Grant required EC2 actions for Lambda VPC networking (
ec2:CreateNetworkInterface,ec2:DescribeNetworkInterfaces,ec2:DeleteNetworkInterface). - 2Evaluate effective permissions across IAM policy, boundary, and organization guardrails.
- 3Validate Lambda service principal trust policy and required condition-key logic.
- 4Retry function update/invoke after policy propagation and permission simulation checks.
Step-by-Step Diagnosis for EC2 Access Denied Exception
- 1Capture denied EC2 action, role ARN, and request ID from CloudTrail/Lambda logs.
- 2Use IAM Policy Simulator with exact EC2 actions required by Lambda VPC attachment path.
- 3Check explicit deny precedence across SCP, permission boundary, and identity policies.
- 4Verify subnet/security-group context and account-region alignment for VPC-configured functions.
EC2 Permission Path Validation
- -Trace denied EC2 actions from Lambda/CloudTrail events (example: explicit deny on
ec2:CreateNetworkInterfaceblocks VPC cold start). - -Simulate effective permissions including SCP, permission boundary, and session policies (example: role allows action but organization policy denies ENI lifecycle calls).
VPC Attachment Preconditions
- -Verify function role trust and VPC configuration alignment (example: wrong execution role attached to function version/alias).
- -Audit subnet/security-group settings and region-account context used by Lambda service (example: policy scoped to one region while function executes in another).
How to Verify the Fix
- -Re-run the denied operation and confirm it succeeds.
- -Confirm adjacent operations remain correctly scoped.
- -Validate audit logs show expected authorization decisions.
How to Prevent Recurrence
- -Enforce policy review workflows with automated simulation checks.
- -Track permission drift and deny spikes with continuous audits.
- -Codify least-privilege patterns in infrastructure templates.
Pro Tip
- -add a pre-deploy IAM simulation gate that validates ENI-related EC2 permissions for every Lambda execution role before any VPC config rollout.
Decision Support
Compare Guide
429 Too Many Requests vs 503 Service Unavailable
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
500 Internal Server Error vs 502 Bad Gateway: Root Cause
Debug 500 vs 502 faster: use 500 for origin failures and 502 for invalid upstream responses at gateways, then route incidents to the right team.
Playbook
API Timeout Playbook (502 / 504 / DEADLINE_EXCEEDED)
Use this playbook to separate invalid upstream responses from upstream wait expiration and deadline exhaustion, and apply timeout budgets, safe retries, and circuit-breaker controls safely.
Playbook
Availability and Dependency Playbook (500 / 503 / ServiceUnavailable)
Use this playbook to separate origin-side 500 failures from temporary 503 dependency or capacity outages, then apply safe retry and escalation paths.
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.