Day 17/90: AWS RDS provisioning

90 Day Security Infrastructure Challenge

I am writing this one as if a teammate opened the pull request and asked what actually matters. My answer is that making cloud primitives safe by default before application teams start attaching workloads to them. Good infrastructure content should make the operational boundary visible, not bury it behind screenshots or one happy-path command.

The Insecure Baseline You Need to Stop Shipping

The practical reason to spend time on the insecure baseline you need to stop shipping is simple: it is one of the places where infrastructure drift hides behind a clean-looking diff. Making cloud primitives safe by default before application teams start attaching workloads to them.

The repo earns trust when Terraform resources for VPC boundaries, subnet placement, security group rules, instance profiles, encryption, and routing tell the same story as the PR summary. That is how you get to an IaC layout where VPC, subnet, security group, IAM, and KMS decisions are visible in code and reviewable in plan output. The cloud console makes it too easy to hide a risky default. The repo should make those defaults painfully obvious.

resource "azurerm_resource_group" "aws_rds_provisioning" {
  name     = "rg-aws_rds_provisioning"
  location = "East US"
}

resource "azurerm_virtual_network" "aws_rds_provisioning" {
  name                = "vnet-aws_rds_provisioning"
  address_space       = ["10.22.0.0/16"]
  location            = azurerm_resource_group.aws_rds_provisioning.location
  resource_group_name = azurerm_resource_group.aws_rds_provisioning.name
}

Subnet Isolation and Security Group Rules

Subnet Isolation and Security Group Rules sounds narrow until it fails under pressure. Then you find out whether the infrastructure repo can explain its own behavior. The real work is still making cloud primitives safe by default before application teams start attaching workloads to them.

I do not want a magical success message. I want Terraform resources for VPC boundaries, subnet placement, security group rules, instance profiles, encryption, and routing, because that evidence is what turns the work into an IaC layout where VPC, subnet, security group, IAM, and KMS decisions are visible in code and reviewable in plan output. The cloud console makes it too easy to hide a risky default. The repo should make those defaults painfully obvious.

KMS Encryption and Forced TLS

KMS Encryption and Forced TLS is where aws rds provisioning becomes operational. On a real team, the argument is rarely about syntax. It is about making cloud primitives safe by default before application teams start attaching workloads to them.

What I want back from this day is an IaC layout where VPC, subnet, security group, IAM, and KMS decisions are visible in code and reviewable in plan output. That only happens when the change leaves evidence in Terraform resources for VPC boundaries, subnet placement, security group rules, instance profiles, encryption, and routing. The cloud console makes it too easy to hide a risky default. The repo should make those defaults painfully obvious.

Review posture

• I want the pull request to name the affected environment, the rollback path, and the state or inventory boundary touched by aws rds provisioning.
• The risky part usually sits in the VPC, subnet, security group, IAM, or KMS boundary connected to the insecure baseline you need to stop shipping, so that is where I read first.
• If a pipeline gate, policy check, or drift report disagrees with the proposed change, that disagreement belongs in the review thread instead of hidden in logs.

The outcome I care about is an IaC layout where VPC, subnet, security group, IAM, and KMS decisions are visible in code and reviewable in plan output. That is only believable when Terraform resources for VPC boundaries, subnet placement, security group rules, instance profiles, encryption, and routing are easy to find and consistent with the explanation in the pull request. The cloud console makes it too easy to hide a risky default. The repo should make those defaults painfully obvious.

Why this belongs in a security infrastructure track

IaC, Ansible, policy as code, GitOps, and infrastructure testing all share the same responsibility: make change review safer than console drift. That is why I keep bringing the lesson back to Terraform, IaC boundaries, pipeline evidence, and the operational story behind the diff.