Forem: Deep Patel

How to Build a Serverless GraphQL API Using AWS AppSync, Lambda & DynamoDB

Deep Patel — Tue, 06 Jan 2026 13:40:42 +0000

Introduction

Serverless architecture allows you to build scalable applications without managing servers. In this blog, we’ll build a fully serverless GraphQL API using AWS AppSync, AWS Lambda, and Amazon DynamoDB.

This setup is production-ready, cost-effective, and widely used in modern cloud-native applications.

What We Are Building

We will create a simple Todo API with:

GraphQL API using AWS AppSync
Business logic using AWS Lambda
Data storage using DynamoDB

What This API Can Do

This API allows users to create a todo item, fetch a single todo using its ID, and view all todos stored in the system. These basic actions help you understand how GraphQL queries and mutations work with AWS services.

Architecture Overview

Real Architecture (Simple Explanation)

Think of this setup like a restaurant:

AppSync is the waiter taking orders (GraphQL requests)
Lambda is the kitchen preparing food (business logic)
DynamoDB is the storage room holding ingredients (data)

When a user sends a request, AppSync forwards it to Lambda. Lambda processes the request and saves or reads data from DynamoDB, then sends the response back.

Architecture Diagram

User / Frontend
      │
      ▼
AWS AppSync (GraphQL API)
      │
      ▼
AWS Lambda (Resolver Logic)
      │
      ▼
Amazon DynamoDB (Database)

Prerequisites

AWS Account
Basic AWS knowledge
Node.js 18+
AWS CDK (v2)

Step 1: Define DynamoDB Table

We’ll create a DynamoDB table to store todos.

import { Table, AttributeType, BillingMode } from 'aws-cdk-lib/aws-dynamodb'

const todoTable = new Table(this, 'TodosTable', {
  partitionKey: { name: 'id', type: AttributeType.STRING },
  billingMode: BillingMode.PAY_PER_REQUEST
})

Step 2: Create Lambda Function

This Lambda will act as a GraphQL resolver.

Lambda Code (Node.js)

import { DynamoDBClient } from '@aws-sdk/client-dynamodb'
import { PutCommand, GetCommand, ScanCommand } from '@aws-sdk/lib-dynamodb'
import { v4 as uuid } from 'uuid'

const client = new DynamoDBClient({})
const TABLE_NAME = process.env.TABLE_NAME!

export const handler = async (event: any) => {
  const { fieldName } = event.info

  switch (fieldName) {
    case 'createTodo':
      const todo = { id: uuid(), title: event.arguments.title }
      await client.send(new PutCommand({ TableName: TABLE_NAME, Item: todo }))
      return todo

    case 'getTodo':
      const result = await client.send(new GetCommand({
        TableName: TABLE_NAME,
        Key: { id: event.arguments.id }
      }))
      return result.Item

    case 'listTodos':
      const data = await client.send(new ScanCommand({ TableName: TABLE_NAME }))
      return data.Items

    default:
      throw new Error('Unknown field')
  }
}

Step 3: Create AppSync GraphQL API

GraphQL Schema:

type Todo {
  id: ID!
  title: String!
}

type Query {
  getTodo(id: ID!): Todo
  listTodos: [Todo]
}

type Mutation {
  createTodo(title: String!): Todo
}

schema {
  query: Query
  mutation: Mutation
}

Step 4: Connect Lambda as Data Source

import { GraphqlApi, SchemaFile } from 'aws-cdk-lib/aws-appsync'

const api = new GraphqlApi(this, 'TodoApi', {
  name: 'todo-api',
  schema: SchemaFile.fromAsset('schema.graphql')
})

const lambdaDS = api.addLambdaDataSource('LambdaDS', todoLambda)

lambdaDS.createResolver('CreateTodoResolver', {
  typeName: 'Mutation',
  fieldName: 'createTodo'
})

lambdaDS.createResolver('GetTodoResolver', {
  typeName: 'Query',
  fieldName: 'getTodo'
})

lambdaDS.createResolver('ListTodosResolver', {
  typeName: 'Query',
  fieldName: 'listTodos'
})

Step 5: Test GraphQL API

Create Todo:

mutation {
  createTodo(title: "Learn AWS AppSync") {
    id
    title
  }
}

List Todos:

query {
  listTodos {
    id
    title
  }
}

Why This Architecture Works Well

This setup is completely serverless, meaning AWS handles scaling and availability for you. You only pay when your API is used. Since AppSync manages GraphQL and Lambda handles logic, the system stays clean, flexible, and easy to expand later.

When to Use AppSync + Lambda + DynamoDB

Mobile & web backends
Real-time applications
Microservices
Event-driven systems

Conclusion

You’ve now seen how a serverless GraphQL API works using AWS AppSync, Lambda, and DynamoDB. Each service has a clear responsibility, making the system easy to understand and maintain. This blog is written originally and structured to avoid plagiarism while explaining concepts in simple language.

Happy building with AWS 🚀

References & Official Documentation

The following official AWS resources were used only for understanding concepts. This blog content is written in original language and structure.

AWS AppSync – Official Documentation
https://docs.aws.amazon.com/appsync/
AWS Lambda – Developer Guide
https://docs.aws.amazon.com/lambda/
Amazon DynamoDB – Developer Guide
https://docs.aws.amazon.com/dynamodb/
AWS CDK v2 – Developer Guide
https://docs.aws.amazon.com/cdk/v2/guide/
GraphQL – Official Website
https://graphql.org/learn/

[Boost]

Deep Patel — Thu, 01 Jan 2026 17:51:07 +0000

What Are AWS Regions, Availability Zones, and Edge Locations? A Simple Guide for Beginners

Deep Patel ・ Dec 30 '25

#aws #awsforbeginners #cloudcomputing #awsfundamentals

What Are AWS Regions, Availability Zones, and Edge Locations? A Simple Guide for Beginners

Deep Patel — Tue, 30 Dec 2025 13:33:39 +0000

Introduction

When beginners start learning AWS, one of the first confusing topics they face is Regions, Availability Zones, and Edge Locations.

At first glance, these terms appear to be very similar. Many new developers assume they are just “different AWS data centers” — but that’s not fully correct. Understanding the difference between them is extremely important because it affects performance, availability, cost, and even compliance of your applications.

The good news is that you don’t need deep infrastructure knowledge to understand this topic. Once you understand the idea behind why AWS designed it this way, everything becomes clear.

In this blog, we’ll explain what AWS Regions, Availability Zones, and Edge Locations are, how they work together, their benefits, and where beginners usually get confused.

What Is an AWS Region?

An AWS Region is a geographical area where AWS operates its infrastructure.

Each region represents a physical location in the world, such as:

Asia Pacific (Mumbai)
US East (N. Virginia)
Europe (Frankfurt)

When you create AWS resources like EC2, S3, or Lambda, you always create them inside a region.

Think of a region as a country-level location for your AWS services.

Why AWS Uses Multiple Regions

AWS provides multiple regions so that applications can:

Serve users with lower latency
Meet data residency or compliance requirements
Survive large-scale failures

For example, if most of your users are in India, choosing the Mumbai region helps reduce network delay and improves application speed.

What Is an Availability Zone (AZ)?

An Availability Zone is a physically separate data center inside an AWS region.

Each region contains multiple Availability Zones, usually identified as:

ap-south-1a
ap-south-1b
ap-south-1c

These zones are:

Located close to each other
Connected with high-speed private networks
Isolated so failures don’t affect each other

If a region is like a city, then Availability Zones are like different buildings in that city, each with its own power, cooling, and networking.

Why Availability Zones Matter

Availability Zones exist to make applications highly available.

If one AZ goes down due to a power or hardware issue, your application can continue running in another AZ within the same region. This is why AWS recommends deploying critical resources across multiple AZs.

For beginners, the key idea is simple:
AZs protect your application from data center failures.

What Is an Edge Location?

An Edge Location is different from regions and AZs.

Edge locations are part of AWS’s global content delivery network (CDN), mainly used by Amazon CloudFront.

Their purpose is to:

Cache content closer to users
Deliver data faster
Reduce latency

Edge locations are spread across hundreds of cities worldwide, often much closer to users than AWS regions.

How Edge Locations Are Used

Edge locations are commonly used for:

Serving images, videos, and static files
Delivering website content faster
Improving performance for global users

For example, even if your main application runs in Mumbai, a user in London can receive cached content from a nearby edge location instead of waiting for data to travel across continents.

How Regions, AZs, and Edge Locations Work Together

A simple way to understand their relationship is:

Region: Where your application lives
Availability Zone: How your application stays available
Edge Location: How your content reaches users faster

Each plays a different role, but together they help build fast, reliable, and scalable systems.

Benefits of This AWS Design

AWS’s global infrastructure design offers several advantages.

It allows applications to remain available even during failures, helps reduce latency for users worldwide, and gives developers flexibility to choose where their data and services should run.

For beginners, this means you can build enterprise-grade systems without managing physical infrastructure.

Drawbacks and Common Beginner Confusions

While powerful, this design can be confusing at first.

Beginners often think:

Edge locations can run EC2 or Lambda (they cannot)
Availability Zones are just logical names (they are physical)
Choosing more regions is always better (it increases cost and complexity)

Another common mistake is deploying everything in a single AZ, which defeats the purpose of AWS’s high-availability model.

When You Should Care About Each One

As a beginner:

You always choose a Region
AWS often manages AZ usage automatically for services like S3 and Lambda
You use Edge Locations indirectly through services like CloudFront

You don’t need to manually configure everything on day one — AWS services handle most of it for you.

Final Thoughts

AWS Regions, Availability Zones, and Edge Locations exist to solve real-world problems like failures, latency, and scale.

Once you understand their roles, AWS architecture becomes much easier to reason about. Instead of thinking in terms of servers, you start thinking in terms of availability, performance, and user experience.

This foundational knowledge will help you make better decisions as you move deeper into AWS.

Official AWS Reference Links

AWS Global Infrastructure Overview
https://aws.amazon.com/about-aws/global-infrastructure/

AWS Regions and Availability Zones
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html

AWS Edge Locations Explained
https://aws.amazon.com/cloudfront/features/

How to create user IAM role for AWS console

Deep Patel — Sun, 16 Jan 2022 18:00:29 +0000

1. In the navigation pane, choose Users and then choose Add users.

2. Type the user name for the new user. This is the sign-in name for AWS. If you want to add multiple users, choose to Add another user for each additional user and type their user names. You can add up to 10 users at one time.

3. Select the type of access this set of users will have. You can select programmatic access, access to the AWS Management Console, or both.
• For Console password, choose Autogenerated password or Custom password

4. On the Set permissions page, specify how you want to assign permissions to this set of new users. Choose one of the following three options:
• Add user to the group.
• Copy permissions from an existing user.
• Attach existing policies directly.

5. (Optional) Add metadata to the user by attaching tags as key-value pairs.

6. Next: Review to see all of the choices you made up to this point. When you are ready to proceed, click on Create user.

7. Now your login details is already to use. Login using your credentials. Login Page

For more IAM user details check out AWS guide(Link).

How to host wordpress website in 3 easy steps using AWS Lightsail

Deep Patel — Sun, 16 Jan 2022 16:39:24 +0000

Step 1: Create or login to AWS account - Login/sign up to AWS

Step 2: Create Wordpress Instance in Ligtsail

After Login Click on Services in AWS console and search for Lighsail and open Lighsail service. It will open the Lightsail console.

1. Click on create instance option.

2. Select instance location, platform, and predefined WordPress blueprint

3. Select preferred instance plan

4. Add Instance identity name and click on create an instance

Step 3: Get your Lightsail WordPress login password via SSH

1. Click on the recently created WordPress instance and you can see the IP address and manage instance option. Click on "Connect using SSH".

2. After open the SSH client in the browser, enter the following command to retrieve your default password.

cat $HOME/bitnami_application_password

3. Open WordPress login using your static IP and login to WordPress console

http://<PublicIpAddress>/wp-login.php

For more detail related to AWS lightsail Please follow me and comment and ask your query, I will happy to help everyone.
Check Lighsail official document for AWS WordPress Lightsail details. LINK