For Compose basics, see the Docker Compose overview. This post covers DynamoDB Local and ElasticMQ (SQS-compatible) for local AWS-style development.

Prerequisites

• Docker Compose installed

Configuration

The following configuration spins up DynamoDB Local, DynamoDB Admin, ElasticMQ, and the ElasticMQ UI.

Connection details:

• DynamoDB endpoint: http://localhost:8000
• SQS endpoint: http://localhost:9324
• DynamoDB Admin: http://localhost:8001
• ElasticMQ UI: http://localhost:3000
• Region: us-east-1
• Credentials: any dummy values (for example local / local)

# docker-compose.yml
services:
  dynamodb:
    image: amazon/dynamodb-local:latest
    user: root
    command: '-jar DynamoDBLocal.jar -sharedDb -dbPath /home/dynamodblocal/data'
    ports:
      - '8000:8000'
    volumes:
      - dynamodb_data:/home/dynamodblocal/data
  dynamodb-admin:
    image: aaronshaf/dynamodb-admin:latest
    ports:
      - '8001:8001'
    environment:
      DYNAMO_ENDPOINT: http://dynamodb:8000
      AWS_REGION: us-east-1
      AWS_ACCESS_KEY_ID: local
      AWS_SECRET_ACCESS_KEY: local
    depends_on:
      - dynamodb
  elasticmq:
    image: softwaremill/elasticmq-native:latest
    ports:
      - '9324:9324'
    volumes:
      - ./elasticmq.conf:/opt/elasticmq.conf
      - elasticmq_data:/data
  elasticmq-ui:
    image: softwaremill/elasticmq-ui:latest
    ports:
      - '3000:3000'
    environment:
      SQS_ENDPOINT: http://elasticmq:9324
    depends_on:
      - elasticmq
volumes:
  dynamodb_data:
  elasticmq_data:

ElasticMQ loads queue definitions from an elasticmq.conf file included in the demo.

Run the following command to spin up the containers.

docker compose up -d

Disclaimer

ElasticMQ provides an SQS-compatible API, but it is not AWS SQS. DynamoDB Local also differs from managed DynamoDB (for example capacity modes, streams, TTL, and global tables). Use these containers for local development and integration tests, not as production substitutes.

Demo

Docker Compose files and scripts for this post live in the dynamodb-sqs-docker-compose folder. Get access via code demos.

Infrastructure as Code (IaC) is a DevOps approach where infrastructure is defined and managed using code instead of manual setup. This makes environments reproducible, version-controlled, and easy to scale.

In this guide, you'll provision an AWS EC2 instance using the AWS Cloud Development Kit (CDK). CDK lets you define infrastructure in TypeScript (or other languages), synthesize CloudFormation templates, and deploy stacks through the CDK CLI.

Requirements

Before starting, install:

• Node.js version 26
• AWS CDK CLI (npm i -g aws-cdk)
• AWS CLI

AWS Credentials Setup

1. Go to IAM → Security credentials in AWS
2. Create access keys
3. Configure locally:

aws configure

This stores credentials in:

• ~/.aws/credentials
• ~/.aws/config

CDK requires CloudFormation permissions (and bootstrap-related IAM/S3 access). An IAM user scoped only for Terraform EC2 is often insufficient - attach broader permissions or use a dedicated CDK user.

Project Structure

A simple CDK TypeScript setup:

.
├── bin/
│   └── app.ts
├── lib/
│   └── ec2-stack.ts
├── cdk.json
├── package.json
└── tsconfig.json

Install dependencies:

npm i

App Entry

The CDK app wires stacks together in bin/app.ts:

#!/usr/bin/env node
import * as cdk from 'aws-cdk-lib';
import { Ec2Stack } from '../lib/ec2-stack';
const app = new cdk.App();
new Ec2Stack(app, 'Ec2Stack', {
  env: {
    account: process.env.CDK_DEFAULT_ACCOUNT,
    region: process.env.CDK_DEFAULT_REGION ?? 'eu-north-1',
  },
  instanceName: app.node.tryGetContext('instanceName') ?? 'MyEC2Name',
});

Set the target account and region once per shell session:

export CDK_DEFAULT_ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
export CDK_DEFAULT_REGION=eu-north-1

On Windows PowerShell:

$env:CDK_DEFAULT_ACCOUNT = aws sts get-caller-identity --query Account --output text
$env:CDK_DEFAULT_REGION = "eu-north-1"

Stack and EC2 Instance

Define the stack in lib/ec2-stack.ts:

import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import { Construct } from 'constructs';
export interface Ec2StackProps extends cdk.StackProps {
  instanceName?: string;
}
export class Ec2Stack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: Ec2StackProps) {
    super(scope, id, props);
    const instanceName = props?.instanceName ?? 'MyEC2Name';
    const instance = new ec2.Instance(this, 'AppServer', {
      vpc: ec2.Vpc.fromLookup(this, 'DefaultVpc', { isDefault: true }),
      instanceType: ec2.InstanceType.of(
        ec2.InstanceClass.T3,
        ec2.InstanceSize.MICRO,
      ),
      machineImage: ec2.MachineImage.latestAmazonLinux2023(),
      instanceName,
    });
    new cdk.CfnOutput(this, 'InstanceId', {
      value: instance.instanceId,
      description: 'EC2 instance ID',
    });
    new cdk.CfnOutput(this, 'InstancePublicIp', {
      value: instance.instancePublicIp,
      description: 'Public IP address',
    });
  }
}

CDK resolves the default VPC during synthesis. Amazon Linux 2023 is selected automatically for the current region.

Configuration

CDK settings live in cdk.json:

{
  "app": "npx ts-node --prefer-ts-exts bin/app.ts",
  "context": {
    "instanceName": "MyEC2Name"
  }
}

Change instanceName in context to override the default tag without editing stack code.

CDK Workflow

Bootstrap the environment (once per account/region):

• cdk bootstrap

Preview the CloudFormation template:

• cdk synth

Compare deployed stack with local changes:

• cdk diff

Deploy the stack:

• cdk deploy

Destroy infrastructure:

• cdk destroy

Important Notes

• State management

CDK deploys through CloudFormation. Stack state lives in AWS, not in a local file like Terraform's terraform.tfstate.

• Bootstrap stack

The first cdk bootstrap creates an S3 bucket and IAM roles CDK uses for deployments. Keep the bootstrap stack in place while you use CDK in that account/region.

• Idempotency

Running cdk deploy again updates the stack in place when possible instead of recreating resources unnecessarily.

• Version control

Treat CDK code like application code. Commit cdk.json and lockfiles; do not commit cdk.out/ or node_modules/.

Demo

CDK project files for this post live in the cdk-aws-ec2 folder. Get access via code demos.

Infrastructure as Code (IaC) is a DevOps approach where infrastructure is defined and managed using code instead of manual setup. This makes environments reproducible, version-controlled, and easy to scale.

In this guide, you'll provision an AWS EC2 instance using Terraform.

Requirements

Before starting, install:

• Terraform
• AWS CLI

AWS Credentials Setup

1. Go to IAM → Security credentials in AWS
2. Create access keys
3. Configure locally:

aws configure

This stores credentials in:

• ~/.aws/credentials
• ~/.aws/config

Project Structure

A simple Terraform setup:

.
├── main.tf
├── variables.tf
├── terraform.tfvars
├── outputs.tf

Provider Configuration

Define your cloud provider in main.tf:

provider "aws" {
  profile = "default"
  region  = "eu-north-1"
}

Variables

Define reusable variables in variables.tf:

variable "instance_name" {
  description = "Name tag for EC2 instance"
  type        = string
  default     = "MyNewInstance"
}
variable "ec2_instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t3.micro"
}

Set values in terraform.tfvars:

instance_name      = "MyEC2Name"
ec2_instance_type  = "t3.micro"

EC2 Instance Configuration

Add the resource in main.tf:

resource "aws_instance" "app_server" {
  ami           = "ami-077d1b9f9a1902bbc"
  instance_type = var.ec2_instance_type
  tags = {
    Name = var.instance_name
  }
}

You can find AMI IDs in EC2 → Images → AMI Catalog.

Outputs

Expose useful data in outputs.tf:

output "instance_id" {
  description = "EC2 instance ID"
  value       = aws_instance.app_server.id
}
output "instance_public_ip" {
  description = "Public IP address"
  value       = aws_instance.app_server.public_ip
}

Terraform Workflow

Initialize the project:

• terraform init

Preview changes:

• terraform plan

Apply changes:

• terraform apply

Destroy infrastructure:

• terraform destroy

Important Notes

• State file

Terraform stores infrastructure state in terraform.tfstate.

Do not commit this file to Git.

• Remote state (recommended)

For teams, store state in S3 with locking.

• Idempotency

Running apply multiple times won't recreate resources unnecessarily.

• Version control

Treat Terraform code like application code.

Demo

Terraform files for this post live in the terraform-aws-ec2 folder. Get access via code demos.