AWS Serverless hands on part 1/2

Introduction

When I started my cloud journey six years ago, serverless architecture was the most difficult concept for me to understand . I transitioned into DevOps world from an OnPrem engineer role (primarily working with mostly PoverVM and VMware). So if someone told me that they were running their app on the serverless schema, I could not really get it.
This post aims to make the serverless topic easier to understand by providing both theoretical insights and a hands-on practical approach. The article is split into two parts to separate planning from implementation, making it easier to absorb.

Our Action Plan

1. Part One:

   • Introduction
   • Main Idea: What we want to achieve
   • Architecture of our app
   • Assumptions and declarations

2. Part Two:

   • Detailed app description
   • OIDC implementation
   • Backend implementation
   • Frontend implementation
   • Deployment with GitHub Actions (GHA)
   • Considerations
   • Costs analysis

What Do We Want to Achieve?

In my experience, the best way to learn is by combining theoretical knowledge with practical experimentation. This post will focus on understanding the basics of serverless architecture and then implementing a fully automated serverless app on AWS.
We are going to use several AWS services to power our application and we will rely on automation tools to avoid making manual changes through AWS Console. I think the plan is ambitious and assumes that the readers have a basic understanding about of IT concepts and are eager to learn more.
Let's dive in!

Architecture and overview the services

Our application will include both a backend and a frontend. Deployment and resource creation will be fully automated. Following best DevOps practices, all changes will be tracked through code ensuring:

• Orderly cloud resource managment
• Rapid recovery capabilities
• Full transparency of changes
• Minimized human error

Let's now go through services we will use.

Backend Services

• AWS API Gateway (fully managed service to create/publish/maintain/monitor and secure API at any scale)
• AWS Lambda (serverless compute service that runs the code without provisioning or managing servers, max timeout = 15 mins)
• AWS DynamoDB (fully managed NoSQL database service designed for HA, performance and scalability)

Frontend Services

• AWS CloudFront (content delivery network [known as CDN] service that accelerates the delivery of static and dynamic web content to users globally)
• AWS S3 bucket (scalable object storage service designed to store and retrieve any amount of data at anytime anywhere)

High-Level Architecture Overview

Main Assumptions

All services will be created using Infrastructure as Code (IaaC) via AWS CDK (Cloud Development Kit). AWS CDK is a software development framework that allows to define cloud infrastructure using code in many programming languages (like TypeScript, Python, Java).
Unlike declarative templates like YAML or JSON, CDK uses programming constructs as building blocks. The stacks defined in CDK correspond to CloudFormation stacks containing all created resources. If you are new to CDK, check out the official AWS CDK docs for more details.

Our codebase will reside on GitHub, and any changes will trigger deployments via GitHub Actions.

A Note on GitHub Actions (GHA)
GitHub Actions is an automation platform integrated into GitHub, allowing developers to automate workflows within repositories. Workflows can handle tasks like building, testing, deploying, and maintaining applications.

Workflows are triggered by events such as:

• Pushes (new code is pushed to a branch)
• Pull Requests (opened/merged or updated)
• Manual triggers (or other GitHub events)

In our case, we’ll create a simple workflow to deploy CDK constructs, ensuring AWS resources remain up to date.

Using OIDC for Secure Communication
To securely connect AWS with GitHub, we’ll use OpenID Connect (OIDC), a secure authentication protocol. OIDC enables GitHub Actions to authenticate with AWS without requiring long-lived credentials, reducing the risk of credential exposure.

It works as follow:

• GitHub Actions acts as OIDC IdP (Identity Provider), allowing AWS to verify workflow identities via signed token
• On AWS, the IAM role is configured to trust GitHub OIDC provider, with conditions specifying which repositories and workflows can assume the role
• GitHub Actions uses the OIDC token to assume the trusted IAM role, obtaining temporary credentials to access AWS

More about OIDC can be read here

First part summary

In this first part, we’ve covered:

• Key services that we’ll use in our project
• A high-level overview of our goals and architecture
• An introduction to the tools and technologies involved

I hope everything is clear so far! Please leave a comment if you have any concerns or need further clarification. When you are ready, move on to the next part