Case study: matching services to a workload

Eleven sessions after they started, Gwen and Mateo spread the service map across the big table in the Calgary boardroom. It has grown to four pages. Lorraine, Dr. Kaur, Hannah, Kwame and Andre are all there, because this is the review before the design goes to the board in December. "Today we do two things," Gwen says. "We check that every requirement has a service and every service has a reason. Then Mateo practises the thing the exam really tests: reading a short scenario and picking the right service quickly."

This lesson pulls the course together. It sets out a method for matching services to a workload, applies it to the whole Cascade Ridge design, shows the finished architecture, and finishes with a set of scenario drills in the style of the exam's third domain.

A method for matching services

Gwen's method has five questions, asked in order. They work for a whole architecture and for a single exam question.

• What is the job? State it in plain words: store images for years, run a vendor's Windows application, send reminders, answer booking questions. Most exam questions hide the job in a sentence of business language.
• What are the constraints? Look for the words that decide between similar services: lowest cost, least operational overhead, millisecond access, retrieval within hours, must not cross the internet, existing Kubernetes, vendor supports only virtual machines, unpredictable traffic.
• Which category? Compute, containers and serverless, storage, database, networking, hybrid connectivity, monitoring, integration, analytics, AI and ML, developer tools, end-user computing or IoT. Naming the category removes most wrong answers.
• Which service in that category best fits the constraints? Prefer managed and serverless services unless a constraint demands control, and choose the highest layer that solves the problem.
• What else does it need? Every service needs identity, network placement, monitoring, backup and cost controls. Good answers and good architectures do not forget them.

The Cascade Ridge requirements

Mateo reads out the requirements gathered over the course, and the team agrees on a service for each.

The architecture

The figure shows a generic version of the pattern the team arrived at, the kind an exam question might describe: an edge layer (Route 53 and CloudFront), a compute layer spread across Availability Zones behind a load balancer, a managed database layer with a standby, a queue that decouples background work, and monitoring around everything. Cascade Ridge's own design follows the same shape, with EC2 instances for VetLedger and RDS for SQL Server instead of containers and Aurora, because of the vendor's requirements.

Dr. Kaur asks the question that matters most to her: what happens at three in the morning if an Availability Zone fails? Mateo answers it in order. The load balancer stops sending clinic traffic to the failed zone. The Auto Scaling group launches a replacement instance in the healthy zone. RDS fails over to its standby in the other zone, usually within a minute or two, keeping the same endpoint name. S3, DynamoDB, SQS and Lambda are Regional services that already span several zones. CloudWatch alarms notify the on-call phone and the charge nurse through SNS. The emergency hospital might see a short pause, not a three-hour outage.

Lorraine asks the other question: what does it cost? Gwen will not give a number in this course, because pricing, budgets and the tools for estimating cost are the subject of the billing course. She lists the decisions in this design that keep costs down: lifecycle rules on the archive, serverless services that cost nothing when idle, Spot for the image-preview job, a Savings Plan for the steady VetLedger servers after measurement, and a gateway endpoint so S3 traffic avoids NAT charges.

Trade-offs the team accepted

• VetLedger stays on EC2. It would be cheaper and simpler to run on containers or serverless, but the vendor supports only Windows servers. The team accepts patching (automated with Systems Manager) in return for vendor support.
• Glacier Instant Retrieval, not Deep Archive, for old images. Deep Archive would cost less, but referral hospitals sometimes need a study the same day.
• VPNs for the clinics, not Direct Connect. Direct Connect to every clinic would cost far more; the clinics' traffic is modest, and a mobile backup line covers outages.
• Athena first, not Redshift. Lorraine's reports are modest in volume and run once a day; a warehouse can come later if needed.
• People review AI output. Transcribe and Textract save time, but a vet or receptionist confirms every note and every allergy.

Scenario drills

Gwen closes with quick-fire scenarios. For each one, Mateo names the category first, then the service, then the word in the question that decided it.

# A tiny keyword helper for revision: which service does a scenario point to?
clues = {"kubernetes": "Amazon EKS", "trace": "AWS X-Ray", "fan out": "Amazon SNS",
         "which user": "AWS CloudTrail", "scanned form": "Amazon Textract",
         "sql on s3": "Amazon Athena", "dedicated link": "AWS Direct Connect",
         "key-value": "Amazon DynamoDB", "shared linux file": "Amazon EFS"}

def suggest(scenario):
    s = scenario.lower()
    hits = [svc for clue, svc in clues.items() if clue in s]
    return hits or ["read the constraints again"]

for q in ["We need a shared Linux file system for 40 servers",
          "Find which user stopped the instance",
          "Query S3 files using SQL with no servers"]:
    print(q, "->", suggest(q))

We need a shared Linux file system for 40 servers -> ['Amazon EFS']
Find which user stopped the instance -> ['AWS CloudTrail']
Query S3 files using SQL with no servers -> ['read the constraints again']

Gwen is quick to add that a keyword list is a revision aid, not a strategy. The third scenario above asks for Athena in different words, so the helper misses it; a person reading for meaning would not. Exam questions are written to reward understanding: the distractors are usually real services that solve a different problem. The habit to build is naming the job and the deciding constraint before looking at the options.

What the design leaves for later

A good design says what it does not yet do. Gwen lists four items so the board is not surprised. The cost estimate comes next, using the AWS Pricing Calculator, with budgets and alerts in the billing course. The support plan must be chosen before cutover; Dr. Kaur's requirement that someone at AWS respond quickly to a production outage points to at least Business Support. The full disaster recovery design, including how quickly the recovery Region could take over and how often that is rehearsed, needs its own workshop. And the phase 2 projects, BookVet's rewrite and the AI features, wait until the core migration has run smoothly for at least a month.

Writing these down protects the project. Each item has an owner and a date, so none can be quietly dropped, and the board can see that the team knows the difference between decided and planned.

Andre asks one last practical question: who will look after all of this after Gwen's contract ends? The answer is part of the design too. Mateo becomes the platform owner, Kwame owns BookVet and its pipeline, Hannah owns security and compliance settings, and Lorraine owns budgets and cost reports. Each owner has a dashboard and a short runbook. The service map stops being a project document and becomes the way the company runs its systems.

By the end of the session the service map is signed off for the board. Mateo has one more task: the cost estimate, which is the subject of the next course. He also has a revision plan for February, built from twelve sessions of notes. "Thirty-odd services," he says, looking at the four pages. "I actually know what every one of them is for."