Building With Serverless on AWS Lambda: Architecture, Costs, Patterns, and Lessons from “Serverless Applications with AWS Lambda” by Thomas Jäger (Objectbay)

Why serverless—and why now?

In “Serverless Applications with AWS Lambda,” Thomas Jäger (Objectbay) offers a grounded walkthrough of what draws many engineering teams to the cloud’s serverless model: less infrastructure friction, more focus on business logic, and reliable scaling without operating your own servers. Jäger’s background is firmly rooted in the era of application-server-heavy web stacks—monolithic, rigid, and slow to move. He reminds us that frameworks come and go quickly; we’ve all ridden more than a few hype cycles into irrelevance. That’s precisely why serverless is attractive: it rethinks enduring problems like scaling, availability, and cost control.

From the DevJobs.at editorial vantage point, this talk is a pragmatic map for teams: What does “serverless” actually mean in the AWS world? Where does it fit? What building blocks and operational models work in practice? And which promises hold up when you put numbers beside them?

What “serverless” means in the AWS context

“Serverless” doesn’t mean servers vanish. It means we don’t manage them. That’s the crux in AWS: you pay only when your code really runs, and scaling is built in. Instead of provisioning, patching, and watching servers idle overnight, compute is delivered on demand.

It’s especially compelling when:

• user traffic varies widely,
• peaks are unpredictable,
• and time-to-value matters without front-loading infrastructure investments.

Jäger is careful to separate marketing claims. Some are hard to measure (“Faster Time to Market”), while others are straightforward and tangible (“Scales with Usage”). That differentiation runs through the talk and is a useful guide for teams planning their first serverless workloads.

AWS Lambda at a glance

Jäger frames AWS Lambda as “code executed in response to events.” An event occurs, and the function runs. Key points he calls out:

• Base image: Amazon Linux AMI (the underlying Amazon Machine Image is managed by AWS).
• Resources: configurable memory from 128 MB up to 10 GB; up to 6 vCPU cores—Lambda now has “real power.”
• Operating model: event-driven with no OS management required by the team.
• Platform value:
• Autoscaling and load balancing are handled for you.
• Error handling and security mechanisms are built in; you can define precise permissions.
• Logging and metrics are available by default.

Practically, that means you focus on building software—not on operating the underlying system.

Three execution models for Lambda

Jäger organizes the common ways of triggering Lambda into three buckets:

1. Push-based:

• Classic via REST—e.g., a POST call to an endpoint.
• The event comes from the outside; Lambda starts and processes the request.

1. Event-based:

• Triggers from other AWS services (e.g., notification services, S3 events) or from Kafka.
• Lambda reacts to events on the bus and acts as a functional consumer.

1. Poll-based:

• Stream or database changes, such as in Amazon DynamoDB or Amazon Kinesis.
• Lambda continuously reads, transforms in real time, or responds to entity changes.

This model diversity underpins patterns beyond simple web backends—think processing pipelines or integration jobs between systems.

API Gateway: the “window to the outside world”

Most backends need a clean, secure way to interact with clients. Jäger underscores Amazon API Gateway as just that: it creates, publishes, and secures APIs (REST, WebSockets) and acts as the doorway through which requests flow into Lambdas and other services.

Without API Gateway, serverless web development feels incomplete. With it, you get versioned, protected entry points that Lambda slots into naturally.

A reference web architecture with S3, CloudFront, API Gateway, and Lambda

Jäger outlines the serverless web setup Objectbay uses most frequently:

• Static content (HTML, JavaScript, CSS, images) is stored in Amazon S3.
• Delivery is handled by a CDN—Amazon CloudFront—so users get content fast on phones and laptops alike.
• For backend functionality and data access, Amazon API Gateway forwards requests to AWS Lambda.
• Lambda interacts behind the scenes with databases and other services—and scales “theoretically to infinity.”

The notable design here is how cleanly this separates scaling from state. Static assets are eminently cacheable, and dynamic compute scales out elastically. From DevJobs.at’s view, the charm is exactly this: there’s hardly a peak you can’t absorb—without maintaining a fleet of servers.

Event-driven patterns: messaging, storage, time, and monitoring

Jäger shares several practical trigger patterns that extend beyond the web front-end:

• Messaging-driven:
• Example: a CRM creates a new customer and emits an event. Multiple services “listen,” including a Lambda that provisions environments or performs customer-specific setup tasks.
• Storage-driven:
• Example: a photographer uploads hundreds of images and videos to S3. The successful upload is the event. A Lambda starts and performs transformations—copying, resizing, preparing formats.
• Time-based:
• Using Amazon CloudWatch, recurring jobs can run on a schedule (e.g., daily at 2 AM). Typical tasks include cleaning log files and generating daily reports.
• Monitoring- and anomaly-driven:
• CloudWatch monitors services. If it detects a service that’s “not feeling well,” that event can trigger a Lambda to attempt a fix.

The unifying pattern: “Event –> Function –> Action.” Teams can apply the same mental model regardless of whether the impulse comes from users, data, the clock, or monitoring.

Orchestration: Step Functions bring order to many Lambdas

Having many small Lambdas is powerful—but can become chaotic. Jäger says it plainly: too many of these things “make it a bit confusing.” The answer is AWS Step Functions to coordinate workflows.

The example in the talk: an image-processing state machine.

• Start: an image is uploaded—a Lambda starts the workflow.
• Step 1: extract image metadata.
• Step 2: based on those metadata, branch: continue processing for formats like JPEG/PNG; treat others separately.
• Parallelism: launch multiple Lambdas in parallel.
• Error paths: unsupported formats produce an error (“Not supporting image type”) that the workflow can handle explicitly.

The point is clarity: Step Functions give you a visual, traceable orchestration of sub-steps, including error handling. For teams running many granular functions, this is a decisive lever against implicit complexity.

The cost model: requests and duration drive the bill

Jäger boils costs down to two factors:

• Number of requests: how often a Lambda is triggered.
• Duration: how long it runs (measured in milliseconds), multiplied by configured memory (as GB-seconds).

He highlights the following:

• One million requests cost $0.20.
• Compute duration is billed per GB-second. Example: a 512 MB Lambda consumes 0.5 GB-seconds per second of runtime.
• Free tier:
• 1,000,000 requests free.
• 400,000 GB-seconds free.

His general take on pricing: “Fundamentally inexpensive.” It’s hard to reconstruct similar elasticity and performance at the same cost with a fixed server estate.

Sample calculation from the slides

• Configuration: 512 MB memory
• Executions: 3,000,000 per month
• Duration: 1 second each
• Cost: $19

The main takeaway: for reliable processing of millions of tasks, this cost level is difficult to beat with fixed servers—especially when load is bursty.

Real-world example: one million uploads, parallel Lambdas, clear costs

The most concrete part of the talk is a project example:

• Workload: 1,000,000 image/video uploads per month into S3.
• Execution: for each upload, a 512 MB Lambda starts; average runtime 5 seconds.
• Fronting: Amazon API Gateway with about 1,000,000 requests, priced at $38 per month in Jäger’s configuration (with room for tuning).

The comparison point is a Spring Boot application running on servers:

• To be resilient, you need multiple instances.
• Servers cost money day and night—even when no uploads happen.
• Nightly shutdowns risk early-morning upload failures.
• In this example, monthly costs land “around $117–$120”—and scale up “massively” with more load.

Two structural insights from this comparison:

1. With Lambda, parallelism is native: 100 simultaneous uploads yield 100 simultaneous Lambdas, without pre-planning.
2. Each Lambda task has its own memory budget (e.g., 512 MB). On a shared server, parallel tasks compete for resources (e.g., 16 GB RAM across processes), which degrades throughput and responsiveness as concurrency rises.

Or, as Jäger emphasizes: on the Lambda side, the price barely changes with load; on the server side, it changes “massively”—because you fund more server power and redundancy.

Which big promises hold up?

Jäger closes by weighing common claims against reality:

• “No Service to Manage”: True. OS management and infrastructure burden are gone.
• “Pay what you need”: True. You’re billed for actual usage—requests and runtime.
• “Faster Time to Market”: Ambiguous. Standing up Lambda, Step Functions, and surrounding pieces takes learning and setup. Long-term gains are plausible; short-term is hard to measure.
• “Scales with Usage”: True. This removes one of the biggest pain points.
• “Availability”: Different. Lambdas aren’t “24/7” in the classical sense—they’re “there exactly when needed.” It’s a shift in the operating model.
• “Better Focus”: Partly. You can focus more on business logic, yet you still need to engage with serverless architecture—especially orchestration and observability.

This honest assessment is what makes the talk valuable: it balances enthusiasm with grounded experience.

Practical guardrails for engineering teams

From our notes on the session, here are pragmatic starting points:

• Begin with a clear event-driven use case.
• S3 uploads plus image/video transformations are a clean fit—exactly the scenario Lambda excels at.
• Alternatively, CRM events triggering follow-up actions (e.g., provisioning), as Jäger outlines.
• Choose triggers deliberately across the three models:
• Direct via REST (API Gateway)
• Event bus (e.g., notification services, Kafka)
• Stream-/database-driven (DynamoDB, Kinesis)
• Bring Step Functions in early when:
• multiple sub-steps exist,
• error paths matter,
• parallel processing is beneficial.
• Nail the external boundary:
• Static assets on S3
• Delivery via CloudFront
• Ingress via API Gateway
• Keep Lambdas focused with clear responsibilities
• Plan for monitoring and reaction:
• Use CloudWatch to observe services
• Trigger Lambdas on anomalies for corrective actions
• Validate costs with realistic parameters:
• Monthly requests, average duration, memory configuration
• Account for the free tier (1M requests, 400k GB-seconds)
• Use example calculations like “3M invocations, 512 MB, 1 second ≈ $19” to build intuition
• Keep architecture tidy:
• Too many uncoordinated Lambdas cause confusion—Step Functions and naming/packaging conventions help.
• Model permissions explicitly—security is integral to the approach.

A realistic expectation set

Jäger’s closing advice is straightforward: “Give it a try.” The AWS calculator helps you explore scenarios, and the free tier lowers the barrier to entry. From DevJobs.at’s perspective, set expectations like this:

• Serverless shines where workloads are spiky or where parallelism is key (e.g., mass uploads, event processing).
• The biggest wins are in operations and scaling—not necessarily in the first development sprint. Budget for learning and orchestration.
• Availability is different: think “available on demand,” not “running continuously.” That affects architecture and monitoring choices.
• Economically, Lambda is hard to beat when you need to process millions of short-lived tasks reliably and in parallel.

Conclusion: A solid, scalable foundation for modern workloads

“Serverless Applications with AWS Lambda” by Thomas Jäger (Objectbay) gives teams exactly what they need: a clear tour of architecture components, trigger models, orchestration, and costs. No overhype—just real numbers and an honest read on the major claims.

For many use cases—especially web workloads with S3/CloudFront/API Gateway/Lambda—the pattern is mature. Messaging-, storage-, and time-based triggers fit naturally, and Step Functions provide order for more complex flows. If you need to parallelize millions of tasks, you get performance, cost control, and operational calm in one package.

The next step is low friction: frame a small, well-scoped event case and run it through the AWS calculator. Let the data guide the rest—and that’s a core strength of serverless.

• 

  

  Microservices for Front Ends

  Michael Eder von Objectbay spricht in seinem devjobs.at TechTalk über einen Ansatz, wie man die gängige Architektur der Microservices auch im Front End anwenden könnte.

  Watch now
• 

  

  Die Wahl der richtigen Software Architektur

  Alexander Knapp von Objectbay beschäftigt sich in seinem devjobs.at TechTalk mit der Herangehensweise, wie man aus einer Vielzahl an verschiedenen Software Architekturen die passende auswählt.

  Watch now
• 

  

  Mutation Testing

  Alexander Knapp von Objectbay widmet sich in seinem devjobs.at TechTalk dem Thema Mutation Testing – was es ist und wie jedes Software Projekt davon profitieren kann.

  Watch now

• 

  

  Alexander Knapp, Full Stack Software Engineer bei Objectbay

  Alexander Knapp von Objectbay schildert im Interview seinen Werdegang bis hin zu seiner aktuellen Rolle im Full Stack Engineering und was seiner Meinung nach für Beginner wichtig ist.

  Watch now