Outposts, Batch, AppFlow, Amplify and Instance Scheduler

By the end of this lesson you will be able to

• Explain what AWS Outposts is (racks and 1U/2U servers, second-generation racks), who is responsible for what, how the service link and local gateway work, what keeps running when the link breaks, and choose between Outposts, Local Zones, Dedicated Local Zones, Wavelength and the closing Snow family.
• Describe AWS Batch: job definitions, job queues with priorities, managed and unmanaged compute environments (EC2, Spot, Fargate, EKS), array jobs, dependencies, retry strategies and timeouts, and why it scales to zero.
• Decide between Batch, Lambda, Fargate and Step Functions with the real differentiators (15 minutes, 10 GB of memory, no GPU), not the myth that only Batch runs containers.
• Use Amazon AppFlow to move data between SaaS applications such as Salesforce, SAP, Zendesk or Slack and S3 or Redshift with schedules, events, filters, mappings and PrivateLink, and tell it apart from Glue, DMS, DataSync and Kinesis.
• Explain AWS Amplify: Amplify Hosting (Git-based CI/CD, previews, SSR for Next.js) and the Gen 2 backend (Cognito, AppSync with DynamoDB, S3, Lambda), and compare it with Elastic Beanstalk, App Runner and S3 with CloudFront.
• Deploy Instance Scheduler on AWS to stop dev and test resources outside office hours, compute the saving, and know what it does not save (EBS, public IPv4, Savings Plans).

#Five services, one exam question each

This lesson closes the chapter with five services that the exam treats as keyword answers. A question describes a situation in one sentence, and one service fits it far better than the others:

Two of them were met before: Outposts in lesson 1.2 and Batch in lesson 24.4. Here each service gets the full treatment: what it is, why and when, how it works, the exam keywords and the wrong answers that sit next to it.

#AWS Outposts: AWS inside your building

Recap from lesson 1.2. Local Zones, Wavelength Zones and Outposts all stretch a parent Region outwards; Outposts is the one that goes into your data center. Running instances survive a broken link to the Region, but management does not.

Many companies run a hybrid cloud: some systems in AWS, some on their own servers. That usually means two ways of working: the AWS console, CLI and APIs for one half, and a different set of tools, hardware and skills for the other. AWS Outposts removes the second half. AWS ships its own hardware to your site, installs it and runs it as part of an AWS Region, so you launch EC2 instances, EBS volumes or RDS databases on your premises with the same APIs, console and tools as in the cloud.

Why would anyone want AWS hardware at home instead of in a Region?

• Data residency: a law or a regulator says the data may not leave the country or the building, and there is no AWS Region in that country.
• Low latency to on-premises systems: a factory's machines, a hospital's scanners or a bank's core system must answer in a few milliseconds, and the nearest Region is too far.
• Local data processing: large amounts of data are created on site and are too expensive or too slow to send away first.
• Easier migration: move applications to AWS APIs first, on site, and to the Region later.
• Fully managed: AWS monitors, patches and replaces the hardware.

#Racks and servers

Outposts comes in two form factors:

In April 2025 AWS released second-generation Outposts racks: newer instance families (C7i, M7i, R7i at launch, C8i, M8i and R8i since February 2026), a separate network rack that tolerates network device failures, and local gateway settings you configure yourself. They support a subset of the first generation's services so far, so check the current list before you design. A single-rack second-generation Outpost followed in September 2026.

Pricing is a three-year term (all upfront, partial upfront or no upfront) for a configuration of servers and storage that you choose when ordering. You do not pay per instance-hour for the EC2 capacity on the Outpost: you bought the rack, so plan to use it.

#Who does what

#Service link and local gateway

Each Outpost is an extension of one Availability Zone of its parent Region. You create subnets of your VPC on it, and instances there talk privately to instances in the Region, inside the same VPC.

• The service link is the encrypted connection from the Outpost to the Region, over the internet or Direct Connect (lesson 22.5). Management traffic (launching, stopping, monitoring) and any traffic between the Outpost and the Region use it.
• The local gateway (racks) is a virtual router between the Outpost's subnets and your on-premises network. Traffic to the core banking system or the factory machines stays in the building. Outposts servers use a local network interface instead.

When the service link goes down, running instances keep running and local traffic keeps flowing, but you cannot launch, stop or change resources, and monitoring data waits. AWS therefore asks for a redundant service link, and you keep spare capacity already running.

#Outposts or another edge option?

#AWS Batch: jobs that start and end

A batch job has a start and an end, unlike a web server that runs continuously. Nightly report generation, genome alignment, risk simulations, video rendering and file conversions are batch jobs. Running them yourself means building a queue, a scheduler, an Auto Scaling fleet, retry logic and a way to turn everything off afterwards. AWS Batch is all of that as a managed service: you submit jobs, and Batch provisions the right amount of compute and memory, runs the jobs as containers and cleans up. Batch itself is free; you pay for the EC2 instances or Fargate tasks it runs.

Lesson 24.4 used Batch for HPC (array jobs on Spot, multi-node parallel jobs for MPI). This section covers the service itself.

#The four building blocks

1. Job definition

   A template for jobs: the container image (from ECR or a public registry), the command, vCPUs, memory and GPUs, environment variables, an IAM role for the job, a retry strategy and a timeout. Like an ECS task definition, versioned by revision.

2. Job queue

   Where submitted jobs wait. Each queue has a priority: when several queues share compute environments, the queue with the higher priority number is scheduled first. A queue maps to up to three compute environments, in order: try Spot first, then On-Demand. A fair-share scheduling policy can split capacity between teams.

3. Compute environment

   The capacity that runs jobs. Managed (Batch launches and terminates instances for you) or unmanaged (you run the ECS container instances). It has a minimum, desired and maximum vCPUs; with minimum 0 it scales to zero when no jobs are waiting.

4. Scheduler

   Batch's scheduler watches the queues, works out what fits where, scales the compute environments up, places the jobs, and scales down when the queues are empty. Jobs move through the states SUBMITTED → PENDING → RUNNABLE → STARTING → RUNNING → SUCCEEDED or FAILED.

#Compute environment types

The documentation now also lists ECS Managed Instances compute environments; the exam's options are EC2, Spot and Fargate.

#Job types and dependencies

• Single jobs: one container run.
• Array jobs: one submission creates 2 to 10,000 child jobs that share the definition; each reads its own index from AWS_BATCH_JOB_ARRAY_INDEX and picks its own input file. The standard way to run “thousands of independent tasks”.
• Dependencies: a job can depend on up to 20 other jobs and starts only after they succeed; array jobs can depend element by element (N_TO_N) or run their children one after another (SEQUENTIAL). Good enough for simple pipelines; for branching, waiting and error handling, let Step Functions submit the Batch jobs (lesson 15.7).
• Multi-node parallel jobs: one job spanning several EC2 instances for MPI, On-Demand only (lesson 24.4).

Jobs are submitted from the console, CLI or SDK, from an EventBridge rule or schedule (a file landing in S3, every night at 02:00), or from Step Functions. Slide p849's example is exactly that: an object lands in S3, a trigger submits a Batch job, the job runs on EC2 or Spot through ECS, and writes the processed object back to S3.

#Retries, timeouts and Spot interruptions

• Batch does not retry by itself. A retry strategy sets 1 to 10 attempts and can retry only for certain exit reasons, for example when the status reason starts with Host EC2 (the Spot instance was reclaimed) but not when the application crashed.
• Batch has no maximum job duration and no default timeout: a hung job runs, and bills, forever. Set attemptDurationSeconds (at least 60 seconds) in the job definition or at submit time; Batch then sends SIGTERM and, 30 seconds later, SIGKILL. A job stopped by its timeout is not retried. Jobs on Fargate should not expect to run more than about 14 days.
• A job stuck in RUNNABLE almost always means the compute environment cannot launch what it asks for: an instance type too small, maximum vCPUs too low, an EC2 quota reached, or no route from a private subnet to ECR, ECS and CloudWatch Logs (NAT gateway or VPC endpoints, lesson 22.2).

#Batch vs Lambda, and where Fargate fits

The notes give the classic rule: if processing takes 20 minutes or several hours, eliminate Lambda and choose Batch (or Fargate). The rule is right; the reasons need care.

So the real differentiators are time (15 minutes), memory (10 GB) and GPUs, and the shape of the work: an event that needs a quick answer vs a queue of jobs. Lesson 15.1 (Lambda basics) also describes Lambda durable functions (December 2025), which checkpoint and can wait up to a year between steps, and Lambda Managed Instances; neither changes the exam's answer for one long, heavy run.

And Fargate? An ECS task on Fargate also has no time limit, up to 16 vCPUs and 120 GB of memory, no GPUs. For one long task per event (an upload triggers one 40-minute conversion) an ECS task on Fargate started by EventBridge or Step Functions is as good as Batch. For many queued jobs with priorities, retries, Spot and dependencies, Batch is the scheduler you would otherwise have to build. Step Functions orchestrates; it does not run heavy code itself, so it is the glue that starts Lambda, Fargate or Batch.

Try the reasoning on your own workloads. The choices below are the ones exam questions use.

#Amazon AppFlow: SaaS data without integration code

Companies keep important data in SaaS applications: deals in Salesforce, orders in SAP, tickets in Zendesk or ServiceNow, messages in Slack, web traffic in Google Analytics, campaigns in Marketo. Analysts want it next to their own data in S3 or Redshift. Writing integration code means learning each vendor's API, handling OAuth tokens, paging, rate limits, retries and schema changes, and then maintaining the scripts forever. Amazon AppFlow is a fully managed, no-code integration service that moves data between SaaS applications and AWS in a few clicks.

#How a flow works

1. Connection

   You connect AppFlow to the SaaS account once (usually OAuth). AppFlow stores the credentials in Secrets Manager in your account. Dozens of connectors are built in, and a Custom Connector SDK (Python, Java) adds private APIs or other systems.

2. Source and destination

   Sources: Salesforce, SAP, Zendesk, Slack, ServiceNow, Google Analytics, Marketo, S3 and more. Destinations: S3, Redshift, Snowflake, EventBridge, and SaaS applications such as Salesforce or Zendesk. Flows can go both ways: from S3 back into Salesforce, for example.

3. Trigger

   On demand (a click or API call), on a schedule (every hour, every day; full or incremental transfers of only changed records), or on an event for sources that publish change events, such as a Salesforce record change.

4. Transform and deliver

   Filter records (only won deals), map and merge fields, mask or truncate sensitive fields, validate values (drop or stop on empty amounts), choose the file format (CSV, JSON, Parquet), partition by date, and register the data in the Glue Data Catalog.

Data is encrypted in transit (TLS) and at rest with a KMS key (AWS managed or your own). For SaaS applications that support it, the transfer goes over AWS PrivateLink instead of the public internet. You pay per flow run and per GB processed. Each run's result (success or failure) is published to EventBridge, so a failed flow can raise an alarm.

#AppFlow or another data service?

#AWS Amplify: full-stack apps for front-end developers

A front-end developer can build a React or Next.js interface, or an iOS, Android or Flutter app, but adding sign-in, a database, file uploads, an API, HTTPS hosting and automatic deployments usually means learning a dozen AWS services. AWS Amplify is a set of tools and services that lets web and mobile developers build, connect and deploy full-stack applications on AWS without deep cloud knowledge. It has two halves.

#Amplify Hosting

Amplify Hosting (the slide's “Amplify Console”, renamed) is Git-based CI/CD plus hosting:

• Connect a repository on GitHub, GitLab, Bitbucket or another Git provider, or upload a zip or deploy from S3.
• Every push to a connected branch builds and deploys the app; each branch can have its own environment (main → production, dev → staging).
• Pull request previews give each pull request its own temporary URL.
• Static sites and server-side rendering (SSR), notably Next.js, are served through a CloudFront-based CDN, with custom domains and free managed HTTPS certificates, redirects, password-protected branches and AWS WAF.
• A failed build never replaces the live site; earlier deployments can be redeployed.

#The backend: Gen 2

Amplify Gen 2 (generally available May 2024) is code-first: you describe the backend in TypeScript files in an amplify/ folder, and Amplify turns them into AWS resources with the CDK and CloudFormation underneath (lesson 25.1):

Each developer gets a personal cloud sandbox (npx ampx sandbox) that deploys their changes in seconds, and the same files deploy to every branch through Amplify Hosting. Front-end libraries (JavaScript for React, Angular, Vue and Next.js; Swift; Android; Flutter; React Native) and ready UI components (a sign-in form, for example) connect the app to the backend. The older Gen 1 used the Amplify CLI (amplify add auth) and Amplify Studio, which is what slide p853 shows; its categories (API with REST or GraphQL, publish-subscribe messaging, analytics, predictions) are now mostly plain CDK or AWS services added to the Gen 2 backend.

#Amplify or another way to host?

#Instance Scheduler on AWS: turn it off when nobody uses it

A development server that runs 24 hours a day, 7 days a week, runs 168 hours. If developers use it from 09:00 to 18:00 on five working days, that is 45 hours: the other 123 hours are pure waste. Instance Scheduler on AWS starts and stops resources on a schedule, based on their tags, and AWS says it can cut the cost of such instances by up to 70%.

It is an AWS Solution, not a service: AWS publishes a CloudFormation template (and the CDK source on GitHub) that you deploy into your own account. You own and pay for what it creates, about $13 a month in us-east-1 for the solution itself.

#How it works

• An EventBridge rule invokes a Lambda function on a fixed interval (every 5 minutes by default).
• The function reads schedules and periods from DynamoDB tables. A period has a begin time, end time and weekdays (and optional month days or months); a schedule groups periods with a time zone and options.
• It finds resources whose tag (by default Schedule) names that schedule, and starts or stops them as the period begins or ends.
• Supported resources: EC2 instances, EC2 Auto Scaling groups (it creates scheduled scaling actions), RDS instances, Aurora clusters, and since version 3.0 (June 2024) Neptune and DocumentDB clusters. EC2 instances can be hibernated instead of stopped.
• Cross-account and cross-Region: the hub stack deploys in one account; a remote stack in each other account gives it a role to assume. It acts on tagged resources in every Region you configure.
• Options worth knowing: enforced (also stop instances started by hand outside the period), retain running (do not stop an instance someone started before the period began), and an override to keep everything running or stopped during an incident.
• You manage schedules with the scheduler CLI, in DynamoDB, or as CloudFormation resources. The current release is 3.2 (October 2026); version 3.1 (December 2025) added tracking of resources by their tagging events.

#What it saves and what it does not

Stopping an EC2 instance stops the compute charge only:

• EBS volumes stay and keep billing per GB-month; so do snapshots.
• Public IPv4 addresses: an Elastic IP is still charged while the instance is stopped (all public IPv4 addresses cost about $0.005 an hour since February 2024).
• Instance store data is lost at stop; instances that depend on it are not candidates.
• Reserved Instances and Savings Plans are commitments paid every hour whether the instance runs or not (lesson 4.4). Stopping a fully covered instance saves nothing. Schedule the part of the fleet that runs On-Demand, and size commitments for what is always on.
• A stopped RDS instance still pays for storage and backups, and RDS starts it again automatically after 7 days (lesson 7.2); Aurora clusters behave the same way. The scheduler simply stops it again on its next run.

#Simpler and alternative ways

• EventBridge Scheduler with a cron expression and a time zone, calling ec2:StopInstances directly as a universal target, or starting an SSM Automation runbook such as AWS-StopEC2Instance (lesson 25.3). Fine for a handful of resources.
• Systems Manager Quick Setup has a Resource Scheduler for tagged EC2 instances.
• Auto Scaling scheduled actions: set the desired capacity to 0 at 18:00 and back at 09:00 for a group.
• For long breaks (weeks), snapshot and terminate, then restore.

#Which of the five? A keyword table

#What goes wrong

• Outposts launch fails with insufficient capacity: the Outpost holds only what you ordered. Order spare capacity, or keep burstable work in the Region.
• Nothing can be launched on the Outpost: the service link is down. Running workloads continue; build the link over two paths.
• Data left the country anyway: EBS snapshots of Outpost volumes went to the Region's S3. Use local snapshots on S3 on Outposts and deny copies with IAM policies or SCPs.
• Outposts server has no EBS: servers use instance storage only; choose a rack for EBS, S3 or RDS.
• Batch jobs stuck in RUNNABLE: instance type too small for the job's memory or GPUs, maximum vCPUs or EC2 quota too low, or no route to ECR from a private subnet.
• Batch jobs lost on Spot: no retry strategy. Set attempts and retry on Host EC2* reasons.
• A hung Batch job billed for a week: no timeout. Set attemptDurationSeconds.
• Lambda says “Task timed out after 900.00 seconds”: the work is longer than 15 minutes. Split it (SQS, Step Functions Map) or move it to Batch or Fargate.
• AppFlow flow fails after months of success: the SaaS user or OAuth token behind the connection was disabled. Alert on failed runs and reconnect.
• Duplicate rows from AppFlow: a full transfer runs every hour instead of an incremental one.
• Amplify build fails: the live site stays on the last good build; read the build log. Environment secrets belong in Amplify's secret settings, not in the repository.
• Instance Scheduler ignores a server: a typo in the tag value or the tag key, or the Region is not in the scheduler's configured Regions.
• Instance Scheduler saved less than expected: the instances were covered by a Savings Plan or RIs, or EBS and Elastic IPs dominate the bill.
• A dev database is running on day 8 of a holiday: RDS restarted it after 7 days and nothing stopped it again.

#These services in system design

• Hybrid with Outposts: keep regulated data and latency-sensitive systems on the Outpost, send anonymised data and elastic work to the parent Region, and use the same CloudFormation, IAM and monitoring for both. Treat the service link as critical infrastructure.
• Event-driven batch pipeline: S3 upload → EventBridge → Batch array job on Spot (with retries and a timeout) → results in S3 → Athena or QuickSight. Use Step Functions when the pipeline branches or needs human approval.
• Right-size the compute engine per step: Lambda for short glue, Fargate for long single tasks, Batch for queues of jobs, EC2 or ParallelCluster for tightly coupled HPC.
• SaaS into the lake: AppFlow (incremental, Parquet, Glue Data Catalog) → S3 → Athena or Redshift; scores computed in AWS flow back into Salesforce.
• Front-end-first products: Amplify Hosting for the web app, Gen 2 for Cognito, AppSync and S3, with per-branch environments; add more AWS services through the CDK when the app grows.
• Cost hygiene: Instance Scheduler for non-production, commitments (Savings Plans) for the always-on baseline, Batch and Spot scaling to zero for batch work. Cost tools to find the waste are in lesson 25.4; the Well-Architected cost optimisation pillar follows in lesson 26.1.

#Try it yourself

These commands use the AWS CLI v2 with made-up IDs. Outposts must be ordered first, so its commands only read. Batch, AppFlow and Amplify resources cost money only while they run or store data; delete them afterwards.

# Outposts: what is installed, and the local gateway to the on-premises network
aws outposts list-outposts --query 'Outposts[].[OutpostId,Name,SiteId,AvailabilityZone,LifeCycleStatus]' --output text
# op-0ab12cd34ef567890   dhaka-dc1   os-0123456789abcdef0   ap-south-1a   ACTIVE
aws ec2 describe-local-gateways --query 'LocalGateways[].[LocalGatewayId,OutpostArn,State]' --output text
# lgw-0a1b2c3d4e5f67890   arn:aws:outposts:ap-south-1:111122223333:outpost/op-0ab12cd34ef567890   available
aws outposts get-outpost-instance-types --outpost-id op-0ab12cd34ef567890 --query 'InstanceTypes[].InstanceType'
# [ "m5.xlarge", "m5.2xlarge", "r5.2xlarge" ]

# Batch: a Spot compute environment that scales to zero, a queue, a job definition with retries and a timeout
aws batch create-compute-environment --compute-environment-name sims-spot --type MANAGED \
  --compute-resources 'type=SPOT,allocationStrategy=SPOT_PRICE_CAPACITY_OPTIMIZED,minvCpus=0,maxvCpus=512,instanceTypes=optimal,subnets=subnet-0a1b2c3d4e5f67890,securityGroupIds=sg-0123456789abcdef0,instanceRole=ecsInstanceRole'
# (a second environment, sims-ondemand, is created the same way with type=EC2)
aws batch create-job-queue --job-queue-name sims --priority 10 \
  --compute-environment-order order=1,computeEnvironment=sims-spot order=2,computeEnvironment=sims-ondemand
aws batch register-job-definition --job-definition-name trial-sim --type container \
  --container-properties '{"image":"111122223333.dkr.ecr.ap-south-1.amazonaws.com/trial-sim:4","resourceRequirements":[{"type":"VCPU","value":"2"},{"type":"MEMORY","value":"4096"}],"command":["python","sim.py"]}' \
  --retry-strategy '{"attempts":3,"evaluateOnExit":[{"onStatusReason":"Host EC2*","action":"RETRY"},{"onReason":"*","action":"EXIT"}]}' \
  --timeout attemptDurationSeconds=7200

# One array job of 1,000 children; each reads AWS_BATCH_JOB_ARRAY_INDEX
aws batch submit-job --job-name trial-2026-11-01 --job-queue sims --job-definition trial-sim --array-properties size=1000
# { "jobName": "trial-2026-11-01", "jobId": "8f1e2d3c-4b5a-6978-8a9b-0c1d2e3f4a5b" }
aws batch describe-jobs --jobs 8f1e2d3c-4b5a-6978-8a9b-0c1d2e3f4a5b --query 'jobs[0].arrayProperties.statusSummary'
# { "RUNNABLE": 612, "RUNNING": 200, "SUCCEEDED": 186, "FAILED": 2 }

# AppFlow: start a flow on demand and check its runs (the flow and connection are created in the console or with create-flow)
aws appflow start-flow --flow-name salesforce-won-deals-hourly
# { "flowArn": "arn:aws:appflow:ap-south-1:111122223333:flow/salesforce-won-deals-hourly", "flowStatus": "Active", "executionId": "c0ffee00-1234-5678-9abc-def012345678" }
aws appflow describe-flow-execution-records --flow-name salesforce-won-deals-hourly \
  --query 'flowExecutions[0].[executionStatus,executionResult.recordsProcessed]' --output text
# Successful   3412

# Amplify Gen 2: a new project, a personal cloud sandbox, then hosting connected to Git
npm create amplify@latest        # adds the amplify/ folder (auth, data) to your app
npx ampx sandbox                 # deploys your own backend copy and watches for changes
# [Sandbox] Watching for file changes... amplify_outputs.json written
aws amplify create-app --name hilsa-booking --repository https://github.com/example/hilsa-booking \
  --access-token "$GITHUB_TOKEN" --platform WEB_COMPUTE
aws amplify create-branch --app-id d1a2b3c4e5f6g7 --branch-name main --stage PRODUCTION --enable-auto-build
aws amplify start-job --app-id d1a2b3c4e5f6g7 --branch-name main --job-type RELEASE

# Instance Scheduler: deploy the CloudFormation template from the solution page, then define the BD work week
scheduler-cli create-period --stack instance-scheduler --name bd-office-hours \
  --begintime 09:00 --endtime 18:00 --weekdays sun,mon-thu     # Instance Scheduler counts mon as day 0, so list Sunday separately
scheduler-cli create-schedule --stack instance-scheduler --name bd-office \
  --periods bd-office-hours --timezone Asia/Dhaka --enforced
aws ec2 create-tags --resources i-0a1b2c3d4e5f67890 --tags Key=Schedule,Value=bd-office
aws rds add-tags-to-resource --resource-name arn:aws:rds:ap-south-1:111122223333:db:dev-db \
  --tags Key=Schedule,Value=bd-office
scheduler-cli describe-schedule-usage --stack instance-scheduler --name bd-office
# Shows, per day, the periods the schedule keeps resources running and the billing hours (9 a day here)

#Summary

Key takeaways

• Outposts: AWS racks (42U) or 1U/2U servers (no longer sold to new customers) in your facility, run by AWS as an extension of a Region's AZ; same APIs and tools. You provide space, power, network and physical security. Service link to the parent Region (management); local gateway to on-premises. Link down → running workloads continue, no launches. Fixed capacity, three-year term. Second-generation racks since April 2025. Keywords: data residency, low latency to on-premises. Not Local Zones (city), Wavelength (5G), Snow (closed to new customers Nov 2025).
• Batch: managed batch jobs as containers; job definition → job queue (priority, up to three compute environments in order) → compute environment (managed EC2, Spot, Fargate, EKS; unmanaged); min 0 vCPUs → scale to zero; array jobs up to 10,000; dependencies; retry strategy (1–10 attempts); no maximum duration but an optional timeout (≥ 60 s, not retried). Batch itself is free.
• Batch vs Lambda: Lambda = events, 15 minutes, 10 GB memory, 10 GB /tmp, no GPU, containers up to 10 GB; Batch = queued jobs of any length and size, GPUs, Spot. Over 15 minutes → Batch or Fargate. Containers are not the differentiator.
• AppFlow: no-code, managed SaaS ↔ AWS data flows (Salesforce, SAP, Zendesk, Slack, ServiceNow → S3, Redshift, Snowflake, back to Salesforce); on demand, schedule (incremental), event; filter, map, mask, validate; KMS encryption, PrivateLink. Not Glue (code ETL), DMS (databases), DataSync (files), Kinesis (streams).
• Amplify: Hosting (Git CI/CD, branch environments, pull request previews, SSR/Next.js, custom domains on a CloudFront CDN) + Gen 2 backend in TypeScript (Cognito, AppSync + DynamoDB, S3, Lambda). Keywords: front-end/mobile developers, auth and storage for a React app. Not Beanstalk (server apps); App Runner closed to new customers April 2026.
• Instance Scheduler on AWS: an AWS Solution deployed by CloudFormation; EventBridge → Lambda → DynamoDB schedules; tag-driven (Schedule); EC2, ASG, RDS, Aurora, Neptune, DocumentDB; cross-account and cross-Region; up to 70% saving. Stopped instances still pay EBS, Elastic IPs; covered Savings Plans/RIs save nothing; RDS restarts after 7 days.

Self-check: Outposts, Batch, AppFlow, Amplify and Instance Scheduler30 questions