Restrict RDS Access with Private Subnets and Tight Security Groups

Overview

Tighten network exposure of your Amazon RDS databases so they are no longer reachable from the public internet and are protected by restricted security groups. This plan inventories your existing RDS network posture, guides you through choosing which instances to lock down and what should still be allowed to connect, applies the changes to public accessibility and security groups, and then validates both security and application connectivity.

By the end, selected RDS instances will have public access disabled, be associated only with vetted security groups, and retain access only from explicitly approved internal sources.

Execution Details

Phase 1: Assessment

In this phase you build a clear picture of your current RDS network configuration and decide which instances should be restricted and what access they require.

Inventory RDS instances and network settings

• Discover all RDS DB instances in scope and record their key attributes: identifiers, engine types and versions, Regions/AZs, VPC and subnet group details, public accessibility setting, endpoints, and attached security groups.
• Identify which instances are currently publicly accessible and store all findings in a structured format for later steps.

Classify RDS subnets as public or private

• From the RDS inventory, compile the set of VPCs and subnets used by DB subnet groups.
• For each subnet, capture its metadata (ID, VPC, CIDR, AZ) and associated route table.
• Determine whether each subnet has an internet gateway route or assigns public IPs, and classify it as public or private.
• Associate each RDS instance with the classification of its subnets for risk and design discussions, without changing subnet or subnet group assignments.

Inventory RDS security groups and inbound rules

• Collect the unique set of security groups attached to RDS instances and document their VPC, descriptions, and all inbound rules (protocols, ports, and sources).
• Highlight inbound rules that are public (such as 0.0.0.0/0 or ::/0) or overly broad internal ranges on database ports.
• Correlate each RDS instance with its security groups and clearly flag which groups are too permissive, storing this information for later hardening.

Guide user to select RDS instances to restrict

• Present a consolidated view of each RDS instance, including its public accessibility flag, endpoint, VPC, subnet group, and security groups.
• Emphasize instances that are publicly accessible and/or use permissive security groups.
• Guide you through selecting which instances should be restricted, while allowing explicit exclusions with optional rationale.
• Capture and store the approved list of instances to be changed.

Guide user to define allowed access sources

• For each selected instance, guide you through specifying which sources must retain access:
  • Approved source security groups (for example, application servers, bastion hosts).
  • Any required CIDR ranges (for example, on-premises ranges via VPN/Direct Connect).
• Capture which ports (typically database ports) must remain open for those approved sources.
• Encourage minimizing broad CIDRs in favor of security group–based references.
• Store the approved access sources and ports for use when creating or updating security groups.

Phase 2: Configuration

This phase applies the network restrictions to the selected RDS instances by disabling public accessibility and tightening security groups.

Disable public accessibility on selected RDS instances

• Use the user-approved list of target instances and confirm their current public accessibility settings.
• For each selected instance that is publicly accessible, plan and apply a change to set it to non-public, aligning with any timing or maintenance constraints.
• Monitor each modification until it completes and verify that public accessibility is now disabled.
• Confirm that instances remain reachable from intended internal networks (such as within the VPC or peered networks) at a basic connectivity level.
• Record the final accessibility state for each instance for later validation.

Create or update restricted security groups for RDS access

• Review the security groups attached to selected instances alongside the user-approved allowed sources and ports.
• Decide whether to tighten existing security groups or create new, dedicated RDS security groups per instance or per group of instances.
• Create any required restricted security groups in the correct VPC, then define inbound rules that:
  • Allow only the approved security group sources and/or CIDR ranges on the required database ports.
  • Avoid public CIDRs such as 0.0.0.0/0 or ::/0 unless explicitly and exceptionally approved.
  • Limit open ports to the minimum required for the RDS engines in use.
• Record the final inbound rules for each restricted group and create a mapping from each RDS instance to the restricted group(s) that should be attached.

Attach restricted security groups and remove permissive groups

• For each selected RDS instance, combine:
  • The newly defined restricted security group(s).
  • Any other required, non-permissive groups (for example, monitoring).
• Update the instance to use this final, approved set of security groups.
• Detach any groups containing public or otherwise disallowed rules unless you have explicitly exempted them.
• Monitor the changes until instances are stable, then verify that only the intended security groups are attached.
• Document the final security group set per instance for validation and future reference.

Phase 3: Validation

This phase confirms that RDS instances are no longer publicly accessible, that security groups enforce the intended restrictions, and that applications still function correctly.

Verify RDS instances are not publicly accessible

• Retrieve the latest configuration for all instances that were restricted.
• Confirm that public accessibility is disabled for each and that they remain associated with their expected DB subnet groups.
• Verify that the attached security groups match the intended restricted set.
• Optionally perform basic checks to ensure that instances are not reachable from arbitrary public internet sources.
• Document any deviations from the desired non-public state and provide guidance on remediation.
• Update a validation summary showing which instances fully meet the non-public accessibility requirement.

Verify RDS security groups enforce approved access only

• List all security groups currently attached to restricted instances and inspect their inbound rules.
• For each instance, confirm that database ports only allow traffic from the user-approved security group sources and/or CIDR ranges.
• Check that public CIDR ranges and unnecessary open ports are not present on these groups unless explicitly approved.
• Record any rules or groups that remain too permissive and detail what needs adjustment.
• Update a validation report indicating which instances and security groups fully satisfy the restriction requirements.

User validation of application connectivity

• Provide application owners with a summary of which RDS endpoints were changed and what modifications were made (public access disabled, security groups tightened).
• Guide them to run application-level tests to verify connectivity and core functionality from approved sources.
• Confirm that no critical client or system has lost necessary database access due to the new restrictions.
• Capture any reported connectivity or functional issues for follow-up investigation.
• Record application owner sign-off for each affected application, or note outstanding issues that still require remediation.