Serverless 101: Deploying your first AWS Lambda function

Serverless sounds magical: you write a little piece of code, point it at an event, and the cloud runs it for you. In reality, it’s simple plumbing with a tiny bit of ceremony up front. This guide walks you through deploying a “Hello, World” AWS Lambda function, explains the choices you’ll make, and points out a few modern considerations so your first serverless step doesn’t trip you up.

Why this matters

• Lambda removes the need to manage servers for many kinds of workloads: web endpoints, scheduled tasks, S3 triggers and more. AWS provides a step‑by‑step console tutorial for beginners that makes a minimal Lambda deployment approachable. (aws.amazon.com)
• Lambda supports both traditional ZIP-based code deployments and container images, so you can start tiny or bring a full container if your runtime needs it. (docs.aws.amazon.com)
• The execution environment and runtime choices affect cold starts, memory use, and cost; Lambda functions also have a maximum duration for a single invocation. We’ll touch on those tradeoffs. (docs.aws.amazon.com)

What you need before you begin

• An AWS account and access to the AWS Management Console (or the AWS CLI if you prefer working locally).
• A short snippet of code (we’ll use Node.js for the example below).
• Basic familiarity with IAM roles (you’ll attach a minimal role so Lambda can write logs).

Step 1 — Pick where to start: Console vs CLI vs Container For your first function, the Console is fastest: it scaffolds the role and provides a simple editor and test runner. If you prefer local development, AWS SAM or the AWS CLI are the next steps. If you expect heavy dependencies or native libraries, you can package as a container image and push to Amazon ECR — Lambda supports container images as a deployment package type. (docs.aws.amazon.com)

Small tip: when creating a function you’ll choose an architecture (x86_64 or arm64). Arm64 (AWS Graviton) often gives better cost-to-performance for many runtimes and workloads in independent benchmarks — so it’s worth trying if you care about costs or latency. (techradar.com)

Step 2 — Create the function (Console quick steps)

1. Open the Lambda console and choose “Create function.”
2. Choose “Author from scratch.” Enter a name (e.g., hello-lambda), pick a runtime (Node.js or Python are beginner-friendly), and choose or create a basic execution role. The console can create a role with the AWSLambdaBasicExecutionRole policy so your function can send logs to CloudWatch. (aws.amazon.com)
3. Click Create. The console will create the function and display a code editor.

Step 3 — The smallest function (Node.js example) Paste this into the editor (index.js or app.js depending on the template):

exports.handler = async (event) => {
  const name = event?.name || 'world';
  return {
    statusCode: 200,
    body: JSON.stringify({ message: `Hello, ${name}!` })
  };
};

Save, then use the Test button in the console to create a sample event:

{ "name": "Ada" }

Invoke the test and you should see the response and log output in the console.

Step 4 — Understand the role and logs

• The minimal “Lambda basic execution” role allows Lambda to write logs to CloudWatch. That’s usually enough for a first function.
• Open CloudWatch Logs to inspect execution output and any stack traces if the function errors. CloudWatch is where you’ll do most of your troubleshooting early on.

Key settings to review

• Memory and CPU: CPU scales with memory allocation. If a function runs longer than you expect, try increasing memory — it often speeds up the function and can reduce overall cost if it shortens runtime.
• Timeout: Lambda enforces a max duration per invocation (up to the service limit). For typical requests, a few seconds is fine; long-running tasks may require other patterns. (docs.aws.amazon.com)
• Architecture: choose arm64 for potential cost/latency benefits on supported runtimes; otherwise stick to x86_64. (techradar.com)

Alternatives: ZIP vs Container images

• ZIP (.zip) packages are simplest for interpreted languages (Node.js, Python) or small compiled artifacts.
• Container images let you package complex dependencies or custom runtimes — you build an image, push to ECR, and point the Lambda function to that image. AWS provides base images to simplify this. Use container images if you need specific OS-level libraries or very large dependency trees. (docs.aws.amazon.com)

Modern context — what’s new and useful AWS regularly adds features that matter even for beginners:

• Lambda now supports newer runtimes and language versions, and has introduced features like durable functions for long-running multi-step workflows and other improvements that reduce the need for external orchestration in some cases. These updates change what you might choose as you grow beyond the “first function.” (aws.amazon.com)
• Benchmarks and community experience increasingly show Graviton (arm64) instances performing better cost‑per‑operation in many scenarios — a good option to experiment with once your function works. (techradar.com)

Debugging checklist (quick)

• Permission error? Confirm the function’s role has the right managed policies.
• No logs? Check CloudWatch and confirm the role can write logs.
• Timeout? Increase the timeout a little, or optimize the handler for cold-start cost (keep initialization light).
• Dependency errors in containers? Ensure the container image is compatible with Lambda’s Linux execution environment and that you built for the right architecture. (docs.aws.amazon.com)

A few practical UX notes

• The console is great for learning, but for repeated deployments use infrastructure-as-code (CloudFormation/SAM/Terraform) so your setup is reproducible.
• Watch cold starts the first few times a function runs, especially if your initialization pulls large dependencies. For production, warmers, provisioned concurrency, or smaller initializations can help — but they add cost and complexity.
• Think in events: Lambda shines as a glue layer reacting to S3 uploads, scheduled events, or API Gateway calls. Start with one trigger and keep the function’s responsibilities narrow.

Wrap up (no extra steps suggested) You’ve just deployed a tiny piece of serverless code and exercised the core loop: create, provide minimal permissions, write a handler, test, and inspect logs. From here, the path forks — you can iterate locally with SAM, swap to a container image, or explore event-driven patterns — but the basic Lambda lifecycle you practiced is the same across those options. Official AWS tutorials and docs are excellent next reads if you want deeper reference material for each path. (aws.amazon.com)

References (selected)

• AWS “Run a Serverless ‘Hello, World!’” tutorial (console walk‑through). (aws.amazon.com)
• AWS Lambda documentation: creating functions, runtimes and execution environment overview. (docs.aws.amazon.com)
• AWS docs on creating Lambda functions from container images. (docs.aws.amazon.com)
• AWS Compute blog: recent serverless feature highlights (durable functions, runtime updates, etc.). (aws.amazon.com)
• Independent benchmarks and coverage on Arm64/Graviton performance for Lambda. (techradar.com)

Finished your first function? Think of it like learning a new song on guitar: once you know the basic chord progression (create → attach role → handler → test → logs), you can jam in different styles — tiny acoustic bits (ZIP) or full-band arrangements (containers and advanced runtimes).