What should be used instead of the AWS AWSLambda_ReadOnlyAccess managed policy for least privilege?

Use a customer-managed policy that allows only the Lambda read actions needed to inspect the specific functions and settings in scope. Avoid giving broad read access across all functions. Read-only Lambda permissions still expose code metadata, configuration and event relationships, which can help an attacker map and target serverless workloads.

Why a Customer-Managed Policy Is the Right Replacement

The right substitute is a customer-managed policy that grants only the Lambda read permissions required for the functions and settings actually in scope. That keeps review access narrow, auditable, and easier to reason about than a broad managed policy. It also avoids turning routine inspection into an implicit reconnaissance path across the whole Lambda estate.

A broad read-only policy can reveal code metadata, environment details, event sources, aliases, versions, and configuration patterns that help an adversary map deployment structure. AWS IAM Policies and Roles Guide is the right place to ground that design choice in policy evaluation, explicit deny, and scope control.

For teams managing multiple AWS workloads, the practical goal is not “read only” in the abstract, but read access limited to the minimum set of resources needed for the job. If the task is inventory or troubleshooting for a single application boundary, the policy should reflect that boundary rather than the entire account.

How to Scope Lambda Read Access Without Overexposing the Estate

Start by listing the exact Lambda actions needed for inspection, then bind them to the specific functions, aliases, tags, or resource patterns that the operator or tool must examine. Avoid wildcard patterns unless there is a clear operational reason, because broad reads often become the easiest way to discover adjacent services, event relationships, and environment naming conventions.

The same logic applies when the reviewer is a human operator, a script, or an automation path. IAM and IGA Basics helps frame least privilege as a lifecycle and entitlement problem, not just a policy syntax problem.

When access is being used for diagnostics, separate “can inspect” from “can change.” Read permissions should not quietly become a bridge to broader AWS visibility, because the safest review policy is one that answers the operational question and nothing more. For teams that already standardise on structured access models, Authorisation Models Guide is useful for deciding whether role, attribute, or resource conditions best constrain the scope.

What Good Least Privilege Looks Like in Practice

Good practice is a policy that is specific enough to support the real work while failing closed everywhere else. It should be easy to see which functions are in scope, which read actions are allowed, and why the exception exists. If the policy cannot be explained in one or two sentences, it is probably too broad.

That review discipline matters because Lambda metadata can be surprisingly revealing even when nobody can modify code. Event source mappings, function configuration, execution roles, and environment variables all help an attacker understand what to target next. Ultimate Guide to NHIs, Key Challenges and Risks is a useful companion for understanding why over-permissioned read access still creates exposure.

Where the reader needs a control baseline, a zero-standing-access mindset is a better fit than persistent broad read entitlements. That means granting access only for the review task, reviewing it regularly, and removing it when the task ends.

Risk and Threat Considerations

Broad Lambda read access is not harmless. Even without write permissions, it can expose enough structure for an attacker or careless operator to map sensitive functions, infer trust relationships, and identify downstream targets. The risk rises when the same policy spans many accounts, environments, or application teams.

Failure mechanism: Excessive read scope turns routine inspection into estate-wide reconnaissance, exposing configuration, relationships, and operational details that should stay compartmentalised.

Impact: An exposed view of functions and settings can accelerate targeting, widen blast radius during compromise, and make later privilege escalation or abuse easier to plan.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Lambda read scope should be limited to task need and resource boundary.
Recommendation — Restrict Lambda read permissions to the minimum actions and resources required for the task.
ISO/IEC 27001:2022	A.5.15 — Access control	The question is about replacing broad access with narrower scoped access.
	A.8.2 — Privileged access rights	Broad read-only policies can still create privileged visibility into sensitive workloads.
Recommendation — Define and enforce scoped access rules for Lambda inspection roles. Review and minimise privileged read entitlements for cloud operator access.
CIS Controls v8	CIS-6 — Access Control Management	This is an access-rights minimisation decision for cloud permissions.
Recommendation — Inventory and right-size Lambda permissions so only approved reads remain.
NIST Zero Trust (SP 800-207)	PR.AA-05 — Least Privilege Access	The answer centers on narrow task-scoped access for serverless inspection.
Recommendation — Apply least-privilege access to Lambda inspection and limit resource scope.

Practitioner Guidance

What to verify: Confirm that the policy only covers the Lambda read actions actually required, and that each resource scope matches a specific application boundary or operational need. If the policy can enumerate functions outside the task, it is already too broad.

Common mistake: Treating a managed read-only policy as “safe enough” because it does not modify resources. In practice, visibility is itself a form of access, and visibility into serverless metadata often reveals more than teams expect.

Practitioner takeaway: Least privilege for Lambda is about limiting what can be learned, not just what can be changed, so the safest replacement is the narrowest customer-managed policy that still supports the exact inspection task.