AWS Lambda Security Model Explained: Roles, Resource Policies, VPCs & Secrets

Simple explanation

When a Lambda function runs, two separate questions need answers. First: who is allowed to start this function? Second: what is this function allowed to do once it is running?

These questions are controlled by different mechanisms. The resource-based policy answers the first question. The execution role answers the second. On top of those, VPC placement controls which private networks the function can reach, and secrets management controls how sensitive values like passwords and API keys get into the function safely.

All four layers need to be correct. A function with a perfectly scoped execution role but a misconfigured resource policy will not run. A function with the right invocation permission but an overly broad execution role is a security risk. They do not compensate for each other.

How Lambda security works

Every Lambda invocation follows this sequence:

1. Invocation request arrives from API Gateway, S3, an SDK call, an EventBridge schedule, or another AWS service.
2. Resource-based policy check. Lambda checks whether the caller has permission to invoke this function. If not, the request is rejected before any code runs.
3. Lambda assumes the execution role. Lambda uses AWS STS to get temporary credentials for the IAM role attached to the function.
4. Function code runs. Your handler executes. Every AWS API call your code makes is authorized or denied based on the execution role’s permissions.
5. Network path. If the function is in a VPC, outbound traffic flows through your private subnets and security groups. If not, it goes through AWS’s managed network with full internet access.
6. Secrets access. If the function fetches secrets from Secrets Manager or SSM Parameter Store, those calls are authorized by the execution role and routed through the network path described above.
7. Logging. Lambda writes logs to CloudWatch Logs, which also requires execution role permissions. Missing CloudWatch permissions means logs are silently dropped.

The 4 layers of Lambda security

Execution role: what your function can do

Every Lambda function has an execution role: an IAM role that Lambda assumes when the function runs. This role determines what AWS services and resources the function can call.

An IAM role has two parts that are easy to confuse:

• Trust policy. Defines who is allowed to assume this role. For a Lambda execution role, the trusted principal must be lambda.amazonaws.com. Without this, Lambda cannot assume the role and the function will not start.
• Permissions policy. Defines what this role can do once assumed. This is where you grant access to DynamoDB, S3, Secrets Manager, or whatever the function actually needs. See the IAM policy structure guide for how these policies are written.

# Create a Lambda execution role with the correct trust policy
aws iam create-role \
  --role-name my-lambda-role \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Service": "lambda.amazonaws.com"},
      "Action": "sts:AssumeRole"
    }]
  }'

# Attach minimum CloudWatch Logs permissions
aws iam attach-role-policy \
  --role-name my-lambda-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

Beyond CloudWatch Logs, add only the permissions the function actually needs. Follow the principle of least privilege and scope every permission to the minimum resource ARN, not a wildcard:

# Least-privilege inline policy for a specific function
aws iam put-role-policy \
  --role-name my-lambda-role \
  --policy-name FunctionSpecificPermissions \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": ["dynamodb:GetItem", "dynamodb:Query"],
        "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/my-table"
      },
      {
        "Effect": "Allow",
        "Action": ["s3:PutObject"],
        "Resource": "arn:aws:s3:::my-output-bucket/*"
      }
    ]
  }'

For Lambda functions attached to a VPC, also attach AWSLambdaVPCAccessExecutionRole. This grants the ENI-related permissions Lambda needs to connect to your private subnets. Without it, the function cannot start in a VPC. Once attached, add your own least-privilege permissions on top for the actual work the function does.

Resource-based policy: who can invoke your function

The execution role controls what the function can do outbound. The resource-based policy controls who can invoke the function inbound. These are entirely separate mechanisms.

When you add a trigger via the console (API Gateway, S3, SNS, EventBridge), AWS adds the resource-based policy permission automatically. When configuring via the CLI or infrastructure as code, you add it manually with aws lambda add-permission.

# Allow API Gateway to invoke the function
aws lambda add-permission \
  --function-name my-api-function \
  --statement-id allow-api-gateway \
  --action lambda:InvokeFunction \
  --principal apigateway.amazonaws.com \
  --source-arn "arn:aws:execute-api:us-east-1:123456789012:abc123/*/*"

# Allow S3 to invoke the function on object uploads
aws lambda add-permission \
  --function-name my-s3-processor \
  --statement-id allow-s3 \
  --action lambda:InvokeFunction \
  --principal s3.amazonaws.com \
  --source-arn "arn:aws:s3:::my-input-bucket" \
  --source-account "123456789012"

# Allow SNS to invoke the function from a specific topic
aws lambda add-permission \
  --function-name my-sns-processor \
  --statement-id allow-sns \
  --action lambda:InvokeFunction \
  --principal sns.amazonaws.com \
  --source-arn "arn:aws:sns:us-east-1:123456789012:my-topic"

# Allow a specific IAM role in another account to invoke
aws lambda add-permission \
  --function-name my-shared-function \
  --statement-id allow-partner-account \
  --action lambda:InvokeFunction \
  --principal "arn:aws:iam::987654321098:role/PartnerServiceRole"

View the current resource policy on any function:

aws lambda get-policy --function-name my-api-function

VPC and network security

By default, Lambda functions do not run inside your VPC. They run in an AWS-managed network environment with outbound internet access and access to all public AWS API endpoints. For most functions, this is the right setup.

When to attach Lambda to a VPC

Attach Lambda to your VPC when the function needs to reach private VPC resources. The serverless VPC access guide covers full setup details. The short version:

aws lambda update-function-configuration \
  --function-name my-db-function \
  --vpc-config '{
    "SubnetIds": ["subnet-private-1a", "subnet-private-1b"],
    "SecurityGroupIds": ["sg-lambda-outbound"]
  }'

Use private subnets (not public) for Lambda VPC placement. The security group attached to Lambda controls its outbound traffic. The security group on your RDS instance must allow inbound from the Lambda security group on the database port.

VPC endpoints for Lambda in private subnets

Gateway endpoints (S3, DynamoDB) are free with no per-hour charge. Interface endpoints cost around $0.01/hour per Availability Zone. If the function needs broad internet access rather than specific AWS services, a NAT Gateway in a public subnet is often simpler than creating individual endpoints for every service.

Secrets and configuration

Environment variables vs Secrets Manager

Environment variables are fine for non-sensitive configuration: feature flags, base URLs, log levels, environment names. They are encrypted at rest using AWS KMS. The problem is not encryption at rest; it is visibility.

Store actual secrets in AWS Secrets Manager and retrieve them at runtime. This keeps secrets out of function configuration, allows rotation without redeployment, and provides an audit trail of every access.

import boto3
import json

# Initialise the client once, outside the handler (reused on warm starts)
secrets_client = boto3.client('secretsmanager')

_db_credentials = None

def get_db_credentials():
    global _db_credentials
    if _db_credentials is None:
        response = secrets_client.get_secret_value(SecretId='prod/myapp/database')
        _db_credentials = json.loads(response['SecretString'])
    return _db_credentials

def handler(event, context):
    creds = get_db_credentials()
    # Use creds['username'] and creds['password']

Caching the secret outside the handler is important. Calling Secrets Manager on every invocation adds latency and cost. The pattern above calls Secrets Manager once per cold start, then reuses the cached value for all subsequent warm invocations.

The execution role needs permission to access the specific secret:

{
  "Effect": "Allow",
  "Action": "secretsmanager:GetSecretValue",
  "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/myapp/database-*"
}

Execution role vs resource-based policy

This is the most common source of confusion when people start working with Lambda. Here is a direct comparison:

When to use this security model

Different Lambda use cases require different layers. Here are common scenarios and which parts of the security model matter most:

Internal API (called by other Lambda functions in the same account)

The calling function’s execution role needs lambda:InvokeFunction on the target function ARN. No resource-based policy is required for same-account calls when the execution role already grants invoke. Keep both functions outside a VPC unless they need private resource access. The shared responsibility model applies here: AWS secures the infrastructure, you secure the permissions.

S3 file processor (triggered by bucket uploads)

Add a resource-based policy allowing s3.amazonaws.com to invoke the function, scoped to the specific bucket ARN and your account ID. The execution role needs s3:GetObject on the source bucket and write permissions on the destination. The function typically stays outside a VPC.

Lambda calling RDS in a private subnet

Place the function in the same VPC as the database, in private subnets. Attach AWSLambdaVPCAccessExecutionRole plus least-privilege permissions for the function’s actual work. Add VPC endpoints for Secrets Manager (to retrieve the database password) and CloudWatch Logs. Use security groups to allow inbound to RDS only from the Lambda security group on the database port.

Public Lambda Function URL

If using NONE auth, your function code must implement authentication. Validate JWT tokens, API keys, or request signatures before doing any real work. Consider API Gateway with a Cognito or Lambda authorizer instead. Never expose business logic through an unauthenticated Function URL without application-level auth in the code.

Lambda Function URL vs API Gateway

Function URLs are the right choice for internal service-to-service calls where the caller can sign requests with AWS credentials (AWS_IAM auth), or for simple webhooks where you own all callers. For anything public-facing or where you need more control, use API Gateway. See choosing between EC2, Lambda, and containers for broader guidance on when Lambda fits a given workload.