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. 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

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.

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. A mapping states which architectural skill a component exercises; it does not claim every product feature is tested on the exam.

3. End-to-end workflow and state model

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.

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

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

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 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:

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.

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

Task definitions and detailed skill checklists: Domain 1, Domain 2, Domain 3, Domain 4.

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.

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.

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.