Exploring AWS Elastic Beanstalk, AWS Batch, and Serverless Application Repository

You've learned EC2 — the raw virtual machine you fully control. But not every team wants to manage servers, patch OS, configure load balancers, and tune Auto Scaling groups. That's where managed compute services come in.

These three services answer the same broad question: "How do I run my workload without managing infrastructure manually?" — but each answers it for a very different type of workload.

Practice Resources for AWS Solutions Architect Associate Exam

If you are preparing for the AWS Certified Solutions Architect — Associate exam and looking for topic-wise practice questions, structured learning paths, and study materials, check out the following resource repository:

👉 https://amitpnk.github.io/AWS-Solutions-Architect-Associate-Exam/

It includes categorized preparation content designed to help you strengthen your concepts and improve exam readiness effectively.

Elastic Beanstalk — Deploy Without the Plumbing

PaaS on AWS — upload your code and Beanstalk handles the rest

Elastic Beanstalk is AWS's Platform-as-a-Service (PaaS). You upload your application code — a ZIP file, a Docker image, or a WAR file — and Beanstalk automatically provisions and manages everything the app needs to run: EC2 instances, an Application Load Balancer, an Auto Scaling Group, security groups, and optionally an RDS database.

The key difference from raw EC2: you don't configure any of that infrastructure yourself. Beanstalk reads your app's requirements and sets it all up. You focus purely on writing code.

The analogy: Think of EC2 as buying land, bricks, and timber — you build the house yourself. Elastic Beanstalk is like hiring a construction company. You hand over the blueprints (your code), they build and maintain the house. But — and this is the key — you still own everything. You can go in and change any wall, any wire, any pipe. It's not a rented apartment; it's your house, built for you.

Free service: Elastic Beanstalk itself has no extra charge. You only pay for the underlying AWS resources it provisions — the EC2 instances, ALB, EBS volumes, etc. Beanstalk is just the orchestration layer on top.

What Beanstalk manages for you

Supported platforms (runtimes)

Beanstalk supports a wide range of application runtimes out of the box — you pick the one your app uses:

Environments — the two types

Deployment policies — the most tested Beanstalk topic

When you deploy a new version of your app, Beanstalk can do it in several ways. Each has different trade-offs between speed, availability, and cost.

SAA-C03 Exam Tips — Beanstalk Deployment Policies

• All at once= fastest, causes downtime — dev/test only.
• Rolling= no downtime but reduced capacity during deploy.
• Rolling with additional batch= no downtime, no capacity reduction — costs a bit more.
• Immutable= safest for production, new instances in a new ASG, old ones stay until new ones pass health checks — zero risk, easy rollback.
• Blue/Green= separate environment entirely, DNS swap via Route 53 weighted routing — instant rollback by swapping back. Blue/Green is NOT a native Beanstalk policy — it requires creating a new environment and swapping CNAMEs.

Beanstalk configuration files — .ebextensions

You can customise Beanstalk environments using .ebextensions — YAML or JSON config files stored in a folder called .ebextensions/ inside your application ZIP. These let you configure environment variables, install packages, run scripts, create AWS resources (like SQS queues or DynamoDB tables), and set up CloudWatch alarms — all automatically during deployment.

• Files must have a.configextension and be valid YAML or JSON
• Applied in alphabetical order — name files numerically (01-packages.config, 02-env.config) to control order
• Use to set environment variables, install system packages, run commands at deploy time
• Stored inside your application source bundle — tracked in version control

Cloning environments & lifecycle

• Clone environment — copy an existing Beanstalk environment exactly (useful for testing in a production-like setup)
• Application versions — Beanstalk keeps a history of your deployed versions. You can roll back to any previous version instantly
• Application version lifecycle policy — auto-delete old versions to stay within the 1000-version limit and save S3 storage cost
• Saved configurations — snapshot the full environment config and apply it to new environments

SAA-C03 Exam Tips — Elastic Beanstalk

• Beanstalk = PaaS, not serverless. It still uses EC2, ALB, and ASG under the hood — you just don't configure them manually. Beanstalk is FREE — you pay only for the underlying resources. You retain full access to the underlying EC2 instances (SSH in, modify config).
• Worker environment + SQS = decoupled background processing pattern.
• Immutable deployment = safest for production.
• Blue/Green = separate environment + Route 53 CNAME swap (not a native policy — it's a pattern). Use Beanstalk when the question says "developer doesn't want to manage infrastructure" or "PaaS" or "deploy code without configuring servers".

AWS Batch — Managed Batch Processing at Any Scale

Submit batch jobs and let AWS handle compute provisioning, queuing, and scaling automatically

A batch job is a piece of work that runs start-to-finish without user interaction — processing a file, running a simulation, rendering a video frame, training a model on a dataset. AWS Batch manages all the infrastructure for running these jobs at scale: it provisions the right amount of compute, queues jobs when compute is busy, runs them when ready, and shuts down compute when done.

The analogy: Imagine a post office that receives thousands of parcels (your jobs). Rather than hiring permanent staff (always-on EC2), it calls in temporary workers whenever the post piles up, processes everything efficiently, then sends them home. You just drop off parcels — the post office handles the rest.

The four key components

Batch vs Lambda — know when to use each

Cost optimisation with Spot Instances

This is the single most important Batch concept for the SAA-C03 exam. Batch jobs are perfect candidates for Spot Instances because:

• Batch jobs are typically fault-tolerant — if Spot is interrupted, Batch automatically retries the job
• You configure the retry count in the job definition — Batch handles interruptions transparently
• Managed compute environments can use a mix of On-Demand and Spot — e.g. "use Spot where possible, fall back to On-Demand"
• Spot Instances can save up to 90% on compute costs for batch workloads
• Set a max price per Spot instance to control costs; Batch only uses capacity below that price

SAA-C03 Exam Tips — AWS Batch

• Batch = the answer for "large-scale batch processing", "HPC", "jobs longer than 15 minutes", or "cost-effective parallel computing". Batch uses Docker containers under the hood (ECS or EKS).
• Managed compute environment = AWS provisions EC2 or Fargate for you.
• Spot Instances in Batch = massive cost savings, Batch handles retries on interruption automatically. Job queue priority — higher priority queues are processed first. Job dependencies — Job B can be set to wait for Job A's SUCCESS before starting. Batch is NOT serverless — it uses EC2 or Fargate.
• Fargate compute environment in Batch = closest to serverless (no EC2 to manage). Key distinction from Lambda: Batch for long-running, resource-heavy jobs. Lambda for short, event-driven functions.

Serverless Application Repository — App Store for Serverless

Browse, deploy, and share reusable serverless applications built with AWS SAM

The Serverless Application Repository (SAR) is a managed repository where developers publish and share reusable serverless applications — packaged as AWS SAM (Serverless Application Model) templates. Instead of building common patterns from scratch, you find a published application, click deploy, and it's running in your account in minutes.

The analogy: SAR is the App Store for serverless building blocks. Just like you don't build a maps app from scratch when Google Maps exists, you don't build a "thumbnail generator" or "Slack notifier" Lambda from scratch when someone's already published and tested one in SAR. Find it, install it, use it.

Two ways to use SAR

What a SAR application contains

• AWS SAM template (a superset of CloudFormation) that defines all resources — Lambda functions, API Gateway, DynamoDB tables, IAM roles, event sources
• Application code packaged and stored in S3 by SAR automatically
• Metadata — name, description, author, version, licence, readme
• Semantic versioning — applications are versioned; consumers pin to a specific version
• Required capabilities declared upfront — e.g. CAPABILITY_IAM if the app creates IAM roles, so deployers know what permissions they're granting

Private vs public applications

SAR vs CloudFormation StackSets: Both deploy infrastructure. The difference is intent — SAR is designed for reusable, shareable application components (serverless focused, SAM-based). CloudFormation StackSets deploys the same stack across multiple accounts/regions (governance focused). Use SAR to share serverless building blocks; use StackSets for organisation-wide infrastructure deployment.

SAA-C03 Exam Tips — Serverless Application Repository

SAR is lightly tested — you don't need deep knowledge. Key facts:

• SAR = managed repository for serverless apps packaged as AWS SAM templates.
• SAM = a superset of CloudFormation with shorthand for serverless resources (Lambda, API Gateway, DynamoDB). Deploying from SAR creates real AWS resources in your account — you own them.
• Private SAR applications = share reusable serverless patterns within an organisation.
• If the question asks "how does a platform team share approved Lambda-based components with developers?" → SAR with private applications. SAR is NOT a runtime — it deploys apps, it doesn't run them.

How to choose between the three

The exam will give you a scenario. Match the key words to the right service:

Quick reference — SAA-C03

The big picture:

• Elastic Beanstalk = "I have a web app, I don't want to manage servers."
• AWS Batch = "I have long-running jobs, I don't want to manage compute."
• SAR = "I have a reusable Lambda pattern, I want to share it." All three reduce operational burden — they differ only in what kind of workload they're designed for.