Organisational Design and Multi-Account Architecture
SAP-C02 heavily tests AWS Organizations and multi-account design. Best practice: use multiple AWS accounts for isolation (not VPCs) — separate accounts for production, development, security tooling, and logging. Account types: management account (limited workloads — only org management and billing), security tooling account (SecurityHub, GuardDuty aggregator, Config aggregator), log archive account (centralised S3 for CloudTrail and Config logs — strict access control), production workload accounts (one per product team or environment). AWS Control Tower: managed service to set up a multi-account landing zone — deploys guardrails (preventive SCPs and detective Config rules), creates accounts via Account Factory (automated provisioning with baseline guardrails applied). AWS Service Catalog: IT service catalogue — allows provisioning of pre-approved, compliant CloudFormation products without giving end users IAM permissions to create resources directly. Ram (Resource Access Manager): share resources across accounts without VPC peering — Transit Gateways, Subnets, Resolver rules, Prefix Lists.
Advanced Networking: Transit Gateway, Direct Connect, and Global Accelerator
Enterprise networking at SAP level. Transit Gateway (TGW): hub for transitive VPC routing — attach VPCs, VPN connections, and Direct Connect Gateways to one TGW — route tables on the TGW control which attachments can communicate. TGW Peering: connect TGWs in different regions or different accounts — traffic stays on AWS backbone. Transit Gateway Network Manager: global network visualisation across regions and on-premises sites. Direct Connect: dedicated private connection from on-premises to AWS — connection types: Dedicated (physical port at DX location, 1G or 10G), Hosted (through DX partner, 50M to 10G). Direct Connect Gateway: associate one DX with multiple VPCs in different regions from a single connection. Resilient DX: use two DX connections from different DX locations (different providers) + VPN as backup. BGP routing: Direct Connect uses BGP — BGP communities for routing preference (AWS public prefix announcements with communities 7224:7100 for local preference). Global Accelerator: anycast routing to nearest AWS edge location, then AWS private network to the region — improves TCP/UDP latency and provides static IPs for whitelisting.
Migration Strategies: 7Rs and AWS Migration Services
SAP-C02 tests migration architecture at depth. The 7R migration strategies: Retire (decommission — no longer needed), Retain (leave on-premises — not ready or not worth migrating), Rehost (lift and shift — move to EC2 as-is, fastest but no cloud optimisation), Replatform (lift and reshape — move to managed services like RDS instead of self-managed DB on EC2, minimal code changes), Repurchase (drop and shop — move to SaaS, e.g., replace custom CRM with Salesforce), Refactor/Re-architect (redesign for cloud-native — highest effort, highest long-term value), Relocate (move to VMware Cloud on AWS — hypervisor level, for VMware workloads). Migration services: AWS Application Migration Service (MGN) — agentless or agent-based replication, continuous sync, cutover with minimal downtime — replaces Server Migration Service. Database Migration Service (DMS) — migrate databases to and from AWS, supports homogeneous (Oracle to Oracle) and heterogeneous (Oracle to Aurora) migrations. Schema Conversion Tool (SCT) — converts schema and application code for heterogeneous migrations. DataSync — high-speed file transfer from on-premises NAS to S3, EFS, or FSx. Snowball Edge — physical data transfer device for petabyte-scale migrations where network bandwidth is insufficient.
Cost Optimisation at Enterprise Scale
SAP-C02 expects sophisticated cost optimisation recommendations. Compute Optimiser: ML-based right-sizing for EC2, Lambda, EBS, and ECS — analyses CloudWatch metrics and recommends changes (over-provisioned instances are the most common enterprise waste). EC2 purchasing strategy: On-Demand for variable/unpredictable workloads, Savings Plans for steady-state baseline (flexible across instance families), Reserved Instances for predictable database workloads (Convertible RIs balance flexibility with discount), Spot for fault-tolerant batch and CI/CD (60-90% discount). Savings Plans types: Compute Savings Plans (any EC2 instance family, region, OS — highest flexibility), EC2 Instance Savings Plans (specific family and region — higher discount). Savings Plans apply to Fargate and Lambda as well. S3 Intelligent-Tiering: automatically moves objects between frequent and infrequent access tiers based on access patterns — eliminates the need to manually set lifecycle rules for unpredictable access patterns, small monitoring fee per object. Reserved capacity for DynamoDB, ElastiCache, OpenSearch, RDS, and Redshift. Cost allocation tags: activate and enforce tagging policies with AWS Config or Tag Policies in Organizations — enables charge-back and show-back reporting by team, project, and environment.