DEV Community: John Walker

Implementing Guardrails on AWS Bedrock AgentCore

John Walker — Sat, 31 Jan 2026 21:56:23 +0000

Creating a multi-agent deployment with Strands SDK and AWS Bedrock AgentCore

John Walker — Sat, 31 Jan 2026 21:42:00 +0000

Deploying Terraform Code via AWS CodeBuild and AWS CodePipeline

John Walker — Sun, 02 Feb 2025 23:16:37 +0000

In a previous post i demonstrated how to use Terraform to deploy an Amazon API Gateway backed by Lambda. This was an example of how you can use Terraform as Infrastructure as Code to manage your resources in AWS.

https://dev.to/aws-builders/deploying-amazon-api-gateway-and-lambda-with-terraform-1i2o

However, the way of deploying the Terraform code to AWS was to manually run the terraform plan and apply steps locally each time we want to update the API Gateway or our Lambda code. We can improve on this and automate the deployment of the Terraform Code using AWS CodePipeline and CodeBuild.

To do this, we will still need to the Deploy the CICD Pipeline initially locally (or from a machine in AWS), which will need to be monitored to update the pipeline itself, but this Pipeline will allow any code committed to the GitHub Repository to be deployed into AWS Automatically, and should only need minimal maintenance as it should not change on the same frequency as the API Gateway / Lambda Code.

To ensure we don't just blindly deploy code that hasn't been checked, we'll split this out into stages:

CodePipeline
- Download Source Code from API Gateway Repository
- Run a Planning Step in AWS CodeBuild.
  - Download and Install Terraform
  - Initialise the Terraform Environment with an S3 Backend
  - Run the Terraform Plan, and save the output to an Artifact
- Send an Email via SNS to say the pipeline is awaiting approval
  - Await Manual Approval
- Run an Apply Step in AWS CodeBuild.
  - Download and Install Terraform
  - Initialise the Terraform Environment with an S3 Backend
  - Run the Terraform Apply using the Artifact from the Planning stage

This is what we are creating in terms of the flow:

Terraform - main.tf

For the main terraform setup, we will need some prerequisites, in terms of the backend and provider etc.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }

  # S3 backend configuration
  backend "s3" {
    bucket = "REPLACE_WITH_YOUR_TERRAFORM_STATE_BUCKET"
    key    = "REPLACE_WITH_FOLDER_NAME/terraform.tfstate"
    region = var.aws_region
    encrypt = true
  }
}

provider "aws" {
  region = var.aws_region
}

This sets up terraform to use the AWS provider and provides a location for the state file (that tracks the changes in your architecture) in S3. You should create an S3 bucket and provide it here, and insert a folder name (such as ci-cd-pipeline) for the state file to be stored in.

S3 Artifacts - main.tf

For the codepipeline, we will need to pass artifacts between the different stages (mainly the plan file), so we need somewhere to store these artifacts during the pipelines run.

resource "aws_s3_bucket" "codepipeline_bucket" {
  bucket_prefix = "tf-pipeline-artifacts-"
  force_destroy = true
}

resource "aws_s3_bucket_ownership_controls" "codepipeline_bucket" {
  bucket = aws_s3_bucket.codepipeline_bucket.id
  rule {
    object_ownership = "BucketOwnerPreferred"
  }
}

resource "aws_s3_bucket_acl" "codepipeline_bucket" {
  depends_on = [aws_s3_bucket_ownership_controls.codepipeline_bucket]
  bucket     = aws_s3_bucket.codepipeline_bucket.id
  acl        = "private"
}

resource "aws_s3_bucket_versioning" "codepipeline_bucket" {
  bucket = aws_s3_bucket.codepipeline_bucket.id
  versioning_configuration {
    status = "Enabled"
  }
}

Notifications - main.tf

When we have the approval step, we'll need to notify someone that an approval is ready, so we'll create an SNS topic to send an email.

resource "aws_sns_topic" "approval_topic" {
  name = "terraform-approval-topic"
}

resource "aws_sns_topic_subscription" "approval_email" {
  topic_arn = aws_sns_topic.approval_topic.arn
  protocol  = "email"
  endpoint  = var.notification_email
}

This will set up a topic and subscribe an email to that topic (which we'll pass in via the variables file later on).

IAM Roles - main.tf

We need to create permissions for our CodeBuild to perform its tasks, as well as the code pipeline and SNS.

# CodeBuild IAM Role
resource "aws_iam_role" "codebuild_role" {
  name = "terraform-codebuild-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "codebuild.amazonaws.com"
        }
      }
    ]
  })
}

resource "aws_iam_role_policy" "codebuild_policy" {
  name = "terraform-codebuild-policy"
  role = aws_iam_role.codebuild_role.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "logs:CreateLogGroup",
          "logs:CreateLogStream",
          "logs:PutLogEvents"
        ]
        Resource = "*"
      },
      {
        Effect = "Allow"
        Action = [
          "s3:GetObject",
          "s3:PutObject",
          "s3:GetObjectVersion",
          "s3:ListBucket"
        ]
        Resource = [
          aws_s3_bucket.codepipeline_bucket.arn,
          "${aws_s3_bucket.codepipeline_bucket.arn}/*",
          "arn:aws:s3:::REPLACE_WITH_YOUR_TERRAFORM_STATE_BUCKET",
          "arn:aws:s3:::REPLACE_WITH_YOUR_TERRAFORM_STATE_BUCKET/*"
        ]
      }
    ]
  })
}

# CodePipeline IAM Role
resource "aws_iam_role" "codepipeline_role" {
  name = "terraform-codepipeline-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "codepipeline.amazonaws.com"
        }
      }
    ]
  })
}

resource "aws_iam_role_policy" "codepipeline_policy" {
  name = "terraform-codepipeline-policy"
  role = aws_iam_role.codepipeline_role.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "s3:GetObject",
          "s3:PutObject",
          "s3:GetObjectVersion",
          "s3:GetBucketVersioning"
        ]
        Resource = [
          aws_s3_bucket.codepipeline_bucket.arn,
          "${aws_s3_bucket.codepipeline_bucket.arn}/*"
        ]
      },
      {
        Effect = "Allow"
        Action = [
          "codebuild:BatchGetBuilds",
          "codebuild:StartBuild"
        ]
        Resource = "*"
      },
      {
        Effect = "Allow"
        Action = [
          "sns:Publish"
        ]
        Resource = aws_sns_topic.approval_topic.arn
      }
    ]
  })
}

The codebuild policy will allow our codebuild project to create logs and to set and retrieve files from our s3 bucket.

The code pipeline role is allowed to be assumed by the AWS CodePipeline service and it can also get S3 artifacts from our bucket, as well as start CodeBuild and send messages to our SNS Topic.

CodeBuild Projects - main.tf

We need 2 CodeBuild Projects, one for each of our Plan and Apply steps.

# Terraform Plan Project
resource "aws_codebuild_project" "terraform_plan" {
  name          = "terraform-plan"
  description   = "Run terraform plan"
  service_role  = aws_iam_role.codebuild_role.arn
  build_timeout = 15

  artifacts {
    type = "CODEPIPELINE"
  }

  environment {
    type                        = "LINUX_CONTAINER"
    compute_type                = "BUILD_GENERAL1_SMALL"
    image                       = "aws/codebuild/amazonlinux2-x86_64-standard:3.0"
    privileged_mode             = false
  }

  logs_config {
    cloudwatch_logs {
      group_name = "terraform-plan-logs"
    }
  }

  source {
    type      = "CODEPIPELINE"
    buildspec = <<EOF
version: 0.2

phases:
  install:
    runtime-versions:
      python: 3.8
    commands:
      - wget https://releases.hashicorp.com/terraform/1.0.11/terraform_1.0.11_linux_amd64.zip
      - unzip terraform_1.0.11_linux_amd64.zip
      - mv terraform /usr/local/bin/
  pre_build:
    commands:
      - echo "Starting Terraform plan phase..."
      - terraform --version
  build:
    commands:
      - terraform init -input=false
      - terraform plan -input=false -out=tfplan
  post_build:
    commands:
      - echo "Completed Terraform plan phase"

artifacts:
  files:
    - tfplan
    - .terraform/**/*
    - '**/*'
EOF
  }
}

# Terraform Apply Project
resource "aws_codebuild_project" "terraform_apply" {
  name          = "terraform-apply"
  description   = "Run terraform apply"
  service_role  = aws_iam_role.codebuild_role.arn
  build_timeout = 15

  artifacts {
    type = "CODEPIPELINE"
  }

  environment {
    type                        = "LINUX_CONTAINER"
    compute_type                = "BUILD_GENERAL1_SMALL"
    image                       = "aws/codebuild/amazonlinux2-x86_64-standard:3.0"
    privileged_mode             = false
  }

  logs_config {
    cloudwatch_logs {
      group_name = "terraform-apply-logs"
    }
  }

  source {
    type      = "CODEPIPELINE"
    buildspec = <<EOF
version: 0.2

phases:
  install:
    runtime-versions:
      python: 3.8
    commands:
      - wget https://releases.hashicorp.com/terraform/1.0.11/terraform_1.0.11_linux_amd64.zip
      - unzip terraform_1.0.11_linux_amd64.zip
      - mv terraform /usr/local/bin/
  pre_build:
    commands:
      - echo "Starting Terraform apply phase..."
      - terraform --version
  build:
    commands:
      - terraform init -input=false
      - terraform apply -input=false tfplan
  post_build:
    commands:
      - echo "Completed Terraform apply phase"

artifacts:
  files:
    - '**/*'
EOF
  }
}

The first project is our Plan stage. Firstly we create the codebuild project, give it a name and service role. Then we apply a 15 minute time out and set the environment variables (linux and small container running amazon linux 2 is fine for our needs).

We then set up the logs and the Source. This is where the main set up is for CodeBuild.

CodeBuild is configured with a YAML file that allows commands to be run in phases. This is the buildspec.yml file (in this case we have it inline, but you could reference it from your repository). the full specifications are here https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html

For our purposes, the important ones are the phases. These blocks run in a specific order, and execute the commands in those blocks. The order is install, pre_build, build, and post_build. You can run commands as different users, have complex error handling, error catching etc here.

In our case we'll do the following. Both CodeBuild projects are nearly identical, just with the plan or apply specific logs, locations etc, and the only command difference is terraform plan vs terraform apply

Install phase:

set up python
set up terraform
- download terraform
- unzip terraform
- move it to the user executable directory

Pre build phase:

echo a message to screen
output the terraform version to show terraform is working (this can help catch errors for debugging)

Build phase:

initialise terraform (syncs up with our back end)
plan or apply the terraform, outputting to a tfplan file in the plan stage, then using this same file in the apply stage

Post build phase:

output a complete message

We then use the Artifacts section to pass the tfplan file from the plan stage over to the apply stage.

Code Pipeline - main.tf

Now that we have our components, we need to assemble them into a Code Pipeline.

resource "aws_codepipeline" "terraform_pipeline" {
  name     = "terraform-deployment-pipeline"
  role_arn = aws_iam_role.codepipeline_role.arn

  artifact_store {
    location = aws_s3_bucket.codepipeline_bucket.bucket
    type     = "S3"
  }

  # Source Stage - Pull from GitHub
  stage {
    name = "Source"

    action {
      name             = "Source"
      category         = "Source"
      owner            = "ThirdParty"
      provider         = "GitHub"
      version          = "1"
      output_artifacts = ["source_output"]

      configuration = {
        Owner      = var.github_repo_owner
        Repo       = var.github_repo_name
        Branch     = var.github_branch
        OAuthToken = var.github_token
      }
    }
  }

  # Plan Stage - Run Terraform Plan
  stage {
    name = "Plan"

    action {
      name             = "TerraformPlan"
      category         = "Build"
      owner            = "AWS"
      provider         = "CodeBuild"
      version          = "1"
      input_artifacts  = ["source_output"]
      output_artifacts = ["plan_output"]

      configuration = {
        ProjectName = aws_codebuild_project.terraform_plan.name
      }
    }
  }

  # Approval Stage - Manual approval before apply
  stage {
    name = "Approval"

    action {
      name     = "Approval"
      category = "Approval"
      owner    = "AWS"
      provider = "Manual"
      version  = "1"

      configuration = {
        NotificationArn = aws_sns_topic.approval_topic.arn
        CustomData      = "Please review the terraform plan and approve to apply changes"
      }
    }
  }

  # Apply Stage - Run Terraform Apply
  stage {
    name = "Apply"

    action {
      name            = "TerraformApply"
      category        = "Build"
      owner           = "AWS"
      provider        = "CodeBuild"
      version         = "1"
      input_artifacts = ["plan_output"]

      configuration = {
        ProjectName = aws_codebuild_project.terraform_apply.name
      }
    }
  }
}

The first section will set up the pipeline and its role and artifact store location.

The next few sections are stages, we'll go through these one at a time.

Source Stage

This source stage is used to link up to GitHub and pull down the source code, and output it as an artifact to be passed through to th next stage. This is currently set up to use OAuth with GitHub, but this can be changed to different providers and types of connections. (The CodeStar connection method is the current recommended way to do this, but i've stuck with OAuth here for simplicity)

https://docs.aws.amazon.com/codepipeline/latest/userguide/integrations-action-type.html#integrations-source

Plan Stage

This stage is set up to use our previously created CodeBuild for planning and links to the CodeBuild Project

Approval Stage

This stage sets up a manual approval so you can go into the console and click approve, and sends out a notification to the email address to say this is ready.

Apply Stage

Similar to Planning we link up to our Codebuild for the apply step.

Outputs - main.tf

If required, you can output some information such as the codepipeline url and the sns topic arn for information:

output "codepipeline_url" {
  description = "URL to the CodePipeline console for the created pipeline"
  value       = "https://${var.aws_region}.console.aws.amazon.com/codesuite/codepipeline/pipelines/${aws_codepipeline.terraform_pipeline.name}/view?region=${var.aws_region}"
}

output "approval_topic_arn" {
  description = "ARN of the SNS topic used for pipeline approval notifications"
  value       = aws_sns_topic.approval_topic.arn
}

Variables - variables.tf

We've set up some variables in the main file to control deployments, covering the region and github information, these should go in a variables.tf file so you can pass the required parameters into the terraform.

`variable "aws_region" {
description = "The AWS region to deploy resources into"
type = string
default = "eu-west-1"
}

variable "github_repo_owner" {
description = "GitHub repository owner"
type = string
default = "REPO_OWNER_NAME"
}

variable "github_repo_name" {
description = "GitHub repository name"
type = string
default = "REPO_NAME"
}

variable "github_branch" {
description = "GitHub repository branch"
type = string
default = "main"
}

variable "github_token" {
description = "GitHub OAuth token"
type = string
sensitive = true
}

variable "notification_email" {
description = "Email address to receive approval notifications"
type = string
}`

Conclusion

This method of planning and applying terraform via CodeBuild can be useful when deploying terraform in an automated way whenever the repository containing the terraform is updated, while still keeping a manual approval step in place, and allowing the plan to be reviewed in the CodeBuild plan step logs.

Deploying Amazon API Gateway and Lambda with Terraform

John Walker — Sat, 01 Feb 2025 04:35:16 +0000

AWS provides multiple ways to deploy infrastructure and code onto their platform, with differing levels of complexity and scalability.

One of the most effective and safe ways is to use Infrastructure as Code (IaC), to define the required resources in a repeatable template that allows you to deploy your Infrastructure and keep it updated, while tracking any changes to ensure the environment stays the way you need it.

AWS provides native CloudFormation for deploying code, however this post will concentrate on Terraform. Each type of IaC has its advantages and disadvantages, as do others like CDK, Serverless Framework, Pulumi and more.

I've come to like Terraform for its more programming like features over CloudFormation, though I do still use CloudFormation in some cases. I also use CDK in some situations, it depends on the nature of what you are deploying.

Architecture

In this example, we'll be deploying an Amazon API Gateway with links to a Lambda Function.

The files for deploying this example are available on my GitHub:
https://github.com/uzusan/apigateway-tf-blogpost

This Lambda will emulate typical CRUD operations (Create, Read, Update, and Delete) as if it was connected to a database, mapping the operations to HTTP requests for POST, GET, PUT and DELETE methods respectively.

Each request into the API Gateway is routed to the Lambda Function (These could be separate Lambdas for each operation) to perform the specific function. In this example, it will just return a JSON object with a text string showing what would be done in a full integration.

Below is the Lambda Function we will be deploying:

import json
from datetime import datetime

def handler(event, context):
    # Get the HTTP method from the event
    http_method = event['httpMethod']

    # Prepare the response based on the HTTP method
    message_map = {
        'GET': 'This would GET (read) an item from the database',
        'POST': 'This would POST (create) a new item in the database',
        'PUT': 'This would PUT (update) an existing item in the database',
        'DELETE': 'This would DELETE an item from the database'
    }

    message = message_map.get(http_method, 'Unsupported HTTP method')

    # Return the response
    return {
        'statusCode': 200,
        'headers': {
            'Content-Type': 'application/json'
        },
        'body': json.dumps({
            'message': message,
            'method': http_method,
            'timestamp': datetime.now().isoformat()
        })
    }

API Gateway

The API Gateway has integrations with the Lambda via a proxy.

API Gateways are made up of 3 levels, the Stage (Production in this case), the resources, then the integrations.

In this example, we are sending requests to the Production Stage (you could also host dev or test on the same endpoint for example), accessing the items resource (our main endpoint for dealing with our expected database), then we have multiple functions for interactions with those resources, for each request type.

Terraform

In this example, we'll be deploying the Terraform from our local machine, however in a separate blog post, i'll detail how to set up a CI/CD pipeline to deploy this automatically via CodePipeline and CodeBuild.

To start we'll need the following installed locally:

AWS CLI v2
Terraform

In this example, we'll also need to pass in an existing S3 bucket to use for the state file for Terraform, allowing us to keep the state in a centralised place. This example doesn't cover state locking with DynamoDB or the more recent S3 State File locking directly, it just uses a single state file, which if only being used by one developer at a time is sufficient for our purposes.

We'll use the following files from the Github repo https://github.com/uzusan/apigateway-tf-blogpost:

index.py
lambda_function.zip (a zip file containing the above index.py)
main.tf

Terraform main.tf

For this example, i'll keep everything in one place to make it easier to understand, but typically you would have separate variables, outputs and maybe a backend file. For more info on Terraform best practices, HashiCorp have a good guide here: https://developer.hashicorp.com/terraform/language/modules/develop/structure

Providers and Backend

First we set up the AWS Provider to allow us to create resources on AWS and our S3 backend, so that our state file that tracks the state of resources can be stored on S3:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }

  # S3 backend configuration
  backend "s3" {
    bucket = "BUCKETNAME_TO_BE_REPLACED"
    key    = "api-lambda/terraform.tfstate"
    region = "eu-west-1"
    encrypt = true
  }
}

The BUCKETNAME_TO_BE_REPLACED should be replaced with a suitable S3 Bucket (this can also be created via a separate Terraform File). Our key is just a unique name for the state file, and in this case i've put the region as eu-west-1, which i'll be using throughout.

Next we have to setup our IAM Permissions, including a role which the Lambda will assume, and a policy attachment to attach the AWS Basic Execution Role policy to our new role:

# IAM role for Lambda
resource "aws_iam_role" "lambda_role" {
  name = "crud_lambda_role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "lambda.amazonaws.com"
        }
      }
    ]
  })
}

# IAM policy for CloudWatch Logs
resource "aws_iam_role_policy_attachment" "lambda_logs" {
  role       = aws_iam_role.lambda_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

The aws_iam_role resource type will create an IAM role for us, and we can create an assume role policy that allows the Lambda Service to assume this role. Next we create a aws_iam_role_policy_attachment that allows us to attach the AWSLambdaBasicExecutionRole, which will allow the Lambda to run and to write logs to CloudWatch.

Next we deploy the Lambda using the aws_lambda_function resource. This method uses a local file (lambda_function.zip) and creates the source code to be uploaded using the source_code_hash attribute.

We also use the earlier role ARN (Amazon Resource Name) to refer to the lambda_role we just created.

We use the handler attribute to point the main execution entry point for Lambda to be our handler function (index.handler refers to the index.py python file, and the handler function def handler(event, context): defined in it.

# Lambda function
resource "aws_lambda_function" "crud_lambda" {
  filename          = "lambda_function.zip"
  function_name     = "crud_operations"
  role              = aws_iam_role.lambda_role.arn
  handler           = "index.handler"
  runtime           = "python3.9"

  source_code_hash = filebase64sha256("lambda_function.zip")
}

Next we create our API Gateway, using the aws_api_gateway_rest_api resource type:

# API Gateway
resource "aws_api_gateway_rest_api" "crud_api" {
  name        = "crud-api"
  description = "CRUD API Gateway"
}

We then create the items resource using the aws_api_gateway_resource resource type:

# API Gateway resource
resource "aws_api_gateway_resource" "items" {
  rest_api_id = aws_api_gateway_rest_api.crud_api.id
  parent_id   = aws_api_gateway_rest_api.crud_api.root_resource_id
  path_part   = "items"
}

Passing in the rest api we just created and with a parent_id of the root resource (we can use this to nest resources by pointing to another id other than root) and have the URL path have items.

We then want to set up our methods for GET, POST, UPDATE and DELETE, using the aws_api_gateway_method resource.

We can also use the http_method ANY here and have all of the requests route to our Lambda in a single method, however below I will demonstrate having each method linked separately, as this will allow us to have different methods linked to different Lambdas if required (you could have different methods handling your read-only vs write requests for example).

# GET method
resource "aws_api_gateway_method" "get" {
  rest_api_id   = aws_api_gateway_rest_api.crud_api.id
  resource_id   = aws_api_gateway_resource.items.id
  http_method   = "GET"
  authorization = "NONE"
}

# POST method
resource "aws_api_gateway_method" "post" {
  rest_api_id   = aws_api_gateway_rest_api.crud_api.id
  resource_id   = aws_api_gateway_resource.items.id
  http_method   = "POST"
  authorization = "NONE"
}

# PUT method
resource "aws_api_gateway_method" "put" {
  rest_api_id   = aws_api_gateway_rest_api.crud_api.id
  resource_id   = aws_api_gateway_resource.items.id
  http_method   = "PUT"
  authorization = "NONE"
}

# DELETE method
resource "aws_api_gateway_method" "delete" {
  rest_api_id   = aws_api_gateway_rest_api.crud_api.id
  resource_id   = aws_api_gateway_resource.items.id
  http_method   = "DELETE"
  authorization = "NONE"
}

For each we pass in the API Gateway ID, the items resource ID and the method to be used (GET, PUT etc).

For each of these methods, we then need to set up a Proxy to route calls to the Lambda (these all go to the same Lambda but could go to different Lambda functions) using the aws_api_gateway_integration resource type:

# Lambda integration for GET
resource "aws_api_gateway_integration" "lambda_get" {
  rest_api_id = aws_api_gateway_rest_api.crud_api.id
  resource_id = aws_api_gateway_resource.items.id
  http_method = aws_api_gateway_method.get.http_method

  integration_http_method = "POST"
  type                   = "AWS_PROXY"
  uri                    = aws_lambda_function.crud_lambda.invoke_arn
}

# Lambda integration for POST
resource "aws_api_gateway_integration" "lambda_post" {
  rest_api_id = aws_api_gateway_rest_api.crud_api.id
  resource_id = aws_api_gateway_resource.items.id
  http_method = aws_api_gateway_method.post.http_method

  integration_http_method = "POST"
  type                   = "AWS_PROXY"
  uri                    = aws_lambda_function.crud_lambda.invoke_arn
}

# Lambda integration for PUT
resource "aws_api_gateway_integration" "lambda_put" {
  rest_api_id = aws_api_gateway_rest_api.crud_api.id
  resource_id = aws_api_gateway_resource.items.id
  http_method = aws_api_gateway_method.put.http_method

  integration_http_method = "POST"
  type                   = "AWS_PROXY"
  uri                    = aws_lambda_function.crud_lambda.invoke_arn
}

# Lambda integration for DELETE
resource "aws_api_gateway_integration" "lambda_delete" {
  rest_api_id = aws_api_gateway_rest_api.crud_api.id
  resource_id = aws_api_gateway_resource.items.id
  http_method = aws_api_gateway_method.delete.http_method

  integration_http_method = "POST"
  type                   = "AWS_PROXY"
  uri                    = aws_lambda_function.crud_lambda.invoke_arn
}

For each method, we pass in the rest api ID, the items resource ID and the http method used (we take this from each of the aws_api_gateway_method's we just set up.

Each integration type uses POST as we are passing the parameters passed in from API Gateway over to Lambda as a POST with parameters. The original method will be passed over as part of the event message (which you can see in index.py where we extract it with http_method = event['httpMethod'] ). We also pass in the type of Proxy and the Lambda's URI, which we can get as the invoke_arn from the function we created earlier.

Next we need to allow the API Gateway and Lambda to talk to each other:


# Lambda permission for API Gateway
resource "aws_lambda_permission" "api_gw" {
  statement_id  = "AllowAPIGatewayInvoke"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.crud_lambda.function_name
  principal     = "apigateway.amazonaws.com"
  source_arn    = "${aws_api_gateway_rest_api.crud_api.execution_arn}/*/*"
}

Here we allow the API Gateway to invoke the Lambda we've created and pass in the specific function name and only allow the principal (the user/system allowed to use this permission) to be api gateway. We also restrict the source to being the API Gateway API we just created (all stages and resources, with the //, we could restrict this to dev for example with /dev/*).

Finally we create an API Gateway Deployment, then attach the Stage to that deployment using the aws_api_gateway_deployment and aws_api_gateway_stage resource types:

# API Gateway deployment
resource "aws_api_gateway_deployment" "crud_deployment" {
  depends_on = [
    aws_api_gateway_integration.lambda_get,
    aws_api_gateway_integration.lambda_post,
    aws_api_gateway_integration.lambda_put,
    aws_api_gateway_integration.lambda_delete
  ]

  rest_api_id = aws_api_gateway_rest_api.crud_api.id
}

# API Gateway stage
resource "aws_api_gateway_stage" "crud_stage" {
  deployment_id = aws_api_gateway_deployment.crud_deployment.id
  rest_api_id   = aws_api_gateway_rest_api.crud_api.id
  stage_name    = "prod"
}

In aws_api_gateway_deployment we technically only need to pass in the ID of the rest api to be deployed, but here we add a depends on, to ensure each of the aws_api_gateway_integration resources are created first, before we deploy the API, ensuring we don't deploy with empty integrations.

We then create a stage with aws_api_gateway_stage to create our production stage, passing in the rest api and the deployment we just created.

Finally we output the API Gateway URL so we can do some testing:

# Output the API Gateway URL
output "api_url" {
  value = "${aws_api_gateway_stage.crud_stage.invoke_url}/items"
}

Deploying the Terraform

Now that we have the main.tf file created, and our index.py file for the Lambda, we can deploy to AWS.

First step is to ensure we have the AWS CLI (v2) installed, and Terraform installed. I won't cover these here, but if you make sure you can communicate with AWS via the CLI (use aws configure to check your credentials are correct if using access keys), then run the following:

terraform init

This should then configure terraform, and you should see output similar to the below (Make sure you see the s3 backend message, if it's not present, you may not have correctly set up your AWS CLI):

Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.
Initializing provider plugins...
- Reusing previous version of hashicorp/aws from the dependency lock file
- Using previously-installed hashicorp/aws v4.67.0

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

You can then create a plan for Terraform:

terraform plan

If this is the first time running, you should see a lot of creation messages such as:

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_api_gateway_deployment.crud_deployment will be created
  + resource "aws_api_gateway_deployment" "crud_deployment" {
      + created_date  = (known after apply)
      + execution_arn = (known after apply)
      + id            = (known after apply)
      + invoke_url    = (known after apply)
      + rest_api_id   = (known after apply)
    }
....

One for each of the resources we are going to deploy. If there are no errors we can run apply:

terraform apply

After which you should see creation messages:

aws_iam_role.lambda_role: Creating...
aws_api_gateway_rest_api.crud_api: Creating...
aws_api_gateway_rest_api.crud_api: Creation complete after 1s

...

Apply complete! Resources: 16 added, 0 changed, 0 destroyed.

Outputs:

api_url = "URL"

At the end, we will have an API URL output that we can use to test the API.

Using the API URL, we can export as an env variable to save typing it each time:

export API_URL="https://XXXXX.execute-api.eu-west-1.amazonaws.com/prod/items"

This allows us to then run each method:

GET:

curl -X GET $API_URL

Which returns:

{"message": "This would GET (read) an item from the database", "method": "GET", "timestamp": "2025-02-01T04:23:08.867240"}%

POST

curl -X POST $API_URL \
  -H "Content-Type: application/json" \
  -d '{"name": "Test Item", "description": "This is a test item"}'

Which returns:

{"message": "This would POST (create) a new item in the database", "method": "POST", "timestamp": "2025-02-01T04:26:15.214840"}%

UPDATE

curl -X PUT $API_URL \
  -H "Content-Type: application/json" \
  -d '{"name": "Updated Item", "description": "This item has been updated"}'

Which returns:

{"message": "This would PUT (update) an existing item in the database", "method": "PUT", "timestamp": "2025-02-01T04:28:16.492926"}%

DELETE

curl -X DELETE $API_URL

Which returns:

{"message": "This would DELETE an item from the database", "method": "DELETE", "timestamp": "2025-02-01T04:28:49.461580"}%

Conclusion

This example can be used to expand other types of resources or Lambda functions deployed via Terraform, and in the next Blog Entry we will use this Terraform and deploy it via a Code Pipeline with a CodeBuild instance, allowing us to automate the execution of the Terraform when triggered by a commit to a GitHub repository.

Controlling Cloud Costs: Strategies for keeping on top of your AWS cloud spend

John Walker — Wed, 21 Jun 2023 20:27:47 +0000

Cloud computing is one of the most cost effective way of running computing and other resources there is, with potential huge savings compared to on-premise datacenters and other methods.

Moving to a pay as you go model from a up front or contract model can be very cost-effective, but with moving to the cloud, or starting out on the cloud, can come with a lot of complexities, and with how easy it is to spin up resources, you can end up spending more than you realise.

In this article, I will cover how to manage some of these complexities when it comes to costs, specifically on AWS (Amazon Web Services). I will cover:

Tips and Strategies to get the most out of your Cloud usage
Common cost drivers and challenges
Monitoring and alerting for unexpected cost spikes

Cloud Costs Overview

Firstly, I want to explain the pay as you go model (PAYG) i mentioned earlier. In AWS you pay for the resources that you use. Which can be a bit of a double edged sword.

As AWS is PAYG, you are paying for the resources you use, but this is generally split into different sections, so that you pay for exactly what you use in each section. As an example, spinning up a Virtual Machine (EC2 instance), will see you paying for the Instance itself, Storage, Backups, Data Transfer, Licensing (for Windows), potentially support, and potentially more, depending on the setup. This does mean that you don't end up paying for resources you don't use, but it makes it complex to keep on top of.

Next I want to touch on Managed vs Unmanaged services. In AWS there are a number of services such as Amazon Relational Database Service (RDS) that can be used to host Databases, such as MySQL, PostgreSQL, Microsoft SQL Server and more, without having to manage the underlying infrastructure. So you would take care of the Database management, but leave the underlying infrastructure, including server management and patching to AWS. Alternatively you can go down the unmanaged route and host your own database installation on an EC2 Instance for example.

As mentioned above, costs in AWS can be much more broken down that expected, and each aspect of a service may come with its own pricing structure, including all different aspects. A good way of finding out how something will break down is the AWS Pricing Calculator: https://calculator.aws/#/. This is a tool from AWS, which can help you understand the costs involved with various services.

In the above example section, you can see the breakdown for an EC2 instance, including instance pricing, metrics, and storage.

In the above example section, you can see the different pricing options for EC2, including on-demand, reserved instance pricing and spot instances.

Management Strategies

Knowing what you are using is key to understanding and controlling your cloud costs.

Ongoing monitoring and management of costs
AWS Cost Explorer, Budgets, Billing Tools
Cost Allocation / Tagging
Budget Management
- Per Project
- Per Team
- Per Service

FinOps Foundation Principles

The FinOps Foundation https://www.finops.org/ is a foundation dedicated to advancing the use of FinOps (Financial Operations) in the clound, with the following main principles:

Teams need to collaborate
Decisions are driven by business value of cloud
Everyone takes ownership for their cloud usage
FinOps data should be accessible and timely
A centralised team drives FinOps
Take advantage of the variable cost model of the cloud

https://www.finops.org/framework/principles/

These principles show the need for organisations to work together on controlling cloud costs, an ensuring that cloud spend is accounted for.

Reviews

The pace of Cloud Innovation is fast, new releases and updates come on a daily basis.
Regular reviews of your costs can help you keep on top of them. Questions to ask:

Are we still using everything we are being charged for?
Do we know what everything we are being charged for is and who is using it?
Is there a better way to achieve the same outcomes? For example, would moving to a managed solution lower manual intervention time spent?
Can we leverage other payment models, such as upfront reserved instances?
Monitor for unexpected changes in cost
- Daily budgeting checks
- Monitor based on expected costs
Be aware of potential spikes in costs based on usage
Adding tags to workloads can help break down costs to assist in monitoring
Third-party tools can help, such as Infracost for changes in costs based on Terraform deployments

DevOps and Infrastructure as Code

DevOps provides a method for continually deploying workloads to the cloud, and provides monitoring and feedback loops for improvement.

Defining all of your workloads in code, using Infrastructure as Code allows you to know what resources are in use, and eliminate unexpected costs.

Hidden / Obscure Costs

With PAYG, you pay for what you use, but sometimes it’s not always immediately obvious how it breaks down

Data Transfer – typically out from the cloud
NAT Gateways especially – for some services you can use private links to reduce traffic over the internet.
Lambda is billed based on 2 factors. The memory and the Duration of the execution time.
S3 cost breakdown dependant on file access frequency, size, retrieval requests
Line items that can add up.

As an example, here is an S3 calculation from the AWS Pricing Calculator, showing a common use:

And here is a more complex example, with multiple levels of Tiering for different storage requirements, such as moving some data to the Infrequent Access Tier, for lesser accessed data, which can save up to 40% on storage costs.

For Lambda, a very useful tool to help optimise is the AWS Lambda Power Tuning tool, released by Alex Casalboni, Developer Advocate at AWS: https://github.com/alexcasalboni/aws-lambda-power-tuning

This tool allows you to figure out what size of memory allocation to give your lambda based on an example execution. Somewhat counterintuitively, you may save money overall by allocating more memory to a Lambda Function.

The reason for this, is that you pay for both the memory allocation and execution time. Having more memory (and virtual CPUs) available to the Lambda, can allow it to finish running your function in a shorter period of time. This means while you pay more for the memory, you pay less for the execution costs.

Alex gives the example in the README of the GitHub project above of a Lambda that takes 35 seconds to run while fiven 128mb of memory, but runs in only 3 seconds when given 1.5GB of memory, saving 14% overall.

Example Savings

Below I've listed a few example savings you can use on AWS, depending on your use case. The goal with cost optimisation on AWS is to always use just what you need and no more. So for example, if you have an EC2 instance that is only using 25% of its memory and CPU, you may be able to go down to a lower tier of EC2 instance with no impact to your application, while lowering your costs.

Right Sizing – Move up or down a size based on the actual usage of the server
For AWS NAT Gateways, use endpoints such as S3 Gateway or DynamoDB to reduce traffic going out over the internet
Elastic Ips not in use are charged, as are remaps:
- $0.005 per additional IP address associated with a running instance per hour on a pro rata basis
- $0.005 per Carrier IP address not associated with a running instance per hour on a pro rata basis
- $0.00 per Carrier IP address remap for the first 100 remaps per month
- $0.10 per Carrier IP address remap for additional remaps over 100 per month
Older snapshots can build up over time
S3 data not in use should be moved down tiers, such as to Infrequent access or to glacier

Microservices and Eventbridge

John Walker — Tue, 14 Mar 2023 12:33:14 +0000

Microservices

Microservices are a software development pattern that breaks down a large application into smaller independent services.

• Small subsets of functionality but self-contained

• Size is variable but should generally be small enough to fit in a single developers head

• Functionality of the Microservice itself shouldn’t depend on other Microservices. User flow within the application should use multiple microservices

Microservice Types

Some examples from Amazon and Netflix of Microservices and their communication paths.

Microservices, like other software development methods, have had various ways of working developed over the years and choosing the right method of development that matches your business needs is critical.

Event-Driven Microservices
Domain Driven Design
Communication Methods:
- API Communication
- Decoupled Messaging
- Pub/Sub

Why Use Microservices?

Microservices have their own design considerations, but they also come with several benefits.

The team size and codebase for each microservice can be small. It should be able to be entirely understood by one person.
Focus on one specific business outcome or aspect and perform 1 task
Development autonomy. Each microservice is separate, so having different programming languages, technologies, and development methods is possible.
Allows alignment with the bounded context of the problem domain. The problem a microservice is trying to solve can align with business outcomes.
Loosely coupled architecture, allowing for separate scaling and consideration of each microservice.

When not to use Microservices?

Microservices are a good software development model for many use cases, but they are not always the best option.

It's important to consider the best method for your software development. Sometimes a hybrid of monolithic development and microservices is the right option.

Microservices should be independent single tasks. In some cases, this isn’t possible, for an overall task to complete, multiple tasks may need to be completed, and they can’t easily be separated.
Separating services adds some latency as each microservice needs to communicate via API or Events to proceed to the next step. This might be a blocker in latency-sensitive applications or even cause data synchronisation issues.
With distributed systems, debugging and tracing becomes more complex

There are methods for resolving or mitigating many of these issues, but these are also considerations when deciding on a software development method. Microservices give many benefits, but there are challenges and complexity considerations.

Event-Driven Services

One of the ways Microservices are used is through event-driven design. In this pattern, a producer is either a microservice or some other source of events, ranging from S3 to 3rd Party applications, that produce an event when something happens, providing a stream of events.

Once these events are produced, they can be put into a queue or an event bus, and other services or microservices interested in dealing with that event can process them.

This can take various forms:

Single queue, where an event is produced and consumed by usually a single target
Pub / Sub pipes or Event buses, where all events are put into a pipe, and multiple different interested targets can process the events or be notified of the event happening
Streaming, where all events are passed through a data stream where they are processed as they pass through, usually in chunks of events rather than one at a time

Event-Driven Service Examples

Single Queue:

Streaming:

Pub/Sub:

EventBridge

Eventbridge is AWS’s service that provides an event bus that can be used to handle events from various sources.

It can be used to:

Send requests to multiple consumers
Create an event lifecycle record
Integrate between different components, including 130 event sources and over 35 targets, as well as third parties.
Create cross-account event pipelines by sending events to Eventbridge buses in other accounts.
Provide filtering of events to trigger consumers.
Provide a schema registry for events to track and version events, allowing for producer-consumer contracts.

Microservice Considerations

Driving microservice design takes the same amount of consideration as other software development methods, with relevant requirements for both your business and application to be considered.

Required scalability and use (Are you over-architecting something with 20 microservices used once a year?)
Business structure – can your development and operations team support a move to microservices?
How closely aligned to your business processes should microservices be? Are those processes well-defined?
Do you want to follow the domain-driven design, where your business needs define the outcomes of the application and its boundaries?
Is your application suitable for microservices, or are there parts that should be in a distributed monolith?
Each microservice, whether API-based, Event-Based or otherwise, should adhere to a contract for each version so that consumers of the event or requesters know the expected inputs and outputs for communicating with the microservice. Contracts should not be changed in a specific version. Any required changes should require a new version, and old versions should run alongside to allow consumers to update to the new version. Breaking changes in microservices have a larger impact than in other development types.

Microservice Anti-patterns

While microservices can provide a whole host of benefits, there are potential pitfalls to watch out for when developing microservices.

Assuming that just because you now use microservices, it solves all your problems
Making microservices the goal in itself, rather than using them as a tool to solve business problems. It's no use changing everything to microservices at the expense of developing features and fixing customer issues.
Piecemeal adoption, having just one team work on one aspect without co-ordination isn’t likely to work.
Uncoordinated adoption. If teams creating microservices don’t collaborate, different approaches and implementations could result, such as one team expecting streaming and another expecting pub/sub.
Focusing more on the technology than the overall service design and how the services communicate
Not changing organisational processes or structure to follow microservice patterns. For example, moving to microservices won't work if you still do six monthly deployments.
Not separating tasks correctly and just building multiple monoliths instead of single-focus microservices

Event Planning

Planning how your microservices communicate is a key step when moving to microservices.

Above is an example based on architecture by AWS, where the planning method has two main sections:

Planning what the microservices are and how they fit together by looking at the following:
- What input events trigger this microservice
- What the service does
- What actions the service takes
- What output events the microservice produces
Then you can drill down into each event and list:
- What attributes are in each event
- Which service owns/produces which event
- What the action that each Microservice was part of

Eventbridge Scheduler

Eventbridge Scheduler is a newer service from AWS that allows you to invoke tasks based on defined parameters. This allows you to perform tasks within your application and scheduled background tasks.

Integrates with 200+ services and over 6000 AWS API calls
Schedule tasks such as customer reminders, delayed actions, prompts to continue if the customer hasn’t performed an action
Perform cron-based tasks, one-time events, fixed-rate events, time-specific events
Add retries, dead letter queues and more

Service Coupling

Microservices are designed to be loosely coupled, in terms of their dependencies on each other, so that each service can act independently of another and not have to consider what is happening in other services.

However, this isn’t 100% the full story. Microservices are still coupled in certain ways, but mainly through semantic coupling.

This means that a microservice depends on events coming in being in a specific format so it knows how to deal with them, and similarly, any microservice that consumes events produced by another microservice needs to know the event format won't change.

Service Contract – events produced by a microservice shouldn’t change without warning, so contracts are important, with versioning being key
Schemas should be available for each event so that other consumers of these events know what the format is and what data is available.

Eventbridge Events

AWS Eventbridge uses a defined format for Events to be put onto the event bus.

An example of an event is shown above, and it is a JSON format document with specific minimum information to be considered valid:

A detail JSON object. (Can be blank, using “{}” )
A detail-type string identifies the type of event
A source string identifies the source. This cannot start with 'aws', but other values are ok.

However, adding in extra fields is recommended:

Id – a unique id per event
Version – event version number
Time – time the event was created

And more detail to help identify the event and provide the information required by the consumers about the event.

Example:

https://github.com/jbesw/eventbridge-sam-example

This GitHub repo from James Beswick – Principal Developer Advocate for AWS Serverless demonstrates setting up an event bus, and multiple microservices that outputs an event and consumes it, using the AWS SAM framework.

Deploying Docker Containers to Lambda using AWS SAM and CodePipeline (Part 1)

John Walker — Sat, 01 Oct 2022 01:56:14 +0000

Deploying to AWS lambda has many advantages, covering cost and speed of execution. There are many options for deployment, including through the console, AWS CLI, CloudFormation and AWS SAM. However, the standard Lambda package size has a limit of 50mb zipped and 250mb unzipped, which in some cases can cause issues, especially with some machine learning frameworks, where the dependencies can hit this limit before you've even written any code.

To solve this issue, you can deploy your code inside a docker container, which has an effective limit of up to 10GB.

Part 1 of this solution will go through a number of AWS Services to show how to use AWS SAM to deploy a docker container to AWS Lambda, based on the Hello World Template.

Part 2 will show how to add this to a CodeBuild and CodePipeline and deploy automatically via GitHub.

Part 1 will use:

AWS SAM
AWS Lambda
AWS API Gateway
Docker

Part 2 will then use:

Github
AWS Github App
AWS CodeStar Connection
AWS Code Pipeline
AWS CodeBuild
AWS CloudFormation

This is what our deployment will look like after both parts are completed:

The first step is to set up AWS Access Keys: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html

Then once you have the Access Key and Secret Key, you need to set them up in a terminal, by either setting up a profile, the AWS CLI directly using 'aws configure' or Environment Variables.

The core of this deployment method is to use the AWS SAM CLI. This deployment can be started with the sample hello world application.

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-getting-started-hello-world.html

You will need the AWS CLI and the AWS SAM CLI:

AWS CLI

AWS SAM CLI

You can also create a blank application, however some of the template.yaml file from the hello world sample application will be useful, and we'll be using it as the base of this guide.

#Step 1 - Download a sample application
sam init

#Step 2 - Build your application
cd sam-app
sam build

#Step 3 - Deploy your application
sam deploy --guided

This will deploy your Lambda Application and create an API Gateway for you. The guided deploy will have some options to choose, make sure you allow role creation, and at this step, allow deployment without authorisation (which you should set up later if you don't want a public API) as sam will not deploy without it.

You could stop here, but this guide will show you how to turn the Lambda deployment into a Docker Container, and then automate the deployment through the use of Code Pipeline, Code Build and link it to Github.

Within the sam-app folder that is generated, the first file you will need to update is the template.yaml file. The section that creates the Lambda Function is with the type AWS::Serverless::Function.

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
    Properties:
      CodeUri: hello_world/
      Handler: app.lambda_handler
      Runtime: python3.9
      Architectures:
        - x86_64
      Events:
        HelloWorld:
          Type: Api # More info about API Event Source: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#api
          Properties:
            Path: /hello
            Method: get

This deploys the Lambda as a python 3.9 application and zipped up, with the x86_64 architecture.

Containerising the Lambda

To change this to use docker we need to make some changes, and define an external docker_file. The main changes are the PackageType, ImageConfig and Metadata. We also remove the CodeUri, Handler and runtime as these are defined in the docker file.

We've also added a HelloWorldAPI section for the API, though one is implicitly defined. If you leave this out you will see some warnings about reserved keywords. This section is also where you can add Cors later on if needed.

Resources:
  HelloWorldAPI:
    Type: AWS::Serverless::Api
    Properties:
      Name: Hello World API
      StageName: Prod
  HelloWorldFunction:
    Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
    Properties:
      PackageType: Image
      ImageConfig:
        Command: ["app.lambda_handler"]
      Events:
        HelloWorld:
          Type: Api # More info about API Event Source: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#api
          Properties:
            RestApiId: !Ref HelloWorldAPI
            Path: /hello
            Method: get
    Metadata:
      Dockerfile: hello_world_docker
      DockerContext: .
      DockerTag: v1

We then create a docker file that creates our docker container.

FROM public.ecr.aws/lambda/python:3.9

COPY hello_world/. ./

RUN python3.9 -m pip install -r requirements.txt

CMD ["app.lambda_handler"]

This uses the Python 3.9 image from the Elastic Container Repository, then copies our code into the home directory of the container, runs python to install the requirements.txt (which just contains the requests module for now) and then sets the lambda_handler to be the entry point.

We then need to build the container with sam:

sam build --use-container -t template.yaml

You can then deploy the container to Lambda using:

sam deploy --stack-name sam-app --resolve-s3 --capabilities CAPABILITY_IAM --resolve-image-repos

(you may need to remove any stored config file from any previous sam build, likely to be called samconfig.toml or it may override, especially the s3 parameters).

This will deploy your lambda to a stack named sam-app, work out the s3 bucket to use for deployment, give permission to create IAM roles for deployment, and work out which ECR Repository to use.

With this deployed, you can go to the API Gateway URL mentioned in the output of the sam deploy command. You should see:

{"message": "hello world"}

Part 2 will create these commands inside a CodeBuild environment, allowing a Code Pipeline to take the code from a GitHub repository, then use the SAM CLI inside CodeBuild to build the container and deploy it automatically.

You can also use the aws cloudformation describe-stacks command inside CodeBuild to get the API generated, and use command line tools like sed to then replace this URL into other files, such as a front end (which could then also be deployed by CodeBuild, or another pipeline).

Part 2 coming soon.

DEV Community: John Walker

Implementing Guardrails on AWS Bedrock AgentCore

Creating a multi-agent deployment with Strands SDK and AWS Bedrock AgentCore

Deploying Terraform Code via AWS CodeBuild and AWS CodePipeline

Terraform - main.tf

S3 Artifacts - main.tf

Notifications - main.tf

IAM Roles - main.tf

CodeBuild Projects - main.tf

Code Pipeline - main.tf

Source Stage

Plan Stage

Approval Stage

Apply Stage

Outputs - main.tf

Variables - variables.tf

Conclusion

Deploying Amazon API Gateway and Lambda with Terraform

Architecture

API Gateway

Terraform

Terraform main.tf

Providers and Backend

Deploying the Terraform

Conclusion

Controlling Cloud Costs: Strategies for keeping on top of your AWS cloud spend

Cloud Costs Overview

Management Strategies

FinOps Foundation Principles

Reviews

DevOps and Infrastructure as Code

Hidden / Obscure Costs

Example Savings

Microservices and Eventbridge

Microservices

Microservice Types

Why Use Microservices?

When not to use Microservices?

Event-Driven Services

Event-Driven Service Examples

EventBridge

Microservice Considerations

Microservice Anti-patterns

Event Planning

Eventbridge Scheduler

Service Coupling

Eventbridge Events

Example:

Further Reading:

Deploying Docker Containers to Lambda using AWS SAM and CodePipeline (Part 1)

Containerising the Lambda