Advanced 20 min read

Securing the Application: IAM Roles and Policies

By the end of this lesson, you'll be able to:

Apply least-privilege IAM roles to each Lambda function in this capstone's API layer, rather than one shared broad role
Explain where secrets belong in this architecture, and where they must never appear
Describe how encryption in transit and at rest, plus CloudTrail, contribute to this capstone's security posture

Prerequisites: "Designing the Data Layer: DynamoDB"

Security is designed in, not appended at the end

Diagram showing four security layers across the architecture: identity (IAM roles and least privilege), secrets (a managed secrets mechanism), data (encryption in transit and at rest), and monitoring/audit (CloudWatch and CloudTrail). — No single layer makes the whole architecture secure — each addresses a different concern, and all four need to be present.

Module 2 introduced IAM and least privilege; Module 10 introduced monitoring and security together. This lesson applies both, specifically, to this capstone's architecture — across four layers that each answer a different question: who or what is allowed to act (identity), where sensitive values live (secrets), whether data can be read if intercepted or accessed directly (encryption), and whether changes can be traced after the fact (audit).

Least-privilege roles, one per function

Each Lambda function in this capstone's API layer gets its own IAM role, scoped to only the specific DynamoDB actions and specific table (or index) it actually needs — not one broad role shared across every function, and never a wildcard Action/Resource policy or an administrator-level role attached "to be safe."

Requirement: a compromised or buggy function should be able to do as little damage as possible. Decision: one IAM role per Lambda function, granting only the specific actions (for example, read-only access to the progress table for a "view progress" function, write access only for a "record progress" function) that function needs. Reason: this limits the blast radius of any single function's compromise or bug to exactly what that function was ever supposed to touch. Alternative: one shared, broadly-scoped role attached to every function for convenience. Trade-off: per-function roles mean more IAM resources to define and keep in the IaC template (Lesson 7) — a maintenance cost accepted in exchange for meaningfully reduced blast radius.

Secrets, encryption, and audit

No credentials or connection details for this application ever belong hardcoded in source code, in a Lambda's deployed code package, or written out to a log statement. Instead, they belong in a managed secrets mechanism that functions are granted permission to read at runtime — the credential itself never passes through source control or a code review.

Data protection here means two related things: encryption in transit (traffic between the learner's browser, CloudFront, API Gateway, and Lambda travels over HTTPS/TLS) and encryption at rest (data stored in DynamoDB and S3 is encrypted on disk). Neither substitutes for the other — a system can encrypt data at rest and still leak it in transit over an unencrypted connection, or vice versa.

Finally, CloudTrail records every AWS API call made against this application's resources — who created, modified, or deleted what, and when. This is the audit trail Lesson 6 draws on when investigating a change after the fact; it answers a different question from CloudWatch's application-health monitoring, covered next.

Exercise

A teammate proposes giving every Lambda function in this application the same IAM role, with full read/write access to every DynamoDB table, "so we don't have to keep managing separate roles." Write a short response explaining the security cost of this shortcut and what you would propose instead.

Show hint

Think in terms of blast radius: what could go wrong with one function's code or credentials under the shared-role approach that couldn't happen under per-function least-privilege roles?

Securing the Application: IAM Roles and Policies Quiz

1. Why does each Lambda function in this capstone get its own IAM role instead of sharing one broad role?

To limit the blast radius of a compromised or buggy function to only what that function actually needs Because AWS does not allow two Lambda functions to share an IAM role Because shared roles are more expensive than per-function roles Because DynamoDB requires a unique role for every table regardless of function scope

2. A secret used by this application is safe to commit to source control as long as the repository is private.

True False

3. Encrypting data at rest removes the need to also encrypt data in transit.

True False

4. Granting an IAM role only the specific actions and resources a function actually needs — rather than broad or wildcard access — is the principle of least ______.

Show hint

This is the same principle introduced in Module 2 and applied here to every Lambda function individually.

My Notes

Questions about this lesson

No questions yet — be the first to ask.

Summary

Security in this capstone is designed in from the start rather than appended at the end: each Lambda function gets its own IAM role scoped to only the DynamoDB actions and resources it actually needs, secrets are held in a managed secrets mechanism and never committed to source or written to logs, data is encrypted in transit and at rest, and CloudTrail records who or what changed any AWS resource.

❬ Previous Next ❭