About egress private connectivity

Introduction to the egress private connectivity feature

Splunk Enterprise Cloud customers can now connect into their own AWS accounts and Amazon Virtual Private Cloud (VPC) to reach endpoints in their VPCs and beyond. This feature augments our existing set of successful private connectivity (ingress) features which already allow customers to access their search tier and or ingestion tier privately. Ingress private connectivity is not required to make use of egress private connectivity.

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

Endpoints are stack-specific and are protected using a stack-specific security group to ensure that connectivity is properly segmented, even when stacks are inside shared VPCs. This functionality allows customers to make use of Splunk features like DBConnect, Federated Search, and so on, where connectivity is initiated from Splunk Enterprise Cloud, but with a terminus in a customer-owned environment.

Requirements

Requirements for using egress private connectivity

Egress private connectivity works in the following Splunk environments:

  • AWS (not GCP or Azure)

  • 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: Splunk Enterprise Cloud supports IPv6, but this feature is only available for IPv4 for now.

Load balancing and DNS considerations

Specific additional considerations for egress private connectivity

You may make use of more advanced load balancing configurations, such as NLB with Application Load Balancer (ALB) target should you leverage more advanced listeners, TLS termination, Server Naming Indication (SNI) routing rules, and so on.

Figure 1. TCP Passthrough

Load balancer examples

Examples of egress private connectivity load balancer configurations

Here are two common examples of how you may choose to set up the load balancing tier serving your VPC endpoint service. Configurations are not limited to these two examples but are meant to illustrate possible configurations based on your particular requirements.

TCP Passthrough

In this example, a simple NLB is set up with unique listener ports. Where there are common backends, the listener will need to be configured to perform a port translation so the backend receives traffic on the particular port. You will need to understand and document the port relationship so you can configure Splunk accordingly using the correct port.

Figure 2. TCP Passthrough

NLB/ALB Target

This example represents a more advanced setup, in which SNI rules on the ALB target groups are used to ensure that traffic is routed to the appropriate backend. This setup is conducive to connectivity when specific hostnames are required 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.