AWS SAP-C02: Enterprise Architecture Before the SAP-C03 Transition

An enterprise cloud architect rarely starts with a clean account and a single application. Most organizations inherit networks, contractual commitments, security policies, regional restrictions, legacy databases, and teams that disagree about who owns production risk. AWS Certified Solutions Architect – Professional (SAP-C02) addresses decisions in this setting: how to design across organizational complexity, introduce new solutions, improve existing systems, and migrate or modernize workloads without breaking essential business services.

Exam status, October 9, 2026: AWS has announced that November 16, 2026 is the last day to take SAP-C02. Registration for its successor, SAP-C03, opens October 27, and SAP-C03 delivery begins November 17, 2026. The newer exam adds explicit emphasis on cloud-native architecture, governance, operational automation, resilience and emerging generative/agentic AI-related architecture. The approved site inventory has the SAP-C02 destination for this article but no SAP-C03 destination as of the October 9 research snapshot, so this article does not invent a successor URL. Existing SAP-C02 preparation can remain useful, but scheduling decisions must respect the published cutover rather than treating the version number as timeless.

AWS's SAP-C02 scored-domain outline is Design Solutions for Organizational Complexity (26%), Design for New Solutions (29%), Continuous Improvement for Existing Solutions (25%), and Accelerate Workload Migration and Modernization (20%). These weights collectively reflect the professional architect's responsibility for competing objectives and dependencies. AWS certifications span foundational and specialist roles, but SAP-C02 assumes broader solution-design judgment than the SAA-C03 associate architecture exam. Candidates should be able to explain how an organizational decision affects delivery speed, security, recoverability, operational ownership and cost across multiple workloads.

Multi-account architecture is an operating model, not a folder structure

In a growing organization, different accounts can separate product teams, development environments, regulated workloads and central services. AWS Organizations and related governance capabilities support consolidated management and guardrails, but the mere creation of accounts does not settle access, budget, logging or incident-response responsibilities. A platform team needs to decide which controls are central, which responsibilities stay local, and how exceptions will be reviewed. Design choices should make the organization governable without making every routine release depend on a single security administrator.

Organizational guardrails have different powers. Service control policies constrain what member-account principals can do within their effective policy context; they do not grant permissions. IAM policies and resource policies remain part of authorization. A central identity pattern should support short-lived access, role assumptions, audit trails, and clear ownership. An architect who knows how to create an account but cannot explain permission boundaries across accounts is missing the design problem. Multi-account architecture with AWS Organizations and permission boundaries, SCPs, and IAM roles deepen the distinction between administrative structure and effective privilege.

An enterprise may also operate identity systems outside AWS. Federation must preserve consistent lifecycle controls for joiners, movers and leavers, and distinguish authentication from authorization. A central identity provider simplifies some processes but can become a critical dependency. Review how administrators gain emergency access when a federation connection fails, how cross-account roles are scoped, and which logs permit later reconstruction of privileged activity. Enterprise identity federation is relevant because a successful sign-in is only the beginning of a secure, supportable authorization workflow.

Shared services introduce their own failure domains. Central DNS, build pipelines, artifact repositories, logging and network inspection may reduce duplication, but they also create blast radius. Choose explicit service boundaries, resilient connectivity and clear service-level expectations. A shared service that every business unit depends on cannot be maintained casually during a regional incident. The challenge explored by shared services across AWS accounts is deciding what to standardize while retaining isolation and autonomy where they matter.

Hybrid networking and DNS must survive partial failure

Most enterprise migrations begin with on-premises services that cannot disappear overnight. AWS Direct Connect, VPN connectivity and the routing design around them must be considered as a system. A dedicated connection can provide predictable network characteristics, but a single connection is not a complete resilience plan. BGP policy, route propagation, redundant locations or providers, and fallback behavior determine what actually happens when a circuit or gateway fails. Application owners need to understand which services depend on a private route and which can tolerate a short switch to an alternate path.

DNS is especially easy to underestimate. Split-horizon names, private hosted zones, on-premises DNS forwarders and Route 53 Resolver endpoints can create ambiguous outcomes when they are assembled without an authority model. A failure may appear as an application outage even though the instance and database are healthy. Explain which resolver answers each class of name, how queries traverse the hybrid boundary, and what happens during a site failover. Hybrid DNS with Route 53 Resolver shows why name resolution deserves architecture review alongside network routing.

Consider a retailer migrating order processing while its warehouse system remains on premises. If only the application servers move, every transaction may cross the hybrid link to read inventory. Latency and failure probability become business risks. An architect might stage data replication or choose asynchronous messages where the workflow permits, but cannot treat eventual consistency as harmless when inventory overselling is unacceptable. Direct Connect and VPN resilience is useful in designing a recovery path; it does not remove the need to understand the underlying business transaction.

Model multi-Region decisions against precise business objectives

A request for 'global availability' needs decomposition. Does the business require an application to survive one Availability Zone, an entire AWS Region, or the loss of a particular network provider? What are the recovery time and recovery point objectives, and who decides when traffic should fail over? Some applications benefit from active-active request serving, but conflict resolution for writes can turn a resilient-looking system into a data-integrity problem. Product catalogs and read-heavy content differ from payment ledgers or inventory reservations.

Architecture options range from restoring backups in a second Region to warm standby and full active-active deployments. Costs rise with continuously running capacity, replicated data, cross-Region transfer, monitoring and the operational complexity of testing. Traffic steering through DNS or other services is not instantaneous and may be affected by caching or client behavior. Multi-Region active-active application design is valuable because the hardest questions concern consistency, workload topology and the operations team—not merely whether two Regions exist on the diagram.

Data residency further constrains replication. A legal requirement to keep certain records in an approved jurisdiction cannot be solved by copying every dataset to every Region for resilience. Security teams, data stewards and legal stakeholders must define which information is regulated, where backups reside, and which support or telemetry flows might cross borders. Data residency and sovereignty architecture illustrates how a plausible disaster-recovery plan can violate a nonfunctional requirement if data boundaries are not modeled explicitly.

Plan migrations around dependencies, not just servers

Migration strategy is more than selecting rehost, replatform or refactor from a list. A portfolio assessment should capture application-to-application calls, identity dependencies, database integration, licensing, maintenance windows, data gravity, and business criticality. An application can look self-contained on a virtual-machine inventory but still call a mainframe for every customer transaction. Moving its compute layer before understanding that dependency may worsen reliability instead of improving it.

An orderly migration uses discovery, dependency mapping, wave planning, cutover rehearsal, rollback criteria, and post-migration validation. Initial low-risk waves can reveal gaps in landing-zone controls, monitoring, backup and network access. A workload with an irrecoverable schema conversion deserves a different cutover strategy from a stateless website. Architects should choose measurable success criteria: transaction correctness, recovery time, error rate and business reconciliation—not simply the number of instances moved. Large-scale migration with AWS services provides examples of coordination beyond copying images into EC2.

Modernization has its own economics. Replacing a monolith with microservices may improve team autonomy and scalability, but it also introduces distributed failure, network access control, observability and deployment-order risks. Managed databases, container platforms and serverless integration can reduce some operating work while changing how costs and quotas behave. An architect should defend an incremental modernization boundary rather than promise that every component becomes cloud-native in one phase. The optimal architecture might deliberately retain a mature subsystem while isolating its interfaces and improving recovery elsewhere.

Continuous improvement means controlling change safely

A professional architect inherits systems that must be improved while remaining available. Observability should show error patterns, saturation, dependencies and user-facing outcomes. Alerting exclusively on CPU usage can miss database deadlocks, failed order processing or a credential-permission outage. Centralized logging helps investigations but needs retention, access boundaries and a defined log owner. Centralized logging across AWS accounts is particularly important when incidents span application accounts and shared identity or networking services.

Continuous improvement also involves controlling infrastructure changes. Infrastructure as code can make deployments reviewable and repeatable, but a bad template can reliably propagate a vulnerability across many accounts. Guardrails, policy checks, approvals where necessary, rollback provisions and validation need to accompany automation. Infrastructure as code with CloudFormation illustrates the engineering discipline behind a controlled change system. Operations must be able to test whether a change achieved its intended result and reverse it when it did not.

Cost optimization at enterprise scale includes purchase commitments, idle resources, rightsizing, data-transfer architecture and team accountability. Finance may prefer predictable commitments while application owners need elasticity. Model predictable baseline usage separately from uncertain peaks, allocate costs to responsible owners, and review whether central services create hidden cross-account charges. Governance through AWS Control Tower can help organizations formalize environment setup and controls, but governance does not eliminate the need for human architecture reviews of unusual workloads.

Prepare for the version handover deliberately

For candidates sitting SAP-C02 by November 16, 2026, the published four-domain SAP-C02 exam guide remains the relevant syllabus. For those scheduling on or after November 17, 2026, AWS says SAP-C03 becomes the delivered exam. Registration for SAP-C03 opens October 27, 2026, so choosing a date and guide is part of preparation. AWS's September 2026 announcement says SAP-C03 will assess five domains and newer cloud-native, governance, resilience and AI-related concerns; its full detailed guide is scheduled to be available when registration opens. As of this article's October 9 research date, do not invent domain weights or test details that AWS has not yet published.

The architectural core persists across the transition: explain an organizational constraint, compare approaches, name the failure modes, and decide who operates each control. Associate-level architectural knowledge remains useful, while specialized AWS Security – Specialty SCS-C03 explores security controls in greater depth. Neither substitutes for the professional architect's obligation to reconcile business, technology, governance and migration choices. The right preparation is not memorizing a growing catalog of services; it is repeatedly testing whether a proposed architecture can meet real requirements when infrastructure or assumptions fail.