AWS Training
Modules Listen Certification
VPC connections — how the packets actually move Q1 — Data Sources and Connectivity
0:00 0:00

← Data Sources and Connectivity

Starts this lesson and continues through 22 more to the end of the course.

VPC connections — how the packets actually move

What a VPC connection actually is

Enterprise edition only ("Applies to: Enterprise Edition", verbatim banner on Configuring VPC connections, verified 2026-08-16). And the API agrees: CreateVPCConnection documents UnsupportedUserEditionException (HTTP 403).

Mechanically (verbatim): "By creating a VPC connection in Amazon Quick, you're adding elastic network interfaces in your VPC." Quick Sight drops ENIs — the docs name the auto-created one the Amazon Quick network interface, QNI — into your subnets, and from that moment your route tables, NACLs, subnets, and security groups govern its traffic "in the same way that they apply to traffic between other instances in your VPC."

That's the entire mental model: a VPC connection is ENIs in your subnets. Not a tunnel, not magic. It reaches anything the VPC can reach — including on-premises data, "if you set up connectivity between the VPC and your on-premises network. For example… AWS Direct Connect, a virtual private network (VPN), or a proxy."

What it can reach

From Supported VPC data sources (verified 2026-08-16), the sources that work through a VPC connection: OpenSearch Service, Redshift, RDS, Aurora, Databricks, Exasol, MariaDB, SQL Server, MySQL, Oracle, PostgreSQL, Presto, Snowflake, Starburst Enterprise, Teradata, Trino. (Notably absent: Athena and S3 — they're reached via the service roles of lesson 3, not through your VPC.)

Same page, the four conditions your setup must satisfy, near-verbatim:

  1. The DNS name of the data source can be resolved from outside your VPC.
  2. The connection returns the private IP of the instance — "Databases hosted by Amazon Redshift, Amazon RDS, and Aurora automatically meet this requirement."
  3. A clearly defined network path from data source to Quick Sight.
  4. The VPC is registered with Quick Sight as a VPC connection.

Conditions 1–2 are why DnsResolvers exists in the API: a private hosted zone name that only resolves inside the VPC fails condition 1 unless you give Quick Sight resolver endpoints (Route 53 Resolver inbound endpoints, per the setup page's topic list) to ask.

The API

From CreateVPCConnection (verified 2026-08-16): POST /accounts/{AwsAccountId}/vpc-connections, with all constraints documented:

Field Required Constraint
VPCConnectionId ✅ 1–1000 chars, [\w\-]+, unique per account per Region
Name ✅ 1–128 chars
RoleArn ✅ the IAM role Quick Sight uses to create the ENIs
SubnetIds ✅ minimum 2, maximum 15
SecurityGroupIds ✅ 1–16
DnsResolvers — up to 15 IP addresses (strings of 7–15 chars — IPv4 only)

Two ceilings to notice: two subnets minimum — availability is forced on you, so have two private subnets in different AZs ready before you start — and the DnsResolvers length constraint (7–15 characters) quietly excludes IPv6 resolver addresses.

The response carries two status fields, and they answer different questions:

PARTIALLY_AVAILABLE is the interesting one operationally: with ENIs in multiple subnets, some can be healthy while others aren't. A VPC connection that "works sometimes" is this enum value in the wild — describe the connection before you blame the database.

Security groups — the rule that looks wrong but is right

This is the section that decides whether your first VPC connection works. From Security groups: inbound and outbound rules (verified 2026-08-16), verbatim:

"The security group attached to the Amazon Quick network interface behaves differently than most security groups, because it isn't stateful. … the Amazon Quick network interface security group doesn't automatically allow return traffic. Because of this, adding an egress rule … doesn't work. To make it work … make sure to add an inbound rule that explicitly authorizes the return traffic from the database host."

And the consequence, also verbatim: "The inbound rule in your security group must allow traffic on all ports. It needs to do this because the destination port number of any inbound return packets is set to a randomly allocated port number."

Every security review flags this rule as sloppy. It isn't — it's the documented requirement. Normal security groups are stateful: outbound connection ⇒ return traffic admitted automatically. The QNI's group doesn't track state, so the return packets — which come back on random high ports — must be admitted explicitly. Restrict the source (the database's SG), never the port range.

The full three-group picture, from the Sample rules page's Redshift example (verified 2026-08-16; MySQL is identical with 3306):

Security group Rule Setting
QNI SG Inbound All TCP, ports 0–65535, source = Redshift's SG
QNI SG Outbound TCP 5439, destination = Redshift's SG
Redshift SG Inbound TCP 5439, source = QNI's SG

Three rules, referencing each other by security-group ID — never by CIDR if you can help it. The setup page recommends a dedicated SG for the QNI (description QuickSight-VPC), "to isolate the rules… It also makes it easier for AWS Support to help you." And a verbatim warning worth quoting in reviews: "Do not configure the security group on the Amazon Quick network interface with an outbound rule to allow traffic on all ports."

⚠️ The dated caveat. Both the inbound and outbound rules sections carry this banner, verbatim: "The following section applies to your VPC connection if the connection was created before April 27, 2023." The page does not say what applies to connections created after that date — I could not verify the post-2023 behavior anywhere on the fetched pages. Treat the rules above as the safe configuration (they work in both worlds); if you want to tighten a post-2023 connection's inbound rule, test it empirically or get AWS Support to state the current behavior in writing. This is exactly the kind of docs gap worth asking Support to confirm — you'll likely get the answer added to your case notes permanently.

⚠️ One legacy trap from the same page: long-standing RDS instances on EC2-Classic use DB security groups (not VPC SGs). If you meet one, its inbound rules need updating separately — or the instance needs moving into the VPC.

Check yourself

  1. What physically appears in your VPC when you create a VPC connection?
  2. Why must the QNI security group's inbound rule span all TCP ports, and what should be restricted instead?
  3. CreationStatus: CREATION_SUCCESSFUL but connections fail intermittently. Which field do you read next, and what value do you expect?
  4. Your database's DNS name lives in a private hosted zone. Which API field saves you, and what are its limits?
  5. Can you reach S3 through a VPC connection? Athena?
  6. Why does CreateVPCConnection demand at least two subnets?
Answers
  1. Elastic network interfaces (the Amazon Quick network interface, QNI) in your subnets — subject to your route tables, NACLs, and security groups like any other ENI.
  2. The QNI's SG is not stateful, so return traffic isn't auto-admitted, and return packets arrive on randomly allocated ports. Restrict the source to the database's security group ID.
  3. AvailabilityStatus — expect PARTIALLY_AVAILABLE: some subnets' ENIs healthy, others not.
  4. DnsResolvers — up to 15 resolver IPs (Route 53 Resolver inbound endpoints). The 7–15 character constraint means IPv4 only.
  5. No and no — neither is on the supported VPC sources list; both ride the lesson-3 service roles.
  6. The API requires SubnetIds minimum 2 (maximum 15) — multi-AZ availability is mandatory, not optional.

Teaching this section

← PreviousThe AWS-managed sources — Athena, S3, and the two rolesNext →The failures that look like network failures