AWS 150: AWS AppSync, AppFlow and Amazon SES
Why this lesson matters
Separate managed GraphQL APIs, SaaS data integration, and email sending because their identity, data, delivery, and failure models are unrelated.
What you will be able to do
By the end, you can:
- explain aws appsync, appflow and amazon ses in plain language;
- locate the current service controls in the AWS Management Console;
- run the matching CloudShell or AWS CLI queries and explain every important field;
- draw the identity, network, data, failure, and monitoring path;
- choose the service from requirements and reject it when those requirements are absent;
- diagnose a failed or misleading result from evidence;
- state the cost owner and prove cleanup or a no-create result.
Before you start
- Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
- CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
- The course example Region is
ap-south-1. Global services and services with a required control Region are called out in their commands. - Run
aws sts get-caller-identityprivately. Redact the account number before sharing evidence. - Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
- This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
- Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.
The core model
| Question | What it means in this lesson |
|---|---|
| Purpose | Separate managed GraphQL APIs, SaaS data integration, and email sending because their identity, data, delivery, and failure models are unrelated. |
| Scope and boundary | The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for AppSync, AppFlow, and Amazon SES. |
| Evidence of success | Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for AppSync, AppFlow, and Amazon SES. |
| Cost model | Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design. |
| Safe rejection rule | Avoid treating SES acceptance as inbox placement, AppFlow as arbitrary ETL code, or GraphQL authorization as database authorization. |
How the request flows
+--------------------------------+
| Client, SaaS, or application |
+--------------------------------+
|
v
+---------------------------------------+
| Managed API, flow, or email control |
+---------------------------------------+
|
v
+-------------------------------------+
| Data source or recipient provider |
+-------------------------------------+
|
v
+--------------------------------------------+
| Resolver, transfer, or delivery evidence |
+--------------------------------------------+For AppSync, AppFlow, and Amazon SES, the important boundary is this: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for AppSync, AppFlow, and Amazon SES. Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for AppSync, AppFlow, and Amazon SES. That is why the lesson pairs the Console with CLI output and a practical artifact. One interface may hide a field, use a cached view, or be scoped differently. Matching evidence is stronger than a screenshot alone.
Architecture decision table
| Situation | Direction | Reason |
|---|---|---|
| Requirement matches | Use each service only for its native job and compliance boundary. | Select only after scope, behavior, security, recovery, operations, and price evidence agree. |
| Requirement does not match | Avoid treating SES acceptance as inbox placement, AppFlow as arbitrary ETL code, or GraphQL authorization as database authorization. | Rejecting an attractive service is a valid architecture result. |
| No create permission or cost approval | Use supplied evidence and local design work | Learning does not depend on creating an hourly resource. |
| Existing resource is unknown or unowned | Inspect only, then stop | Never change or delete a resource merely because it resembles a course example. |
AWS AppSync: GraphQL and real-time APIs
A GraphQL schema defines types, queries, mutations and subscriptions; it does not store data. A resolver maps a field to DynamoDB, Lambda, Aurora/OpenSearch/HTTP or other supported data sources through JavaScript or mapping logic and an AppSync service role. Pipelines compose functions. One client query can trigger many resolver/data-source operations, so depth/complexity, pagination, N+1 calls, caching and downstream capacity need limits and tracing.
Choose API key only for bounded low-risk/public development cases; production choices include IAM SigV4, Cognito User Pools, OIDC and Lambda authorization, with multiple modes/field directives where supported. Authentication at GraphQL entry does not automatically enforce row/tenant ownership. Inject trusted identity into key/condition expressions and prevent clients from selecting another tenant. Validate null/error behavior because GraphQL may return HTTP 200 with an errors array and partial data.
Subscriptions maintain managed real-time delivery based on mutations/configuration; reconnect, authorization, duplicate/stale state and client catch-up need design. Current AWS AppSync also offers AppSync Events for managed publish/subscribe WebSocket event APIs; do not confuse it with GraphQL subscriptions. Monitor request, resolver/data-source latency/errors, throttles, cache, active connections/messages and business results; redact field arguments and tokens.
Amazon AppFlow: governed SaaS transfer
AppFlow moves supported SaaS data to/from supported AWS/services using connectors, connections, flow triggers, field mappings, filters, validations and transformations. On-demand, scheduled or event-triggered support depends on connector. OAuth/client secrets and connector profiles are sensitive; ownership, token rotation, SaaS API quotas and consent must be documented. A successful flow run does not prove complete data - compare source watermark/count/key ranges to destination objects/records and handle pagination, deletions, schema changes and duplicates.
AppFlow is managed transfer and light transformation, not arbitrary ETL orchestration. Use Glue/DataBrew/Lambda/EMR or another governed pipeline when joins, complex quality rules or custom code dominate. Encrypt destinations, restrict S3 bucket/KMS policies, use PrivateLink where supported/required, classify personal data, set retention and prevent a broad SaaS connector from exfiltrating unrelated fields. Monitor run status, processed/failed records/bytes, connector errors and freshness SLA.
Amazon SES: sending is not delivery
SES identity verification proves control of a domain/address. Production access is Regional and new accounts may begin in a sandbox with recipient/rate restrictions. Use a verified domain, DKIM signing, custom MAIL FROM/SPF alignment where required and publish DMARC policy/reporting. IAM authorizes sending; sending authorization policies can delegate identities. Configuration sets/event destinations publish send, delivery, bounce, complaint, reject, open/click and rendering events as configured.
An accepted SES message ID means SES accepted the request, not that the recipient inbox accepted or displayed it. Handle hard bounces and complaints immediately using account-level/global suppression and list hygiene; soft outcomes need bounded retry. Separate transactional from marketing reputation and consent/unsubscribe requirements. Templates need version/test ownership and must prevent header/template injection or accidental personal-data logging. Dedicated IPs, managed dedicated pools and shared pools have different warm-up, reputation and cost implications.
AWS Management Console, step by step
Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.
- Use the Console service search and open AppSync APIs, AppFlow flows, and SES account dashboard; confirm the account and Region before reading the page.
- Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
- Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
- Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.
CloudShell and AWS CLI, step by step
Start with a known caller and Region:
export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure listRedact the account part of the ARN in shared evidence. Now run the topic queries:
aws appsync list-graphql-apis --api-type GRAPHQL --query 'graphqlApis[].{Name:name,Auth:authenticationType,Status:status}' --output table
aws appflow list-flows --query 'flows[].{Name:flowName,Status:flowStatus,Trigger:triggerType}' --output table
aws sesv2 get-account --output jsonExpected interpretation
The results expose API auth, flow state, and SES account status. They do not prove resolver correctness, transferred-record accuracy, or inbox placement.
Practical work
Create three one-page designs: a real-time GraphQL product API, an approved SaaS-to-S3 transfer, and transactional order email. Define authorization, encryption, data ownership, failures, quotas, and observability.
For AppSync, include tenant-safe schema/resolvers, pagination, complexity limits, subscription reconnect and partial-error tests. For AppFlow, include connector OAuth owner, incremental watermark, source/destination reconciliation, schema/deletion behavior and failed-record replay. For SES, include Region/sandbox status, domain/DKIM/SPF/DMARC, configuration-set events, bounce/complaint suppression, consent and deliverability runbook. Test wrong tenant, resolver timeout, expired SaaS token, changed field, duplicate transfer, unverified recipient, bounce, complaint and accepted-but-not-delivered message.
Diagnose this topic from its own evidence
AppSync HTTP 200 can contain field errors: inspect resolver path, identity context, generated request, data-source role/response and X-Ray/logs. AppFlow Successful needs source-to-destination reconciliation; failures require connector token/quota, mapping/schema, destination IAM/KMS and rejected-record evidence. SES send denial requires Region/sandbox/identity/IAM evidence; accepted mail requires event destination, bounce/complaint/delivery and DNS authentication - not Lambda logs - to determine outcome.
Cost and cleanup
Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Knowledge check
- What operational purpose is this lesson solving?
Expected direction: Separate managed GraphQL APIs, SaaS data integration, and email sending because their identity, data, delivery, and failure models are unrelated.
- Which scope or ownership boundary must be proved first?
Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for AppSync, AppFlow, and Amazon SES.
- What evidence is strong enough to accept the result?
Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for AppSync, AppFlow, and Amazon SES.
- Which tempting design or shortcut must be rejected?
Expected direction: Avoid treating SES acceptance as inbox placement, AppFlow as arbitrary ETL code, or GraphQL authorization as database authorization.
- Which cost dimensions and retained resources need an owner?
Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Lesson acceptance
Pass only when all three unrelated services are modeled independently. AppSync must enforce field/tenant data authorization and handle resolver/real-time behavior; AppFlow must prove governed, reconciled transfer and replay; SES must prove domain authentication, reputation/compliance and delivery feedback. Fail if GraphQL auth is delegated blindly to the database, AppFlow success replaces reconciliation, or SES acceptance is called inbox delivery.