RDS Security Group Rule Referencing a Shared SG Lets All Its Members Reach the Database

Symptom

A database team reports that an RDS for PostgreSQL instance, believed to be reachable only from a dedicated application tier, is accepting connections from EC2 instances that were never intended to touch it. Nothing changed in the RDS security group rules themselves. The inbound rule still shows a single entry: allow TCP 5432 from security group sg-0a1b2c3d4e5f60789. On paper this looks tighter than an IP-based rule because it references an identity rather than a CIDR block.

The team only discovers the exposure when a batch-processing instance in a different application, added to that same security group months later for an unrelated reason, is found querying the production database in VPC Flow Logs.

False Assumption

The operators assumed that a security-group-referencing rule was inherently scoped to “the application tier,” because that group was originally created and named for that purpose (for example sg-app-tier). In practice, a security group reference in an RDS rule authorises traffic from any current or future member of that group ID, not from the workload the group was originally created to describe. The rule’s safety depends entirely on ongoing membership discipline for that group, which is an organisational control, not a technical one enforced by the rule itself.

Root Cause

RDS security group rules that reference a source security group ID grant access dynamically: AWS Well-Architected Reliability Pillar guidance on workload boundaries frames this as a shared-fate dependency across every resource attached to the referenced group. When platform teams reuse a general-purpose security group across multiple applications (for cost, convenience, or historical reasons), any resource later added to that group inherits database access without a separate review of the RDS security group itself. The RDS-side configuration is unchanged and audits of the RDS security group rules will not reveal the drift, because the exposure is introduced entirely on the EC2/network side by group membership changes.

Impact

The practical impact is an undocumented widening of the database’s network attack surface that is invisible to anyone reviewing RDS configuration alone. Any workload added to the referenced security group gains direct network-layer access to the database port, independent of application-level authentication, IAM policy, or secrets management. In a shared or multi-tenant VPC this can expose a production database to lower-trust workloads, contractor tooling, or test instances that were attached to the group for an unrelated reason. Because the RDS rule itself never changes, standard configuration-drift detection on the database resource will not flag the exposure; only security group membership auditing will.

Diagnosis

Confirm the exposure using read-only checks before making any change.

• Identify the referenced security group ID in the RDS instance’s inbound rule.
• Enumerate every ENI and instance currently attached to that security group.
• Cross-reference that membership list against the application(s) that are supposed to have database access.
• Review VPC Flow Logs for the RDS ENI to identify source IPs/instances actually connecting on the database port.

aws ec2 describe-security-groups --group-ids sg-0a1b2c3d4e5f60789 --query "SecurityGroups[].IpPermissions"

aws ec2 describe-network-interfaces --filters "Name=group-id,Values=sg-0a1b2c3d4e5f60789" --query "NetworkInterfaces[].{Instance:Attachment.InstanceId,ENI:NetworkInterfaceId,Description:Description}"

If the returned instance list contains resources outside the intended application tier, the exposure is confirmed.

Correction

Replace the shared, identity-based reference with a dedicated security group scoped only to the RDS client workload. Create a new security group used exclusively by the application instances that must reach the database, attach it to those instances, and update the RDS security group to reference the new dedicated group instead of the shared one. Do not remove the old rule until the new group is confirmed attached and validated (see Validation), to avoid an availability gap.

aws ec2 create-security-group --group-name app-rds-client-only --description "Dedicated RDS client SG - no shared membership" --vpc-id vpc-0123456789abcdef0

aws ec2 authorize-security-group-ingress --group-id sg-RDS_TARGET --protocol tcp --port 5432 --source-group sg-NEW_DEDICATED_ID

Validation

Validation confirms only the intended instances retain database connectivity and unrelated members of the old shared group no longer do.

• Attach the new dedicated security group to each legitimate application instance and confirm connectivity to the database on port 5432.
• From an instance that remains in the old shared group but is not part of the application tier, confirm the connection attempt now times out once the old rule is removed in a maintenance window.
• Re-run the ENI membership query against the new dedicated group and confirm the member list matches only the intended application instances.
• Review VPC Flow Logs for 24–48 hours post-change to confirm no unexpected source ENIs are reaching the database port.

Rollback

Rollback restores the prior security group reference on the RDS instance if the new dedicated group breaks legitimate application connectivity.

1. Re-authorise the original shared security group ID on the RDS security group ingress rule.
2. Confirm affected application instances regain connectivity using the same validation query used during correction.
3. Leave the new dedicated security group in place, unattached, for later retry once the affected application’s actual dependency is clarified.

Stop condition: if removing the old rule causes any production application to lose database connectivity before the new dedicated group is confirmed attached to every legitimate client, re-add the old rule immediately and pause further changes until the client instance inventory is re-verified.

Prevention

Treat every security-group-referencing rule on a database as a trust boundary tied to group membership, not to the group’s name or original purpose. Maintain one dedicated security group per distinct client workload for RDS access, never a shared general-purpose group. Add a periodic, scheduled review of security group membership for any group referenced in an RDS ingress rule, and alert when membership changes for groups referenced by production database security rules.