2.7 - Deployment strategies and purpose-built services
AWS Solutions Architect Professional objective 2.7 covers deployment strategies and purpose-built services. You shift a slice of Lambda traffic to a new version with an AWS CodeDeploy canary configuration on the alias and auto-roll-back on errors, and the ECS deployment circuit breaker automatically stops and reverses a bad rollout. Purpose-built targets matter: Amazon MSK keeps Kafka APIs and connectors unchanged, Amazon Timestream stores billions of time-series readings with automatic lifecycle to cheaper storage, transient EMR clusters with Spot task nodes run interruptible big-data jobs cheaply, and DynamoDB Streams triggers an analytics Lambda within seconds of a change. AWS Budgets alerts before spend crosses a threshold, QuickSight embedding with row-level security and namespaces isolates each SaaS tenant, standard Cross-Region Replication with RTC only on strict-SLA objects balances cost, and a Network Load Balancer gives static IPs, ultra-low latency and preserved source IPs over raw TCP. Expect scenarios about a canary rollout, a time-series or streaming trigger, or multi-tenant dashboards, and ask which strategy or service fits.
Gradual traffic shift with auto rollback on Lambda = CodeDeploy canary on the alias. Auto-stop and reverse a bad ECS rollout = deployment circuit breaker with rollback. React within seconds to a DynamoDB item change = DynamoDB Streams trigger.
Practice questions
1. An event-driven system must fan a single event out to several independent consumers, each with its own retry and dead-letter handling, and add new consumers without touching producers. What should the architect use?
- A single SQS queue that every consumer polls
- SNS (or EventBridge) fan-out to one SQS queue per consumer (correct answer)
- A Kinesis stream with a single shard read by all consumers
- Direct Lambda invocation from the producer to each consumer
SNS or EventBridge fan-out to a dedicated SQS queue per consumer decouples producers from consumers: each queue has its own retry and DLQ, and new subscribers are added without changing producers. One shared queue means consumers compete for messages; direct invocation couples producer to every consumer.
2. A team deploys a Lambda function behind an alias and wants each release to shift 10% of traffic to the new version for ten minutes, then the rest, rolling back automatically if errors spike. Which approach delivers this canary rollout?
- Publish a new version and repoint the alias to it all at once
- AWS CodeDeploy with a canary traffic-shifting configuration on the Lambda alias (correct answer)
- Deploy the new code to $LATEST and let clients call it immediately
- Create a second function and split traffic between them with a Route 53 weighted record set
CodeDeploy shifts a weighted percentage of alias traffic to the new version on a canary or linear schedule and auto-rolls back on a CloudWatch alarm, exactly matching a 10%-then-rest rollout. Repointing the alias at once is a big-bang cutover, $LATEST bypasses controlled shifting, and Route 53 weighting is coarse DNS-level and not tied to Lambda alarms.
3. A revenue-critical API on ECS behind an Application Load Balancer must test a new version on a small slice of real users before full release, keeping the old version instantly available for rollback. The team wants the safest deployment style. Which fits best?
- A rolling update that replaces tasks in place a few at a time
- An in-place restart of every task after the new image is pushed
- Blue/green with CodeDeploy shifting a canary percentage between two target groups (correct answer)
- A one-shot swap of the ALB listener over to a brand-new service with no canary test slice
Blue/green with CodeDeploy runs the new version in a separate target group, shifts a canary slice of live traffic to validate it, and rolls back instantly by shifting back to the untouched old group. Rolling and in-place restarts mutate the running version (no instant rollback), and a one-shot listener swap skips the canary test entirely.
4. An EC2 web tier managed by Elastic Beanstalk must deploy new versions with zero downtime and guarantee that a failed deployment leaves no partially updated instances mixing old and new code. Which deployment policy meets this?
- Immutable deployment, which launches a fresh instance set and swaps only on success (correct answer)
- All-at-once deployment, which updates every running instance in the group simultaneously
- Rolling deployment, which updates instances in small in-place batches
- Rolling with additional batch, updating existing instances after adding a batch
Immutable deployment launches a parallel set of brand-new instances with the new version and only shifts traffic if they pass health checks, so a failure is discarded with no mixed-version instances. All-at-once causes downtime, and both rolling variants update existing instances in place, risking a mixed or partially updated fleet on failure.
5. An ECS rolling deployment behind an ALB sometimes leaves a broken new version running because failing tasks pass the basic container health check but return errors to users, and no one rolls it back promptly. Which ECS feature automatically stops and reverses such a bad rollout?
- A longer ECS deployment minimum healthy percent so more old tasks stay running
- Manual monitoring of CloudWatch dashboards during every deployment window
- A scheduled Lambda that redeploys the previous task definition every night
- The ECS deployment circuit breaker with rollback tied to failed health checks (correct answer)
The ECS deployment circuit breaker watches health checks during a rolling deployment and, on repeated failures, automatically stops and rolls back to the last known-good task set with no human action. A higher minimum healthy percent only keeps capacity up, manual monitoring is not automatic, and a nightly redeploy is far too slow to protect a live rollout.
6. An Aurora MySQL cluster serves a read-heavy reporting workload whose traffic varies wildly through the day. The team wants read capacity to grow and shrink automatically without manually managing replica counts. What should be configured?
- Aurora Auto Scaling for Aurora Replicas driven by a target metric (correct answer)
- One very large Aurora Replica manually sized to cover the entire daily peak load
- DynamoDB on-demand tables mirroring the reporting queries
- Aurora Global Database with a secondary Region for reports
Aurora Auto Scaling adds and removes Aurora Replicas automatically against a target metric such as average CPU or connections, matching capacity to the swinging read load. A fixed large replica overpays at troughs, DynamoDB is not relational for these queries, and Global Database targets multi-Region, not local scaling.