Data Perimeter Implementation Strategies: Lessons Learned Rolling Out SCPs/RCPs

Agnel Amodia (Tech Lead · Vanguard), Ben Joyce (IM Cloud Leader · Vanguard)

fwd:cloudsec North America 2025 · Day 1 · Track 1 - Crystal

Overview

Agnel Amodia and Ben Joyce from Vanguard presented a detailed account of how one of the world's largest investment management companies implemented a comprehensive data perimeter program across its AWS cloud environment. With more than 50 million investors, 20,000 employees, and over 80% of workloads in AWS, the stakes for getting cloud security right at Vanguard are enormous. This talk moved beyond theoretical frameworks and delivered a practitioner's guide to rolling out Service Control Policies (SCPs) and Resource Control Policies (RCPs) at genuine enterprise scale -- 500+ AWS accounts, 10,000+ human identities, and 16,000+ application identities spread across 700+ VPCs.

Watch on YouTube

Visual summary for Data Perimeter Implementation Strategies: Lessons Learned Rolling Out SCPs/RCPs by Agnel Amodia, Ben Joyce
Visual summary for Data Perimeter Implementation Strategies: Lessons Learned Rolling Out SCPs/RCPs by Agnel Amodia, Ben Joyce

Key moments

  1. 1:30 Scale of Vanguard's AWS environment: 500+ accounts, 16,000+ identities
  2. 5:45 Defining the three data perimeter boundaries: resource, network, identity
  3. 8:10 No dry-run mode for SCPs/RCPs -- using CloudTrail for impact prediction
  4. 11:50 Incomplete CloudTrail visibility and involving developers to fill gaps
  5. 13:50 Hitting AWS policy size limits and the Lambda-based dynamic solution
  6. 15:40 aws:ResourceTag not supported on S3 buckets -- forced coarse-grained fallback
  7. 16:30 CI/CD pipeline integration for exception management
  8. 18:15 Key takeaways: start small, focus on high-risk identities first

Data Perimeter Implementation Strategies: Lessons Learned Rolling Out SCPs/RCPs

Speakers: Agnel Amodia, Ben Joyce

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=Pd6rbBjiXaA

Overview

Agnel Amodia and Ben Joyce from Vanguard presented a detailed account of how one of the world's largest investment management companies implemented a comprehensive data perimeter program across its AWS cloud environment. With more than 50 million investors, 20,000 employees, and over 80% of workloads in AWS, the stakes for getting cloud security right at Vanguard are enormous. This talk moved beyond theoretical frameworks and delivered a practitioner's guide to rolling out Service Control Policies (SCPs) and Resource Control Policies (RCPs) at genuine enterprise scale -- 500+ AWS accounts, 10,000+ human identities, and 16,000+ application identities spread across 700+ VPCs.

Background

▶ Watch: Scale of Vanguard's AWS environment: 500+ accounts, 16,000+ identities (1:30)

The data perimeter model in AWS rests on three pillars: controlling who can access resources (identity), which resources can be accessed (resource), and from where access can originate (network). AWS provides SCPs, RCPs, VPC endpoint policies, and permission boundaries as the policy levers for enforcing these controls. However, implementing them across a large, complex financial services organization introduces challenges that go well beyond what AWS documentation covers. Vanguard's AWS environment is segmented by environment (production, non-production) and business domains, with SCPs custom-built per line-of-business OU based on risk profiles. Some individual accounts contain over 1,000 S3 buckets, 5,000 IAM roles, and 10,000+ policies. Three centralized teams -- network/infrastructure, cloud IAM, and development -- each manage different layers of the policy stack, meaning policy changes must be threaded through independently managed control planes without breaking existing workloads.

Key Findings

▶ Watch: No dry-run mode for SCPs/RCPs -- using CloudTrail for impact prediction (8:10)

The most critical finding was that there is no dry-run mode for SCPs or RCPs -- once deployed, policies take immediate effect and can break production applications without warning. Vanguard overcame this by building custom Python scripts that analyzed CloudTrail logs to predict the impact of proposed policy changes before deployment. For the resource perimeter, they flagged violations where a user identity's account ID did not match the recipient account ID. For the network perimeter, they compared source IP addresses against trusted VPC and corporate CIDR ranges. For the identity perimeter, they checked for external principals accessing internal resources.

A second major finding involved AWS policy size limits. Initially, Vanguard hardcoded VPC IDs and corporate CIDR blocks directly into SCPs and RCPs. As the environment grew, these policies hit the AWS character limit. The solution was deploying a Lambda function in each account that dynamically fetches VPC IDs and feeds them into CloudFormation templates -- though this introduced its own fragility, since a Lambda failure would cascade into a policy deployment failure.

They also discovered that the aws:ResourceTag condition key is not supported on S3 buckets at the bucket level (only on individual objects). This forced them to fall back to the coarser aws:PrincipalAccount condition key for identity perimeter RCP policies, sacrificing fine-grained access control.

Technical Deep Dive

▶ Watch: Hitting AWS policy size limits and the Lambda-based dynamic solution (13:50)

Vanguard's data perimeter defines three strict boundaries. The resource perimeter prevents non-production principals from accessing production resources and vice versa, and blocks any principal from accessing resources outside the organization. The network perimeter ensures that access to resources is allowed only from trusted networks (internal VPCs and corporate CIDR ranges), blocking public internet access even from legitimate corporate principals. The identity perimeter restricts resource access to trusted identities within the organization.

A pivotal architectural decision was to apply SCPs and RCPs at the account level rather than the OU level. While OU-level policies are simpler to manage initially, they become problematic when fine-grained exceptions are required for specific accounts or teams. Applying at account level gave Vanguard more control and flexibility, while keeping the OU layer clean for future use with broader security invariant controls.

For exception handling, Vanguard integrated data perimeter compliance into their CI/CD pipeline. When a developer's code includes an external account reference in an IAM permission policy or resource-based policy, the build fails. To proceed, the developer must log a risk in the risk management system. Once approved, they can apply a data perimeter exception tag to the relevant resources. Regular queries identify all tagged resources that lack documented exceptions, ensuring continuous compliance tracking.

Post-deployment monitoring relied on CloudTrail dashboards that tracked spikes in access-denied errors. A large spike indicated a policy problem warranting rollback and investigation. Individual access denials triggered direct developer engagement to add the appropriate exception tags.

The team identified that not all API activities are logged in CloudTrail due to business decisions or service limitations. For example, if S3 GetObject calls were not logged, they could not see which IAM roles were accessing resources outside the organization. To compensate, they involved developers directly, spreading awareness about the data perimeter program through office hours, email campaigns, and line-of-business outreach.

Demo / Proof of Concept

▶ Watch: aws:ResourceTag not supported on S3 buckets -- forced coarse-grained fallback (15:40)

No live demo was performed. The talk was entirely a lessons-learned presentation based on Vanguard's production implementation.

Defensive Implications

▶ Watch: Key takeaways: start small, focus on high-risk identities first (18:15)

Organizations embarking on data perimeter implementations should start small and define trust boundaries before writing any policies. Prioritizing high-risk identities -- human users, privileged application identities, and EC2 instance roles -- delivers the greatest initial value. For Lambda functions, deploying detective controls first to enforce VPC attachment gives developers time to adapt without breaking existing functions.

Defenders should build predictive impact analysis tooling using CloudTrail before deploying any SCPs or RCPs, since there is no dry-run capability. Tag-based exception management integrated into CI/CD pipelines ensures that exceptions are approved, documented, and auditable. Finally, organizations should design with AWS policy size limits in mind from the start and consider dynamic policy generation via Lambda or CloudFormation rather than hardcoding values.

Key Takeaways

  • No dry-run mode exists for SCPs/RCPs -- build CloudTrail-based impact prediction tooling before deploying preventive controls
  • Apply SCPs and RCPs at the account level for maximum flexibility; reserve the OU layer for broad security invariants
  • AWS policy size limits are a real constraint at scale; use dynamic policy generation via Lambda instead of hardcoding VPC IDs and CIDR blocks
  • The aws:ResourceTag condition key does not support S3 buckets, forcing coarser-grained exception handling
  • Integrate data perimeter compliance checks into CI/CD pipelines with mandatory risk documentation for any exceptions
  • Start with high-risk identities first and use detective controls (e.g., requiring Lambda VPC attachment) before deploying preventive controls

About the Speaker(s)

Ben Joyce is an IAM Cloud Leader at Vanguard, one of the world's largest investment management companies managing assets for over 50 million investors. Agnel Amodia is the Technical Lead at Vanguard who has been leading and driving the data perimeter program. Together they manage SCPs, RCPs, and permission boundaries as part of Vanguard's centralized cloud IAM team.

Reviews

Dr. Zero (Offensive Security Researcher) — SOLID

A well-structured operational lessons-learned talk from Vanguard's data perimeter rollout across 500+ AWS accounts. No novel attacks or exploits, but genuinely useful practitioner-grade detail on the pain of deploying SCPs/RCPs at scale, including real AWS limitations like the missing ResourceTag support on S3 buckets and policy size constraints.

Heather Calloway (CISO) — STRONG ACCEPT

Vanguard delivers exactly the kind of talk the industry needs more of: a real enterprise sharing the operational reality of implementing data perimeters at scale across 500+ AWS accounts, with honest discussion of AWS limitations, exception management through CI/CD governance, and the organizational change management required to bring 20,000 employees along. This is directly applicable to any CISO building a cloud security program at scale.

→ Top-rated talks at fwd:cloudsec North America 2025

All talks from fwd:cloudsec North America 2025