About egress private connectivity

Use egress private connectivity for private outbound connections from Splunk Cloud Platform to your AWS VPC endpoints.

Egress private connectivity allows you to initiate connections from Splunk Cloud Platform to endpoints in your AWS Virtual Private Cloud (VPC) without routing traffic over the public internet. This feature operates independently from private connectivity (ingress), which provides private access to your search and ingestion tiers.

Note: Hybrid connectivity (AWS to other cloud providers) is not supported.

Endpoints are protected by stack-specific security groups, ensuring connectivity is properly segmented even when stacks share a VPC. Use egress private connectivity with features such as DB Connect and Federated Search, where Splunk Cloud Platform initiates outbound connections to customer-owned resources.

To configure egress private connectivity for your deployment, see Set up egress private connectivity.

Requirements

Requirements for using egress private connectivity

Splunk Cloud Platform supports egress private connectivity in the following environments:

  • AWS (GCP and Azure are not supported)

  • Amazon GovCloud IL2 and IL5 (but not for U.S. Department of Defense)

    Note: GovCloud stacks must be in the same region as the VPC endpoint service.
Note: Egress private connectivity is only available for IPv4.
Important: Egress private connectivity is not compatible with Cross-Region Disaster Recovery on Splunk Cloud Platform.

Load balancing and DNS considerations

Specific additional considerations for egress private connectivity

You can use advanced load balancing configurations, such as NLB with an Application Load Balancer (ALB) target, to support TLS termination and Server Name Indication (SNI) routing rules.

Figure 1. TCP Passthrough

Load balancer examples

Examples of egress private connectivity load balancer configurations

The following examples illustrate two common load balancing configurations for your VPC endpoint service. Your configuration may differ based on your requirements.

TCP Passthrough

In this example, you set up a simple NLB with unique listener ports. Where backends share a port, configure the listener to perform port translation so the backend receives traffic on the correct port. Document the port relationships so you can configure Splunk with the correct port.

Figure 2. TCP Passthrough

NLB/ALB Target

In this example, SNI rules on the ALB target groups route traffic to the appropriate backend. Use this configuration when you require specific hostnames for TLS validation.

Figure 3. NLB/ALB Target

Private DNS name sharing

Egress private connectivity requires private DNS name sharing

Depending on your needs, you can implement private DNS name sharing in several ways. Here are two implementation paths and some pros and cons of each. You must perform validation in a public zone--or subdomain contained therein--that you own. Shared, or exclusively private, zones are not supported by AWS at this time.

Single record resolution

For this approach, a single FQDN DNS entry will be resolvable to a given endpoint. This setup is great when you are using simple TCP passthrough on your provider NLB, and don't have a need for more advanced load balancing setups that, perhaps require SNI functionality.

Note:

You specify a FQDN when sharing, and only this record will be resolvable by the Splunk stack to the VPC endpoint in our VPC.

In the example below, only abc.mydomain.com will be resolvable, and you will need to use disparate ports to route traffic to the appropriate backend.

CODE 
# Example
            abc.subdomain.mydomain.com

Pros

  • Great for TCP passthrough-only load balancing.
  • Can set up multiple DNS records in the same zone to disparate VPC endpoint services.
  • Supports TLS validation.

Cons

  • Not compatible with complex load balancing, SNI rules.
  • Could require several VPC endpoint services.

Multi-record resolution

For this approach, a wildcard FQDN DNS entry will be resolvable to a given endpoint. This setup is ideal if you require complex load balancing configurations, and or SNI routing to ensure requests make it to the appropriate backend using specific host headers.

Note:

You specify a FWDN when sharing, thus allowing anything from the zone to resolve to the VPC endpoint within our SEC VPC.

In the example below, *.mydomain.com will be resolvable, and you will need to use disparate ports or SNI rules to ensure that the load balancing tier in your VPC routes traffic to the appropriate backend.

CODE 
# Example
            *.subdomain.mydomain.com

Pros

  • Great for complex load balancing configurations (SNI, and so on).
  • Can resolve multiple DNS records for a given zone to a single VPC endpoint.
  • Supports TLS validation.

Cons

  • Supports resolving zones to only a single VPC endpoint.
    • Additional endpoints would require the use of a disparate zone.
  • Could require several VPC endpoint services.