DEV Community: nao1515

Running a Tomcat App on ECS Fargate — A Complete Step-by-Step Guide

nao1515 — Sun, 10 May 2026 08:50:36 +0000

Introduction

This guide walks you through migrating an existing Tomcat application to AWS ECS Fargate — covering everything from session management and DB migration to Auto Scaling, with a production-ready setup in mind.

Who this is for

Developers migrating a Tomcat app to AWS
Engineers new to ECS Fargate

Final Architecture

Internet
    │
   ALB (port 80/443)
    │
  ECS Fargate
    ├─ ElastiCache (Redis) ← session store
    └─ RDS (PostgreSQL)   ← persistent data

STEP 1: Create Security Groups

Create dedicated security groups for ALB, ECS, Redis, and RDS. Following the principle of least privilege, only allow what is strictly necessary.

# ALB — allow HTTP/HTTPS from the internet
aws ec2 create-security-group \
  --group-name sg-alb \
  --description "ALB SG" \
  --vpc-id vpc-xxxxxxxx

aws ec2 authorize-security-group-ingress \
  --group-id sg-alb --protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress \
  --group-id sg-alb --protocol tcp --port 443 --cidr 0.0.0.0/0

# ECS — allow 8080 from ALB only
aws ec2 create-security-group \
  --group-name sg-ecs \
  --description "ECS SG" \
  --vpc-id vpc-xxxxxxxx

aws ec2 authorize-security-group-ingress \
  --group-id sg-ecs --protocol tcp --port 8080 \
  --source-group sg-alb

# Redis — allow 6379 from ECS only
aws ec2 create-security-group \
  --group-name sg-redis \
  --description "Redis SG" \
  --vpc-id vpc-xxxxxxxx

aws ec2 authorize-security-group-ingress \
  --group-id sg-redis --protocol tcp --port 6379 \
  --source-group sg-ecs

# RDS — allow 5432 from ECS only
aws ec2 create-security-group \
  --group-name sg-rds \
  --description "RDS SG" \
  --vpc-id vpc-xxxxxxxx

aws ec2 authorize-security-group-ingress \
  --group-id sg-rds --protocol tcp --port 5432 \
  --source-group sg-ecs

Here is a summary of the security group rules:

Security Group	Inbound Rule
sg-alb	0.0.0.0/0 → 80, 443
sg-ecs	sg-alb → 8080
sg-redis	sg-ecs → 6379
sg-rds	sg-ecs → 5432

STEP 2: Store Credentials in Secrets Manager

Store passwords and other sensitive values in Secrets Manager so they never appear as plain text in your task definition.

aws secretsmanager create-secret \
  --name myapp/db-password \
  --secret-string "your-db-password"

aws secretsmanager create-secret \
  --name myapp/db-user \
  --secret-string "your-db-user"

aws secretsmanager create-secret \
  --name myapp/redis-password \
  --secret-string "your-redis-password"

STEP 3: Provision RDS

# Subnet group (private subnets)
aws rds create-db-subnet-group \
  --db-subnet-group-name myapp-rds-subnet \
  --db-subnet-group-description "myapp RDS subnet" \
  --subnet-ids subnet-aaaaaaaa subnet-bbbbbbbb

# RDS instance
aws rds create-db-instance \
  --db-instance-identifier myapp-db \
  --db-instance-class db.t4g.small \
  --engine postgres \
  --engine-version 15.4 \
  --master-username myapp \
  --master-user-password "your-db-password" \
  --db-name myapp \
  --db-subnet-group-name myapp-rds-subnet \
  --vpc-security-group-ids sg-rds \
  --multi-az \
  --storage-type gp3 \
  --allocated-storage 20 \
  --no-publicly-accessible

STEP 4: Provision ElastiCache (Redis)

Because Fargate replaces the underlying instance on every task restart, any session stored in memory will be lost. With multiple tasks running, a request routed to a different task will fail to find the session.

Externalizing sessions to ElastiCache (Redis) solves both problems.

# Subnet group
aws elasticache create-cache-subnet-group \
  --cache-subnet-group-name myapp-redis-subnet \
  --cache-subnet-group-description "myapp redis subnet" \
  --subnet-ids subnet-aaaaaaaa subnet-bbbbbbbb

# Parameter group
aws elasticache create-cache-parameter-group \
  --cache-parameter-group-name myapp-redis-params \
  --cache-parameter-group-family redis7 \
  --description "myapp redis params"

aws elasticache modify-cache-parameter-group \
  --cache-parameter-group-name myapp-redis-params \
  --parameter-name-values \
    ParameterName=maxmemory-policy,ParameterValue=allkeys-lru \
    ParameterName=timeout,ParameterValue=300

# Redis cluster (Multi-AZ, encrypted)
aws elasticache create-replication-group \
  --replication-group-id myapp-redis \
  --description "myapp session store" \
  --engine redis \
  --engine-version 7.0 \
  --cache-node-type cache.t4g.medium \
  --num-cache-clusters 2 \
  --multi-az-enabled \
  --automatic-failover-enabled \
  --cache-subnet-group-name myapp-redis-subnet \
  --cache-parameter-group-name myapp-redis-params \
  --security-group-ids sg-redis \
  --at-rest-encryption-enabled \
  --transit-encryption-enabled \
  --auth-token "your-redis-password"

Spring Session configuration

Add the dependencies to pom.xml:

<dependency>
    <groupId>org.springframework.session</groupId>
    <artifactId>spring-session-data-redis</artifactId>
</dependency>
<dependency>
    <groupId>io.lettuce</groupId>
    <artifactId>lettuce-core</artifactId>
</dependency>

Configure application.yml:

spring:
  session:
    store-type: redis
    timeout: 30m
  data:
    redis:
      host: ${REDIS_HOST}
      port: ${REDIS_PORT}
      password: ${REDIS_PASSWORD}
      ssl:
        enabled: true
      lettuce:
        pool:
          max-active: 8
          max-idle: 8
          min-idle: 2

STEP 5: Build Docker Images and Push to ECR

Dockerfile (application)

FROM tomcat:10.1-jdk17

RUN rm -rf /usr/local/tomcat/webapps/*
COPY target/myapp.war /usr/local/tomcat/webapps/ROOT.war

EXPOSE 8080
CMD ["catalina.sh", "run"]

Dockerfile.migration (Flyway)

FROM flyway/flyway:10-alpine

COPY db/migration /flyway/sql
COPY flyway.conf /flyway/conf/flyway.conf

ENTRYPOINT ["flyway", "migrate"]

flyway.conf:

flyway.url=jdbc:postgresql://${DB_HOST}:5432/${DB_NAME}
flyway.user=${DB_USER}
flyway.password=${DB_PASSWORD}
flyway.locations=filesystem:/flyway/sql
flyway.baselineOnMigrate=true

Push to ECR

# Create repositories
aws ecr create-repository --repository-name myapp
aws ecr create-repository --repository-name myapp-migration

# Login
aws ecr get-login-password --region ap-northeast-1 \
  | docker login --username AWS --password-stdin \
    <account_id>.dkr.ecr.ap-northeast-1.amazonaws.com

# Application image
docker build -t myapp .
docker tag myapp:latest \
  <account_id>.dkr.ecr.ap-northeast-1.amazonaws.com/myapp:latest
docker push \
  <account_id>.dkr.ecr.ap-northeast-1.amazonaws.com/myapp:latest

# Migration image
docker build -f Dockerfile.migration -t myapp-migration .
docker tag myapp-migration:latest \
  <account_id>.dkr.ecr.ap-northeast-1.amazonaws.com/myapp-migration:latest
docker push \
  <account_id>.dkr.ecr.ap-northeast-1.amazonaws.com/myapp-migration:latest

STEP 6: Create CloudWatch Logs Groups

aws logs create-log-group --log-group-name /ecs/myapp/migration
aws logs create-log-group --log-group-name /ecs/myapp/tomcat

STEP 7: Create the IAM Execution Role

The ECS agent needs this role to pull images from ECR and fetch secrets from Secrets Manager.

aws iam create-role \
  --role-name ecsTaskExecutionRole \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": { "Service": "ecs-tasks.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }]
  }'

aws iam attach-role-policy \
  --role-name ecsTaskExecutionRole \
  --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy

aws iam attach-role-policy \
  --role-name ecsTaskExecutionRole \
  --policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite

STEP 8: Register the Task Definition

The key point here is dependsOn with condition: SUCCESS — Tomcat will not start until the migration container exits cleanly.

{
  "family": "myapp-task",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::<account_id>:role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      "name": "migration",
      "image": "<account_id>.dkr.ecr.ap-northeast-1.amazonaws.com/myapp-migration:latest",
      "essential": false,
      "secrets": [
        { "name": "DB_USER", "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:<account_id>:secret:myapp/db-user" },
        { "name": "DB_PASSWORD", "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:<account_id>:secret:myapp/db-password" }
      ],
      "environment": [
        { "name": "DB_HOST", "value": "myapp-db.xxxx.ap-northeast-1.rds.amazonaws.com" },
        { "name": "DB_NAME", "value": "myapp" }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/myapp/migration",
          "awslogs-region": "ap-northeast-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    },
    {
      "name": "tomcat",
      "image": "<account_id>.dkr.ecr.ap-northeast-1.amazonaws.com/myapp:latest",
      "essential": true,
      "dependsOn": [
        { "containerName": "migration", "condition": "SUCCESS" }
      ],
      "portMappings": [
        { "containerPort": 8080, "protocol": "tcp" }
      ],
      "environment": [
        { "name": "DB_HOST", "value": "myapp-db.xxxx.ap-northeast-1.rds.amazonaws.com" },
        { "name": "DB_NAME", "value": "myapp" },
        { "name": "REDIS_HOST", "value": "myapp-redis.xxxx.ng.0001.apne1.cache.amazonaws.com" },
        { "name": "REDIS_PORT", "value": "6379" },
        { "name": "TZ", "value": "Asia/Tokyo" }
      ],
      "secrets": [
        { "name": "DB_USER", "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:<account_id>:secret:myapp/db-user" },
        { "name": "DB_PASSWORD", "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:<account_id>:secret:myapp/db-password" },
        { "name": "REDIS_PASSWORD", "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:<account_id>:secret:myapp/redis-password" }
      ],
      "healthCheck": {
        "command": ["CMD-SHELL", "curl -f http://localhost:8080/health || exit 1"],
        "interval": 30,
        "timeout": 5,
        "retries": 3,
        "startPeriod": 90
      },
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/myapp/tomcat",
          "awslogs-region": "ap-northeast-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

aws ecs register-task-definition \
  --cli-input-json file://task-definition.json

Note: Setting essential: false on the migration container means the task keeps running after migration completes. Tomcat uses condition: SUCCESS to wait for a clean exit before starting.

STEP 9: Create the ALB

# Create ALB
aws elbv2 create-load-balancer \
  --name myapp-alb \
  --subnets subnet-aaaaaaaa subnet-bbbbbbbb \
  --security-groups sg-alb \
  --scheme internet-facing \
  --type application

# Create target group
# Important: Fargate requires --target-type ip, not instance
aws elbv2 create-target-group \
  --name myapp-tg \
  --protocol HTTP \
  --port 8080 \
  --vpc-id vpc-xxxxxxxx \
  --target-type ip \
  --health-check-path /health \
  --health-check-interval-seconds 30 \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 3

# Create listener
aws elbv2 create-listener \
  --load-balancer-arn <alb-arn> \
  --protocol HTTP \
  --port 80 \
  --default-actions Type=forward,TargetGroupArn=<tg-arn>

# Shorten deregistration delay (default 300s is too long)
aws elbv2 modify-target-group-attributes \
  --target-group-arn <tg-arn> \
  --attributes Key=deregistration_delay.timeout_seconds,Value=30

STEP 10: Create the ECS Cluster and Service

# Create cluster
aws ecs create-cluster --cluster-name myapp-cluster

# Create service
aws ecs create-service \
  --cluster myapp-cluster \
  --service-name myapp-service \
  --task-definition myapp-task \
  --desired-count 8 \
  --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={
    subnets=[subnet-aaaaaaaa,subnet-bbbbbbbb],
    securityGroups=[sg-ecs],
    assignPublicIp=DISABLED
  }" \
  --load-balancers "targetGroupArn=<tg-arn>,containerName=tomcat,containerPort=8080" \
  --deployment-configuration \
    "minimumHealthyPercent=50,maximumPercent=200,deploymentCircuitBreaker={enable=true,rollback=true}"

Enabling deploymentCircuitBreaker means ECS automatically rolls back to the previous revision if a deployment fails repeatedly.

STEP 11: Configure Auto Scaling

Auto Scaling handles traffic spikes without manual intervention.

aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/myapp-cluster/myapp-service \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 4 \
  --max-capacity 12

aws application-autoscaling put-scaling-policy \
  --policy-name cpu-tracking \
  --service-namespace ecs \
  --resource-id service/myapp-cluster/myapp-service \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    },
    "ScaleOutCooldown": 60,
    "ScaleInCooldown": 300
  }'

Setting	Value	Reason
min-capacity	4	Baseline task count
max-capacity	12	Peak capacity
TargetValue	70%	Scale out when CPU exceeds 70%
ScaleOutCooldown	60s	React quickly to load spikes
ScaleInCooldown	300s	Prevent aggressive scale-in

Verify the Deployment

# Check running tasks
aws ecs list-tasks --cluster myapp-cluster

# Check service status
aws ecs describe-services \
  --cluster myapp-cluster \
  --services myapp-service \
  --query 'services[0].{Status:status,Running:runningCount,Desired:desiredCount}'

# Get the ALB DNS name and open it in a browser
aws elbv2 describe-load-balancers \
  --names myapp-alb \
  --query 'LoadBalancers[0].DNSName'

Common Pitfalls

Problem	Cause	Fix
Task exits immediately after start	Application startup error	Check CloudWatch Logs for the stack trace
Health check never passes	Tomcat takes too long to start	Set `startPeriod` to 90–120 seconds
Cannot pull image from ECR	Missing permissions on `ecsTaskExecutionRole`	Attach `AmazonECSTaskExecutionRolePolicy`
Cannot connect to Redis	Security group misconfiguration	Verify sg-ecs → sg-redis on port 6379
Tomcat does not start after migration	Missing `dependsOn`	Add `condition: SUCCESS` to the task definition
ALB returns 502	Target type set to `instance`	Change to `ip`

Summary

Step	What you do
1	Create security groups
2	Store credentials in Secrets Manager
3	Provision RDS
4	Provision ElastiCache
5	Build images and push to ECR
6	Create CloudWatch Logs groups
7	Create IAM execution role
8	Register task definition
9	Create ALB
10	Create ECS cluster and service
11	Configure Auto Scaling

Fargate eliminates server management and hands off deployment and scaling to AWS. Setting up session management, DB migration, and Auto Scaling from the start dramatically reduces rework later.

Production-Ready AWS 3-Tier Architecture with Terraform (SSM & Secrets Manager)

nao1515 — Tue, 05 May 2026 14:56:34 +0000

Introduction

Building a "VPC-EC2-RDS" stack is a common task, but making it production-ready requires more than just resource creation. In this post, I will share a modular Terraform setup that implements:

Modular Design: Reusable code for VPC, EC2, and RDS.
Bastion-less Access: Using AWS Systems Manager (SSM) instead of SSH.
Secret Management: Managing RDS passwords via AWS Secrets Manager.

Project Structure

We follow the standard environment/module separation to ensure scalability.

terraform/
├── envs/
│   └── dev/                # Environment-specific configuration
│       ├── main.tf         # Root module calling local modules
│       └── terraform.tfvars
└── modules/
    ├── vpc/                # Networking & Security Groups
    ├── ec2/                # IAM Roles & SSM-ready Instances
    └── rds/                # Private Database Instances

Key Features

Networking (modules/vpc)

We define a VPC with both public and private subnets. The RDS instance stays in the private subnet, while the EC2 is also kept private for maximum security, relying on the NAT Gateway for outbound traffic.

resource "aws_vpc" "this" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags = { Name = "${var.project}-${var.env}-vpc" }
}

resource "aws_security_group" "web" {
  name   = "${var.project}-${var.env}-web-sg"
  vpc_id = aws_vpc.this.id

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_security_group" "db" {
  name   = "${var.project}-${var.env}-db-sg"
  vpc_id = aws_vpc.this.id

  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.web.id]
  }
}

modules/ec2: Bastion-less Access via SSM

Build secure EC2 instances by closing all SSH ports and leveraging AWS Systems Manager (SSM) for remote access.

IAM Instance Profile for SSM Permissions
Instead of managing SSH keys, we attach an IAM role with the AmazonSSMManagedInstanceCore policy. This allows secure terminal access through the AWS Console or CLI.

Deployment in Private Subnets
The instances are placed in private subnets with no public IP addresses, significantly reducing the attack surface by making them inaccessible from the open internet.

resource "aws_instance" "this" {
  ami                    = var.ami_id
  instance_type          = var.instance_type
  subnet_id              = var.subnet_id
  vpc_security_group_ids = var.security_group_ids
  iam_instance_profile   = aws_iam_instance_profile.ssm_profile.name

  metadata_options {
    http_endpoint = "enabled"
    http_tokens   = "required"
  }

  tags = { Name = "${var.project}-${var.env}-ec2" }
}

resource "aws_iam_role" "ssm_role" {
  name = "${var.project}-${var.env}-ssm-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{ Action = "sts:AssumeRole", Effect = "Allow", Principal = { Service = "ec2.amazonaws.com" } }]
  })
}

resource "aws_iam_role_policy_attachment" "ssm_managed" {
  role       = aws_iam_role.ssm_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

modules/rds: Managed Database Layer

We deploy a production-grade PostgreSQL instance with a focus on maximum security and automated credential management.

Private Isolation from External Traffic
The database is placed in a dedicated private subnet with publicly_accessible = false. All direct ingress from the internet is strictly blocked, ensuring your data remains isolated.

Dynamic Password Injection via Variables
To avoid hardcoding sensitive information, the database password is parameterized. This allows for dynamic injection from higher-level environments or secret management services (like AWS Secrets Manager), ensuring a secure CI/CD pipeline.

resource "aws_db_subnet_group" "this" {
  name       = "${var.project}-${var.env}-rds-subnet-group"
  subnet_ids = var.subnet_ids
}

resource "aws_db_instance" "this" {
  identifier             = var.identifier
  engine                 = var.engine
  engine_version         = var.engine_version
  instance_class         = var.instance_class
  allocated_storage      = 20
  db_name                = var.database_name
  username               = var.master_username
  password               = var.master_password
  db_subnet_group_name   = aws_db_subnet_group.this.name
  vpc_security_group_ids = var.security_group_ids
  publicly_accessible    = false
  skip_final_snapshot    = true
}

envs/dev: Environment-Specific Configuration & Secret Management

In this directory, we integrate the individual modules to build a complete "Development" environment while ensuring that sensitive information like passwords is handled securely.

Secure RDS Password Retrieval via AWS Secrets Manager
Instead of hardcoding database credentials, we dynamically fetch the RDS master password from AWS Secrets Manager at runtime.

data "aws_secretsmanager_secret" "rds_password" {
  name = "${var.project}/${var.env}/rds-password"
}

data "aws_secretsmanager_secret_version" "rds_password" {
  secret_id = data.aws_secretsmanager_secret.rds_password.id
}

module "vpc" {
  source   = "../../modules/vpc"
  vpc_cidr = var.vpc_cidr
  # ...
}

module "rds" {
  source          = "../../modules/rds"
  master_password = data.aws_secretsmanager_secret_version.rds_password.secret_string
  vpc_id          = module.vpc.vpc_id
  subnet_ids      = module.vpc.private_subnet_ids
  security_group_ids = [module.vpc.db_sg_id]
}

module "ec2" {
  source             = "../../modules/ec2"
  subnet_id          = module.vpc.private_subnet_ids[0]
  security_group_ids = [module.vpc.web_sg_id]
}

Conclusion: Aiming for Production-Ready Terraform Architecture

In this walkthrough, we didn't just focus on turning resources into code. We prioritized the core pillars required in real-world operations: Maintainability, Security, and Reusability.

Key Benefits of This Architecture
Environment Portability
Need a production environment? Just create a new envs/prod/ directory. You can replicate this entire stack for production in minutes.

Moving Beyond Bastion Hosts
By leveraging AWS Systems Manager (SSM), we've eliminated the security risk of leaving SSH ports open to the world.

Proper Secret Management
With AWS Secrets Manager, sensitive passwords are decoupled from your codebase, ensuring they never leak into your Git history.

Infrastructure as Code (IaC) with Terraform is a powerful weapon that drastically reduces manual engineering hours and prevents human error. I encourage you to take this template and customize it to fit the specific needs of your own projects.

Connect to RDS (PostgreSQL) in a Private Subnet via AWS Client VPN

nao1515 — Sun, 03 May 2026 17:09:53 +0000

Introduction

Placing RDS in a private subnet protects it from unauthorized external access — but it also means you can no longer connect directly from your developer machine.

This article walks you through a step-by-step guide to securely connect to a private-subnet RDS (PostgreSQL) instance using AWS Client VPN.

Architecture Overview

Developer PC
  │
  │  UDP 443 (TLS / Mutual Certificate Authentication)
  ▼
Client VPN Endpoint (Public Subnet)
  │
  │  Authorization Rule + Route Table
  ▼
Private Subnet
  │
  │  SG: Port 5432 allowed from Client CIDR
  ▼
Amazon RDS (PostgreSQL)

Prerequisites

Item	Value
VPC CIDR	`10.0.0.0/16`
Public Subnet	`10.0.0.0/24` (for VPN association)
Private Subnet	`10.0.1.0/24` (for RDS)
Client CIDR	`10.100.0.0/22` (IP range assigned to VPN clients)
DB Engine	PostgreSQL
Port	5432

Step 1: Create Certificates and Import to ACM

Generate server and client certificates using Easy-RSA.

git clone https://github.com/OpenVPN/easy-rsa.git
cd easy-rsa/easyrsa3

./easyrsa init-pki
./easyrsa build-ca nopass
./easyrsa build-server-full server nopass
./easyrsa build-client-full client1 nopass

Import the generated certificates into ACM.

# Server certificate
aws acm import-certificate \
  --certificate fileb://pki/issued/server.crt \
  --private-key fileb://pki/private/server.key \
  --certificate-chain fileb://pki/ca.crt \
  --region ap-northeast-1

# Client certificate
aws acm import-certificate \
  --certificate fileb://pki/issued/client1.crt \
  --private-key fileb://pki/private/client1.key \
  --certificate-chain fileb://pki/ca.crt \
  --region ap-northeast-1

Important: The ACM region must match the region where you create the Client VPN endpoint.

Step 2: Create the Client VPN Endpoint

Go to AWS Management Console → VPC → Client VPN Endpoints → Create

Setting	Value
Client IPv4 CIDR	`10.100.0.0/22`
Server Certificate ARN	Server certificate imported in ACM
Authentication Type	Mutual Authentication (client certificate)
Client Certificate ARN	Client certificate imported in ACM
DNS Server	`10.0.0.2` (VPC DNS)
Protocol	UDP
Split Tunnel	Enabled

Why enable Split Tunnel? Only traffic destined for the VPC is routed through the VPN. This avoids impacting regular internet traffic and improves performance.

Step 3: Associate a Target Network

Client VPN Endpoint → Target Network Associations → Associate

Subnet to associate: Public Subnet (10.0.0.0/24)

Step 4: Add Authorization Rules and Routes

Authorization Rule

Client VPN Endpoint → Authorization Rules → Add Authorization Rule

Field	Value
Destination CIDR	`10.0.1.0/24` (RDS subnet)
Grant access to	All users

Add Route

Client VPN Endpoint → Route Table → Create Route

Field	Value
Route Destination	`10.0.1.0/24`
Target Subnet	The subnet associated in Step 3

Step 5: Configure Security Groups

Client VPN Endpoint SG

No inbound rules needed for the Client VPN endpoint SG.

Because Client VPN is a managed AWS service, you do not need to add an inbound rule for UDP 443 to its security group. Only outbound rules are required.

Direction	Protocol	Port	Target
Outbound	All	All	`0.0.0.0/0`

RDS Security Group (Critical)

You must allow inbound traffic from the Client CIDR to the RDS security group.

Direction	Protocol	Port	Source
Inbound	TCP	5432	`10.100.0.0/22` (Client CIDR)

This is the most important step. Without allowing port 5432 from the Client CIDR in the RDS security group, the connection will never succeed — no matter how correctly the VPN is configured.

Step 6: Prepare the Client Configuration File

Download the .ovpn File

Client VPN Endpoint → Download Client Configuration

Append Certificate Information

Add the client certificate and private key to the end of the downloaded .ovpn file.

# View certificate contents
cat pki/issued/client1.crt
cat pki/private/client1.key

# Append to the end of the .ovpn file
<cert>
-----BEGIN CERTIFICATE-----
(Paste the contents of client1.crt here)
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN PRIVATE KEY-----
(Paste the contents of client1.key here)
-----END PRIVATE KEY-----
</key>

Step 7: Connect via VPN and Verify RDS Access

Connect to the VPN

# Using CLI
sudo openvpn --config downloaded-client-config.ovpn

# Or use the AWS VPN Client (GUI)

Verify Connectivity

# Check port reachability
nc -zv mydb.xxxxxx.ap-northeast-1.rds.amazonaws.com 5432
# Connection to mydb... 5432 port [tcp/postgresql] succeeded!

Connect to PostgreSQL

psql \
  -h mydb.xxxxxx.ap-northeast-1.rds.amazonaws.com \
  -U postgres \
  -d mydb \
  -p 5432

If the connection is successful, you'll see:

psql (15.x)
SSL connection (protocol: TLSv1.3, ...)
Type "help" for help.

mydb=#

Verify VPC DNS Settings

RDS endpoint hostname resolution requires proper VPC DNS configuration.

VPC → Settings

Setting	Value
DNS Resolution	Enabled
DNS Hostnames	Enabled

Set the VPC DNS address (e.g., 10.0.0.2) as the DNS server in the Client VPN endpoint settings so that RDS endpoint names resolve correctly from the client.

Troubleshooting

Symptom	What to Check
Connection times out	Is port 5432 from the Client CIDR allowed in the RDS SG inbound rules?
DNS resolution fails	Is the VPC DNS (subnet base + 2) set as the DNS server on the VPN endpoint?
VPN itself won't connect	Does the ACM certificate region match the Client VPN endpoint region?
VPN connected but can't reach RDS	With Split Tunnel enabled, is `10.0.1.0/24` added to the route table?
Authorization rule error	Is the Client CIDR `10.100.0.0/22` included in routes and authorization rules?

Summary

Component	Configuration	Key Point
Client VPN Endpoint SG	Outbound only	No inbound rules needed
RDS SG	Inbound port 5432	Source = Client CIDR
Authorization Rule	Allow private subnet CIDR	—
Route Table	Add private subnet CIDR	—
Split Tunnel	Enabled	Only VPC traffic goes through VPN

A common misconception is that you need to open inbound UDP 443 on the Client VPN endpoint's security group — you don't. What matters is allowing the Client CIDR on the destination resource (RDS) security group.

References

aws

nao1515 — Sun, 03 May 2026 11:41:56 +0000