Lesson 309 · AWS Learning Path

AWS 309: AWS Amplify, AWS End User Messaging, Amazon Connect outbound campaigns, and Device Farm

Anil Jalela · Published Apr 30, 2026 · 11 min read

Why this lesson matters

These services sit at different boundaries of a digital product. Amplify builds and hosts web experiences and can define cloud backends. AWS End User Messaging delivers transactional SMS, MMS, push, WhatsApp, voice, and one-time-password messages according to channel and Region. Amazon Connect outbound campaigns orchestrate proactive customer contact. Device Farm runs mobile and web tests on managed devices and browsers.

Combining them without clear boundaries creates serious failures: preview branches expose production data, a retry sends duplicate SMS, a campaign contacts a person without consent, a test package contains customer credentials, or automation spends money on thousands of messages and device minutes.

Amazon Pinpoint is no longer a new-design destination. It stopped accepting new customers on May 20, 2025 and ends support October 30, 2026. Its communication channel APIs were renamed AWS End User Messaging and continue, while endpoints, segments, campaigns, journeys, analytics, and email need migration. Current AWS guidance points engagement workloads toward Amazon Connect proactive engagement, transactional channels toward End User Messaging, email toward SES, and event analytics toward services such as Kinesis.

What you will be able to do

By the end, you can:

• separate web hosting/backend, transactional delivery, campaign orchestration, and test execution;
• explain Amplify Gen 2, Hosting, branches, builds, previews, domains, rewrites, environment variables, and backend isolation;
• design messaging identity, registration, consent, opt-out, destination, template, throughput, retries, delivery events, and spend controls;
• distinguish transactional messages from coordinated outbound campaigns;
• model Amazon Connect outbound lists, segments, schedules, channels, flows, agents, suppression, and outcomes;
• create a Device Farm device-pool, test-package, run, artifact, and cleanup strategy;
• migrate away from Pinpoint without assuming renamed APIs preserve engagement features;
• diagnose build, DNS, delivery, campaign, and device-test failures; and
• produce a governed launch design for a customer application.

Before you start

• Use a synthetic domain, fake users, reserved/documentation phone examples, test endpoints, and non-production application packages.
• Do not send a lab message to a real person. Messaging can create telecom charges and legal obligations.
• Obtain legal/privacy approval for consent language, quiet hours, age restrictions, recording, suppression, and regional rules.
• Never upload signing keys, production API secrets, customer databases, call recordings, or live push credentials to a test.
• The default T0 path is design and read-only inventory. A T1 pilot needs a spend cap, sandbox/origination identity, allowlisted destinations, and cleanup owner.

mkdir -p "$HOME/aws309-evidence"
cd "$HOME/aws309-evidence"
export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text

1. Keep the four service planes separate

developer commit
   -> Amplify build/deploy -> web user -> application APIs

business event
   -> End User Messaging -> carrier/provider -> recipient device
                              -> delivery/engagement events

approved audience and strategy
   -> Connect outbound campaign -> channel/flow/agent -> customer outcome

application build + test code
   -> Device Farm run -> device/browser sessions -> logs/video/results

Amplify does not grant permission to contact users. Messaging delivery does not manage a complete marketing journey. A campaign does not prove carrier delivery or consent. Device Farm tests software behavior, not production data governance.

2. Build and host with Amplify deliberately

Amplify Hosting connects a repository or manual artifact to a build and deploy pipeline, CDN-backed hosting, TLS, domains, redirects, and branch environments. Amplify Gen 2 is the recommended TypeScript code-first path for defining supported backend resources. Gen 1 and Gen 2 have different workflows; identify the generation before following a command.

A hosting deployment flows through provisioning, build, deploy, and verification. The build specification defines commands, artifact base directory, files, cache paths, and environment. Pin runtime and package-manager versions, use lockfiles, fail on tests, and avoid untrusted post-install behavior. Cache improves speed but can preserve stale or poisoned dependencies; include invalidation and clean-build tests.

Branch deployments are independent release surfaces. Map production, staging, and feature previews to separate data and identity boundaries. A pull-request preview must not receive production database credentials merely because its frontend is temporary. Treat contributor-controlled build code as untrusted for secrets.

Environment variables are configuration, not automatically a secret vault. Browser build variables can be embedded into downloadable JavaScript. Put only public client configuration in the bundle. Resolve server-side secrets from an approved secret service with least privilege.

Custom domains require DNS validation, certificate issuance, correct subdomain mapping, and redirect/canonical decisions. Test apex and www, HTTP-to-HTTPS, SPA fallback, real 404s, API routes, cache headers, and certificate renewal. A catch-all rewrite can turn missing files or API errors into misleading HTTP 200 pages.

aws amplify list-apps --max-results 20 --output table
aws amplify list-branches --app-id REDACTED_APP_ID --output table
aws amplify list-jobs --app-id REDACTED_APP_ID --branch-name main --output table

Record app/branch/build IDs privately. A green deploy proves artifact publication, not functional correctness. Add synthetic page, authentication, API, accessibility, and security checks before traffic promotion. Preserve the previous artifact and backend compatibility for rollback.

3. Design transactional messaging

A message design includes:

1. business event and owner;
2. channel and destination;
3. consent and lawful purpose;
4. origination identity and registration;
5. template and language;
6. idempotency key and retry rule;
7. quiet hours and rate limit;
8. opt-out/suppression;
9. delivery event and reconciliation;
10. spend alarm and shutdown authority; and
11. retention/deletion for destination and content.

SMS acceptance by an AWS API is not handset delivery. Messages traverse carrier networks and can be queued, filtered, rejected, delayed, or delivered without being read. Sender IDs, long/short codes, toll-free numbers, templates, registrations, and two-way support vary by country.

Use separate origination identities and pools for transactional, OTP, and promotional traffic where policy requires. An OTP needs cryptographically strong generation, short expiry, attempt limits, single use, secure comparison, destination protection, and account-recovery defenses. Never log the code.

Retries can duplicate a message after an ambiguous timeout. Assign an application event ID, store send state, bound retries, and reconcile provider events. Do not repeatedly retry permanent opt-out, invalid-number, or regulatory rejection. Protect against queue replay and bulk-trigger mistakes with per-recipient and global rate/spend limits.

Push messaging uses platform credentials and device tokens that expire or rotate. Remove invalid endpoints and avoid sensitive content on lock screens. WhatsApp and other channels have business/template/conversation rules. Voice and text-to-speech need caller identity, consent, and abuse controls.

Read-only examples depend on channel API namespaces:

aws pinpoint-sms-voice-v2 describe-spend-limits --output table
aws pinpoint-sms-voice-v2 describe-phone-numbers --output table
aws pinpoint-sms-voice-v2 describe-pools --output table
aws pinpoint-sms-voice-v2 list-opt-out-lists --output table
aws pinpoint list-apps --output table

The retained pinpoint command may expose legacy resources; it does not mean the Pinpoint engagement service remains a valid future architecture.

4. Orchestrate proactive contact with Amazon Connect

Use Connect outbound campaigns when the workload needs coordinated customer engagement, segmentation, channel strategy, contact limits, flows, predictive/progressive dialing, agent involvement, and unified inbound/outbound operations. Use direct End User Messaging or SES when the requirement is high-volume transactional delivery without campaign orchestration.

A campaign needs an approved audience snapshot, contact attributes, channel, schedule/time zone, suppression, attempt limits, contact flow, agent queue/capacity where applicable, outcome codes, and stop control. Validate every list column, normalize destinations, deduplicate by governed customer identity, and exclude withdrawn consent before upload or activation.

Predictive dialing trades agent idle time against abandonment risk and regulation. Progressive or agentless patterns have different capacity and customer experience. Model answer rate, average handle time, agent occupancy, pacing, concurrency, contact-flow duration, and channel quota. Stop automatically when complaints, errors, abandonment, or spend cross approved thresholds.

Do not infer consent from presence in a CRM. Keep proof of purpose, source, timestamp, channel, jurisdiction, and withdrawal. Enforce quiet hours in the customer's local time, including daylight-saving behavior. A global UTC schedule is insufficient.

aws connect list-instances --max-results 20 --output table
aws connect list-contact-flows --instance-id REDACTED --max-results 20 --output table
aws connect list-queues --instance-id REDACTED --max-results 20 --output table

5. Migrate away from Amazon Pinpoint

Inventory Pinpoint projects, endpoints, attributes, segments, journeys, campaigns, templates, events, analytics, channels, suppression, and email dependencies. Classify destinations:

Export before October 30, 2026 with checksums, row counts, schemas, consent provenance, suppression lists, and retention approval. Rebuild behavior, not only data. Compare segmentation semantics, scheduling, template rendering, event status, retry, quiet hours, and reports. Run a controlled parallel validation without double-contacting recipients, then disable triggers and revoke legacy access.

6. Test with Device Farm

Device Farm tests Android, iOS, and web applications on managed real devices or browser infrastructure according to current project/run options. A mobile run combines application package, test package/framework, device pool, execution configuration, network settings, and artifacts.

Build device pools from supported OS, model, manufacturer, form factor, and availability. Cover a risk-based matrix instead of every device: minimum/current OS, small/large screen, low/high performance, major vendors, and known customer concentration. A test on one flagship phone is not compatibility evidence.

Tests must be deterministic and independent. Seed synthetic accounts, wait for observable conditions rather than fixed sleeps, reset state, assign unique data, capture logs/screenshots/video, and separate application failure from test-harness or device failure. Quarantine flaky tests only with an owner and expiry.

Private application testing requires a controlled path to non-production endpoints. Restrict inbound scope, use temporary credentials, and remove it after the run. Never tunnel into production merely to make a test pass.

aws devicefarm list-projects --output table
aws devicefarm list-device-pools --arn REDACTED_PROJECT_ARN --output table
aws devicefarm list-runs --arn REDACTED_PROJECT_ARN --output table
aws devicefarm list-uploads --arn REDACTED_PROJECT_ARN --output table

Artifacts can contain screenshots, logs, tokens, typed fields, crash dumps, and video. Restrict access, scan/redact, set retention, and delete uploads/runs according to policy.

7. Diagnose from evidence

8. Architecture workshop

Design a retail application launch with Amplify web hosting, order SMS, optional promotional campaign, and mobile regression. Produce:

• branch/backend/account isolation and rollback;
• domain, TLS, rewrite, cache, and deployment tests;
• order-event idempotency and message status state machine;
• origination registration, consent, opt-out, quiet hours, and spend guard;
• campaign list provenance, pacing, agent capacity, suppression, and emergency stop;
• Pinpoint inventory and migration plan;
• Device Farm matrix, synthetic data, private test network, and artifact retention;
• security/observability ownership;
• normal, retry-storm, campaign, build-minute, and device-minute cost; and
• full cleanup/decommission procedure.

Inject a poisoned dependency, DNS validation error, ambiguous SMS timeout, opt-out arriving during campaign, daylight-saving schedule error, and leaked test screenshot. Diagnose, contain, recover, and prevent each.

Cost and cleanup

Costs can include Amplify build minutes, hosting storage/requests/transfer, domains, WAF/logs, backend services, message parts and destination-country rates, origination numbers/registration, carrier fees, campaign and Connect usage, telephony, agent time, Device Farm minutes/concurrency, artifacts, NAT, and monitoring.

For a pilot, disable webhooks and campaigns first; delete only owned branches/apps/backends after dependency review; release messaging identities only after regulatory/porting approval; remove test endpoints and credentials; stop campaign schedules; delete Device Farm uploads/projects/artifacts under policy; and verify delayed billing. Never delete a shared opt-out list or production domain to clean a lab.

Practical submission

Submit: service-boundary diagram; Amplify build/branch/domain plan; secret classification; messaging state machine; consent/suppression evidence model; channel/origination matrix; campaign capacity and stop controls; Pinpoint migration map; Device Farm risk matrix; nine diagnostic cases; six failure-injection reports; security/privacy review; cost/quota model; rollback; and cleanup/no-create proof.

Knowledge check

1. Why is an Amplify variable not automatically secret? Browser builds can embed it in public JavaScript.
2. Why is an accepted SMS not proven delivery? Carriers and devices add later states and failures.
3. What prevents ambiguous retries from duplicating messages? Stable business-event idempotency and reconciliation.
4. Direct messaging versus campaign? Transaction delivery versus audience orchestration, pacing, flows, and outcomes.
5. What ends with Pinpoint? Engagement resources and console on October 30, 2026; renamed channel APIs continue.
6. Why test suppression immediately before contact? Consent may change after audience creation.
7. Why use a risk-based device pool? Device coverage is combinatorial and must represent actual users and failures.
8. Why protect test artifacts? They can contain sensitive screens, logs, identifiers, and credentials.

Lesson acceptance

Pass when every commit, message, campaign contact, and test run has a governed source, identity, limit, evidence, failure response, cost owner, and deletion path. Fail if previews use production secrets, the design targets new Pinpoint engagement, sends without consent, retries blindly, treats API acceptance as delivery, uploads production data to Device Farm, or lacks an emergency stop.

Official sources

• AWS Amplify documentation
• Amplify Hosting
• Amplify Gen 2
• AWS End User Messaging SMS
• Amazon Pinpoint end of support
• Amazon Connect outbound campaigns
• AWS Device Farm
• AWS End User Messaging pricing
• AWS Device Farm pricing