Forem: nao1515

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