# Case Study: WickedSpooky.ai The Creator Workbench

**Design baseline:** October 8, 2026 · **Primary Region:** US East (N. Virginia), `us-east-1` · **Owner:** Wicked Spooky AI

**Reading contract:** This is a completed-design narrative and a specification for a build from scratch. Past tense describes the selected target architecture, not a claim that resources were deployed or tests passed. Implementation, measurements, incidents, and exam evidence remain **not yet verified** until linked artifacts replace the acceptance criteria below. Prices are a dated planning baseline, not a bill or quote.

## 1. The problem and the outcome we designed

We designed Creator for a one-person business that needed research, content preparation, publishing, community triage, and revenue reporting without employing a social media team. We normalized the source blueprint's speaker identity to **Wicked Spooky AI**. Research became a weekly content plan; original hooks, captions, carousels, and short-video scripts entered a review queue; approved versions became scheduled publications; comments and DMs became reviewable replies and qualified leads; attribution fed a daily brief.

The project served two purposes: an ultra-low-budget SAA-C03 training portfolio and a subscription business that could support growing demand. We retained production-quality correctness in the training mode, while limiting volume and expensive features. We made cost, approvals, recovery, and profitability part of admission control rather than promises made after a viral spike.

Creator's product identity remained `creator.wickedspooky.ai`; WickedSpooky.org remained the operations and documentation domain. This follows the existing [service/domain model](../architecture/service-domain-model.md). DNS does not tie the product to WordPress or a particular runtime. This case study lives in the Documentation section and follows the repository's planned private access boundary; no access control is implemented by this document.

### Business and technical acceptance criteria

| Constraint | Specification | Evidence required |
| --- | --- | --- |
| Training first | One tenant, synthetic identities, dry-run adapters by default; proposed AWS cash ceiling $10/month after credits, with a separate bounded live-test allowance | Monthly usage ledger and bill reconciliation |
| Portfolio quality | Real authentication, authorization, state transitions, retries, idempotency, and restore behavior; no mocked success claims | Repeatable tests with sanitized artifacts |
| Human authority | Every external post, comment reply, or DM requires approval of its exact version | Tampering, stale approval, revocation, and race tests |
| Elastic demand | Accepted work queues durably and scales within resource, platform, and commercial limits | Load curve, queue-drain trace, overload response |
| Sustainable subscriptions | At least 30% runtime gross margin; target 50% operating contribution margin after allocated operating cost | Full-price unit economics and subscription settlement reconciliation |
| Headless operation | Browser is a control surface; jobs continue independently after it closes | Close-browser workflow test |
| Recovery | No silent loss of accepted work; regional recovery explicitly bounded | Backup restore and pending-job reconciliation |

These are design targets, not measured outcomes. Infrastructure/runtime cost includes AI inference, storage, transfer, secrets, logs, backups, retries, and paid platform dependencies. Labor, support, payment fees, refunds, and fixed overhead are also included in the subscription sustainability calculation.

## 2. Architecture and component-to-skill alignment

We used Amplify Gen 2 for the control surface and infrastructure definitions, with custom CDK resources for orchestration and messaging. Cognito identified users; AppSync enforced tenant-scoped operations; DynamoDB held business state; S3 held media and reports. EventBridge Scheduler triggered timed work; EventBridge distributed domain events; Step Functions orchestrated bounded jobs; SQS buffered work and DLQs exposed failures; Lambda implemented stateless processing and publishing adapters. Bedrock supplied model inference. Claude Code was a development aid, never the production orchestrator.

```text
Creator operator / subscriber
  -> Amplify Gen 2 control surface -> Cognito -> AppSync -> DynamoDB
                                  |                |       |
                                  |                +-> command / outbox
                                  +-> signed S3 upload     |
                                                         v
Scheduler -> EventBridge -> SQS -> Lambda -> Step Functions -> Bedrock
                            |       |             |
                           DLQ      +-> S3 assets + DynamoDB drafts
                                                     |
                                  approve exact content version
                                                     |
Scheduler -> publish queue -> adapter Lambda -> platform API
                                       |            |
                                       +-> Secrets Manager / KMS
                                       +-> receipt / reconciliation
Platform + commerce webhooks -> verified ingress -> SQS -> attribution
Daily Scheduler -> aggregate -> optional bounded Bedrock summary -> S3 brief
All paths -> CloudWatch metrics/logs/alarms + audit and cost ledger
```

The task IDs below refer to the official [SAA-C03 guide](https://docs.aws.amazon.com/aws-certification/latest/solutions-architect-associate-03.html). A mapping states which architectural skill a component exercises; it does not claim every product feature is tested on the exam.

| Component | Responsibility and boundary | SAA tasks | Proof artifact |
| --- | --- | --- | --- |
| Amplify Hosting / Gen 2, CDK, CI | Static control UI, repeatable environments, reviewed resource diffs; backend resources billed separately | 2.1, 2.2, 3.2, 4.2 | Clean deployment, rollback, generated resource inventory |
| Cognito and IAM/STS | User authentication, operator MFA, workload roles, least privilege; tenant membership separate from login | 1.1, 1.2 | Cross-tenant deny tests; IAM policy evaluation |
| AppSync | Tenant-scoped queries and mutations; custom approval and entitlement resolvers; no direct status-setting by clients | 1.1, 1.2, 2.1 | Resolver authorization and pagination tests |
| DynamoDB, indexes, Streams | Durable state, conditional writes, transactional outbox, usage reservations; access-pattern-first keys | 2.1, 2.2, 3.3, 4.3 | Query plans, conditional race tests, restore evidence |
| S3 | Private media and research, versioned approved objects, lifecycle policies, signed uploads/downloads | 1.3, 3.1, 4.1 | Bucket-policy denial, checksum, retention and restore tests |
| EventBridge Scheduler | Timed research, approved publication, local-time daily brief, cancellation/reconciliation | 2.1, 2.2, 4.2 | Duplicate, DST/timezone, expired-schedule tests |
| EventBridge | Versioned domain-event routing, isolated subscribers, delivery retry/DLQ | 2.1, 2.2, 3.5 | Event schema and target-failure evidence |
| Step Functions Standard | Short durable orchestration, bounded retries, explicit failure states | 2.1, 2.2, 4.2 | Execution history with retry and catch paths |
| SQS / DLQs | Buffer bursts, worker isolation, visibility timeout, partial batch failures, controlled redrive | 2.1, 2.2, 3.2, 3.5 | Backlog, poison-message and replay tests |
| Lambda | Stateless workers, right-sized memory, bounded concurrency, independent scaling | 2.1, 2.2, 3.2, 4.2 | Duration/memory benchmark and overload trace |
| Bedrock | Replaceable model adapter, structured output, token caps, latency/quality/cost evaluation | 2.1, 3.2, 4.2 | Token ledger and model evaluation; applied workload, not an exam guarantee |
| Secrets Manager / KMS | Scoped OAuth secrets, token rotation/revocation, encryption and key policies | 1.1, 1.2, 1.3 | Redacted rotation and denied-decrypt tests |
| Platform adapters | Capability checks, quota handling, external idempotency/reconciliation; approved content only | 1.2, 2.1, 2.2, 3.5 | Contract tests, 429/5xx and ambiguous-send cases |
| Webhook ingress (API Gateway + Lambda) | HTTPS, provider signature verification, replay defense, durable acknowledgement | 1.2, 2.1, 3.4, 3.5 | Invalid-signature and duplicate-event tests |
| Attribution and daily brief | Deduplicated conversion facts, bounded aggregation, source-linked summary | 2.1, 3.3, 3.5, 4.3 | Order/refund reconciliation and report lineage |
| CloudWatch, tracing, audit | Business SLOs, queue age, failure alerts, redacted correlation IDs; durable approval audit outside short-lived logs | 2.2, 3.2, 4.2 | Alarm drill, trace, incident timeline |
| Budgets, Cost Explorer, cost exports, admission ledger | Forecasting, full-price accounting, quotas and profitability controls | 4.1, 4.2, 4.3, 4.4 | Spend alerts, bill reconciliation, reservation races |
| Route 53 / TLS / delivery edge | Stable ingress, encrypted transport, cacheable UI/media; signed private media delivery where needed | 1.3, 2.2, 3.4, 4.4 | DNS/TLS and origin-bypass tests |
| Subscription provider + entitlement resolver | Verified paid status, quotas, renewal/cancellation, overage consent, auditable settlement | 1.2, 2.1, 2.2, 4.2 | Webhook replay and expired-subscription tests |

## 3. End-to-end workflow and state model

| Step | Selected behavior | SAA task alignment |
| --- | --- | --- |
| 1. Onboard | Verify subscription, tenant ownership and platform OAuth scopes; record brand voice and timezone | 1.1, 1.2, 2.1 |
| 2. Admit | Authenticate, validate, reserve worst-case cost and included usage atomically; return job ID only after durable acceptance | 1.1, 2.2, 3.3, 4.2 |
| 3. Research | Scheduled adapters collect permitted sources, audience questions, trends, and hooks; cache by niche/time window with provenance | 2.1, 3.5, 4.2 |
| 4. Generate | Bounded Bedrock calls produce original scripts, captions, carousel plans; schema checks and citations accompany drafts | 2.1, 3.2, 4.2 |
| 5. Store and review | S3 stores assets; DynamoDB stores versions, hashes and review state; sensitive or unsupported material returns for revision | 1.3, 3.1, 3.3 |
| 6. Approve | Server validates approver role and conditionally approves the exact version, hash, destinations and schedule | 1.1, 1.2, 2.2 |
| 7. Schedule | Approval transaction creates outbox intent; dispatcher creates a deterministic schedule; reconciler repairs missing schedules | 2.1, 2.2 |
| 8. Publish | Worker rechecks approval and entitlement, obtains a per-destination lease, validates capability, sends and saves platform receipt | 1.2, 2.1, 2.2 |
| 9. Triage community | Verified incoming comments/DMs become drafts; pricing intent becomes a lead; replies pass through the same approval gate | 1.2, 2.1, 3.5 |
| 10. Attribute | Signed campaign IDs and UTM metadata link posts to clicks and verified orders; deduplicate and account for refunds | 1.3, 3.3, 3.5 |
| 11. Brief | Local-time morning aggregation reports revenue, attribution uncertainty, leads, approvals, failures and costs | 2.1, 3.5, 4.3 |
| 12. Reconcile | Settle cost reservations, compare operational meter to billing exports, reconcile external receipts, check margins | 2.2, 4.1, 4.2, 4.3, 4.4 |

We keyed every entity and authorization check by tenant. Core records were Tenant, Subscription, Entitlement, BrandProfile, PlatformConnection, ResearchRun, Source, ContentVersion, Approval, PublishJob, DeliveryReceipt, CommunityItem, Lead, Click, Conversion, DailyBrief, UsageReservation, CostEntry and OutboxEvent. Indexes supported review queues, due work, platform receipts and daily aggregation without table scans. Large assets stayed in S3; event payloads carried IDs and object pointers.

Content followed `DRAFT -> IN_REVIEW -> APPROVED -> SCHEDULED -> PUBLISHING -> PUBLISHED`, with explicit `REJECTED`, `CANCELLED`, `PARTIAL`, `FAILED` and `UNKNOWN_DELIVERY` outcomes. Editing invalidated approval. Approval recorded tenant, approver, timestamp, version, immutable object version/checksum, platforms and expiry. Clients could not write approval or publication states directly.

The publish claim and approval/version check were one conditional transaction. Revocation before that claim blocked sending. After a network send began, cancellation became best effort with visible status; approval could not make an already accepted external action reversible. Partial multi-platform success retried only unfinished destinations.

At-least-once events were expected. Deterministic keys (`tenant/contentVersion/platform/scheduleVersion`) and conditional state changes protected each boundary. FIFO deduplication alone was insufficient. Where a provider lacked idempotency support, timeout after submission entered `UNKNOWN_DELIVERY`; reconciliation searched the provider receipt or required operator review instead of blindly reposting. We did not claim exactly-once delivery across AWS and third-party APIs.

Transactional outbox intent closed the database/event-publication gap. Dispatch retries could duplicate events, which consumers deduplicated. A scheduled reconciler repaired stranded outbox records and stale leases; it also checked schedules against authoritative approval state. Retention exceeded the retry/redrive window, while business receipts survived operational deduplication expiry. TTL deletion was eventual and never enforced authorization or expiration.

Research respected platform permissions and licensing. Unsupported scraping, universal DM automation, and guaranteed access to competitor comments were outside the contract. We began with permitted data and uploads. Video scripts and existing media were the economical default; generated video, transcription, and heavy rendering were separately metered add-ons. Bedrock outputs were untrusted data, never instructions with authority to publish or retrieve secrets.

## 4. Options and why we selected this path

All decisions below describe the completed design baseline. A new requirement can supersede a decision through a fail-forward record.

| Decision | Options considered | Selected path and reason | Tradeoff / revisit trigger | SAA tasks |
| --- | --- | --- | --- | --- |
| Control surface | Amplify static UI, SSR, custom S3/CloudFront | Amplify Gen 2 static client for fast portfolio delivery and repeatable backend definitions | Avoid SSR cost initially; reassess hosting transfer at sustained volume | 2.1, 3.4, 4.2, 4.4 |
| Runtime | Developer agent loop, EC2 cron, managed orchestration | Lambda + EventBridge + Step Functions; explicit state/retries and no idle server | More service boundaries and IAM policies | 2.1, 2.2, 3.2, 4.2 |
| Workflow type | Standard, Express, database-driven events | Standard for bounded orchestration; approval stored as durable state and resumes a fresh job | No long Lambda polling; Express only for short high-volume idempotent transforms after benchmark | 2.1, 2.2, 4.2 |
| Database | DynamoDB, RDS/Aurora, relational analytics store | DynamoDB for tenant/key-based operational access and conditional writes | Joins/ad hoc analytics less convenient; relational requirement triggers reevaluation | 3.3, 4.3 |
| Capacity mode | Provisioned free allowance, auto-scaled provisioned, on-demand | On-demand baseline to survive unpredictable tests; explicit max throughput and admission caps | Request units are paid. Optional provisioned training lab shares finite allowance across tables/indexes; switch mode through IaC, not an assumed instantaneous free-to-paid transition | 2.1, 3.3, 4.3 |
| Messaging | Direct synchronous calls, SQS, streaming log | SQS workers + EventBridge fan-out | Delivery duplicates and lag require idempotency; sustained ordered replay needs may justify Kinesis | 2.1, 2.2, 3.5 |
| Compute for media | Lambda, ECS/Fargate, Batch/Spot | Lambda for bounded small work; S3 uploads bypass it | Work beyond Lambda limits or sustained rendering moves to queued container/Batch workers, with a separate price | 2.1, 3.2, 4.2 |
| Storage | Database blobs, S3, EFS/EBS | S3 for immutable object assets and lifecycle retention | Small objects and retrieval charges can negate cold-tier savings | 1.3, 3.1, 4.1 |
| Network | VPC Lambda + NAT/endpoints, standard Lambda networking | No customer VPC for baseline workers; HTTPS AWS/platform APIs and IAM protection | Private dependencies add private subnets, endpoints and deliberate NAT budgeting; public-subnet Lambda alone does not grant internet access | 1.2, 3.4, 4.4 |
| AI | Largest model for all jobs, economical model routing, deterministic processing | Deterministic aggregation first; economical supported Bedrock model for routine drafts; premium model only within allowance | Quality evaluation gates routing; model IDs/rates/version availability reviewed before launch | 3.2, 4.2 |
| Keys and secrets | Plain environment credentials, managed keys, customer-managed keys | Secrets Manager scoped to adapter; AWS-managed/service encryption where adequate; customer-managed KMS where separate audit/key policy is required | Fixed secret/key costs accepted; broader enterprise isolation increases per-tenant cost | 1.1, 1.2, 1.3 |
| Availability / DR | One Region managed HA, warm standby, active-active | Managed multi-AZ regional services + backup/restore and reproducible IaC | Regional outage delays publication; global tables and standby require paid SLA justification | 2.2, 4.1, 4.3, 4.4 |
| Billing | Unlimited cheap plan, flat subscription, metered subscription | Base subscription with included usage, explicit overages and entitlements | More accounting logic; avoids loss-making unlimited inference | 2.1, 4.2 |
| Observability | Unlimited detailed logs, no logs, sampled redacted telemetry | Short retention for operational logs and durable minimal business audit | Lower debug detail balanced against privacy and log cost | 1.3, 2.2, 4.1, 4.2 |

## 5. Free Tier assumptions versus paid-scale assumptions

We treated the owner's new **Paid plan** account as eligible for applicable offers, not as a free sandbox. For accounts opened under the program introduced July 15, 2025, AWS provides $100 at signup and up to $100 more through qualifying activities. Credits expire 12 months from account creation; the separate Free account plan lasts at most six months. Paid accounts incur charges beyond applicable allowances/credits. Account eligibility, earned balance, expiration and other workloads must be checked in Billing. Creating/joining an AWS Organization can immediately expire Free Tier credits; the multi-account lab is therefore isolated or deferred until that consequence is accepted. [AWS Free Tier FAQ](https://aws.amazon.com/free/free-tier-faqs/)

We maintained two cost views: **cash bill after verified offers/credits**, and **replacement cost at paid rates without credits or shared free allowances**. Only replacement cost informed pricing. Legacy 12-month offers displayed on service pages were not assumed to apply to this new account; ambiguous eligibility was budgeted as paid until the console confirmed it. Allowances were shared according to each service's aggregation rules, never multiplied per tenant or sandbox. [AWS billing guidance](https://docs.aws.amazon.com/us_en/awsaccountbilling/latest/aboutv2/tracking-free-tier-usage.html)

| Service | Training / recurring allowance assumption | Paid planning baseline / caveat |
| --- | --- | --- |
| Lambda | 1M requests and 400,000 GB-seconds monthly, subject to offer rules | Example x86 first-tier compute $0.0000166667/GB-second; $0.20/M requests; memory, duration and architecture matter. [Pricing](https://aws.amazon.com/lambda/pricing/) |
| SQS | 1M requests/month across applicable Regions | Charge sends, receives, deletes, empty polls and payload chunks; FIFO/fair queue features differ. Estimate selected queue type. [Pricing](https://aws.amazon.com/sqs/pricing/) |
| Step Functions Standard | 4,000 transitions/month | $0.000025/transition in us-east-1; retries add transitions, Express has separate request/duration metering. [Pricing](https://aws.amazon.com/step-functions/pricing/) |
| Scheduler / event bus | Scheduler 14M invocations/month; no assumption that custom bus events are free | Scheduler excess example $1/M; custom events $1/M per 64 KB unit in cited examples; archives/replays add cost. [Pricing](https://aws.amazon.com/eventbridge/pricing/) |
| DynamoDB Standard | 25 GB storage; 25 RCUs/25 WCUs allowance applies to provisioned capacity, subject to aggregation rules | On-demand requests are paid. Indexes, transactions, backups/PITR, exports and replicas add charges. [Pricing](https://aws.amazon.com/dynamodb/pricing/) |
| Cognito | Lite/Essentials: 10,000 direct/social MAUs; SAML/OIDC federation allowance only 50 MAUs | Plus, M2M token usage, messaging and additional features differ; use selected identity flow and tier. [Pricing](https://aws.amazon.com/cognito/pricing/) |
| AppSync GraphQL | Budget as paid unless this account's time-limited offer is confirmed | $4/M queries/mutations, $2/M real-time updates, $0.08/M connection-minutes; transfer and backend charges additional. [Pricing](https://aws.amazon.com/appsync/pricing/) |
| Amplify Hosting | Budget paid; page's legacy 12-month allowances are conditional | Standard builds $0.01/minute; CDN storage $0.023/GB-month; served data $0.15/GB. Static UI avoids SSR meters. Backend is separately billed. [Pricing](https://aws.amazon.com/amplify/pricing/) |
| S3 | No universal always-free storage assumption for the new account | Charge storage, requests, lifecycle transitions, retrieval, versions, replication and transfer; cap uploaded/rendered bytes. [Pricing](https://aws.amazon.com/s3/pricing/) |
| Bedrock | No general always-free inference assumption; eligible credits may offset usage | Model, Region, inference mode, input/output, cache and media prices vary; record exact selected rate card before enabling. [Pricing](https://aws.amazon.com/bedrock/pricing/) |
| Secrets Manager / KMS | No perpetual free secret-storage assumption; qualifying KMS API allowance does not remove key charges | Secrets $0.40/secret-month and $0.05/10,000 API calls; customer-managed KMS key baseline $1/month, plus applicable requests/rotation charges. [Secrets](https://aws.amazon.com/secrets-manager/pricing/), [KMS](https://aws.amazon.com/kms/pricing/) |
| CloudWatch | Published allowances include limited metrics/alarms and 5 GB log-related usage; confirm feature meter | Ingestion, retention, queries, tracing and high-cardinality custom metrics can dominate a small bill. [Pricing](https://aws.amazon.com/cloudwatch/pricing/) |

Rates above were checked October 8, 2026. They do not imply the whole system is free. DNS, messaging, webhook ingress, payment processing, platform APIs, WAF, backups and delivery require their own estimate. Before deployment, save a dated [AWS Pricing Calculator](https://calculator.aws/) estimate with Region, selected model, account offers and workload inputs. Recheck monthly and whenever the architecture or rate card changes.

### Workload envelopes and reproducible calculations

The training envelope admitted one tenant, 30 research jobs, 120 draft jobs, 30 briefs, at most 60 approved destination publications, 1 GB of media and 2 GB of served UI data monthly. A 200-job orchestration subset at 15 transitions/job consumed 3,000 transitions before retries, leaving only 1,000 of the monthly allowance for retries and other workflows. A 50,000-call Lambda workload at 256 MB and 200 ms consumed `50,000 × 0.25 × 0.2 = 2,500 GB-seconds`; Bedrock waiting time and heavier jobs must be measured separately.

For cost arithmetic, 100,000 Standard jobs at 15 transitions cost $37.50 at full rates, or $37.40 after a verified 4,000-transition allowance. One million AppSync queries cost $4 at the listed full rate. A 120-minute standard Amplify build month plus 2 GB served and 0.1 GB stored costs `$1.20 + $0.30 + $0.0023 = $1.5023` before offers. Three secrets cost $1.20/month before API calls; one customer-managed key adds at least $1. These are partial calculations, not an all-in estimate.

For each model call, `AI cost = inputTokens × inputRate + outputTokens × outputRate + cache/media charges`, with rates normalized per token. A **hypothetical** $1/M input and $5/M output model with 4,000 input and 1,000 output tokens costs $0.009/call; 180 such calls cost $1.62. This is a sensitivity example, not a verified Claude price or model selection. Longer research context, multiple revisions, and generated media can multiply it. Measured provider token counters and timeout/retry charges replace estimates.

The commercial envelope started with a test scenario of 100 paying tenants and a 10× burst of admitted jobs. It used paid rates, per-tenant usage caps and measured worst-case included usage. No linear revenue assumption authorized unbounded compute. We included idle/fixed costs, failed jobs, free trials and cancelled accounts when modeling cohort profitability.

## 6. A self-sustaining subscription model

We replaced the original 30% markup idea with two explicit gates. A 30% markup on cost produces only 23.08% gross margin. The runtime floor is `(net revenue - runtime cost) / net revenue >= 30%`, so net revenue must be at least `runtime cost / 0.70`, a 42.86% markup. Our selected sustainability target is **50% operating contribution margin**, including allocated support, fixed overhead and a maintenance/reinvestment reserve. That is a **100% markup on all-in cost**, before accounting for payment fees and refunds. It is a planning policy, not a guaranteed financial result.

Let `F` be monthly fixed operating cost, `N_floor` the conservative paid subscriber count, `V_p95` the measured per-tenant included-use cost envelope, `S` allocated support, and `B` a contingency/reinvestment reserve. We used:

```text
C_all = F / N_floor + V_p95 + S + B
P_min = (C_all / (1 - 0.50) + fixedPaymentFee) / (1 - variablePaymentFee - refundReserveRate)
Runtime gate: net realized revenue >= C_runtime / 0.70
```

`N_floor` could not be a speculative viral forecast. During low enrollment, the founder funded the uncovered fixed-cost runway, raised price, or delayed commercial launch. Subscription revenue from customers was distinct from revenue attributed to their social posts; customer sales did not pay our AWS bill unless a separate contracted revenue share existed.

| Proposed plan | Monthly price hypothesis | Included usage ceiling | Operating cost envelope |
| --- | --- | --- | --- |
| Solo | $19 | One brand, two platforms, 120 text drafts, 60 destination publications, 30 briefs, 1 GB retained media | At most $8.00 all-in before payment fees/refunds |
| Studio | $49 | Three brands, six connections, 400 text drafts, 240 destination publications, 90 briefs, 5 GB media | At most $21.00 on the same basis |

These prices and allowances are **unvalidated hypotheses**, not active offers. One publication means one destination; retries/revisions and community drafting consume the relevant included allowance. Generated video, premium inference, large media transfer and paid platform dependencies require separate metering. We did not sell unlimited generation, comments or DMs.

Illustratively, assuming 3% variable payment cost, a $0.30 fixed transaction fee and a 2% refund reserve, Solo leaves `$19 × 0.95 - $0.30 = $17.75`; an $8 all-in envelope yields 54.93% operating contribution margin. Studio leaves $46.25 and yields 54.59% at $21. These fee rates are assumptions, not a provider quote. A Solo plan exceeds the 50% target only while all-in cost stays at or below $8.875; runtime cost must also remain at or below $12.425 for the 30% floor. The stricter operating envelope governs admission.

Before launching, we required a measured price sheet with exact model rates, per-feature costs, fixed-cost allocation, churn/refunds and fee terms. Overage price followed the same margin formula; overages required subscriber opt-in. Expired entitlements stopped new expensive work. Included work already accepted retained its reserved budget and visible completion/failure semantics.

### Profitability guardrail

Admission conditionally reserved worst-case tokens, media bytes, retries and downstream runtime cost against both tenant allowance and a global spend ceiling. Parallel requests could not overspend the same balance. Reservations carried leases and a reconciliation state; ambiguous external or model charges stayed reserved until resolved. Failed attempts were included in cost accounting.

At 70% of allowance we notified; at 90% we offered an upgrade or approved overages; at exhaustion we rejected new premium work or offered a bounded economical mode. Forecast runtime margin below 35% triggered investigation, and below 30% blocked new subsidized work. The 50% operating target had its own envelope alarm. Thresholds were design policy and needed validation against billing lag and load tests.

We reconciled operational estimates daily to billing exports/Cost Explorer and settlements. Billing data and AWS Budgets are delayed; budget alerts are not hard spending caps. The admission ledger, maximum token limits, concurrency caps and adapter circuit breakers were the immediate controls. No mechanism guaranteed zero overshoot across already-running requests or external billing uncertainty; the contingency reserve covered that exposure.

## 7. Autoscaling boundaries and resiliency

SQS absorbed bursts while Lambda event-source maximum concurrency and reserved concurrency bounded drain rate. In training, expensive generation workers began at concurrency 2; commercial load testing began at 10, with a per-tenant outstanding-job ceiling of 20. These were initial IaC parameters, not discovered service limits. Concurrency stayed within account quotas and did not starve approval, webhook or reconciliation workers.

Effective throughput was the minimum of worker concurrency/duration, DynamoDB capacity/hot partitions, Bedrock token/request quotas, platform rate limits, and available commercial budget. Separate per-platform/tenant rate buckets enforced tokens or calls per time window; concurrency alone did not enforce a rate limit. Queue age, not just invocation count, drove scaling decisions. Caps increased automatically only within a preconfigured paid envelope; service-quota increases and architectural changes required engineering review. DynamoDB on-demand, AppSync, Scheduler and queues still had quotas, scaling constraints and downstream bottlenecks. Autoscaling never meant infinite instantaneous capacity.

Overloaded interactive requests returned an explicit throttled response with retry guidance before acceptance. Accepted work remained queued, with a deadline and visible status; overdue publications required a configured skip or review decision. Retryable 429/5xx responses used jittered exponential backoff and bounded attempts; permanent authentication/capability failures stopped immediately. SQS visibility exceeded processing timeout plus safe retry margin; partial batch responses prevented healthy messages being retried with poison messages. EventBridge target DLQs and worker DLQs handled different failure boundaries.

We designed a single-Region baseline using regional managed availability, S3 versioning and DynamoDB PITR/backup according to environment value. Business data recovery targets were RPO <= 24 hours in synthetic training, <= 15 minutes in commercial operation, and regional restore RTO <= 4 hours. These remained unmeasured objectives. A commercial requirement for surviving total regional loss required cross-Region backup/replication and a restore drill; PITR in the affected Region alone was not that guarantee. Replay verified current approvals, entitlements and existing platform receipts. The system tolerated a delayed report more readily than an unauthorized or duplicate post.

## 8. Security and observability

We separated creator, approver and operator permissions; trusted server context supplied tenant IDs. Cognito claims alone did not authorize cross-tenant queries. IAM roles scoped DynamoDB keys, S3 prefixes, secrets, KMS permissions and queue access where applicable. Private objects used Block Public Access and short-lived signed access. TLS protected network transport. OAuth tokens never appeared in prompts, client bundles, logs or evidence; adapters cached secrets only for a bounded interval and handled provider-specific refresh/rotation rather than assuming generic database-secret rotation worked for OAuth.

Data classification separated licensed public research, private brand material, personal messages/leads, commerce facts and audit records. Retention defaults were 7 days for debug logs, 30 days for research snapshots, and 90 days for private leads/messages unless a justified policy required otherwise. Approval/audit and financial retention required explicit legal/business selection before commercial launch. Deletion included backups/versions according to documented retention; changing a prefix or a hidden link never enforced access.

Structured telemetry carried tenant/job/content/version/destination/correlation IDs and redacted sensitive payloads. CloudWatch tracked queue oldest age, DLQ depth, Lambda errors/throttles/duration, workflow failures, Bedrock tokens/latency, DynamoDB throttles, publish ambiguity, approval-to-publish latency, verified conversion counts, cost/job and margin. We avoided per-tenant custom metric dimensions at large scale; tenant cost detail lived in the ledger and exports. Trace sampling connected job boundaries without retaining full prompts or messages.

Initial test SLOs were p95 acknowledgement <2 seconds at declared test load, 99% of due publications attempted within five minutes when providers were available, and daily briefs ready by 08:00 in tenant timezone. Provider failures and exhausted entitlements were reported separately, not removed silently from the denominator. Alarms triggered an operator runbook: identify correlation ID, pause affected admission/adapter, inspect DLQ or unknown receipt, repair, replay narrowly, and verify business state and cost.

## 9. SAA-C03 coverage and proof plan

The official exam has four domains: secure architectures 30%, resilient 26%, high-performing 24%, cost-optimized 20%. The guide is not exhaustive and a case study cannot guarantee a pass. We designed coverage of **all 14 task statements**, with extension labs for skills the economical Creator baseline does not exercise. Evidence status for every row is currently **pending**. A completed row must link the architecture decision, reproducible lab, sanitized output, failure/repair evidence, and a short explanation of why an alternative would be better under different requirements. [Exam guide](https://docs.aws.amazon.com/aws-certification/latest/solutions-architect-associate-03.html)

| Task | Portfolio proof requirement | Coverage boundary |
| --- | --- | --- |
| 1.1 Secure access to AWS resources | Root MFA, role trust/resource policies, cross-tenant denials; federation and cross-account assume-role lab | Multi-account/SCP/Identity Center exercise isolated from credit-bearing account |
| 1.2 Secure workloads and applications | Signed ingress, secret handling, app authorization; draw and test segmented VPC, route tables, SG/NACL behavior | VPN/Direct Connect, WAF/Shield and endpoint choices compared in extension |
| 1.3 Data security controls | TLS/key-policy denials, rotation, access/lifecycle rules, backup restore and classification | Compliance requirements explained rather than falsely claimed certified |
| 2.1 Scalable, loosely coupled architecture | Headless event chain, independent worker scaling, outbox, containers/serverless comparison | Long media worker extension demonstrates container boundary |
| 2.2 Highly available/fault-tolerant architecture | DLQ and failure drills, regional recovery, RPO/RTO measurements, immutable rollback | Compare backup/restore, pilot light, warm standby and active-active |
| 3.1 Scalable storage | Signed object transfer and benchmark; object/file/block decision | EBS/EFS/FSx and hybrid storage extension |
| 3.2 Elastic compute | Memory/concurrency benchmark, backlog drain curve, compute-family selection | EC2 Auto Scaling/ALB and ECS/Batch lab for sustained rendering |
| 3.3 Database performance | Key/index access patterns, throttling/hot-key test, conditional writes | Relational engine/read-replica/proxy and cache comparison lab |
| 3.4 Network performance | TLS/DNS/edge and transfer path diagram, bandwidth/latency test | ALB/NLB, hybrid, peering/Transit Gateway, PrivateLink and Global Accelerator decisions |
| 3.5 Ingestion/transformation | Signed events to S3 analytics, deduplication, JSON/CSV-to-Parquet and visualization | Kinesis, Glue/Athena, secure lake and hybrid-transfer extensions |
| 4.1 Storage cost | Retention/size/request model, storage-class break-even and restore/retrieval cost | DataSync/Storage Gateway/Transfer and backup choices compared |
| 4.2 Compute cost | Full-price usage ledger, right-sizing, burst/steady break-even and cost guardrail | Spot/on-demand/Savings Plans/Reserved Instances; no premature commitment |
| 4.3 Database cost | Provisioned versus on-demand estimate including indexes/PITR and relational alternative | Schema/data migration and retention comparison |
| 4.4 Network cost | NAT versus endpoints/no-VPC, CDN hit/egress model and cross-AZ/Region routes | Hybrid bandwidth and throttling plan; costed topology alternatives |

Task definitions and detailed skill checklists: [Domain 1](https://docs.aws.amazon.com/aws-certification/latest/solutions-architect-associate-03/solutions-architect-associate-03-domain1.html), [Domain 2](https://docs.aws.amazon.com/aws-certification/latest/solutions-architect-associate-03/solutions-architect-associate-03-domain2.html), [Domain 3](https://docs.aws.amazon.com/aws-certification/latest/solutions-architect-associate-03/solutions-architect-associate-03-domain3.html), [Domain 4](https://docs.aws.amazon.com/aws-certification/latest/solutions-architect-associate-03/solutions-architect-associate-03-domain4.html).

### Closing the skills outside the baseline

We defined five bounded extensions, each using synthetic data, a preflight estimate and same-day teardown. Each extension records every relevant detailed skill from the linked official task checklist as demonstrated, explained by comparison, or still missing. Only hands-on artifacts count as implementation proof; a comparison proves design reasoning.

1. **Identity and network lab:** federation, STS, resource/key policies, account boundaries/SCPs, public/private topology, routing, SG/NACL, TLS and an endpoint/NAT comparison. Produce a hybrid VPN/Direct Connect bandwidth/security decision without buying a dedicated connection.
2. **Compute and availability lab:** a small multi-AZ ALB + EC2 Auto Scaling or ECS workload; horizontal/vertical scaling, container/image rollback, failure recovery and purchase-option estimates. Compare L7 ALB, L4 NLB and appliance routing. Demonstrate improving a legacy service through load balancing, managed persistence and recovery without requiring application changes. Avoid persistent idle resources after the exercise.
3. **Database and migration lab:** a temporary relational dataset with engine choice, read replica, connection pooling/proxy and cache benchmark; compare with DynamoDB hot-key/access patterns. Demonstrate a bounded schema/data move, backup restore, retention and replication behavior.
4. **Storage and hybrid-transfer lab:** object versus file/block performance and cost; lifecycle minimum-duration/retrieval tradeoffs; compare EBS volume types, EFS/FSx, DataSync, Transfer Family and Storage Gateway. Execute the economical transfer/restore subset and document unexecuted enterprise alternatives.
5. **Analytics and regional-recovery lab:** secure a small S3 lake, transform to Parquet, query/visualize bounded data, compare batch versus Kinesis streaming, and restore into a second Region. Record actual RPO/RTO, DNS/failover and quota readiness rather than assuming replication equals recovery.

Before labeling the portfolio complete, reconcile this registry against **every detailed skill bullet** in the then-current guide, explain all gaps, and finish the missing exercise or mark it unproven. The baseline deliberately excludes unnecessary enterprise services; excluding them saves money but does not remove the study requirement.

### Detailed skill acceptance register

The following compact register makes the proof workload explicit. Each semicolon-separated item needs its own evidence link or an honest gap entry. All items are **pending**. The official task pages above remain authoritative if the exam changes; this register covers their current skills rather than claiming to enumerate every possible exam question.

| Task | Individual evidence checks |
| --- | --- |
| 1.1 | Root/user safeguards; role/group/policy model; STS role boundaries; organizational policy exercise; resource-policy test; directory-to-role federation decision |
| 1.2 | Secured VPC design; subnet isolation test; application security integration; protected hybrid connection design |
| 1.3 | Requirement-to-control trace; stored-data encryption; transport encryption; key authorization; backup/replica recovery; access/retention policy; key rotation; certificate renewal |
| 2.1 | Event/service/tier decomposition; scaling choice per component; decoupling proof; container threshold; serverless threshold; technology-fit comparison; purpose-built service selection |
| 2.2 | Reproducible infrastructure; zone/Region availability design; business reliability metrics; single-failure removal; durable restore; DR selection; legacy reliability improvement; managed-service fit |
| 3.1 | Performance-fit storage configuration; growth-fit storage configuration |
| 3.2 | Independent compute scaling; metric-triggered elasticity; compute-feature fit; memory/instance sizing |
| 3.3 | Read-replica configuration; database topology; engine choice; database category choice; cache integration |
| 3.4 | Global/hybrid/tiered topology; growth-ready connectivity; resource placement; load-balancer fit |
| 3.5 | Protected lake; stream design; transfer design; visualization; processing engine choice; ingestion configuration; format conversion |
| 4.1 | Upload strategy; storage sizing; economical inbound transfer; growth policy; lifecycle rules; backup/archive choice; migration service; tier choice; retention choice; service cost comparison |
| 4.2 | Load-balancer economics; scaling economics; compute-service economics; production/nonproduction availability; instance family; instance size |
| 4.3 | Backup/retention economics; engine economics; service economics; data-shape economics; schema/data migration |
| 4.4 | NAT layout; connection economics; transfer-aware routing; edge-cache value; network optimization; throttling economics; bandwidth sizing |

For every comparison, record both the selected answer and the conditions that would change it. This distinguishes architectural judgment from memorizing service names. Knowledge topics such as shared responsibility, global infrastructure, pricing commitments, caching, network protocols, and recovery terminology accompany the practical checks; they also require independent study and scenario practice.

## 10. Validation and fail-forward evidence

We defined delivery slices: (1) identity/IaC/observability, (2) research and immutable drafts, (3) approval state machine, (4) dry-run publishing and receipt reconciliation, (5) live adapters and community drafts, (6) attribution and daily brief, (7) subscriptions and admission ledger, and (8) load/restore/extension labs. Each slice had an exam mapping, cost envelope, acceptance test and rollback artifact. Synthetic contracts came first; a bounded live trial proved provider behavior before enabling paid customers.

Required acceptance cases included cross-tenant denial, simultaneous approve/edit/revoke, duplicate schedule/event/webhook, retry after ambiguous publication, invalid provider signature, partial multi-platform success, 429/backoff, expired OAuth/subscription, exhausted allowance, token/byte overspend races, DLQ redrive, malformed AI output, prompt injection, cold starts, hot partition, restore and 10× burst. Performance and margin tests recorded dataset, concurrency, duration, Region, model/rate version, actual cost and assertion results. Success targets above were not substituted for measurements.

### Fail-forward event record

No incidents are claimed yet. During the build, every meaningful design failure becomes an append-only case-study event. A failure is valuable evidence only when diagnosis and corrective verification are traceable.

| Field | Required content |
| --- | --- |
| Event identity | ID, date, build slice, environment, commit, affected SAA tasks |
| Intended behavior | Requirement and expected result; workload and budget |
| Observed failure | Exact symptom, user impact, scope, redacted logs/trace and reproducible input |
| Detection | Alarm/test/operator signal, first occurrence and detection time |
| Diagnosis | Hypotheses tested; evidence supporting root cause; distinction from correlation |
| Containment | Pause/reject affected work, preserve state, bound spend and external side effects |
| Decision | Options compared, selected correction, cost/security/performance tradeoff |
| Fix | Code/IaC/config change and rollback procedure, linked commit |
| Verification | Original failing case now passes, regression checks, measured latency/cost/recovery |
| Learning | Why the assumption failed, SAA skill demonstrated, prevention and remaining risk |
| Status | Open, contained, corrected, verified; never mark verified without artifacts |

For example, a provider accepting a post before the client timed out is a **planned fault-injection scenario**, not an incident that has happened. Its expected lesson is that blind retries can duplicate external side effects; the proposed correction is unknown-delivery reconciliation. Actual outcome and evidence must be recorded after the experiment.

## 11. Completion criteria and remaining decisions

The design was complete when requirements, decisions, component/step mappings, pricing assumptions and proof criteria were reviewable. The implementation becomes complete only after the evidence registry demonstrates the promised behavior, full-price unit economics meet both margin gates, a restore is measured, and subscription/provider contracts are verified. A portfolio claim of broad SAA readiness additionally requires the extension checklist and practice-exam gap review; no pass guarantee follows from an architecture document.

Before building, confirm the AWS account creation date/credit eligibility, chosen Bedrock model and rate card, supported platform API capabilities/scopes, billing provider fees, conservative paid-subscriber floor, retention/classification policy and commercial recovery/SLO commitments. Keep prices and envelopes configurable. Design issues encountered while building are recorded as fail-forward events, resolved with evidence, and incorporated into the next version of this case study.