Cloud Platform

Web Elastic IP addresses FAQs

This page details the FAQs that are specific to Web Elastic IP addresses (Web EIPs).

What are Web EIPs? Why would my application need this feature?

For Cloud Platform Enterprise, Site Factory and Cloud Platform Professional subscribers, Acquia can provision an Elastic IP address (EIP) on the Cloud Classic application’s Drupal infrastructure when:

  • The application must communicate to a remote service

  • The service requires all sources of inbound connections to be allowlisted

In Cloud Next, outbound requests come from shared IPs. To allow auto-scaling and other resiliency measures, Acquia cannot assign specific servers to serve outbound requests for customer applications.

Web EIPs are designed to solve this problem. Application environments are assigned dedicated outbound proxies, and the proxies are assigned static IP addresses. Requests that originate from an application go through the proxies on their way out of the Acquia network, and you can allowlist the static IPs.

How does a customer get Web EIPs? Is it an entitlement?

Customers who opt for Elastic IP addresses (EIPs) for their Cloud Classic applications receive Web EIPs as part of their Cloud Next upgrade. Self-service is not available for Web EIPs. Cloud Next customers who need Web EIPs added to an environment must create a Support ticket.

How many Web EIPs does an application receive?

  • Two Web EIPs in production environments

  • One Web EIP in non-production environments

Can I move my existing elastic IPs from my Cloud Classic environment to Cloud Next?

No, there is no ability to move an existing elastic IP from a Cloud Classic server to a Cloud Next Web EIP proxy. New IP addresses are provisioned as part of your Cloud Next upgrade.

Where can I view the Web EIPs for my application?

To view your Web EIPs, access the Cloud Platform user interface. Web EIPs are listed on the Infrastructure page for a given application environment.

In which regions are Web EIPs available?

This feature is available in all Cloud Next-enabled regions.

Are Web EIPs highly available?

  • For production environments, Acquia provides a pair of Web EIPs for high availability. If one of the proxies becomes unavailable, traffic is routed to the other proxy automatically.

  • For non-production environments, there is no high availability. If the Web EIP proxy becomes unavailable, applications cannot make outbound requests until the unhealthy proxy is automatically replaced by Kubernetes.

What kind of outbound traffic is supported by this feature? Is it just HTTP/HTTPS traffic only, or can I use it for other types of traffic like SMTP, LDAP, SFTP?

With the egress proxy, Web EIPs enable any protocol or library to use static IPs or EIPs to make outbound requests.

Some of the supported protocols or libraries are:

  • Outbound HTTP and HTTPS requests by using curl libraries or PHP streams and file_get_contents()

  • Log forwarding

  • SMTP

  • LDAP

  • SSH/SFTP

  • MySQL

Is any port usable or only the standard ports 80 and 443?

Any destination port is supported.

Is this feature available for cron jobs or interactive SSH sessions?

Yes, cron jobs and interactive SSH sessions have access to the Web EIP proxies.

Does this work with anything running on Cloud Next or just Drupal and PHP?

Acquia tested that Web EIPs work with the following methods for making HTTP/HTTP requests from Drupal, PHP, or command line:

What if I want to integrate Web EIPs with PHP scripts other than Drupal? What if my application is not using Web EIPs automatically?

Acquia does not support use of the Web EIPs feature by processes other than Drupal, Drush, or curl.

If your application is not using Web EIPs as expected, ensure that any contributed or custom modules use methods provided by Drupal for making external requests.

Are there any limitations to the TLS versions it can handle?

There are no limitations to the TLS versions supported by Web EIPs.

Does it introduce a timeout that my application needs to be aware of?

The Web EIP proxy does not introduce a timeout. It relies on the client, for example, Drupal or PHP to enforce a timeout and terminate the request.

Will New Relic report these connections?

Yes, New Relic reports these connections.