Rowan Udell, AWS Community Builder and author of the “Practical AWS IAM Guide,” brings over a decade of hands-on AWS experience to the conversation about cloud security. In this episode, Rowan shares practical insights on navigating AWS Identity and Access Management (IAM), from foundational concepts like least privilege to advanced strategies like just-in-time access and data perimeters.
The discussion covers the evolution of cloud security thinking, the challenges of measuring security ROI, and how organizations can mature their IAM practices without sacrificing developer velocity.
You can read the complete transcript of the episode here >
How has cloud security thinking evolved over the past decade?
Rowan started working with AWS over a decade ago, when the fundamental question was “should we use the public cloud?” Today, that debate is settled. The conversation has shifted to “how do we use cloud services securely and effectively?”
The cloud has become the de facto standard for building modern solutions, offering unmatched benefits for on-demand workloads and scalability. But with that shift comes new security challenges—particularly around identity and access management.
Should humans have access to production cloud accounts?
AWS’s Chad Lawrence champions the principle that “humans do not need access to production cloud accounts.” While this is an aspirational goal, Rowan emphasizes that it’s not a binary switch—it’s a journey that depends on organizational maturity.
Business needs often take precedence. Abruptly cutting off production access can hinder deployments, operations, and incident response. The key is to start with visibility:
- Use AWS Identity Center to centralize identities across your organization
- Create an audit trail of who did what, where, and when
- Identify why humans are accessing production—is it for manual deployments? Emergency fixes? Lack of automation?
Once you understand the underlying issues, you can implement solutions like infrastructure as code, CI/CD pipelines, and increased automation. Rowan also recommends moving from long-term access keys to short-term credentials to reduce the window of potential compromise.
What are the foundational AWS security tools every organization should use?
Beyond Identity Center, Rowan strongly recommends leveraging AWS Organizations along with Service Control Policies (SCPs) and Resource Control Policies (RCPs).
AWS accounts act as ownership groups, providing a natural “blast radius” for permissions. If an administrator has access to one account, their actions are confined to that account—minimizing impact on other environments like production.
Many older AWS customers, who predate AWS Organizations, suffer from having too many resources and teams in a single account. This leads to complexity and security challenges.
SCPs and RCPs are critical because they override individual account settings, allowing for robust controls like:
- Disabling root account access
- Preventing backup deletions
- Restricting resource sharing outside the organization
These guardrails apply automatically to every account in your organization, including new ones, dramatically simplifying your security posture.
How do you measure ROI for security initiatives?
Measuring the return on investment for security is notoriously difficult because security is often a non-functional requirement. The cost of an outage can be significant—impacting customer trust, SLAs, and revenue—but translating this into a precise monetary value is highly context-dependent.
From an IAM perspective, Rowan suggests focusing on measurable metrics like:
- Reducing the number of IAM users with excessive permissions
- Tracking incidents caused by overprivileged access
- Monitoring the frequency of permission-related outages
ROI becomes clearer when security measures solve recurring problems, such as one team inadvertently breaking another’s roles due to overly broad permissions.
Why is identity the new perimeter?
Historically, networks were the primary focus of security. Organizations spent significant time designing networks, protecting perimeters, and ensuring resources weren’t publicly accessible.
In the cloud, the right identity can change the network. The right identity can do virtually anything. In AWS terms, if you have the ability to create IAM resources or attach policies, you can escalate your privileges and do pretty much whatever you want.
This is where permissions boundaries become critical. They act as a second layer of defense, restricting the maximum permissions a role can have—even if created by a developer. While challenging to implement, a simpler approach can be to give developers their own AWS accounts, allowing them to manage their own environments within a contained blast radius.
What does “least privilege equals maximum effort” mean?
Eric Brandwine, an AWS principal engineer, coined the phrase: “Least privilege equals maximum effort.”
Achieving least privilege in AWS is incredibly challenging. It requires:
- Deep understanding of exactly what permissions are needed
- Continuous monitoring as your business evolves
- Regular optimization as AWS itself changes (new services, new permissions)
Moreover, it’s not a one-time task. As Rowan notes, “This was least privilege according to last year, but it’s not least privilege according to this year.” Businesses change, cloud services evolve, and permissions must be continuously revised.
Many security practitioners and compliance auditors simply say “just do least privilege,” but it’s not that easy. It takes significant effort and ongoing commitment.
What is just-in-time access and when should you implement it?
Just-in-time (JIT) access is a highly advanced strategy that minimizes standing access to environments like production. Instead of permanent access, individuals request access only when needed, for a predefined window.
Benefits of JIT access include:
- Reduced attack surface: No standing access means fewer opportunities for compromise
- Clear audit trail: Every access request is logged with justification
- Protection against accidents: Dramatically reduces incidents like “I thought I was in dev, but I was in production”
- Detection of unauthorized access: Alerts can flag access without a corresponding request
However, JIT requires a high level of automation and is not suitable for early-stage startups. As Rowan notes, “There’s a cost associated to doing these things. You don’t get just-in-time access for free.”
For organizations at the right maturity level, JIT is an excellent goal to work toward.
Learn more about Just-In-Time Access >>
How should healthcare organizations secure sensitive data?
Addressing a question from a security leader at a remote-first healthcare startup, Rowan emphasized the paramount importance of knowing exactly where all sensitive data resides.
Without this precise knowledge, effectively securing data becomes impossible. Different data locations require different protection strategies:
- Client-side encryption: AWS database encryption libraries can encrypt data on the client side, so even administrators in the AWS console only see masked values
- Data classification: Use tags or naming conventions to classify resources by sensitivity level
- Access controls: Implement strict IAM policies based on data classification
Rowan also cautioned about using tags for attribute-based access control (ABAC). While tags work well for data classification, they have limitations:
- Originally designed for cost allocation
- Inconsistent across AWS services (some resources can only be tagged at creation)
- Tagging permissions vary by service and API call
Organizations must carefully control who can modify tags if they’re using them for security purposes.
What are common IAM misconfigurations to avoid?
The biggest misconfiguration Rowan sees is organizations that predate AWS Organizations and haven’t gone back to implement modern best practices. They’re missing out on newer features and struggling with complexity.
Key recommendations:
- Simplify your architecture: Complexity doesn’t result in more security—the opposite is true
- Use organizational-level controls: SCPs and RCPs apply automatically to all accounts
- Enable GuardDuty: It’s cost-effective at smaller scales and can detect credential exfiltration and other threats
- Leverage session policies: Dynamically limit permissions even when assuming a role with broad access
- Monitor IAM Access Analyzer: Review the actual resulting configuration, not just your intentions
What lesser-known AWS features should security teams use?
Rowan highlighted several underutilized features:
GuardDuty: Still not turned on everywhere, despite being cost-effective and capable of detecting credential exfiltration and anomalous behavior.
Session policies: The last policy evaluated in the IAM policy evaluation chain. They can only remove permissions, not grant them. This allows you to dynamically limit your own access—for example, when running a script that only needs S3 access, even though you have admin permissions.
IAM Access Analyzer: Provides visibility into the actual resulting configuration of your IAM policies, helping you catch unintended access grants.
How will AI and LLMs impact IAM in 2025 and beyond?
Rowan sees both opportunities and challenges with AI in the IAM space:
Current limitations: LLMs are not yet reliable for writing IAM policies. They work well for common scenarios (Lambda with API Gateway), but struggle with specific, least-privilege configurations. They often hallucinate actions that don’t exist.
Potential benefits: AI can help raise the floor of security posture by:
- Reviewing code for security issues
- Suggesting fixes for common vulnerabilities
- Assessing code against the OWASP Top 10
- Providing examples of how to address security issues
Future outlook: With agentic AI and autonomous services, the guardrails discussed in this episode—SCPs, RCPs, data perimeters, session policies—become even more critical for limiting blast radius.
Rowan hopes AI will make baseline security reviews more accessible, especially for less experienced developers who may not have access to senior security engineers.
