AWS

This example demonstrates how to build and deploy a simple serverless API using AWS Lambda, API Gateway, and AWS SAM (Serverless Application Model). The core focus here is on leveraging modularity and nested stacks to create a well-organized and scalable project structure. Project Structure Here’s a quick overview of the project’s key components: api.yaml: This SAM file defines the API Gateway. It’s responsible for linking HTTP paths (like /orders and /logs) to the appropriate Lambda Functions. Crucially, it imports the API definition from openapi.yaml. log.yaml: This SAM file contains the definition for the Lambda Function responsible for fetching logs (GetLogs). order.yaml: This SAM file contains the definition for the Lambda Function responsible for fetching orders (GetOrders). openapi.yaml: This is the OpenAPI (Swagger) file that specifies the API paths (e.g., /orders, /logs) and how they integrate with the Lambda Functions. Here, we define the x-amazon-apigateway-integration that links each path to the ARN of the relevant Lambda Function. template.yaml: This is the main SAM template for your project. It acts as an orchestrator for all the sub-stacks (OrderStack, LogStack, ApiStack). Each sub-stack points to its respective YAML file using the Location property of AWS::Serverless::Application. Why Modularity and Nested Stacks? Modularity & Organization: When you split your project into separate files like order.yaml, log.yaml, and api.yaml, your project becomes easier to organize and understand. Each file focuses on one part of the app, so it’s easier to work on and update, especially when the project gets bigger. ...

This example shows how to build and deploy a simple Python application using AWS Elastic Beanstalk for managed hosting and Terraform for infrastructure as code. The deploy.sh script automates the application packaging and deployment process. Project Structure Here’s a quick overview of the project’s key components: app/: Contains the Python application, main.py, along with Procfile for defining the web server, and requirements.txt for Python dependencies. terraform/: Holds all the Terraform configuration files (.tf) that define the AWS infrastructure: main.tf: Defines the core AWS resources like the S3 bucket for application versions, IAM roles for Elastic Beanstalk, and the Elastic Beanstalk application and environment themselves. variables.tf: Declares input variables for customizability (e.g., AWS region, instance type). outputs.tf: Exports important values like the S3 bucket name and the Elastic Beanstalk environment URL. deploy.sh: A shell script that orchestrates the deployment process: Reads outputs from Terraform to get dynamic values. Zips the app/ directory. Uploads the zipped application to the designated S3 bucket. Creates a new Elastic Beanstalk application version. Updates the Elastic Beanstalk environment to use the new version. How It Works First, Terraform provisions all necessary AWS resources for Elastic Beanstalk. Then, the deploy.sh script automates the rest: it fetches deployment details from Terraform, zips your Python application, uploads it to S3, and finally, updates your Elastic Beanstalk environment with this new application version. ...

This example shows how to build and deploy a simple serverless API using AWS Lambda, API Gateway, and AWS SAM (Serverless Application Model). The API fetches a list of todos from a public endpoint and returns them via an HTTP GET request. Project Structure Here’s a quick overview of the project’s key components: functions/: Contains the Lambda function ListTodos.mjs, which fetches todo items from a public API using Axios. tests/: Contains a Jest test to ensure the function returns items with a 200 status code. layers/: Optional shared layer for common dependencies (e.g., axios), defined under nodejs/package.json. template.yaml: AWS SAM template that defines the infrastructure: Lambda function (ListTodosFunction) API Gateway (/posts) Shared Layer How It Works When a client makes a GET request to /todos, the Lambda function is triggered, fetches data from https://jsonplaceholder.typicode.com/todos?_limit=3, and returns it as JSON. ...

This example outlines a method for deploying static websites on Amazon Web Services (AWS) using Terraform for infrastructure as code, Amazon S3 for content storage, and Amazon CloudFront for global content delivery. The deployment process is fully automated. Project Structure Below is an overview of the project’s key directories and files: public/: Contains the static website assets, such as index.html and 404.html. These are the files that will be served to users. terraform/: This directory holds all the Terraform configuration files (.tf) responsible for provisioning and managing AWS resources. main.tf: Defines the core AWS resources, including the S3 bucket and CloudFront distribution. variables.tf: Contains input variables to parameterize the Terraform configuration (e.g., bucket names, domain names). outputs.tf: Specifies output values that are useful after Terraform applies the configuration, such as the CloudFront distribution domain name. deploy.sh: A shell script to execute the Terraform plan and apply the infrastructure, including uploading static files to S3. destroy.sh: A shell script to tear down all provisioned AWS resources. Project Repository: https://github.com/OmarMakled/aws-terraform-s3 ...

This example shows how to build a modular AWS Lambda project using SAM (Serverless Application Model) with nested stacks and a shared layer. This helps keep your project clean and organized by separating logic and shared dependencies. How It Works layer.yaml creates a shared Lambda Layer that contains Node.js packages (like axios). order.yaml and log.yaml are two Lambda functions that use this shared layer. The root template (template.yaml): Creates the layer stack. Passes the layer reference to the other stacks as a parameter. sam build sam deploy --guided Project Repository: https://github.com/OmarMakled/sam-nested-layer

This example provides a structured approach to deploying a Serverless GraphQL API using AWS Serverless Application Model (SAM), leveraging Nested Stacks for modularity. Project Structure: Modular Stacks The core idea is to break down the infrastructure into specialized, manageable units using SAM’s Nested Stacks. This separation enhances clarity, reusability, and maintainability. The Root Template acts as the orchestrator, defining the dependencies between the smaller stacks: RolesStack (stacks/roles.yaml): Creates the necessary IAM Roles for Lambda execution and for AppSync to invoke the Lambda function. GraphQLStack (stacks/graphql.yaml): Provisions the AWS AppSync GraphQL API, including the API itself, the API Key, and the Schema definition (which is assumed to be uploaded to an S3 location). FunctionsStack (stacks/functions.yaml): Deploys the Lambda function, the AppSync Data Source, and the Resolvers query.graphql the schema definition can also be split into smaller files (types, queries, and mutations). These fragments are then merged into a single final schema file (schema.graphql). The best thing about this design is that everything is organized and independent. Each group of functions or resources is in its own box (stack). ...

What is AWS Lambda? AWS Lambda is a serverless computing service from Amazon. No servers to manage – AWS handles all the infrastructure. Automatic scaling – if 10,000 users call your API, AWS runs 10,000 copies of your function. Cost-efficient – you pay only for execution time, not idle time. Fast to deploy – perfect for small tasks or microservices. How does it work? Each Lambda function is triggered by an event — like an HTTP request, a file upload, or a message. When that event happens, AWS automatically runs your code. ...

When you build serverless applications with AWS SAM or CloudFormation, sometimes you need to share resources between stacks. For example, you may have: A Cognito User Pool in one stack (for user authentication) And an API Gateway in another stack that needs to use that Cognito pool There are two main ways to connect these stacks: Option 1: Using Parameters You can pass values like the User Pool ARN or ID as a parameter when you deploy the second stack. ...