AWS Cloud & DevOps Tutorial 0/70 lessons ~6 min read Lesson 49“IAM, VPC, EC2, Lambda, ECS, EKS, Terraform, CI/CD, and AWS operations”

Cross-Account Access and Multi-Account Networking

Once TechLearningPro’s accounts exist under Organizations ([lesson 48](/learn/aws-cloud-devops-engineering/aws-organizations-control-tower-and-landing-zones)), humans and pipelines

Course progress0%

Focus

15 guided sections

Practice signal

Examples included

Career prep

Interview Q&A included

Cross-Account Access and Multi-Account Networking

AWS Cloud & DevOps Engineering · Lesson 49 · Advanced Platforms and Networking

Lesson Overview

Once TechLearningPro’s accounts exist under Organizations (lesson 48), humans and pipelines still need a safe way to act across account boundaries—and VPCs still need a deliberate way to talk without becoming a flat trust network. This lesson centers cross-account IAM role assumption (including role chaining concepts), resource-based policies where they apply, an introductory tease of AWS Resource Access Manager (RAM) for sharing selected resources (such as subnets or Transit Gateway attachments in supported patterns), and multi-account VPC patterns that lead into hub-and-spoke designs. You will design how a CI role in the Shared Services account deploys into Dev/Stage/Prod, how Security auditors read CloudTrail in Log Archive, and how application VPCs avoid spaghetti peering—without inventing APIs or treating “share everything via RAM” as a strategy.

Continuity: AWS Identity and Access Management, Identity Center foundations, FinOps tagging from lesson 47. Forward links: AWS PrivateLink, VPC Endpoints and DNS, AWS Transit Gateway and Network Architecture. Tag Project=tlp-lesson49. Budgets before creating test roles that spin compute, peering, or Transit Gateway attachments; delete lab roles, peering connections, and shared resources when done.

Learning Objectives

Explain why cross-account roles beat long-lived access keys copied between accounts.
Design trust policies that limit which principals can assume a role (account, org, or specific role).
Contrast identity-based policies with resource-based policies for cross-account access.
Describe role chaining risks (session duration, confused deputy) at a conceptual level.
Map Identity Center permission sets to cross-account operational roles.
Design CI/CD deploy roles from a Shared Services account into workload accounts.
Tease AWS RAM: what kinds of resources can be shared and why subnet sharing appears in landing zones.
Compare VPC peering mesh vs hub-and-spoke (TGW) for multi-account connectivity.
Identify when PrivateLink is preferable to routing entire CIDRs (preview lesson 50).
Segment prod from sandbox at both IAM and network layers.
Apply external ID / confused deputy mitigations where third parties assume roles.
Plan CloudTrail and Config visibility for AssumeRole events.
Estimate cost drivers of TGW attachments, NAT, and data transfer without inventing rates.
Troubleshoot AccessDenied on AssumeRole vs network path failures.
Write ADRs for deploy-role topology and VPC connectivity pattern.
Prepare interview answers with TechLearningPro multi-account narratives.
Avoid standing admin across all accounts.
Clean up lab shares, peers, and roles; keep budgets on.

Prerequisites

Lesson 48 landing zone OU mental model; IAM policy literacy.
Optional sandbox with two accounts or Instructor-provided trust diagrams if org access is limited.
Budget alerts; no production RAM shares without change control.

Detailed Core Concepts

Cross-account IAM roles

Account A’s principal calls sts:AssumeRole on a role in Account B. The role’s trust policy must allow that principal; the role’s permissions policy authorizes actions in B. Temporary credentials replace static keys. TechLearningPro’s pipeline role in Shared Services assumes TLPDeployRole in tlp-prod-apps with a narrow permissions set (ECS update, S3 sync to content buckets—not * on day one).

Trust policy design

Trust on account root is coarse; prefer trusting a specific role ARN or Identity Center role path. Organization ID conditions (where supported) reduce accidental trust of the wrong account. External IDs help when SaaS vendors assume into your account—understand the confused deputy problem before copying blog JSON.

Resource-based policies

S3 bucket policies, KMS key policies, Secrets Manager resource policies, and similar allow principals in other accounts when identity policies alone are insufficient. Cross-account KMS needs both key policy and IAM grants aligned (AWS KMS and Encryption Architecture).

Role chaining

Role A assumes Role B assumes Role C. Useful for broker patterns; risky for duration limits, auditing complexity, and accidental privilege accumulation. Prefer short chains. Document every hop in ADRs.

AWS RAM tease

Resource Access Manager shares selected resources with accounts or OUs (for example, sharing a Transit Gateway or VPC subnets in supported architectures—verify current shareable resource types in AWS docs). RAM is not a replacement for IAM on every API; it is a sharing fabric for specific resource classes. Landing zones often share networking constructs from a Network Hub account to avoid duplicating TGW per account.

Multi-account VPC patterns

Isolated VPCs — no east-west routing; only public/edge access. Simple for sandboxes.
VPC peering — pairwise; does not transit; meshes explode with N accounts.
Transit Gateway hub-and-spoke — centralize routing (deep dive lesson 52).
Shared VPC (RAM) — participants launch into shared subnets with careful IAM/network ACLs—powerful and easy to get wrong; use with platform ownership.
PrivateLink to shared services — expose a service without sharing full CIDR reachability (lesson 50).

TechLearningPro default aspiration: spokes for app accounts, hub network account, PrivateLink for internal APIs, TGW for selective CIDR routing—not “peer all the things.”

Inspection and segmentation tease

Central inspection VPCs (firewall appliances / AWS Network Firewall patterns) often attach to TGW. Mentioned here as a reason to avoid flat transitive trust; detailed in lesson 52.

Architecture and Design Diagrams

mermaid
flowchart LR
  DevHuman[Developer Identity Center]
  SharedCI[Shared Services CI role]
  DevAcct[Dev account TLPDeployRole]
  StageAcct[Stage TLPDeployRole]
  ProdAcct[Prod TLPDeployRole]

  DevHuman -->|AssumeRole / portal| DevAcct
  SharedCI -->|AssumeRole| DevAcct
  SharedCI -->|AssumeRole| StageAcct
  SharedCI -->|AssumeRole gated| ProdAcct

mermaid
flowchart TB
  Hub[Network Hub account TGW]
  App1[Dev VPC]
  App2[Prod VPC]
  Shared[Shared Services VPC]
  Hub --- App1
  Hub --- App2
  Hub --- Shared

Technical Explanation

Deploy path walkthrough

CodePipeline/GitHub Actions OIDC role in Shared Services obtains credentials.
Pipeline assumes arn:aws:iam::PROD:role/TLPDeployRole with an ExternalId or condition keys as designed.
Deploy role may push images to prod ECR, update ECS task definitions, invalidate CloudFront—only listed actions.
CloudTrail in both accounts records AssumeRole and deploy APIs for forensics (CloudTrail lesson).

Human access path

Identity Center permission sets federate into accounts. Prod write access is break-glass or change-window only. Read-only for on-call by default. Continuity with incident lessons: assume-role into prod for live response must be logged and time-bound.

Confused deputy

If a role trusts a vendor account too broadly, another customer of that vendor might trick it into acting on your resources. External IDs and precise trust principals mitigate. Never paste vendor trust policies without reading condition keys.

Network path vs IAM path

IAM success does not imply packets flow. Security groups, NACLs, route tables, TGW route tables, and DNS all matter. Triage: “Can I AssumeRole?” then “Can I resolve the name?” then “Is there a route?” then “Do SGs allow?” Lesson 50 deepens private DNS; lesson 52 deepens TGW routes.

RAM sharing lifecycle

Share from owner account → accept in participant (depending on settings) → use shared resource → revoke carefully. Orphaned shares confuse operators. Tag shares Project=tlp-lesson49. Verify current RAM invitation behaviors in docs.

Data transfer and NAT

Cross-AZ and cross-account patterns can increase data transfer and NAT usage. Prefer gateway endpoints for S3/DynamoDB where applicable (lesson 50) to reduce NAT hairpinning. FinOps continuity: measure before optimizing with invented savings.

Security Hub / GuardDuty across accounts

Delegated administrator patterns aggregate findings—identity and network controls still local. Cross-account access for security tooling roles should be least privilege read of findings and evidence buckets.

Performance notes

AssumeRole adds milliseconds and failure modes (throttling). Cache sessions in runners within remaining TTL carefully. Network-wise, TGW inspection adds hops—budget latency for chatty microservices; sometimes PrivateLink to a shared service is cleaner than full mesh routing.

Practical Implementation or Design Walkthrough

Problem

Design hub-and-spoke connectivity intents for TechLearningPro application accounts plus a cross-account deploy role topology from Shared Services.

Steps

Budget check; tag Project=tlp-lesson49.
Draw trust relationships: CI → Dev/Stage/Prod deploy roles with least privilege action lists (illustrative).
Write example trust policy structure (Principal, Action sts:AssumeRole, Condition placeholders)—verify Condition keys in current STS/IAM docs before applying.
Decide VPC pattern: isolated sandbox vs TGW spokes for stage/prod.
RAM tease worksheet: which resources would Network Hub share (TGW, subnets?)—cite shareable types from docs.
Negative tests: wrong account AssumeRole denied; prod deploy role cannot iam:CreateUser.
Document CloudTrail verification queries conceptually.
ADR: peering mesh rejected; TGW + PrivateLink preferred—why.
Cleanup lab peers/roles/shares.

Enterprise Real-World Scenarios

Keys in Jenkins

Legacy CI stored prod access keys. Migration to OIDC + AssumeRole eliminated key rotation theater and a leaked-key class of incidents.

Peering explosion

12 accounts, 66 peering connections, routing tribal knowledge. TGW consolidation project with route table segmentation (lesson 52) and IAM still separate.

Overbroad RAM share

Shared subnets to entire Workloads OU including sandboxes; student labs reached stage databases via SG mistakes. Fix: share only to Stage/Prod OUs; tighten SGs; prefer PrivateLink for DB access patterns where suitable.

Auditor access

Security needs read-only across Log Archive and prod Config. Identity Center SecurityAuditor permission set; no network admin rights.

Third-party vendor

Monitoring SaaS needs CloudWatch read. Dedicated role with external ID, scoped policies, expire via automation—not account root trust.

Best Practices

Prefer AssumeRole / OIDC over static cross-account keys.
Trust specific role ARNs when possible.
Least privilege deploy roles per environment.
Log and alert on sensitive AssumeRole into prod.
Separate IAM segmentation from network segmentation—use both.
Avoid VPC peering meshes past a handful of accounts.
Use RAM deliberately; inventory shares.
External IDs for third-party assumptions.
Short role chains.
Deny sandbox principals paths into prod roles via trust + SCP.
Tag all shared networking resources.
Test negative AssumeRole paths in CI.
Document who owns Network Hub.
Verify RAM/TGW shareable resource lists in current docs.
Clean up lab shares the same day.

Common Mistakes and Anti-Patterns

Access keys copied into multiple accounts.
Trust policy Principal * without conditions.
Admin deploy roles “temporarily” forever.
Assuming IAM success means connectivity works.
Peering everything including sandboxes to prod.
RAM share to entire organization without OU scoping.
Forgetting resource policies on KMS/S3 for cross-account.
Role chaining without session duration planning.
No CloudTrail review of AssumeRole.
Invented STS condition keys in labs.

Troubleshooting and Design Review

Symptom	Cause	Action
AssumeRole AccessDenied	Trust/SCP/IAM	Inspect trust policy, SCP, caller identity
Assumed but API denied	Permissions policy	Tighten understanding: trust ≠ permissions
Timeout to private IP	No route/SG	Check TGW/peer routes and SGs
Intermittent deploy failures	Session expiry / throttling	Renew sessions; backoff
Shared subnet launch fail	RAM not accepted / AZ mismatch	Verify share state and subnet AZs
Prod reachable from sandbox	Overbroad routes/SGs	Segment TGW tables; fix SGs

Interview Questions and Answers

Q1: Why cross-account roles? A: Temporary credentials, centralized audit, no long-lived shared keys.
Q2: Trust vs permissions policy? A: Trust controls who can assume; permissions control what the role can do.
Q3: Confused deputy? A: Tricking a privileged entity to act on attacker’s behalf—mitigate with external ID/conditions.
Q4: RAM purpose? A: Share supported resources across accounts/OUs without duplicating them.
Q5: Peering limitation? A: Non-transitive; mesh scales poorly.
Q6: Hub-and-spoke benefit? A: Central routing control, fewer connections, segmentation via route tables.
Q7: When PrivateLink? A: Expose a service privately without broad CIDR connectivity.
Q8: CI into prod? A: OIDC/CI role assumes narrow deploy role; change control.
Q9: How segment sandbox? A: Separate accounts, SCPs, no routes to prod, no trust to prod roles.
Q10: Cross-account S3? A: Bucket policy + IAM; KMS key policy if encrypted with CMK.
Q11: Role chaining risk? A: Complexity, duration, audit difficulty.
Q12: Detect abuse? A: CloudTrail AssumeRole spikes, GuardDuty findings, unusual ASGs.
Q13: Shared VPC caution? A: Co-tenancy requires strong SG/IAM discipline and platform ownership.
Q14: First troubleshooting step? A: Identity (STS) vs network path isolation.
Q15: Landing zone link? A: Roles and shares hang off OU/account design from lesson 48.

Hands-On Exercises

Exercise: Design hub-and-spoke connectivity for application accounts

Deliverable: trust diagrams, sample policy structures with doc-cited condition keys, VPC pattern ADR, RAM tease worksheet, negative test plan, budget proof, cleanup.

Challenge ADR

Constraint: third-party content CDN invalidation API needs limited prod access. Design vendor role with external ID, 1-hour max session intent, and CloudTrail metric filter conceptual alert.

Lab evidence checklist

Diagrams; policy drafts; negative AssumeRole evidence; ADR; cleanup; no invented APIs.

Narrative: the mesh that ate ops

Peering grew until nobody could explain why sandbox reached Redis. TGW + segmented tables + PrivateLink for shared auth service restored sleep.

Continuity

Next: AWS PrivateLink, VPC Endpoints and DNS. Later: hybrid VPN/DX (51), TGW deep dive (52).

Deep dive: OIDC federation for GitHub Actions

Prefer official AWS OIDC provider patterns for GitHub/GitLab over stored keys. Validate audience/sub claims. Continuity with Module 3 GitHub Actions lesson.

Deep dive: permission boundaries on deploy roles

Boundaries cap maximum permissions even if someone attaches a broader policy later. Useful for Account Factory baselines.

Deep dive: network account ownership RACI

Platform owns TGW/RAM; app teams own spoke SGs and subnet sizing; Security owns inspection policy. Write RACI in the ADR.

Extended enterprise scenario: exam-week blast radius

Only prod deploy role can scale ECS; sandbox load tests cannot assume prod. SCP denies sandboxes creating peering to prod CIDRs (intent—verify actions).

Extended enterprise scenario: data science account

Needs read-only S3 in prod analytics lake later (/learn/data-engineering continuity) via role + bucket policy—not VPC mesh to prod app tier.

Extended practice scenario 1 — 49 cross account access and multi account networking

Draft trust policy structure for Shared Services CI → Dev deploy role; cite STS condition keys from docs.

In a timed drill for cross-account IAM and multi-account VPC design, implement or design the core lab with a partner observing. The observer's job is to stop any step that invents API flags, hardcodes secrets, invents pricing numbers presented as current quotes, or skips budget and cleanup. After the drill, rewrite your ADR in ten lines: context, decision, consequences. Attach evidence: trust diagrams, policy drafts with doc citations, negative AssumeRole proofs, ADR, budget proof, and destroy confirmation for any lab resources.

Discuss how this lesson connects to Organizations landing zones (48), IAM/Identity Center, CloudTrail, upcoming PrivateLink (50) and TGW (52). List two failure modes you simulated or observed (overbroad trust; sandbox route to prod), including detection and fix. Note which billable dimensions may move and when Cost Explorer would show them—verify current pricing pages; never invent rates.

Finally, teach back the lesson overview paragraph from memory, then check against the text. Gaps become flashcards. Premium courses finish when you can operate under time pressure without treating multi-account networking and data platforms as mystery consoles.

Extended practice scenario 2 — 49 cross account access and multi account networking

Produce least-privilege action list for ECS+ECR deploy role; explicitly exclude iam:, organizations:.

Extended practice scenario 3 — 49 cross account access and multi account networking

Negative lab: attempt AssumeRole from wrong account; capture AccessDenied evidence.

Extended practice scenario 4 — 49 cross account access and multi account networking

Compare peering mesh vs TGW for 8 TechLearningPro accounts in a decision table.

Extended practice scenario 5 — 49 cross account access and multi account networking

RAM worksheet: list candidate shared resources from Network Hub with doc links for shareable types.

Extended practice scenario 6 — 49 cross account access and multi account networking

Design Identity Center assignments for human prod break-glass vs standing read-only.

Extended practice scenario 7 — 49 cross account access and multi account networking

Cross-account S3+KMS access sketch for lecture assets—key policy + bucket policy checklist.

Extended practice scenario 8 — 49 cross account access and multi account networking

Confused deputy tabletop with a fictional SaaS vendor; add external ID.

Extended practice scenario 9 — 49 cross account access and multi account networking

CloudTrail investigation storyboard for a suspicious AssumeRole into prod.

Extended practice scenario 10 — 49 cross account access and multi account networking

Segment sandbox: propose SG, route, and trust controls that prevent prod data plane access.

Extended practice scenario 11 — 49 cross account access and multi account networking

Role chaining diagram limited to two hops max; justify.

Extended practice scenario 12 — 49 cross account access and multi account networking

Estimate which networking choices affect data transfer bills—qualitative only; verify pricing later.

Extended practice scenario 13 — 49 cross account access and multi account networking

Write runbook: revoke compromised deploy role in 15 minutes.

Extended practice scenario 14 — 49 cross account access and multi account networking

Shared VPC pros/cons one-pager for TechLearningPro platform guild.

Extended practice scenario 15 — 49 cross account access and multi account networking

Map lesson 48 OUs to which accounts may share TGW via RAM.

Extended practice scenario 16 — 49 cross account access and multi account networking

OIDC GitHub Actions trust design for tlp-prod-apps only on main branch.

Extended practice scenario 17 — 49 cross account access and multi account networking

Document dual control for prod deploy role policy changes.

Extended practice scenario 18 — 49 cross account access and multi account networking

Create glossary cards for RAM, TGW, peering, PrivateLink, AssumeRole, external ID.

Extended practice scenario 19 — 49 cross account access and multi account networking

Peer-review a classmate's overbroad Principal:* trust policy; rewrite.

Extended practice scenario 20 — 49 cross account access and multi account networking

Inspection VPC tease: why flat transitive routes undermine segmentation.

Extended practice scenario 21 — 49 cross account access and multi account networking

FinOps: tag cross-account network resources; showback to Network Hub cost center.

Extended practice scenario 22 — 49 cross account access and multi account networking

Tabletop: CI role permissions accidentally include s3:DeleteBucket on prod—detection and fix.

Extended practice scenario 23 — 49 cross account access and multi account networking

Budget alert verification before creating any paid networking resources.

Extended practice scenario 24 — 49 cross account access and multi account networking

Cleanup checklist for peers, RAM shares, and lab IAM roles.

Extended practice scenario 25 — 49 cross account access and multi account networking

Dress rehearsal: diagrams + policies + negative tests + ADR + teach-back.

Compliance evidence pack for auditors / Finance

Role inventory; trust policies; prod break-glass procedure; RAM share inventory; network architecture ADR; CloudTrail samples of AssumeRole; budget configs.

Glossary drill

AssumeRole; trust policy; resource-based policy; external ID; confused deputy; role chaining; AWS RAM; VPC peering; Transit Gateway; shared VPC; PrivateLink; spoke account; Network Hub; OIDC federation.

Budget and cleanup sworn statement

I verified budgets remain enabled. I deleted lab peering/RAM shares/roles named ____. I invented no API names or prices. Signed ________ date ________.

Interview story to memorize

“TechLearningPro CI in Shared Services assumes narrow deploy roles per account, humans use Identity Center with break-glass for prod, we rejected peering meshes for TGW hub-and-spoke plus PrivateLink for shared services, and RAM shares only Network Hub constructs to the right OUs—audited with CloudTrail.”

Self-assessment rubric

Area	Weight
IAM cross-account correctness	25%
Network pattern selection	20%
Security / least privilege	20%
Troubleshooting realism	20%
Docs citations + cleanup	15%

Final synthesis before summary

Accounts without controlled cross-account identity become key sprawl; accounts without controlled networking become an unexamined LAN. TechLearningPro needs both gates closed by default and opened with purpose.

Lesson Summary

Cross-account access should use temporary AssumeRole (and OIDC) with tight trust and permissions, resource policies where required, and careful third-party controls. Multi-account networking should prefer hub-and-spoke and PrivateLink over peering meshes, with RAM as a deliberate sharing tool—not a blunt trust wand. Tag Project=tlp-lesson49; budget and clean up.

Next: AWS PrivateLink, VPC Endpoints and DNS.

Cross-Account Access and Multi-Account Networking

Cross-Account Access and Multi-Account Networking

Lesson Overview

Learning Objectives

Prerequisites

Detailed Core Concepts

Cross-account IAM roles

Trust policy design

Resource-based policies

Role chaining

AWS RAM tease

Multi-account VPC patterns

Inspection and segmentation tease

Architecture and Design Diagrams

Technical Explanation

Deploy path walkthrough

Human access path

Confused deputy

Network path vs IAM path

RAM sharing lifecycle

Data transfer and NAT

Security Hub / GuardDuty across accounts

Performance notes

Practical Implementation or Design Walkthrough

Problem

Steps

Enterprise Real-World Scenarios

Keys in Jenkins

Peering explosion

Overbroad RAM share

Auditor access

Third-party vendor

Best Practices

Common Mistakes and Anti-Patterns

Troubleshooting and Design Review

Interview Questions and Answers

Hands-On Exercises

Exercise: Design hub-and-spoke connectivity for application accounts

Challenge ADR

Lab evidence checklist

Narrative: the mesh that ate ops

Continuity

Deep dive: OIDC federation for GitHub Actions

Deep dive: permission boundaries on deploy roles

Deep dive: network account ownership RACI

Extended enterprise scenario: exam-week blast radius

Extended enterprise scenario: data science account

Extended practice scenario 1 — 49 cross account access and multi account networking

Extended practice scenario 2 — 49 cross account access and multi account networking

Extended practice scenario 3 — 49 cross account access and multi account networking

Extended practice scenario 4 — 49 cross account access and multi account networking

Extended practice scenario 5 — 49 cross account access and multi account networking

Extended practice scenario 6 — 49 cross account access and multi account networking

Extended practice scenario 7 — 49 cross account access and multi account networking

Extended practice scenario 8 — 49 cross account access and multi account networking

Extended practice scenario 9 — 49 cross account access and multi account networking

Extended practice scenario 10 — 49 cross account access and multi account networking

Extended practice scenario 11 — 49 cross account access and multi account networking

Extended practice scenario 12 — 49 cross account access and multi account networking

Extended practice scenario 13 — 49 cross account access and multi account networking

Extended practice scenario 14 — 49 cross account access and multi account networking

Extended practice scenario 15 — 49 cross account access and multi account networking

Extended practice scenario 16 — 49 cross account access and multi account networking

Extended practice scenario 17 — 49 cross account access and multi account networking

Extended practice scenario 18 — 49 cross account access and multi account networking

Extended practice scenario 19 — 49 cross account access and multi account networking

Extended practice scenario 20 — 49 cross account access and multi account networking

Extended practice scenario 21 — 49 cross account access and multi account networking

Extended practice scenario 22 — 49 cross account access and multi account networking

Extended practice scenario 23 — 49 cross account access and multi account networking

Extended practice scenario 24 — 49 cross account access and multi account networking

Extended practice scenario 25 — 49 cross account access and multi account networking

Compliance evidence pack for auditors / Finance

Glossary drill

Budget and cleanup sworn statement

Interview story to memorize

Self-assessment rubric

Final synthesis before summary

Lesson Summary

Further Reading