How do you prevent public access to AWS Lambda functions and function URLs?

What actually blocks public Lambda invocation and function URL exposure?

Public access is prevented at the permission layer, not by the function code itself. The key question is whether the Lambda resource policy and any function URL configuration allow unauthenticated callers or broad principals to invoke the function. If they do, the function is effectively public even if the code sits inside a private VPC.

For serverless environments, the practical control is to keep invocation limited to the smallest set of authenticated principals that genuinely need it. That includes reviewing resource-based policies for wildcard principals, checking cross-account invoke grants, and making sure function URLs are not left with open authentication settings. The Serverless Security Guide is the best place to anchor that review because it covers function permissions, function URLs, secrets, dependencies and serverless logging together.

Function URLs deserve special attention because they create a direct HTTP entry point to the function. If the URL is enabled, the real control decision is whether the URL uses AWS_IAM or an equivalent authenticated path, and whether any policy attached to the URL or function still allows public invocation. If the URL is not required, disabling it is safer than relying on ad hoc network controls.

How do you check for public access and remove it safely?

Start with the Lambda resource-based policy, because that is where public invoke permissions are usually hidden. Look for statements that allow lambda:InvokeFunction or related permissions to *, to anonymous callers, or to principals that are broader than intended. Then verify the function URL auth type and any conditions that restrict who can call it. A function can look private in one console view and still be callable from the internet if the URL policy is permissive.

Use this as an access review, not just a configuration cleanup. If the function was ever exposed, the review should also cover whether the invoke path can be reached through API Gateway, EventBridge, an application load balancer, or another cross-account integration that may still be valid. The AWS Security Guide is useful here because it ties Lambda hardening to broader AWS account, logging and public-access controls.

When the function must remain reachable, tighten the trust boundary around the caller instead of making the endpoint broadly public. That usually means authenticated invocation, narrowly scoped permissions, and explicit review of who can create or modify function URLs. If the business requirement does not clearly justify internet reachability, remove the URL entirely and rely on a private invocation path.

What should you do if you need the endpoint but not public exposure?

If a function must be exposed to users or services, treat that as an application access decision, not a default Lambda setting. The safer pattern is authenticated access with clearly defined authorization checks upstream, plus logging that lets you distinguish legitimate traffic from unexpected invocation attempts. Do not assume that private code execution alone prevents abuse, because the public surface is the invoke permission and URL configuration.

There is also an operational issue: public endpoints tend to accumulate forgotten exceptions. Over time, teams add temporary grants for testing, partner integrations or emergency access and never remove them. That is why the permission model should be revisited after deployment changes, not only during initial setup. The Broken Access Control Prevention Guide is relevant because the same failure pattern appears when server-side authorization is weaker than the intended access model.

For deeper validation of the authenticated path, the OWASP ASVS requirements around authentication, session handling and access control provide a useful benchmark for the layers in front of the function. They do not replace AWS configuration checks, but they help verify that the exposed endpoint is not merely reachable, it is also properly controlled.

Risk and Threat Considerations

Public Lambda exposure is risky because it turns a serverless function into an externally reachable execution surface. If the function performs state changes, handles credentials, or calls other services with elevated privileges, an attacker does not need to break into the account first, they only need a way to invoke the function.

Failure mechanism: A permissive resource policy, open function URL, or overly broad cross-account grant allows unauthenticated or unintended callers to invoke code and abuse downstream permissions.

Impact: The result can be unauthorized execution, data exposure, service abuse, unexpected cost, or lateral movement through whatever the function is permitted to access.

Practitioner Guidance

What to verify: Confirm that every Lambda function and function URL has an explicit owner, a documented reason for exposure, and a testable allowlist of callers. If you cannot explain why a function must be callable from outside its trusted boundary, it should not be publicly reachable.

Common mistake: Teams often check the function code and ignore the resource policy. That misses the real control plane, because public invocation is usually decided by permissions, not by the implementation language or runtime.

Practitioner takeaway: Treat Lambda public exposure as an authorization problem first and an infrastructure problem second, because the safest configuration is the one that makes public invocation impossible unless it is explicitly required and continuously reviewed.

Related resources from NHI Mgmt Group

• How do you prevent AWS Lambda functions from being publicly accessible?
• How do you prevent anonymous public access to Azure Blob Storage containers?
• How should security teams decide whether JIT access is safe for non-human identities?
• What is the difference between JIT access and Zero Trust for NHIs?