I organized the 4 common questions and best practices about Amazon Redshift enhanced VPC routing
This page has been translated by machine translation. View original
This is Ishikawa from the Cloud Business Division. I've organized four common questions that frequently come up in recent inquiries and investigations regarding Amazon Redshift's Enhanced VPC Routing, and compiled them as best practices.
Amazon Redshift's Enhanced VPC Routing is a feature that forces traffic between Redshift and other AWS services (particularly Amazon S3) to route through a VPC. It is disabled by default and requires additional configuration to enable.
Recently, inquiries about this feature have been increasing due to the following backgrounds:
- The introduction of new Graviton-based RG instances released on May 12, 2026
- An increasing trend of enabling Enhanced VPC Routing based on VPC design considerations in Redshift Serverless
- The impact of Amazon VPC FAQ explicitly stating "even when using public IP addresses, all communication uses AWS's private network"
This article organizes four questions commonly asked by field Redshift operators from the perspective of "how are decisions actually made in the field," and systematizes them as best practices in the latter half.
What is Enhanced VPC Routing
When Enhanced VPC Routing is enabled, all traffic between Redshift clusters and AWS services (S3, DynamoDB, Glue Data Catalog, etc.) is routed through the user's VPC.
Behavior when disabled:
- S3 access for COPY/UNLOAD goes through the AWS backbone (outside VPC)
- Not recorded in VPC flow logs
- Cannot be controlled with VPC Endpoint Policy / Security Groups
Behavior when enabled:
- S3 access goes through VPC Endpoint or internet gateway
- S3 access can be recorded in VPC flow logs
- Communication can be controlled with VPC Endpoint Policy
Four Common Questions in the Field
Q1: Which is more common in the field, enabled or disabled?
To get straight to the point, my intuitive sense is that disabled environments are slightly more common, at roughly a "disabled 6: enabled 4" ratio. There is no consensus that "disabled is the norm" as there is with public access settings, and decisions vary depending on organizational security requirements.
Reasons why disabled remains common
- Default is disabled, so it remains that way unless explicitly changed
- Enabling requires creating an S3 VPC Endpoint (Gateway type) + route table configuration, which takes some extra effort
- There are concerns about cost spikes from cross-region S3 access via NAT Gateway for COPY/UNLOAD
- An operational culture of "don't touch settings that are working"
Cases where enabling is more likely
- Industries with strict compliance requirements such as finance, healthcare, and public sector
- Requirements to audit S3 traffic with VPC flow logs
- Design philosophy of configuring "public access disabled + private subnet placement + Enhanced VPC Routing enabled" as a set of three
- Wanting to close data boundaries within VPC in combination with Lake Formation and Glue Catalog
The enabling rate tends to increase in proportion to governance maturity, with enterprise-oriented projects more likely to enable it.
Q2: Can Redshift Spectrum be used with Enhanced VPC Routing enabled?
Conclusion: Yes, it can. However, there are a few things to note.
Note 1: Required VPC Endpoints
When Enhanced VPC Routing is enabled, Spectrum accesses S3 and Glue Data Catalog, so the following VPC Endpoint configurations are required.
| Required Endpoint | Purpose |
|---|---|
| S3 VPC Endpoint (Gateway type) | Access to S3 data (same region) |
Glue Interface Endpoint (com.amazonaws.<region>.glue) |
Data Catalog reference |
| Route table configuration | Subnet → Endpoint routing |
| Endpoint Policy / Bucket Policy | Access permissions |
Note 2: Traffic from Spectrum's external fleet is not covered
This is an important point that is surprisingly not well known.
According to the official documentation, traffic from the "external fleet" (a separate group of nodes managed by Redshift) used to execute Spectrum queries to S3 is not subject to Enhanced VPC Routing. In other words, even if you enable Enhanced VPC Routing, not all S3 access via Spectrum will go through the VPC.
Those who want to "keep Spectrum communications within the VPC" need to design with this in mind. The RG instances in Q3 below significantly change this situation.
Common pitfalls
- Cross-region S3 cannot be read from Spectrum (a Spectrum constraint regardless of whether Enhanced VPC Routing is enabled)
- If Glue Data Catalog is in a different account, both Lake Formation permissions and VPC Endpoint Policy need to be configured
- If VPC Endpoint Policy is not the default "Full Access," S3 access for Spectrum must be explicitly permitted, otherwise queries will fail
Q3: What about the RG instances released last week?
The RG instances (Redshift Graviton) released on May 12, 2026 bring an important change to the concept of Enhanced VPC Routing.
RG's biggest feature: Integrated Data Lake Engine
| Item | RA3 + Spectrum | RG |
|---|---|---|
| Where S3 queries are executed | Spectrum external fleet (separate node group) | Directly on cluster nodes |
| Scan charges | $5/TB | None |
| Enhanced VPC Routing coverage | Cluster → S3 only (external fleet not covered) | All S3 access goes through VPC |
RG has the Integrated Data Lake Engine built into cluster nodes, and queries against Parquet/Iceberg data on S3 are executed directly without going through the Spectrum external fleet.
The meaning of Enhanced VPC Routing × RG
This resolves the limitation raised in Q2 that "Spectrum external fleet's S3 communications are not confined to the VPC" in RG.
- Data lake queries are also executed on cluster nodes, so enabling Enhanced VPC Routing means S3 access is also completed through the VPC
- Iceberg/Parquet access can also be observed on the VPC side with VPC flow logs
- Data lake routes can be uniformly controlled with VPC Endpoint Policy
For organizations with strict security and audit requirements, the configuration pattern of "RG + Enhanced VPC Routing enabled + S3 VPC Endpoint (Gateway type)" becomes a cleaner choice.
Provisioned vs Serverless vs RG
| Item | Provisioned (DC2/RA3) | RG (Provisioned) | Serverless |
|---|---|---|---|
| Enhanced VPC Routing | Optional (disabled by default) | Optional (disabled by default) | Optional (disabled by default) |
| Data lake queries | Spectrum external fleet | Cluster nodes (integrated engine) | Spectrum external fleet |
| VPC Endpoint advance preparation | Required only when enabling | Required only when enabling | Required when enabling (enabling tends to be recommended based on VPC design) |
Note that Enhanced VPC Routing is also optional in Serverless and disabled by default. It can be toggled with aws redshift-serverless update-workgroup --enhanced-vpc-routing, and unlike Provisioned, it does not require a cluster restart.
Q4: The VPC FAQ says "even with public IPs, AWS private network is used" — can we stop worrying about this?
This is content explicitly stated in the Amazon VPC FAQ as of 2026, and it is information that affects design decisions.
"When using public IP addresses, all communication between instances and services hosted on AWS uses AWS's private network."
There are increasing cases where this FAQ is used as the basis for deciding "Enhanced VPC Routing can remain disabled without issue."
Perspectives where you "don't need to worry" ← As the FAQ states
| Perspective | Conclusion |
|---|---|
| Whether communication routes go through the internet | NO, through AWS backbone |
| Physical layer encryption | Automatically encrypted by AWS |
| General MITM / eavesdropping risks | Practically none |
| Cross-datacenter transit | Completed within AWS global network |
If the concern is the intuitive worry that "S3 traffic might go through the public internet as IP routing = dangerous," there is no need to be overly concerned, as the FAQ states.
Perspectives where you "should still be concerned" ← Not resolved by the FAQ
However, from the perspectives of audit, control, and visibility, separate issues remain.
| Perspective | Disabled | Enabled |
|---|---|---|
| VPC flow log recording | Not recorded | Recorded |
| Control with VPC Endpoint Policy | Not possible | Possible |
| Control with Security Groups | Not possible | Possible |
aws:SourceVpce condition in S3 bucket policy |
Cannot use | Can use |
| Technical proof that "data is confined within VPC" | Difficult | Easy |
| PCI DSS / FISC / Government "VPC-only communication" requirements | May not be satisfied | Can be satisfied |
In other words, the modern judgment axis is understanding that the significance of enabling Enhanced VPC Routing has shifted from "communication route safety" to "visibility and control design."
Having gone through the four questions, what has become clear is that Enhanced VPC Routing is not a "required security feature" but a "governance design option." With that in mind, the latter half organizes practical decision criteria.
Design and Operation Best Practices
Decision Flowchart
Whether to enable Enhanced VPC Routing can be easily decided using the following flow.
Common Pitfalls
Pitfall 1: COPY/UNLOAD fails without VPC Endpoint configured
When Enhanced VPC Routing is enabled, COPY/UNLOAD will fail if the S3 VPC Endpoint (Gateway type) is not present. The error message will be network connection related.
[Amazon](500310) Invalid operation: Failed to connect to S3 endpoint.
(Endpoint: s3.ap-northeast-1.amazonaws.com, Port: 443)
Pitfall 2: How to distinguish between network errors and IAM permission errors
The type of error can be used to identify the cause.
| Error string | Cause |
|---|---|
Connection timed out, Failed to connect to endpoint, Could not resolve host |
VPC Endpoint not configured or route table misconfiguration |
Access Denied, Forbidden, S3ServiceException |
Insufficient IAM role permissions or Endpoint Policy restrictions |
Pitfall 3: NAT Gateway cost explosion with cross-region S3
When Enhanced VPC Routing is enabled and COPY/UNLOAD is performed to S3 buckets in different regions, Gateway Endpoints cannot be used and traffic goes through NAT Gateway. Costs can balloon depending on the amount of data transferred, so prior confirmation is required.
When disabled, traffic goes through the AWS backbone at lower cost, so leaving it disabled may be advantageous in cases with a lot of cross-region traffic.
Pitfall 4: Spectrum becomes unavailable when VPC Endpoint Policy default is changed
If VPC Endpoint Policy is changed from the default Full Access, access to S3 buckets used internally by Spectrum (such as for temporary query result storage) is denied, making Spectrum queries unavailable. When restricting Endpoint Policy, don't forget to allow the buckets and prefixes used by Spectrum.
Pitfall 5: Forgetting to prepare VPC Endpoint when migrating to Serverless
When migrating from Provisioned (Enhanced VPC Routing disabled) to a Serverless + Enhanced VPC Routing enabled configuration, forgetting to prepare VPC Endpoints will cause COPY/UNLOAD to fail immediately. It is safer to complete Endpoint configuration before creating the Workgroup.
Conclusion
The current state of "mostly disabled" is likely to change
Until now, environments remained disabled for reasons such as "default is disabled," "there's some extra work," and "the FAQ says communication routes are protected," but the following trends may shift the configuration balance.
- Spread of Redshift Serverless: Easier to integrate with VPC design, increasing trend of configurations where it is enabled
- Introduction of RG instances: The integrated data lake engine expands the benefits of enabling Enhanced VPC Routing
- Stricter compliance requirements: Increasing "VPC-internal communication" requirements in various industry regulations
At the timing of new builds or migrations, a design process of "explicitly making a decision" rather than "disabled by default" is recommended.
The decision axis is "visibility and control," not "security"
As indicated by the VPC FAQ description, the enabling/disabling of Enhanced VPC Routing is no longer a matter of "communication route safety." The decision axis can be organized as follows:
- Visibility: Do you want to observe data lake access with VPC flow logs?
- Control: Do you want to control communication routes with VPC Endpoint Policy?
- Demonstrability: Is there a need to show during audits that "data is confined within the VPC"?
If any of these is "Yes," enable it; if all are "No," leaving it disabled will cause no practical harm.
Future expected feature enhancements
At this point, changing Enhanced VPC Routing settings on Provisioned may require a cluster restart in some cases, which is a factor in operational burden. While Serverless allows relatively easy changes with update-workgroup, if "zero-downtime enable/disable switching" is supported in the future for the Provisioned side as well, more flexible operations will be possible.
Also, since the RG instance release is recent, the recording granularity of VPC flow logs for S3 access via the integrated data lake engine, and the control behavior with Endpoint Policy, are expected to be clarified through future verification.
In Closing
I organized four common field questions and best practices regarding Amazon Redshift's Enhanced VPC Routing.
- The field ratio is approximately "disabled 6: enabled 4." The default of disabled is common
- Spectrum can be used even when enabled, but there is a constraint that external fleet traffic is not covered
- The integrated data lake engine of RG instances is an innovative change that resolves this constraint
- While the significance of "enabling for security purposes" has diminished due to the VPC FAQ description, it remains effective for visibility and control purposes
Rather than "enabled by default" or "disabled by default," what is required for future Redshift operations is explicitly making decisions based on the balance between your organization's governance requirements and operational burden.
Especially for those considering migration to Redshift Serverless or the new RG instances, I recommend using the migration timing as an opportunity to review the entire configuration and redesign it together with VPC Endpoint preparation. I hope this article is helpful to someone.
