Before you choose between AWS Transit Gateway and VPC peering, before you decide whether to use AWS Direct Connect or AWS Site-to-Site VPN, you must fix five upstream decisions: which Regions and Availability Zones host the workload, how cross-account access flows, what RTO and RPO the workload commits to, what shape the AWS account hierarchy takes, and how tags route cost back to business units. The SAP-C02 exam treats these five decisions as one composite design problem, and a scenario that asks "which connectivity option" frequently hinges on a constraint hidden in one of the other four areas.
Network connectivity at the Professional level is rarely about throughput in isolation. It is about constraints layered on top of throughput: a 99.99 percent availability SLA forces redundant Direct Connect connections in two locations, a sovereignty rule forces a Region pinned in country, a multi-account governance posture forces traffic inspection through a central inspection VPC, and an audit obligation forces VPC Flow Logs delivered to an org-level Amazon S3 bucket. The architect's job is to align the network with all of these constraints at once.
Selecting AWS Regions and Availability Zones based on network and latency requirements
A Region is a physical group of three or more Availability Zones, each AZ is one or more discrete data centers with redundant power and networking, and inter-AZ latency within a Region is typically in the single-digit millisecond range. Inter-Region latency is bounded by the speed of light over the AWS global backbone, so a workload that requires sub-10 millisecond response between two components must keep those components in the same Region, in most cases in the same AZ, and frequently in the same cluster placement group.
Region selection is driven by four factors. The first is data residency: a contract that requires customer data to stay in the European Union forces a Region inside the EU, typically eu-west-1, eu-central-1, or eu-west-2. The second is service availability: not every AWS service launches in every Region simultaneously, so a workload that depends on a newer service must verify the Region service list. The third is latency to end users: a public-facing application serving Australian users places its origin in ap-southeast-2 and fronts it with Amazon CloudFront edge locations. The fourth is cost: cross-Region data transfer is billed, and inter-Region replication of a 100 TB dataset can swamp the savings from a cheaper compute Region.
Availability Zone selection within a Region is driven by spread, not by name. AZ names like us-east-1a are randomized per account, so what one account sees as us-east-1a is not the same physical AZ another account sees with the same name. For deterministic cross-account AZ placement, use the AZ ID (for example, use1-az1), which is stable across accounts. This becomes operationally important when you peer subnets across accounts for low-latency communication, because traffic between two subnets in different physical AZs incurs cross-AZ data transfer.
aws ec2 describe-availability-zones \
--region us-east-1 \
--query "AvailabilityZones[].[ZoneName,ZoneId]" \
--output table
For workloads with strict latency budgets, AWS Local Zones place compute, storage, and networking closer to large population centers, AWS Wavelength embeds infrastructure in telecom carrier networks for 5G applications, and AWS Outposts delivers AWS-managed hardware on premises. Each option trades a different axis: Local Zones reduce client-to-Region latency, Wavelength reduces mobile last-mile latency, and Outposts reduces data residency exposure while preserving the AWS API surface.
💡 Exam Trap: A scenario claims a global application must serve users in Singapore, Sydney, and Frankfurt with under 50 ms response. A single-Region design with Amazon CloudFront edge caching is not a substitute for multi-Region origins when the request pattern is write-heavy. CloudFront accelerates reads, but write traffic still traverses the backbone to the origin Region.
📊 Limit: A standard AWS account starts with a quota of 5 VPCs per Region and 5 Elastic IP addresses per Region. Both are soft quotas. A Direct Connect connection has hard physical port speeds of 1, 10, and 100 Gbps for dedicated connections; hosted connections start at 50 Mbps.
Evaluating cross-account access management
Cross-account access is the connective tissue of every multi-account AWS environment. The default mechanism is the IAM role with a trust policy that names the trusted principal in another account. A user or service in account A assumes a role in account B by calling sts:AssumeRole, receives temporary credentials, and acts as the role for the duration of the session.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111122223333:role/DeploymentRole" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": { "sts:ExternalId": "fictional-external-id-9c2a" }
}
}
]
}
External IDs guard against the confused deputy problem and are mandatory when a third party assumes a role in your account on your behalf. Session tags and source identity propagation let you carry attributes from the calling identity into the assumed session, so a CloudTrail entry recorded in account B still names the original human user from account A. Without source identity, every cross-account action attributes back only to the role.
AWS Resource Access Manager (AWS RAM) shares specific resources rather than granting role-based access. RAM works for subnets, Transit Gateway attachments, Route 53 Resolver rules, AWS License Manager licenses, AWS KMS keys (through grants), and several other resource types. RAM is the right mechanism when account B should consume a resource without owning it; cross-account roles are the right mechanism when account B needs to perform actions on resources it owns.
💡 Exam Trap: A scenario describes a vendor service that needs to read objects from your S3 bucket and asks for the simplest secure design. The simplest secure pattern is a cross-account role with an external ID set by the vendor, not an IAM user with long-lived access keys. Access keys are an anti-pattern for third-party access.
⚠️ Anti-Pattern: Sharing IAM access keys between accounts to perform automated workflows. Long-lived access keys leak through CI logs, snapshots, and developer machines, and they bypass the trust-policy review that role assumption forces.
Designing disaster recovery solutions based on RTO and RPO requirements
RTO is the maximum acceptable time the workload can be unavailable after a disruption. RPO is the maximum acceptable data loss measured in time. The two metrics drive the disaster recovery pattern and the cost. A workload with an RTO of seconds and an RPO of seconds runs hot in two Regions with synchronous or near-synchronous replication. A workload with an RTO of hours and an RPO of 24 hours can rely on nightly snapshots.
AWS recognizes four canonical DR patterns. Backup and restore stores snapshots and AMIs in a recovery Region and rebuilds infrastructure on demand; RTO is hours, RPO is the snapshot interval. Pilot light keeps the minimal core (databases replicating, AMIs warm) running in the recovery Region; RTO is tens of minutes, RPO is replication lag. Warm standby runs a scaled-down but functional copy in the recovery Region; RTO is minutes, RPO is replication lag. Multi-site active-active runs full capacity in two or more Regions with traffic balanced across them; RTO is near zero, RPO is near zero.
AWS Elastic Disaster Recovery (AWS DRS) replicates block-level data from source servers (on premises or in AWS) into a low-cost staging area in a target Region and launches recovery instances within minutes when a recovery is invoked. AWS DRS is the recommended pattern for unmodified workloads where rewriting the application for active-active is not on the table.
The cost gradient is steep. Backup and restore costs storage plus a one-time recovery. Pilot light adds the cost of replication and the small footprint of warm components. Warm standby adds the cost of a scaled-down compute footprint. Multi-site doubles or triples the compute bill. Choose the cheapest pattern that meets the contractual RTO and RPO, not the pattern that sounds the most resilient.
🎯 Scenario: A regulated financial reporting application must recover within 15 minutes (RTO) and tolerate at most 60 seconds of data loss (RPO). The team currently runs a single-Region deployment with hourly RDS snapshots. The right answer is warm standby in a second Region with Amazon RDS cross-Region read replicas (which can be promoted in minutes) and an Amazon Route 53 health-checked failover record. Backup and restore cannot meet the 15-minute RTO; multi-site is over-engineered for a 15-minute target.
Evaluating the most appropriate account structure for organizational requirements
A single AWS account is rarely the right answer for an enterprise. Account boundaries are the strongest blast-radius isolation AWS offers: a runaway script in one account cannot exhaust the quotas of another, and an IAM mistake in one account cannot expose data in another unless an explicit trust was granted. The typical Professional-level enterprise pattern is one account per workload per environment, organized under AWS Organizations into Organizational Units (OUs) by lifecycle stage (Production, Staging, Sandbox) and by function (Security, Logging, Network, Shared Services).
The AWS Multi-Account Strategy guidance defines a foundational pattern: a management account at the root that holds billing and the Organizations service, a Security Tooling account that hosts AWS Security Hub, Amazon GuardDuty, and AWS Config aggregators, a Log Archive account that receives immutable copies of CloudTrail and Config history, and one or more workload accounts. AWS Control Tower automates the provisioning of this baseline.
The choice between one account per workload and one account per team is driven by chargeback granularity and audit boundaries. If finance needs cost attribution at the workload level, an account per workload makes that mechanical: the consolidated bill already itemizes by account. If the audit boundary is at the workload level (for example, separate PCI scope from non-PCI scope), an account per workload makes the audit boundary the network boundary.
Developing an effective tagging strategy that maps costs to business units
A tag is a key-value pair on a resource. The AWS billing system can apportion cost by tag once you activate user-defined cost allocation tags in the billing console. The constraint is consistency: a resource without the cost-center tag does not appear in the by-cost-center report, and the unallocated bucket grows until the report becomes useless.
A workable enterprise tagging strategy fixes a small mandatory set: cost-center, business-unit, environment (one of prod, staging, dev, sandbox), owner, data-classification, and workload-id. Mandatory tags are enforced through Service Control Policies that deny creation of resources without the required tags, AWS Config rules that flag drift, and AWS Organizations tag policies that constrain allowed values.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyCreateWithoutCostCenter",
"Effect": "Deny",
"Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
"Resource": "*",
"Condition": {
"Null": { "aws:RequestTag/cost-center": "true" }
}
}
]
}
💡 Exam Trap: A scenario asks how to allocate a shared NAT gateway to two business units. NAT gateways do not propagate workload tags to traffic, so the most accurate cost attribution comes from VPC Flow Logs analyzed through Amazon Athena, not from tags on the NAT gateway. Tags allocate the per-hour and per-GB cost of the NAT itself, but the data routed through it must be attributed by flow analysis.
⚠️ Anti-Pattern: Letting each team invent its own tag keys.
costCenter,cost-center,CostCenter, andccare four different tag keys to AWS Cost Explorer, and the resulting report is useless. Tag policies in AWS Organizations standardize keys across the org.
📊 Limit: A resource supports up to 50 user-defined tags. Tag keys are case-sensitive in most APIs and case-insensitive in the cost allocation system, which is a frequent source of mismatched reports.
Decision Anchor: Choose one account per workload when audit boundaries align with workloads and chargeback granularity is at the workload level. Choose one account per team with multiple workloads inside when teams are small, audit pressure is low, and the operational overhead of many accounts exceeds the value of isolation. Choose multi-site active-active for DR when RTO and RPO are both near zero and the application can tolerate eventual consistency or supports active-active writes; choose warm standby when RTO is minutes and the cost of full active-active is not justified.