Access Your VPC using AWS PrivateLink

This page applies to Appian Cloud only. It may not reflect the differences with Appian Government Cloud.

Overview

This page documents how to configure an Appian Cloud to access your resources through AWS Privatelink. For an overview of integrating with Appian Cloud using AWS Privatelink, see AWS PrivateLink integration with Appian Cloud.

Architecture

In order to integrate with PrivateLink, the Appian Cloud VPC is configured as the service consumer connecting to your resource through an interface VPC endpoint. You will need to create a VPC endpoint service inside your own VPC (service provider) to expose your resources.

The end-to-end traffic flow is shown in the diagram below where the Appian Cloud environment forwards requests to the interface VPC endpoint over a private connection to your VPC endpoint service. In your VPC, this traffic is received by the Network Load Balancer (NLB) and routed to your service.

Alternatively, you may also want to leverage PrivateLink to connect with supported AWS managed services. In order to do this, skip the steps to create a VPC Endpoint Service, and use the managed service "service name" in your Appian Support Case notes.

privatelink image 1

Example Usage - HA Cloud Environment Integrated With An AWS Hosted Service

You can use PrivateLink to connect your Appian Cloud High-Availability environment with your external resources. An Appian Cloud HA environment is composed of three nodes distributed across three different Availability Zones. The application server running on each node forwards requests to a single VPC interface endpoint located in the Appian Cloud VPC. From there, the traffic is routed to the customer's service in the same fashion as described in the architecture section.

privatelink image 2

Example Usage - Multiple Cloud Environments Integrated With An AWS Hosted Service

The below example displays two Appian Cloud environments (Production and Development) forwarding requests to a customer's service over PrivateLink. The request originates from the Appian Cloud environment, which is routed over the interface VPC endpoint, to the customer's NLB. In this case, the customer has configured their NLB to distribute traffic between two different EC2 instances hosted in separate availability zones.

privatelink image 3

Example Usage - External Systems Accessed Through AWS Direct Connect

You may also utilize PrivateLink in conjunction with your own AWS Direct Connect to expose your systems to your Appian Cloud environments. Rather than forwarding traffic from the NLB directly to an AWS hosted service, you may configure your NLB with the target private IP address of your resource behind AWS Direct Connect.

Once traffic is received by the NLB, traffic can be routed through the virtual private gateway linked to your AWS Direct Connect. With this connection model, requests can be made directly to a service hosted in your private network without traversing the Internet. Note that the exact traffic flow will depend on the architecture of your network.

privatelink image 4

Prerequisites

The prerequisites below are not necessary to connect to a supported AWS managed service. To connect with one of these, open a Support Case and specify the service name that is provided in the AWS documentation for that managed service.

Prerequisite Steps Description Organizational Role
Create a VPC endpoint service This service must be created in the same AWS region as your Appian Cloud environments. To create a VPC endpoint service, follow the steps here. Your AWS Administrator
Allow Principals Upon creation of a VPC endpoint service, Appian will need access to send connection requests to the endpoint service. This can be achieved by adding IAM principals to the allowed principals list. You may add an entry of `*` to allow connection requests from any principal. The connection request from Appian can then be manually approved. Alternatively, you may request Appian Support to provide a specific principal to allow. Your AWS Administrator
Create a Support Case Open a support case with Appian Support. Include the following information:
  • Use Case: What type of service you are integrating with (i.e. LDAP, Data Source, etc)
  • Service Name: The AWS provided Service Name generated when creating the VPC endpoint service.
    • Example: com.amazonaws.vpce.us-east-1.vpce-svc-1234
  • Hostname: If your target system employs server side authentication (for example with TLS), you should also include the hostname that will be used when referencing this service in your Appian Cloud environments (see Handling Server-Side Authentication below).
  • Allowed Principals: You should provide confirmation that you have added * to the allowed principals list, or request for a specific principal to allow in the support case
Your Business Relationship Owner

Setup

Once the prerequisite steps above have been completed, Appian Support will work with you through the following configuration procedure.

We recommend testing on lower environments prior to elevating to production usage.

Configuration Action Description Owner
Create VPC endpoint Appian will create a VPC endpoint to connect to the VPC endpoint service you have provided. Appian
Accept VPC endpoint connection You will need to accept the VPC endpoint connection on your VPC endpoint service, unless the service is set to automatically accept connection requests. Your AWS Administrator
Provide endpoint-specific DNS hostname In the case that the your service does not employ server side authentication, Appian Support will provide you with an endpoint-specific DNS hostname that can be used to send requests to the endpoint service from your Appian Cloud environment. Appian
Schedule a Maintenance Window for the Affected environments Appian Support will work with you to schedule Maintenance Windows for the affected environments once the request has been accepted. The changes will be applied during this window. Appian
Update Admin Console to utilize new configurations Admin Console updates may be required to begin integrating with the new endpoint service. You may need to make updates to pre-existing configurations using the new DNS hostnames resolving to PrivateLink. Alternatively, you may need to create new entries for brand new integrations. Your Business Relationship Owner
Verify the integration works as expected Appian Support will work with you to ensure connectivity to your resources is working as expected. Appian / Your Business Relationship Owner

Handling Server Side Authentication

PrivateLink does not inherently encrypt traffic. In order to enhance your application level security, some implementations may employ encryption. Depending on the implementation, these clients may perform server-side authentication (for example, HTTPS, TLS, LDAPS) in order to prove the identity of the server to the client. This type of authentication may require the caller to reference your resource using a valid DNS hostname that matches the server certificate. In these cases, the certificate on your resource server will need to be trusted by a public Certificate Authority. Alternatively, in some implementations, you may be able to disable server certificate validation while still encrypting traffic; however, this is not recommended as your environment would still be susceptible to a man-in-the-middle attack to circumvent the encryption.

In order to ensure that the traffic from a particular hostname routes through PrivateLink, the hostname must resolve directly to the Appian VPC interface endpoint DNS name or to a particular Appian interface VPC endpoint ENI (Elastic Network Interface).

Appian Cloud currently supports two methods of enabling server name resolution:

Option 1: Customer Controlled Hostname DNS Resolution

In this method, you will need to add a publicly resolvable CNAME record in your DNS infrastructure that resolves the DNS hostname of your resource to the interface VPC endpoint DNS name provided by Appian. This means that DNS resolution will occur over the Internet, with the subsequent requests being sent over PrivateLink.

Option 2: Appian Controlled Hostname Resolution

Appian will resolve any calls to specific hostnames within the application to an Appian Cloud interface VPC endpoint ENI IP Address. This will allow any requests destined to that particular hostname to resolve directly to an ENI without traversing over the Internet. For this case, it is also recommended that you enable Cross Zone Load Balancing on your NLB to ensure traffic is load balanced among your instances evenly.

Limitations

Inbound Support

Appian Cloud supports inbound access using a different set of configurations. This is because the nature of AWS PrivateLink is inherently unidirectional. See the Access an Appian Cloud Environment Using AWS PrivateLink documentation for more details.

BYOK Support

Due to AWS limitations on supporting CloudHSM behind Network Load Balancers, BYOK is currently not supported over AWS PrivateLink.

RDS Support

RDS integrations can be successful; however, the implementation is not straightforward. RDS is not officially supported behind a Network Load Balancer; therefore, if you would like to connect to RDS environments over AWS PrivateLink, you will have to employ one of many workarounds to create a VPC endpoint service in their VPC. There are three common options that you may attempt:

  1. Using a private IP address of the RDS environment: RDS does not support static IPs; however, an IP address can be obtained through a DNS lookup of the RDS FQDN. A private IP from this lookup can then be utilized as a target for the Network Load Balancer that will be configured as part of the creation of a VPC endpoint service. However, it should be noted that AWS does not guarantee this IP remains associated with the RDS environment; in the case of a server failure, AWS may change the IP address of the RDS environment, therefore losing connectivity from the Network Load Balancer.
  2. Using a proxy EC2 environment(s): Forward proxies can be utilized to connect to your RDS environment indirectly. The traffic flow in this case would be Network Load Balancer > EC2 environment(Proxy) > RDS environment. In this case, the DNS name can be referenced from the proxy server rather than the private IP address in option 1; however, you would have the added cost of the EC2 environment(s) and possible performance degradation depending on a variety of factors such as the computing power of the proxy server(s).
  3. Using an AWS Lambda function: In this approach; you would need to set up a Lambda function which runs a DNS lookup of the RDS environment similar to option 1. However, this lambda function would have the added responsibility of adding the set of IPs to an S3 bucket and deregistering stale targets from the Network Load Balancer. This way, the downside to option 1 can be mitigated. Reference this AWS blog on how a similar setup worked for an Application Load Balancer (in this case RDS).

We strongly recommend that you conduct your own tests on your test and development Appian environments prior to implementing these setups in production.

Gateway Endpoints

Gateway endpoints are currently not supported.

VPC Endpoint Policies

VPC Endpoint policies are ways to restrict the use of an endpoint to specific resources (usually in relation to a particular AWS managed service such as API Gateway.) These policies are currently not supported for use with Appian Cloud integrations.

Open in Github Built: Fri, Jun 03, 2022 (01:08:29 PM)

On This Page

FEEDBACK