Serverless removes the need to manage servers, but it does not remove application security work. For AWS Lambda workloads, you still choose who can invoke each function, what its code can access, which network paths it can use, and how data and failures are handled. This guide covers nine practical controls for those decisions, with a focus on the boundaries around Lambda, API Gateway, and AWS data services.

A VPC is one tool in that design, not a default security switch. Every Lambda function runs in a Lambda-managed VPC; configuring access to a VPC in your account gives the function paths to selected private resources. Whether a function needs that connection depends on its dependencies and network requirements, as the Lambda VPC documentation explains.

  1. Give each function only the IAM permissions it needs.
  2. Authenticate and authorize API callers correctly.
  3. Use VPC networking for private resources and controlled egress.
  4. Protect data in transit and at rest.
  5. Collect the right application, network, and account activity.
  6. Filter public HTTP traffic with AWS WAF where it fits.
  7. Restrict access to stored data and review exposure.
  8. Keep errors and logs from disclosing sensitive information.
  9. Continuously review permissions, configuration, and findings.

1. Use Least Privilege Access

A Lambda function uses an execution role when its code calls AWS services. Scope that role to the actions and resources required by that function. A function that reads a small set of objects should not also be able to change bucket policies, administer unrelated tables, or manage IAM. Keep invoke access distinct from the execution role: direct invocations can be granted through a function's resource policy, while event source mappings can use the execution role to read from a source. Check the permission model for each trigger.

Give each function a narrow execution role

Start from the function's job, list the AWS API actions and resources it needs, and grant those permissions on the narrowest practical resource ARNs. Separate roles when functions have different trust boundaries or data access. AWS recommends temporary credentials from IAM roles for workloads; do not embed long-lived AWS access keys in code or configuration. Store external service credentials in AWS Secrets Manager with narrowly scoped access.

Review and reduce permissions over time

Use IAM Access Analyzer policy generation to draft a narrower policy from CloudTrail activity, then review the result and test the function's real paths before replacing permissions. Observed activity can miss infrequent jobs or failure paths, so generated policies are evidence for review rather than proof that an action is unnecessary. Also inspect the function's resource policy for unintended public or cross-account invocation.

2. Protect API Gateways

For an HTTP-facing function, the API is a separate trust boundary. Choose an authorizer that matches the caller: IAM authorization for AWS principals, a JWT authorizer for HTTP APIs, a user-pool authorizer for REST APIs, or a Lambda authorizer for custom rules. Supported choices differ by API type; see AWS's REST API access-control guide. Keep the function's own resource permissions narrow as well, so an exposed route does not inherit unrelated AWS access.

Authenticate callers and authorize each request

Do not treat an API key as a user credential. On REST APIs, API Gateway API keys identify clients for usage-plan metering; AWS says they should not be used for authentication or authorization. Use a supported authorizer for access control, then authorize sensitive operations and records in the application using the verified caller identity.

Validate input and set traffic limits

Reject malformed or oversized requests, validate values against the operation being performed, and return only the data the caller is allowed to see. Configure API Gateway throttling and quotas to shape expected traffic, but treat them as targets: AWS applies usage-plan limits on a best-effort basis. They are not a hard access-control or cost ceiling. For more on API Gateway's authorization and usage-plan options, see the API Gateway usage-plan guidance.

Event-driven functions may also be invoked without passing through an HTTP gateway. Limit which principals can publish or configure event sources, and validate event contents at the function boundary. The site's EventBridge security guide covers event-bus permissions, encryption, monitoring, and failure handling in more detail.

3. Use VPCs for Sensitive Tasks

Attach a function to your VPC when it needs to reach private resources such as a database or internal service. Its access to those resources and to the internet is determined by the VPC's routes, security groups, endpoints, and other network controls. In particular, selecting a public subnet does not give a VPC-connected Lambda function internet access.

Choose routes for required destinations

For outbound access to the public internet, a function in a private subnet needs a route through a NAT gateway or another suitable egress design. If it only needs supported AWS services, consider VPC endpoints instead; for example, an S3 gateway endpoint lets a VPC reach S3 without an internet gateway or NAT device. Restrict security-group egress and destination-side ingress to the flows the function needs. Security groups control network traffic; they do not replace API authentication or IAM authorization.

Lambda needs EC2 network-interface permissions on its execution role to attach or change a VPC configuration. AWS notes that these permissions are needed to create and manage interfaces, not to invoke the function, so you can remove them after setup; restore them before a later VPC configuration change. See the Lambda VPC permissions guidance, and the site's AWS VPC configuration guide for help with route tables, subnets, endpoints, and security groups.

4. Use Strong Encryption

Use HTTPS/TLS for network connections to APIs and AWS service endpoints, and choose supported TLS policies for custom API domains. Encryption in transit protects a connection; it does not prevent an authorized application or compromised function from reading data after it has been decrypted.

Protect stored data and control key access

Amazon S3 encrypts new objects at rest by default, and DynamoDB encrypts table data at rest by default. Decide whether service-managed keys meet your access, audit, and compliance needs or whether a customer-managed KMS key is required. If you use customer-managed keys, limit who can use and administer them, and review key policies alongside the data resource policies. Key rotation alone does not repair overly broad access.

Match encryption to the data path

Use client-side encryption when your threat model requires the service to receive ciphertext rather than plaintext. Otherwise, define where plaintext is handled, limit access to it, and avoid copying it into logs or diagnostic output. Follow AWS's service-specific guidance for S3 encryption and DynamoDB encryption at rest.

5. Track Network Activity

Monitoring should answer different questions with the right evidence. CloudWatch metrics and logs help you understand function and API behavior. CloudTrail records account API activity. GuardDuty Lambda Protection analyzes Lambda network activity for potential threats. These sources complement one another; a function log is not a complete network-flow record, and CloudTrail management events are not a record of every invocation or data access.

Collect useful, structured signals

Emit concise structured logs with a request or correlation identifier, outcome, and relevant operational context. Track Lambda errors, throttles, duration, and concurrency, plus API Gateway authorization failures, latency, and 4xx/5xx responses. Create alarms for failures and unusual changes that matter to your workload. The site's Lambda error-monitoring guide goes deeper on metrics, log queries, and alarms.

Enable the records your investigation needs

CloudTrail records Lambda management activity, but Lambda invocation data events are not logged by default. Enable the relevant data-event selectors when you need that audit trail, and account for their volume and cost. For network threat detection, GuardDuty Lambda Protection analyzes Lambda network activity logs and can produce findings for suspicious behavior. Decide which signals you need, how long to retain them, who may read them, and how findings reach responders.

6. Use Web Application Firewall (WAF)

A web application firewall adds a request-filtering layer for public HTTP workloads. AWS WAF can inspect requests against rule groups and custom rules before traffic reaches a protected resource. It complements authentication, application validation, and API Gateway throttling; it does not replace them.

Associate a web ACL with the right resource

For API Gateway, AWS documents AWS WAF protection for REST API stages. A Regional API requires a Regional web ACL in the same Region. CloudFront distributions use a different scope. Confirm that your API type and deployment match the current AWS WAF integration requirements before creating rules.

Tune rules and watch their results

AWS baseline managed rule groups can provide a starting layer; add rules for abuse patterns relevant to your application. Test and tune changes in a staging environment, then use count mode with production traffic before blocking requests. Review metrics, logs, and sampled requests for false positives. Configure logging only where it helps investigation, and avoid retaining unnecessary personal or secret data from request fields. Monitor allowed, blocked, and counted traffic so rule changes have visible effects.

7. Protect Data Storage

Restrict S3 access explicitly

Keep S3 Block Public Access enabled at the account or organization level unless a documented use case requires public content. Scope Lambda roles and bucket policies to the required bucket and prefixes, and review access-point and cross-account policies. Block Public Access guards against public bucket or object permissions, but it does not correct an overbroad identity policy. IAM Access Analyzer for S3 can help identify external or public access. For policy patterns and access-control tradeoffs, see the site's S3 access-management guide.

Apply least privilege to tables and indexes

Grant functions only the DynamoDB actions and table or index resources they need. DynamoDB encrypts data at rest and service communications in transit by default; use a customer-managed KMS key when you need its additional control over key policy and lifecycle. A DynamoDB VPC endpoint can provide a private network path, but IAM still decides whether a request is authorized.

Audit object-level activity selectively

CloudTrail S3 data events can record object-level reads and writes, but they are not enabled by default and can be high volume with additional charges. Turn them on for the buckets and operations where that evidence is needed, then protect the logs as sensitive data. Keep access policies, endpoint policies, and key policies consistent with the same intended data boundary.

8. Handle Errors Safely

Return errors that help a caller recover without disclosing implementation details. Do not expose stack traces, internal hostnames, SQL statements, tokens, secret values, or raw upstream responses in public API messages. Use a stable error code and correlation identifier so support staff can locate the corresponding protected server-side record.

Keep secrets and personal data out of logs

Log the smallest amount of context needed to diagnose a failure. Avoid logging authorization headers, credentials, full event payloads, or sensitive fields. Restrict log-group access and retention to the people and period required by operations. CloudWatch Logs data-protection policies can audit for and mask selected sensitive data in log events, but they are a backstop; prevent sensitive values from being emitted whenever possible.

9. Do Regular Security Checks

Review security as the application and its permissions change. Include the function's execution role and invocation policy, API authorizers and resource policies, VPC routes and security groups, public data access, encryption keys, logging, and third-party dependencies. Test changes through your normal deployment process and investigate findings rather than treating a clean dashboard as proof that every control is appropriate.

Use findings to guide a focused review

IAM Access Analyzer can identify external access and help refine permissions from observed use. AWS Security Hub CSPM evaluates supported Lambda resource settings through security controls, while GuardDuty detects potential threats from activity signals. Amazon Inspector Lambda standard scanning identifies vulnerabilities in supported function and layer dependencies. Coverage and controls vary by service, Region, and configuration, so check what is enabled for the accounts you operate. The site's cross-account Inspector and Security Hub guide describes how to review findings across accounts.

Revisit the design when dependencies change

Recheck permissions when a function gains a new data source or destination, when an API operation changes, and when a dependency or runtime is updated. Remove obsolete access, confirm that event-source permissions still name the intended principals and resources, and verify that alerts reach an owner. Include those checks in the normal maintenance and release process so the security design stays aligned with the application.

Conclusion

Secure serverless workloads by making each boundary explicit: who can invoke a function, what its role can do, which network destinations it can reach, and how data is stored, monitored, and reported. Use VPCs when private connectivity or controlled routing is required, then add the IAM, API, storage, logging, and review controls that fit the application's actual paths. Reassess those choices as code, event sources, and dependencies change.