Build small. Secure deliberately. Scale with evidence.

Manual implementation and certification practice. Selected design: three VPCs; root account admin@wickedspooky.org; day-to-day AWS administrator sam@wickedspooky.org; Sam also uses his matching Google account for website/workbench access; other users use Google application sign-in without AWS account access. This is a training plan, not executed infrastructure.

Core controls are not optional cost cuts. Reduce unnecessary resources and oversized capacity before weakening identity, isolation, authorization or recovery.

1. Record the boundary and spending envelope

Keep the three-VPC design as the selected architecture. Record Region us-east-1, non-overlapping address ranges, owner, expected traffic, data classification, recovery time (RTO) and acceptable data loss (RPO). In Billing and Cost Management, create a budget and notification contacts, then estimate the chosen services in AWS Pricing Calculator. Budget alerts are notifications, not a hard spending cap.

Cost / design trade-off: Start with only S3/CloudFront for genuinely public static pages. Do not create an always-on ALB, EC2 or database solely to serve those pages. Private content is a separate deployment gate.

Verify and explain: Evidence: saved estimate with assumptions and a documented monthly envelope. Explain why three VPCs add routing and cost without automatically creating application authorization.

2. Establish the AWS administrator identities

In IAM Identity Center, use an AWS-account access configuration supported by your organization. The existing AWS account root email is admin@wickedspooky.org; root is not an IAM user or an Identity Center workforce identity. Keep it for root-only tasks and account recovery. Establish sam@wickedspooky.org as the day-to-day workforce principal with AWS account access. Confirm both addresses are controlled and attributable; never share credentials. Assign a least-privilege daily permission set and a separately controlled elevated role only when required. Enable MFA for the actual workforce identity source. Protect root with MFA, keep recovery contacts current and do not create root access keys.

Cost / design trade-off: Do not create IAM users for either address merely to match this diagram, and do not duplicate the root identity as a routine workforce administrator. Identity Center users assume roles with temporary credentials. Workload IAM roles still exist. Other people can use Google website sign-in but receive no AWS account assignment.

Verify and explain: Evidence: Sam can obtain the intended temporary roles; an unassigned identity cannot enter the AWS account. Verify root MFA and recovery readiness separately without using root for routine work. Inspect CloudTrail event history for the resulting actions. Maintain an independently tested account-recovery procedure.

3. Build the public static endpoint

In S3, create a general-purpose public-content bucket with Block Public Access enabled, bucket-owner-enforced ownership and default encryption. In CloudFront, select the S3 REST origin, configure OAC and apply the distribution-scoped bucket policy. Request/validate the CloudFront viewer certificate in ACM us-east-1, then configure the approved domain alias in Route 53 or your DNS provider. Redirect HTTP viewers to HTTPS. Upload only public pages and assets.

Cost / design trade-off: Use compressed artwork and long cache lifetimes for versioned assets, with shorter lifetimes for HTML. S3 Standard is a simple starting storage class for frequently accessed tiny websites; use lifecycle rules for old versions/logs only after retention needs are known.

Verify and explain: Evidence: the public site works through its domain and direct anonymous S3 reads fail. Do not upload internal docs to this public-content origin.

4. Create the three-VPC network deliberately

In VPC, create Public DMZ, Private DMZ and Internal/Super Trusted VPCs with planned subnets in two AZs. Add an Internet Gateway only where Internet-facing resources require it. If using the selected Transit Gateway design, create the attachments and explicit forward/return routes between approved subnets. Route tables and security groups must both allow a path. Keep Web EC2 and RDS without public access.

Cost / design trade-off: TGW attachment-hours and processing, NAT gateway hours/data, interface endpoints, public IPv4 and cross-AZ transfer can exceed a small instance bill. Cost each item before creation. A one-VPC subnet/SG design is an optional future review, not a silent replacement of the agreed segmentation. Do not use peering as a transitive egress shortcut.

Verify and explain: Evidence: approved cross-VPC paths work; unapproved paths and public EC2/RDS access fail. Record each route and its purpose.

5. Set network security groups and egress

Create the named Edge ALB, Web, Database, Mail and endpoint groups from the security diagram. Restrict the ALB listener to HTTPS; allow only intended CloudFront sources and enforce the separate origin-header check. Allow Web targets only from the ALB path and the agreed target/health port; database 3306 only from approved application sources. Validate TGW inbound SG-reference support before using it; use tightly scoped private sources where unsupported. Keep inbound SSH closed.

Cost / design trade-off: Use an S3 gateway endpoint in the consuming Web VPC, with scoped endpoint/bucket policies; gateway endpoints have no additional charge and do not transit TGW. For SSM and other HTTPS egress, compare NAT and per-AZ interface endpoint costs. Identity-provider calls and software updates still need a working outbound path. A single-AZ egress choice is a cost/recovery trade-off, not highly available egress.

Verify and explain: Evidence: SSM access works using authorized AWS roles, S3 is reachable through the intended route, identity endpoints are reachable, and denied ports remain denied.

6. Configure Google federation for web users

In Google Cloud, configure the OAuth consent screen/audience and a web OAuth client. Register the exact Cognito domain callback ending /oauth2/idpresponse. Keep the client secret server-side. In Cognito User Pools, add Google under Social and external providers, map only required identity attributes, and configure managed login. Do not create a Cognito identity pool. For the ALB app client, use the documented client-secret and authorization-code configuration with openid and only necessary profile/email scopes. Enable Google for this client rather than opening an unintended local-password sign-in path.

Cost / design trade-off: Google is the web identity source for customers, WSAI web-only staff and Sam’s matching sam@wickedspooky.org Google account. Assign Sam’s application roles explicitly using the verified identity subject; never inherit AWS privileges from the matching email. Keep workforce and application sessions separate. Federation creates an application identity record, not an IAM user. Primary authentication/MFA is delegated to the identity provider; a Cognito local-user MFA setting is not proof of Google-user MFA. For privileged internal users, verify enforceable MFA at the chosen Google/Workspace identity source before granting access.

Verify and explain: Evidence: Google sign-in completes; the browser never receives AWS access keys or the OAuth client secret. Unapproved users may authenticate but cannot access internal content. Review Google consent/testing limitations before launch.

7. Configure ALB authentication and protect origins

Create the ALB in two public subnets/AZs and register private Web targets by IP across the VPC boundary. Configure a regional ACM certificate for its HTTPS listener. For private routes, use authenticate-cognito before forwarding; set the app callback to the exact externally used HTTPS hostname plus /oauth2/idpresponse. Follow AWS ALB/Cognito region and issuer compatibility requirements. Do not create an alternate unauthenticated forward rule for the same protected content.

Cost / design trade-off: For CloudFront private/dynamic behaviors, forward the cookies, headers and query parameters required by ALB authentication, use HTTPS and disable caching. Retain public caching separately. The private origin header is a secret; the CloudFront prefix list alone admits other CloudFront distributions. Validate both controls. One ALB can serve multiple approved host/path rules, but sharing introduces a shared failure/configuration boundary.

Verify and explain: Evidence: login round-trip succeeds through the domain; missing origin header, direct origin access and unauthenticated protected routes fail. Confirm no private response is served from a shared cache.

8. Enforce application and document authorization

Deploy server-side authorization before publishing non-public content. Verify ALB-signed claims with AWS-documented signature verification and expected signer checks; map stable issuer/subject to approved memberships. Create the proposed operators, developers, creators, documentation-readers, evidence-readers, governance-readers and access-admins assignments explicitly. Add resource/tenant-level checks independently of those roles. Never trust an email suffix, browser group field or unsigned header for privilege.

Cost / design trade-off: Serve private documents from a separate private S3 bucket through an authorized handler using a scoped EC2 instance role. Keep public access blocked. For this design, do not add a public CloudFront S3 behavior for the private bucket. Handle HTML, Mermaid, JSON and downloadable sources with the same authorization. Do not cache private responses publicly.

Verify and explain: Evidence: wrong-role users receive denial; tenant A cannot read tenant B objects; revocation takes effect within a defined session/membership refresh window; every private file extension is checked. Static HTML alone cannot perform this gate.

9. Add compute and data only when the workload needs them

Start with a measured, modest instance size supported by the application; evaluate Graviton only after dependencies are verified on ARM. Use an instance profile and IMDSv2, patched images, encrypted storage and approved secret storage. When RDS is needed, create a private DB subnet group, restricted database SG, encryption, backups and tested recovery. Do not add RDS solely for a static site.

Cost / design trade-off: One Web instance or Single-AZ database lowers cost but accepts an interruption during failure/maintenance; choose only against explicit RTO/RPO. Multi-AZ RDS DB-instance standby provides failover, not read scaling. Burstable instances need credit and memory monitoring; cheap hourly price alone is not a capacity plan.

Verify and explain: Evidence: restore a backup in a safe test environment, exercise target failure, and measure latency/error/CPU/memory/credit usage under representative load.

10. Prepare scale without buying it all now

Keep application instances replaceable. Before enabling multi-instance Auto Scaling, externalize sessions and durable uploads using a workload-appropriate design; do not leave WordPress uploads/plugins or sessions dependent on one local disk. Use a launch template, health checks and tested rolling changes. Scale on observed bottlenecks, with maximum capacity and cost controls. Do not assume adding EC2 nodes fixes a database or shared-storage bottleneck.

Cost / design trade-off: CloudFront/S3 already absorb public-static growth. Add a second healthy Web target across AZs when availability or demand justifies it. Price shared file storage, database capacity and transfer before adopting them. Savings Plans or reservations should follow stable usage evidence, not speculative launch sizing.

Verify and explain: Evidence: terminate a test target and prove the service/state recovers; load-test scale-out and scale-in without losing sessions or uploads.

11. Observe, review and contain recurring cost

Set CloudWatch alarms for availability, latency, errors and resource saturation. Configure security/audit logging with explicit retention and redaction. Inspect IAM Access Analyzer findings and review account assignments, unused resources and spending regularly. Never record tokens or document contents just to troubleshoot sign-in.

Cost / design trade-off: CloudTrail event history is not the same as a durable trail or S3 object-level data-event logging. Choose retained logs/data events based on audit needs and price ingestion, storage and queries. Add AWS Config recording/inventory automation after selecting resource scope; it is not a free prerequisite for the static diagrams.

Verify and explain: Evidence: trigger a controlled alert, confirm its owner receives it, record a recovery action, and compare actual spend with the estimate.

12. Complete a security and recovery acceptance exercise

Test Sam’s Google session independently of his AWS workforce session: each must require its own assigned permissions, and signing into one must not grant the other. Test anonymous public access, anonymous internal denial, ordinary Google-user internal denial, allowed staff-role access, wrong tenant/object denial, expired sessions, revocation and logout behavior. Test direct S3/ALB access denial, no public Web SSH or RDS, scoped workload-role permissions and successful backup restoration. Record browser, resource IDs, timestamp and evidence without secrets.

Cost / design trade-off: Do not label a topology secure or scalable just because every diagram renders. Keep the current ZIP unrestricted only as a content prototype, and gate production private-content publication on these checks. No security settings, cloud resources or repository commits are created by this guide.

Verify and explain: Evidence: a signed-off checklist with failures left visible, remediation ownership and re-test results. Stop deployment on a failed private-access test.

Certification practice

SAA-C03: Domain 1 (secure architectures) maps to identities, OAC, private routes and least privilege; Domain 2 (resilience) to recovery, Multi-AZ and failover; Domain 3 (performance) to caching, right-sizing and scaling; Domain 4 (cost) to phased adoption, transfer/egress and retention. For each exercise, explain a cheaper alternative and what reliability or operational capability it gives up.

For AI study, this guide uses AWS AI Practitioner AIF-C01 as the assumed exam: Domain 5 covers security, compliance and governance; Domain 4 covers responsible AI. These infrastructure exercises support those topics but do not demonstrate model quality or complete exam coverage.

AI exercise: design a future assistant that reads only the caller’s authorized documents. Keep document-level permissions in retrieval, isolate tenants, treat retrieved instructions as untrusted, redact personal data, evaluate hallucination and prompt-injection failure cases, and require human approval for consequential operations. Do not give an assistant broad administrator credentials. No AI service is deployed here; compare inference, retrieval, storage and evaluation cost before adding one.

Cost worksheet

Estimate monthly total as recurring resource hours + requests/MAUs + storage + data processing/transfer + logs/security services + backup retention. Enter public traffic, authenticated users, hours, GB, AZ count and retention separately. Compare: static only; private one-target pilot with accepted downtime; two-AZ production. Use current regional prices and do not assume a free tier. No monthly price is quoted without workload inputs.

Sources and maintenance

Guide checked against AWS documentation on 6 October 2026. Console labels, pricing and service compatibility can change: follow the linked service guide during creation. No SLA, certification or automatic compliance claim is made.