SERVERLESS RUBY
Build and Deploy AWS Lambda Functions from Scratch

Chapter 2: The Core AWS Services You'll Use

Chapter 2

Just Enough AWS to Get the Job Done

Let's be honest, AWS is a jungle.

There are over 200 services with names like Glue, Fargate, CloudTrail, CodePipeline, Elastic Beanstalk, and others that sound like made-up startup names. You don't need to know all of them.

You need just enough to build powerful, production-ready serverless systems in Ruby. That's what we'll focus on here.

🧠 The Big Picture

Here's how to think about AWS in the context of this guide:

Role AWS Service
Runs your code Lambda
Stores your data/files S3
Triggers events SQS / SNS / Kinesis
Routes HTTP requests API Gateway
Gives permissions IAM
Stores container images ECR

Let's break down the services you'll actually use and understand what role they play.

🦾 AWS Lambda – The Worker

What it does: Runs your code on-demand without servers.

You give Lambda your Ruby function (wrapped in a Docker image), and AWS handles everything else. You define the "trigger" and what happens when it runs. It scales automatically and can run thousands of invocations in parallel if needed.

💡 You only pay for the time your function is actually running.

Use it for:

  • Processing uploaded files
  • Responding to events from other AWS services
  • Crunching heavy data or images
  • Receiving requests from your Rails app

📦 Amazon S3 – The File Drop

What it does: Stores and retrieves files at internet scale.

Think of S3 as a folder in the cloud where other systems can drop files and trigger downstream events.

We'll use S3 to:

  • Receive large CSV files
  • Trigger a Lambda when a new file is uploaded
  • Store Lambda output (like reports or transformed data)

S3 events can trigger Lambda functions indirectly via SNS or SQS (which we'll get to shortly).

📣 Amazon SNS – The Broadcaster

What it does: Publishes messages to multiple listeners.

SNS is a pub/sub service: one publisher, many subscribers. If S3 drops a file and publishes a message to SNS, you can have multiple systems receive that message, SQS, email, Lambda, etc.

We'll use SNS to:

  • Relay S3 events to an SQS queue
  • Fan out events to multiple systems from a single trigger
  • Send notification-like messages between services

💡 SNS doesn't queue messages, it just blasts them out. For actual message storage and retry logic, you'll want...

📬 Amazon SQS – The Queue

What it does: Stores messages until they're processed.

SQS is the backbone of reliable messaging. Think of it like Sidekiq, but without Redis. You can connect SQS to Lambda using an event source mapping, so every message in the queue invokes the Lambda function once.

Use SQS when:

  • You want decoupled, retryable processing
  • Your Rails app sends a message, and Lambda handles it
  • You need to process things asynchronously in batches

SQS + Lambda is one of the most powerful combos in serverless Ruby architecture.

🔀 Amazon Kinesis – The Stream

What it does: Handles high-volume, real-time event streams.

Kinesis is like a firehose of data. You send events (e.g. analytics, logs, data changes) into a stream, and one or more Lambda functions process them in near real time.

We'll use Kinesis for:

  • Real-time ingestion
  • Ordered or batched event processing
  • Scenarios where SNS/SQS isn't fast or parallel enough

💡 You usually don't need Kinesis unless you're working with lots of real-time data.

🌐 API Gateway – The HTTP Doorway

What it does: Routes HTTP requests to your Lambda functions.

API Gateway turns your Lambda into a fully-functioning REST API (or WebSocket endpoint). You define a route (/process), hook it to a Lambda function, and you've got an endpoint ready to call from Rails, JavaScript, or anywhere else.

Use it when:

  • You want your Lambda function to receive a direct HTTP request
  • You're building an API powered by serverless functions
  • Your Rails app needs a synchronous result back from Lambda

👮 IAM – The Security Guard

What it does: Grants and restricts permissions.

Every Lambda function and AWS service needs permissions, and that's what IAM (Identity and Access Management) handles.

You'll create IAM roles that define:

  • What your Lambda function can access (e.g. S3, SQS)
  • Who can invoke your Lambda function
  • What Terraform and your deployment tools can do

We'll give you copy-paste-ready roles and policies you can tweak safely.

🐳 ECR – The Image Warehouse

What it does: Hosts your Docker images.

AWS Lambda with the container runtime uses Docker images, and ECR (Elastic Container Registry) is where you store those images.

In this guide, you'll:

  • Build your Ruby Lambda into a Docker image
  • Push it to ECR
  • Point Lambda to that image so it knows what to run

ECR is just GitHub for Docker containers, but hosted inside AWS.

Bringing It Together

Here's a common setup you'll build:

  1. A user uploads a CSV to S3
  2. S3 triggers a message via SNS
  3. That message is sent to SQS
  4. SQS triggers a Lambda to process the file
  5. Lambda transforms the data and sends it to your Rails app
  6. All permissions are handled via IAM
  7. The function is packaged as a Docker image in ECR

Welcome to modern Ruby serverless architecture.

Up Next

Now that you understand the tools, it's time to build your own Lambda function.

In the next chapter, we'll:

  • Set up a reusable Lambda function project in Ruby
  • Write a basic service
  • Package it with Docker
  • Understand the file structure you'll use across all your projects

Let's write some code.

Chapter 2