Cloud Performance Testing & Infrastructure-as-Code Security: Terraform, CloudFormation, and Policy Validation

Introduction

Cloud performance and infrastructure security represent two of the most critical pillars in modern DevOps practices. According to 2025 cloud security research, 99% of cloud breaches trace to preventable misconfigurations, while performance issues cost organizations an estimated $15,000 per minute of downtime. This comprehensive guide bridges both domains—showing how to optimize cloud network performance, validate infrastructure-as-code (IaC) security, and enforce policy guardrails across Terraform, CloudFormation, and container orchestration platforms.

Whether you're migrating workloads to the cloud, scaling existing infrastructure, or hardening your security posture, this article provides actionable techniques used by Fortune 500 cloud architects and platform engineers. We'll cover:

1. Performance Testing Fundamentals - Load testing, latency analysis, and benchmark strategies
2. Network Optimization - Latency reduction, TCP tuning, and WAN acceleration
3. IaC Security Scanning - Terraform, CloudFormation, and Kubernetes manifest validation
4. Policy-as-Code - Enforcement with OPA, Sentinel, and Azure Policy
5. CI/CD Integration - Automating security scanning in deployment pipelines
6. Drift Detection & Remediation - Keeping infrastructure synchronized with code

Why This Matters in 2025

The cloud landscape has evolved dramatically. Organizations now manage:

• Multi-cloud infrastructure across AWS, Azure, GCP, and hybrid on-premises
• Rapid infrastructure changes with automated deployments every hour
• Regulatory complexity requiring continuous compliance validation (PCI-DSS, HIPAA, GDPR, SOC 2)
• Performance expectations with SLA targets of 99.99% uptime and sub-200ms latency

Traditional quarterly audits and manual testing can no longer keep pace. Modern organizations require continuous, automated validation of both security posture and performance characteristics.

---

Part 1: Cloud Performance Testing & Optimization

Performance Testing Fundamentals

Performance testing validates that your cloud infrastructure meets response time, throughput, and scalability requirements. There are five key types:

1. Load Testing Validates system behavior under expected normal load (e.g., 10,000 concurrent users during peak hours). Tools: Apache JMeter, Locust, k6.

2. Stress Testing Pushes beyond normal capacity to identify breaking points and resource exhaustion scenarios. Example: increasing load from 10,000 to 50,000 users to find breaking point.

3. Spike Testing Simulates sudden traffic spikes (e.g., Black Friday shopping, viral social media event). Tools: AWS Synthetic Monitoring, Datadog Synthetic Tests.

4. Soak Testing Runs moderate load for extended periods (12-24 hours) to identify memory leaks, connection pool exhaustion, and other long-running issues.

5. Scalability Testing Validates that adding resources (horizontal scaling) proportionally improves performance. Example: doubling EC2 instances should roughly double throughput.

Network Latency Optimization

Network latency—the time required for data to travel between client and server—directly impacts user experience. Research shows that every 100ms increase in latency reduces conversion rates by 1-7% depending on industry.

Key Latency Metrics:

• Round-trip time (RTT): Time for request to reach server and response to return to client
• Time to first byte (TTFB): Latency before server begins sending response
• P95/P99 latency: 95th and 99th percentile response times (more meaningful than averages)

Tool: Network Latency Calculator

Use our Network Latency Calculator to model latency improvements across different network paths and identify bottlenecks in your cloud architecture.

Optimization Strategies:

1. Geographic Distribution (Content Delivery Networks)

Deploy content globally using CDNs to reduce distance between users and servers.

Without CDN:
User in Tokyo → AWS us-east-1 → ~150ms latency

With CDN:
User in Tokyo → AWS CloudFront (Tokyo edge) → ~15ms latency

AWS CloudFront Configuration:

{
  "DistributionConfig": {
    "Origins": {
      "S3BucketOrigin": "my-app.s3.us-east-1.amazonaws.com"
    },
    "CacheBehaviors": {
      "CacheTTL": 86400,
      "Compress": true,
      "ViewerProtocolPolicy": "redirect-to-https"
    },
    "PriceClass": "PriceClass_100"
  }
}

2. Connection Pooling & Keep-Alive

Reuse TCP connections instead of establishing new ones for each request, eliminating the TCP handshake overhead (~15ms per new connection on WAN).

Terraform Example:

resource "aws_db_proxy" "app_db_proxy" {
  name                   = "app-db-proxy"
  debug_logging          = false
  engine_family          = "POSTGRESQL"
  role_arn               = aws_iam_role.proxy_role.arn
  auth {
    auth_scheme = "SECRETS"
    secret_arn  = aws_secretsmanager_secret.db_password.arn
  }

  max_idle_connections      = 100  # Connection pooling
  max_connections           = 200
  connection_borrow_timeout = 120
}

3. Database Query Optimization

Slow database queries are the #1 cause of application latency. Implement indexing strategies and query optimization.

Identifying Slow Queries (PostgreSQL):

-- Find queries taking >100ms average
SELECT
  query,
  calls,
  mean_exec_time,
  total_exec_time
FROM pg_stat_statements
WHERE mean_exec_time > 100
ORDER BY mean_exec_time DESC
LIMIT 10;

Adding Indexes for Common Queries:

-- Slow query: SELECT * FROM users WHERE email = '[email protected]'
CREATE INDEX idx_users_email ON users(email);

-- Composite index for multi-column filters
CREATE INDEX idx_orders_date_customer ON orders(customer_id, order_date);

4. Application Caching

Reduce database load and improve response times using caching layers.

Redis Caching Pattern (Terraform):

resource "aws_elasticache_cluster" "app_cache" {
  cluster_id           = "app-redis"
  engine               = "redis"
  node_type            = "cache.r7g.large"
  num_cache_nodes      = 3
  parameter_group_name = "default.redis7"
  engine_version       = "7.0"
  port                 = 6379
  automatic_failover_enabled = true
}

Application Code (Python Flask example):

from flask import Flask
from redis import Redis
import json

app = Flask(__name__)
redis = Redis(host='app-redis.xxxxx.ng.0001.use1.cache.amazonaws.com')

@app.route('/api/users/<user_id>')
def get_user(user_id):
    # Check cache first
    cached = redis.get(f'user:{user_id}')
    if cached:
        return json.loads(cached)

    # Cache miss - query database
    user = db.query(User).filter(User.id == user_id).first()

    # Store in cache for 3600 seconds
    redis.setex(f'user:{user_id}', 3600, json.dumps(user.to_dict()))
    return user.to_dict()

TCP Window Sizing for WAN Performance

TCP congestion control and window sizing dramatically impact WAN performance, especially over high-latency or high-bandwidth networks.

Understanding TCP Windows:

The TCP window advertises how much data the receiver is willing to accept. For high-latency, high-bandwidth networks:

Maximum Throughput = (TCP Window Size) / Latency

Example:
- Window: 64KB, Latency: 100ms (transpacific)
- Max throughput: 64KB / 0.1s = 512 Kbps (too low!)

- Window: 64MB, Latency: 100ms
- Max throughput: 64MB / 0.1s = 5 Gbps (optimal)

Tool: TCP Window Size Calculator

Use our TCP Window Size Calculator to determine optimal TCP window sizes based on your network characteristics.

Optimal TCP Tuning (Linux):

# For high-latency, high-bandwidth networks (WAN acceleration)
# File: /etc/sysctl.conf

# Increase maximum TCP window size
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# Enable TCP Window Scaling (allows windows > 64KB)
net.ipv4.tcp_window_scaling = 1

# Buffer tuning for long-distance links
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728

# Enable SACK (Selective Acknowledgment)
net.ipv4.tcp_sack = 1

# Increase backlog queues
net.ipv4.tcp_max_syn_backlog = 4096
net.core.netdev_max_backlog = 5000

# Apply settings
sysctl -p

AWS EC2 Instance Tuning (User Data):

#!/bin/bash
cat >> /etc/sysctl.conf <<EOF
# WAN optimization for high-latency networks
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_window_scaling = 1
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
EOF

sysctl -p

Measuring Impact:

Before/after bandwidth tests over WAN links:

# Test 1: Default settings
iperf3 -c remote-server.example.com -t 60
# Result: 200 Mbps (suboptimal)

# Test 2: After TCP tuning
iperf3 -c remote-server.example.com -t 60
# Result: 800 Mbps (4x improvement)

---

Part 2: Infrastructure-as-Code Security Validation

IaC Security Scanning Overview

Infrastructure-as-Code (IaC) enables infrastructure definition in version-controlled code—Terraform, CloudFormation, ARM templates, Kubernetes manifests. However, misconfigured IaC can expose entire infrastructure. Gartner predicts 99% of cloud breaches by 2025 will trace to preventable misconfigurations.

IaC Security Scanning Landscape (2025):

Tool	Terraform	CloudFormation	Kubernetes	Policies	Best For
Checkov	✅	✅	✅	750+	Comprehensive scanning, compliance frameworks
KICS	✅	✅	✅	2000+	Deep heuristic analysis, multi-cloud
Trivy	✅	✅	✅	CIS/CISA	Fast scanning, image + IaC coverage
Terrascan	✅	✅	✅	500+	Terraform-focused, Kubernetes
TFLint	✅	❌	❌	Plugin	Terraform linting, best practices

Common IaC Misconfigurations

Misconfiguration #1: Overly Permissive Security Groups

The most common finding across cloud audits. Allows unauthorized network access to sensitive services.

Anti-Pattern (UNSAFE):

# ❌ SSH accessible from anywhere
resource "aws_security_group" "web" {
  name = "web-sg"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]  # DANGEROUS: Open to Internet
  }

  ingress {
    from_port   = 5432
    to_port     = 5432
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]  # DANGEROUS: Database exposed
  }
}

Secure Pattern:

# ✅ Restricted to corporate VPN and bastion host
resource "aws_security_group" "web" {
  name = "web-sg"

  ingress {
    description = "SSH from bastion host only"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["10.0.1.0/24"]  # Bastion security group subnet
  }

  ingress {
    description = "PostgreSQL from app tier only"
    from_port   = 5432
    to_port     = 5432
    protocol    = "tcp"
    security_groups = [aws_security_group.app.id]  # Explicit source
  }
}

Tool: CORS Policy Analyzer

Validate cross-origin policies on public APIs using our CORS Policy Analyzer to prevent misconfigured CORS headers.

Misconfiguration #2: Unencrypted Data Storage

S3 buckets, EBS volumes, and RDS instances without encryption expose sensitive data to unauthorized access.

Anti-Pattern (UNSAFE):

# ❌ S3 bucket with no encryption
resource "aws_s3_bucket" "app_data" {
  bucket = "my-company-data"
  # No encryption configured!
}

# ❌ RDS without encryption
resource "aws_db_instance" "prod_db" {
  allocated_storage    = 100
  storage_type         = "gp3"
  engine               = "postgres"
  engine_version       = "15.2"
  instance_class       = "db.r6g.xlarge"
  # storage_encrypted = false (default - UNSAFE)
}

Secure Pattern:

# ✅ Encrypted S3 bucket with KMS
resource "aws_s3_bucket" "app_data" {
  bucket = "my-company-data"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "app_data" {
  bucket = aws_s3_bucket.app_data.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.s3.arn
    }
    bucket_key_enabled = true
  }
}

# ✅ Encrypted RDS with automated backup encryption
resource "aws_db_instance" "prod_db" {
  allocated_storage       = 100
  storage_type            = "gp3"
  storage_encrypted       = true  # Enable encryption
  kms_key_id              = aws_kms_key.rds.arn
  engine                  = "postgres"
  engine_version          = "15.2"
  instance_class          = "db.r6g.xlarge"
  backup_retention_period = 30
  skip_final_snapshot     = false
  final_snapshot_identifier = "prod-db-final-snapshot"
}

Misconfiguration #3: Publicly Accessible Databases

RDS instances and Cloud SQL databases accidentally exposed to the internet create critical security vulnerabilities.

Anti-Pattern (UNSAFE):

# ❌ RDS publicly accessible
resource "aws_db_instance" "customer_db" {
  allocated_storage    = 50
  storage_type         = "gp3"
  engine               = "postgres"
  instance_class       = "db.t3.small"
  publicly_accessible  = true  # DANGEROUS: Exposed to Internet
  skip_final_snapshot  = true
}

Secure Pattern:

# ✅ Database in private subnet, accessible only from app tier
resource "aws_db_subnet_group" "private" {
  name       = "private-db-subnet"
  subnet_ids = [aws_subnet.private_1.id, aws_subnet.private_2.id]
}

resource "aws_security_group" "database" {
  name = "database-sg"

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

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

resource "aws_db_instance" "customer_db" {
  allocated_storage      = 50
  storage_type           = "gp3"
  engine                 = "postgres"
  instance_class         = "db.t3.small"
  publicly_accessible    = false  # Private access only
  db_subnet_group_name   = aws_db_subnet_group.private.name
  vpc_security_group_ids = [aws_security_group.database.id]
  skip_final_snapshot    = false
}

Misconfiguration #4: Hardcoded Secrets

Embedding passwords, API keys, and credentials in IaC code creates maximum exposure—especially when code is version-controlled in Git.

Anti-Pattern (UNSAFE):

# ❌ Hardcoded credentials (NEVER DO THIS!)
resource "aws_db_instance" "database" {
  username = "admin"
  password = "MySecurePassword123!"  # Exposed in Git history forever!
}

variable "api_key" {
  default = "sk-abcd1234efgh5678ijkl9012"  # Hardcoded API key
}

Secure Pattern:

# ✅ Use AWS Secrets Manager
data "aws_secretsmanager_secret_version" "db_password" {
  secret_id = "prod/database/password"
}

resource "aws_db_instance" "database" {
  username = "admin"
  password = data.aws_secretsmanager_secret_version.db_password.secret_string
}

# ✅ Use environment variables for local testing
variable "api_key" {
  description = "API key - pass via environment variable TF_VAR_api_key"
  type        = string
  sensitive   = true  # Hide from console output
}

# Usage: TF_VAR_api_key="sk-abcd..." terraform apply

Terraform Plan Analysis & Validation

Terraform plans show exactly what infrastructure changes will be applied. Scanning plans reveals dynamic elements (injected secrets, interpolated values) that static code analysis misses.

Tool: Terraform Plan Explainer

Analyze Terraform plans with our Terraform Plan Explainer to understand blast radius and identify risky changes before applying.

Terraform Plan Scanning Workflow:

# Step 1: Generate plan binary
terraform plan -out=tfplan

# Step 2: Convert to JSON for analysis
terraform show -json tfplan > tfplan.json

# Step 3: Scan with Checkov
checkov --framework terraform_plan --file tfplan.json --output cli

# Step 4: Review findings
# If all checks pass:
terraform apply tfplan

Example Checkov Output:

Passed checks: 45, Failed checks: 3, Skipped checks: 0

Failed check: CKV_AWS_1: "Ensure S3 bucket has versioning enabled"
  Resource: aws_s3_bucket.artifacts
  File: main.tf:12-15

Failed check: CKV_AWS_2: "Ensure S3 bucket does not allow an empty ACL"
  Resource: aws_s3_bucket.artifacts
  File: main.tf:12-15

Failed check: CKV_AWS_21: "Ensure all data stored in S3 is secured with KMS"
  Resource: aws_s3_bucket.artifacts
  File: main.tf:12-15

Policy-as-Code with OPA & Sentinel

Policy-as-Code enforces organizational security standards automatically, preventing misconfigurations before they reach production.

Open Policy Agent (OPA) - For Terraform

OPA enables custom security policies written in Rego, a declarative policy language.

Example OPA Policy - Enforce S3 Encryption:

# enforce_s3_encryption.rego
package terraform

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_s3_bucket"

  # Check if encryption is NOT configured
  not has_encryption(resource)

  msg := sprintf(
    "S3 bucket '%s' must have server-side encryption enabled",
    [resource.name]
  )
}

has_encryption(resource) {
  resource.change.after.server_side_encryption_configuration
}

Example OPA Policy - Prevent Public RDS:

# prevent_public_rds.rego
package terraform

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_db_instance"
  resource.change.after.publicly_accessible == true

  msg := sprintf(
    "RDS instance '%s' must not be publicly accessible",
    [resource.name]
  )
}

OPA Integration in CI/CD (GitHub Actions):

name: OPA Policy Validation

on: [pull_request]

jobs:
  policy_check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Terraform Plan
        run: |
          terraform plan -out=tfplan
          terraform show -json tfplan > tfplan.json

      - name: OPA Policy Evaluation
        uses: open-policy-agent/setup-opa@v1
        with:
          version: v0.58.0

      - name: Evaluate Policies
        run: |
          opa eval -d policies/ -input tfplan.json "data.terraform.deny"

HashiCorp Sentinel - For Enterprise Terraform Cloud

Sentinel is HashiCorp's policy-as-code language, built into Terraform Cloud/Enterprise.

Example Sentinel Policy - Enforce Tags:

# enforce_tags.sentinel
import "tfplan/v2" as tfplan

resource_tags_required = [
  "Environment",
  "Owner",
  "CostCenter",
]

mandatory_tag_violation = false

for resources as resource_type, instances in tfplan.resource_changes {
  if resource_type in ["aws_instance", "aws_db_instance", "aws_s3_bucket"] {
    for instance_name, instance in instances {
      if instance.change.after["tags"] is null or instance.change.after["tags"] is undefined {
        mandatory_tag_violation = true
        print("Resource", resource_type + "." + instance_name, "missing required tags")
      } else {
        for tag in resource_tags_required {
          if instance.change.after["tags"][tag] is null {
            mandatory_tag_violation = true
            print("Resource", resource_type + "." + instance_name, "missing tag:", tag)
          }
        }
      }
    }
  }
}

main = rule { mandatory_tag_violation is false }

Azure Policy & CloudFormation Security

Azure Policy - Native Policy-as-Code for Azure

Azure Policy integrates directly with Azure Resource Manager for continuous compliance.

Example Azure Policy - Enforce HTTPS:

{
  "mode": "Indexed",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Storage/storageAccounts"
        }
      ]
    },
    "then": {
      "effect": "deny",
      "details": {
        "message": "Storage accounts must have secure transfer enabled (HTTPS only)"
      }
    }
  },
  "parameters": {}
}

AWS CloudFormation cfn-lint

CloudFormation templates can be validated with cfn-lint for syntax and best practice violations.

# Install cfn-lint
pip install cfn-lint

# Validate template
cfn-lint my-template.yaml

# Output:
# E1001: Property Name is unsupported
# W1011: cloudformation is a deprecated property

---

Part 3: CI/CD Integration & Continuous Monitoring

Security Scanning in CI/CD Pipelines

GitHub Actions + Checkov Example:

name: Infrastructure Security Scanning

on:
  pull_request:
    paths:
      - 'terraform/**'

jobs:
  security_scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Run Checkov Scan
        id: checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: terraform/
          framework: terraform
          download_external_modules: true
          quiet: false
          soft_fail: false  # Fail pipeline on violations

      - name: Comment PR with Results
        if: always()
        uses: actions/github-script@v6
        with:
          script: |
            const fs = require('fs');
            const results = JSON.parse(fs.readFileSync('results.json', 'utf8'));
            const summary = `## Security Scan Results\\n\\n${results.summary}`;
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: summary
            });

GitLab CI + Terrascan Example:

stages:
  - scan
  - deploy

security_scan:
  stage: scan
  image: terascan/terascan:latest
  script:
    - terascan scan -d terraform/ --output json -o scan-results.json
  artifacts:
    reports:
      sast: scan-results.json
  allow_failure: false

terraform_apply:
  stage: deploy
  dependencies:
    - security_scan
  script:
    - terraform init
    - terraform apply -auto-approve tfplan

Drift Detection & Continuous Compliance

Infrastructure drift occurs when actual cloud resources diverge from IaC definitions. Manual console changes, emergency patches, and incomplete automation all contribute to drift.

Drift Detection Tools:

1. AWS Config Rules Continuous monitoring for resource configuration compliance.

resource "aws_config_config_rule" "s3_encryption_enabled" {
  name = "s3-bucket-server-side-encryption-enabled"

  source {
    owner             = "AWS"
    source_identifier = "S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED"
  }

  scope {
    compliance_resource_types = ["AWS::S3::Bucket"]
  }
}

2. Terraform Sentinel - Drift Prevention

Sentinel policies can enforce that all changes come through IaC:

# enforce_terraform_changes.sentinel
# Prevent any resource changes outside of Terraform

import "tfplan/v2" as tfplan
import "tfstate/v1" as tfstate

# Check if resources are being destroyed without explicit code changes
enforcement = rule {
  tfplan.resource_changes["aws_security_group"] is empty or
  tfplan.resource_changes["aws_security_group"][_].change.actions is ["no-op"]
}

main = rule { enforcement }

3. AWS Systems Manager Compliance

Scan EC2 instances and on-premises servers for configuration drift.

# Scan EC2 instances for patch compliance
aws ssm describe-instance-associations-status \\
  --filters "key=AssociationStatusName,value=Success"

# Generate compliance report
aws ssm list-compliance-items \\
  --compliance-types PATCH \\
  --query 'ComplianceItems[*].[ResourceType,ResourceId,Status]' \\
  --output table

---

Putting It All Together: End-to-End Example

Let's walk through a complete scenario: deploying a highly available, secure, performant web application.

Architecture:

• CloudFront CDN for global performance
• ALB with connection pooling
• Autoscaling EC2 instances with optimized TCP tuning
• RDS with encryption, automated backups, private subnet
• IaC security scanning in CI/CD

Complete Terraform Configuration:

# variables.tf
variable "environment" {
  default = "production"
}

variable "instance_count" {
  default = 3
}

# network.tf - VPC with private/public subnets
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "production-vpc"
  }
}

resource "aws_subnet" "public" {
  count                   = 2
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.${count.index}.0/24"
  availability_zone       = data.aws_availability_zones.available.names[count.index]
  map_public_ip_on_launch = true
}

resource "aws_subnet" "private" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index + 10}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]
}

# security_groups.tf
resource "aws_security_group" "alb" {
  name   = "alb-sg"
  vpc_id = aws_vpc.main.id

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

  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"]
  }

  tags = {
    Name = "alb-sg"
  }
}

resource "aws_security_group" "app" {
  name   = "app-sg"
  vpc_id = aws_vpc.main.id

  ingress {
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }

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

  tags = {
    Name = "app-sg"
  }
}

resource "aws_security_group" "database" {
  name   = "database-sg"
  vpc_id = aws_vpc.main.id

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

  tags = {
    Name = "database-sg"
  }
}

# rds.tf - Encrypted, non-public database
resource "aws_db_subnet_group" "private" {
  name       = "private-db-subnet"
  subnet_ids = aws_subnet.private[*].id
}

resource "aws_db_instance" "main" {
  identifier            = "production-db"
  engine               = "postgres"
  engine_version       = "15.2"
  instance_class       = "db.r6g.xlarge"
  allocated_storage    = 100
  storage_type         = "gp3"
  storage_encrypted    = true
  kms_key_id           = aws_kms_key.rds.arn
  publicly_accessible  = false
  db_subnet_group_name = aws_db_subnet_group.private.name
  vpc_security_group_ids = [aws_security_group.database.id]

  username                    = "postgres"
  password                    = random_password.db_password.result
  backup_retention_period     = 30
  backup_window              = "03:00-04:00"
  maintenance_window         = "mon:04:00-mon:05:00"
  multi_az                   = true
  skip_final_snapshot        = false
  final_snapshot_identifier  = "production-db-final-snapshot-${formatdate("YYYY-MM-DD-hhmm", timestamp())}"

  tags = {
    Name        = "production-db"
    Environment = "production"
  }
}

# rds_connection_pool.tf
resource "aws_db_proxy" "main" {
  name                   = "production-proxy"
  engine_family          = "POSTGRESQL"
  role_arn               = aws_iam_role.proxy_role.arn

  auth {
    auth_scheme = "SECRETS"
    secret_arn  = aws_secretsmanager_secret.db_password.arn
  }

  max_idle_connections      = 100
  max_connections           = 200
  connection_borrow_timeout = 120

  depends_on = [aws_db_instance.main]
}

# cdn.tf - CloudFront for global performance
resource "aws_cloudfront_distribution" "main" {
  origin {
    domain_name = aws_lb.main.dns_name
    origin_id   = "alb"

    custom_origin_config {
      http_port              = 80
      https_port             = 443
      origin_protocol_policy = "https-only"
      origin_ssl_protocols   = ["TLSv1.2"]
    }
  }

  enabled = true

  default_cache_behavior {
    allowed_methods  = ["GET", "HEAD", "OPTIONS"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = "alb"

    forwarded_values {
      query_string = true

      cookies {
        forward = "all"
      }

      headers = ["Host", "CloudFront-Viewer-Country"]
    }

    viewer_protocol_policy = "redirect-to-https"
    compress               = true
    default_ttl            = 3600
    max_ttl                = 86400
  }

  viewer_certificate {
    cloudfront_default_certificate = true
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  tags = {
    Name = "production-cdn"
  }
}

---

Conclusion & Best Practices

Cloud performance optimization and IaC security are not one-time activities—they require continuous, automated validation as infrastructure evolves.

Key Takeaways:

1. Performance Testing - Implement load testing, latency analysis, and monitoring as part of your deployment pipeline
2. Network Optimization - Leverage CDNs, connection pooling, and TCP tuning for WAN performance
3. IaC Security - Scan Terraform, CloudFormation, and Kubernetes manifests automatically in CI/CD
4. Policy-as-Code - Enforce organizational standards with OPA, Sentinel, or Azure Policy
5. Drift Detection - Monitor for configuration drift with AWS Config, Terraform Sentinel, or Systems Manager
6. Continuous Monitoring - Track performance metrics and security posture in real-time

Next Steps:

• Start with basic IaC scanning (Checkov) in your CI/CD pipeline
• Establish performance baselines with load testing
• Implement policy-as-code for critical security controls
• Enable continuous compliance monitoring with cloud-native tools
• Review and optimize quarterly based on actual usage patterns

For more information, see our companion guide: Cloud Infrastructure Audit & Optimization.

---

Resources & Tools

Free Tools from InventiveHQ:

• Network Latency Calculator - Model network performance improvements
• TCP Window Size Calculator - Optimize WAN throughput
• Terraform Plan Explainer - Analyze infrastructure changes
• CORS Policy Analyzer - Validate cross-origin policies

Open-Source IaC Security Tools:

• Checkov - Multi-framework IaC security scanning
• KICS - Keep Infrastructure as Code Secure
• Trivy - Vulnerability and configuration scanning
• Terrascan - Infrastructure-as-code security scanning
• TFLint - Terraform linting

Cloud Security & Compliance:

• AWS Well-Architected Framework
• CIS Benchmarks - Security best practices
• NIST Cybersecurity Framework

Performance Testing Tools:

• Apache JMeter - Load testing
• Locust - Python-based performance testing
• k6 - Modern load testing platform