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

Configure private DNS name sharing for egress private connectivity.

You can implement private DNS name sharing in several ways. You must validate in a public zone, or a subdomain within one, that you own. Shared or exclusively private zones are not supported by AWS.

Single record resolution

With single record resolution, a single FQDN resolves to one endpoint. Use this approach with simple TCP passthrough on your NLB when you don't need SNI routing.

Note:

When you specify a FQDN, only that record resolves from the Splunk stack to the VPC endpoint.

In the following example, only abc.mydomain.com resolves. Use separate ports to route traffic to the appropriate backend.

CODE 
# Example
            abc.subdomain.mydomain.com

Pros

  • Best for TCP passthrough-only load balancing.
  • Allows multiple DNS records in the same zone to separate VPC endpoint services.
  • Supports TLS validation.

Cons

  • Not compatible with complex load balancing or SNI rules.
  • May require several VPC endpoint services.

Multi-record resolution

With multi-record resolution, a wildcard FQDN resolves to a single endpoint. Use this approach when you need complex load balancing configurations or SNI routing to direct requests to the appropriate backend using specific host headers.

Note:

When you specify a wildcard FQDN, any record in the zone resolves to the VPC endpoint.

In the following example, *.mydomain.com resolves. Use separate ports or SNI rules to ensure the load balancing tier in your VPC routes traffic to the appropriate backend.

CODE 
# Example
            *.subdomain.mydomain.com

Pros

  • Best for complex load balancing configurations and SNI routing.
  • Resolves multiple DNS records for a given zone to a single VPC endpoint.
  • Supports TLS validation.

Cons

  • Resolves zones to a single VPC endpoint only.
    • Additional endpoints require a separate zone.
  • May require several VPC endpoint services.

For configuration instructions, see Set up egress private connectivity.