Deployment guide

Envoy

Overview

Envoy is a high-performance, cloud-native Layer 7 edge and service proxy. It was originally built at Lyft and is now a graduated CNCF project. Envoy is the data plane behind Istio and many service meshes, and it is widely used for API gateways, edge routing, load balancing, observability and zero-trust service-to-service traffic.

The SecureAnyCloud image installs the official Envoy binary as /usr/local/bin/envoy and runs it under a dedicated envoy system user. It ships a sample proxy configuration, so the proxy is serving traffic from the moment the VM boots.

What you get:

Envoy 1.31.x (Apache-2.0), the official upstream binary, at /usr/local/bin/envoy.
An envoy.service systemd unit, enabled and running on boot, under a dedicated envoy user.
A sample proxy configuration at /etc/envoy/envoy.yaml with an HTTP listener on 0.0.0.0:10000.
An http_connection_manager that routes requests through to a sample upstream cluster, demonstrating L7 routing and upstream proxying.
The Envoy admin interface on 127.0.0.1:9901 (/ready, /stats, /clusters) and stdout access logging.
24/7 SecureAnyCloud support.

Envoy has no product web UI. The admin interface on port 9901 is a debug and observability surface, and it is bound to loopback only. The proxy listener uses port 10000, and the SecureAnyCloud image does not open 10000 in any network security group. Front the listener with your own TLS and NSG rules, and adapt the sample configuration to your own routes, clusters, filters and authentication. The proxy ships no per-VM password.

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a good starting point.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network. Open 10000/tcp, or front it with your own load balancer and TLS termination, only when you are ready to expose the proxy to clients.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Envoy by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22).

Select Review + create, then Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:envoy-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name envoy \
  --image sac1647283583153:envoy-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

Step 3 - Connect to your VM

Connect over SSH as azureuser:

ssh azureuser@<vm-public-ip>

Step 4 - Confirm Envoy is installed and running

Check the version and confirm that the service is active:

envoy --version systemctl is-active envoy

envoy --version reports the Envoy version and build, and systemctl is-active envoy prints active.

Step 5 - Review and validate the sample configuration

The sample proxy configuration lives at /etc/envoy/envoy.yaml. It declares the admin interface, an HTTP listener, the routes that map incoming requests onto an upstream cluster, and the upstream cluster definition. View it:

cat /etc/envoy/envoy.yaml

Envoy configuration is declarative. You describe the listeners, routes, clusters and filters you want, and Envoy programs its data plane accordingly. Before the service loads a configuration, validate its syntax and semantics with Envoy's built-in validation mode:

envoy --mode validate -c /etc/envoy/envoy.yaml

A valid configuration prints configuration '/etc/envoy/envoy.yaml' OK. Run this validation every time you edit envoy.yaml, then run sudo systemctl restart envoy to apply your changes.

Step 6 - Check the admin readiness endpoint

Envoy exposes an admin interface on 127.0.0.1:9901. The /ready endpoint returns 200 with the body LIVE when the proxy is up and serving:

curl 127.0.0.1:9901/ready

You can use this endpoint for your Azure Load Balancer or Application Gateway health probe. Proxy it appropriately, because the admin interface is loopback-only by design. The admin interface also exposes /stats and /clusters for observability.

Step 7 - Make a request through the proxy

The sample configuration routes every request on the listener through to the upstream cluster. Envoy receives a request on the listener, the http_connection_manager routes it, and Envoy proxies it to the upstream. The upstream returns the response back through Envoy to you:

curl -s 127.0.0.1:10000/posts/1

The JSON response is the upstream's reply, returned through Envoy. It shows that the proxy routes traffic end to end.

Step 8 - Inspect the upstream cluster health

Envoy continuously tracks the state of every upstream. The admin /clusters endpoint reports each cluster, its endpoints, connection and request counters, and health flags:

curl -s 127.0.0.1:9901/clusters

Look for the sample_upstream cluster. The health_flags::healthy line and the active connection counters confirm that Envoy considers the upstream reachable and is routing to it.

Envoy also writes a stdout access log, captured by journald, for every request it proxies:

sudo journalctl -u envoy -n 20 --no-pager

Step 9 - Build your own proxy

Edit /etc/envoy/envoy.yaml to define your own listeners, routes, clusters and filters. The sample, a single HTTP listener routing to one upstream cluster over TLS, is the foundation for most edge and service-proxy use cases. You can layer on rate limiting, JWT authentication, CORS, header transformation, retries, circuit breaking and gRPC support from Envoy's filter chain.

Always run envoy --mode validate -c /etc/envoy/envoy.yaml before restarting the service. See the Envoy documentation for the full configuration reference.

To expose the proxy to clients, open 10000/tcp (or your chosen listener port) in your NSG, ideally only from a load balancer subnet. The recommended approach is to place Envoy behind an Azure Application Gateway, or to terminate TLS directly in Envoy with a TLS transport socket on the listener.

Support

SecureAnyCloud maintains this image with 24/7 support. Envoy is licensed under the Apache License 2.0. Envoy and Envoy Proxy are trademarks of The Linux Foundation / CNCF. SecureAnyCloud is an independent image publisher and is not affiliated with or endorsed by the Envoy project or the CNCF. For help with the image or your deployment, contact sales@secureanycloud.com.

Deploy on Azure

Launch Envoy Proxy on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure

Overview

The SecureAnyCloud image installs the official Envoy binary and runs it as a systemd service under a dedicated envoy user. It ships a sample proxy configuration that reverse-proxies HTTP traffic to an upstream, so the proxy is serving traffic from the moment the instance boots. An nginx front on port 80 reverse-proxies public traffic to the Envoy listener, so you can exercise the proxy from any client straight away.

What you get:

Envoy (Apache-2.0), the official upstream binary.
An envoy.service systemd unit, enabled and running on boot, under a dedicated envoy user.
A sample proxy configuration at /etc/envoy/envoy.yaml with an HTTP listener on 0.0.0.0:10000.
An http_connection_manager that routes requests through to a sample upstream cluster, demonstrating L7 routing and upstream proxying.
nginx on port 80 reverse-proxying public traffic to the Envoy listener on 10000.
The Envoy admin interface on 127.0.0.1:9901 (/ready, /stats, /clusters, /config_dump) and access logging.
The access log and runtime content on a dedicated data volume mounted at /var/lib/envoy.
24/7 SecureAnyCloud support.

Envoy is a headless proxy service. There is no web interface to log in to, and the image ships no per-instance password. The admin interface on port 9901 is a debug and observability surface, and it is bound to loopback only. Welcome notes for the image live in a root-only file. Read them with sudo cat /root/envoy-info.txt.

Prerequisites

You need an Amazon Web Services account where you can launch EC2 instances, an EC2 key pair in the target Region, and a VPC with a subnet.

m5.large is a good starting point.

Configure the security group to allow inbound 22/tcp from your management network and 80/tcp from the clients that should reach the proxy through the nginx front.

Launch the Instance from the AWS Marketplace

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for Envoy by SecureAnyCloud. Select the SecureAnyCloud listing, choose Select, and then choose Continue on the subscription summary.

Pick your instance type and EC2 key pair. Under Network settings, select a security group that allows inbound ports 22 and 80 as described above, then select Launch instance.

Launch the Instance from the AWS CLI

Run the following command, replacing the values in angle brackets with your own:

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=envoy-01}]'

Connect to your Instance

The SSH login user depends on the operating system of the AMI variant you launched:

AMI variant SSH login user

Envoy on Ubuntu 24.04 ubuntu

ssh -i <path-to-key>.pem ubuntu@<instance-public-ip>

Read the welcome notes with sudo cat /root/envoy-info.txt.

Confirm Envoy is installed and running

Check the version and confirm that the service is active:

envoy --version systemctl is-active envoy

envoy --version reports the Envoy version and build, and systemctl is-active envoy prints active.

Review and validate the sample configuration

cat /etc/envoy/envoy.yaml

sudo envoy --mode validate -c /etc/envoy/envoy.yaml

A valid configuration prints configuration '/etc/envoy/envoy.yaml' OK. Run this validation every time you edit envoy.yaml, then run sudo systemctl restart envoy to apply your changes.

Check the admin readiness endpoint

Envoy exposes an admin interface on 127.0.0.1:9901. The /ready endpoint returns 200 with the body LIVE when the proxy is up and serving:

curl 127.0.0.1:9901/ready

You can use this endpoint for your Application Load Balancer health probe. Proxy it appropriately, because the admin interface is loopback-only by design. The admin interface also exposes /stats, /clusters and /config_dump for observability.

Make a request through the proxy

The sample configuration routes every request on the listener through to the upstream cluster. The Envoy listener binds port 10000, and nginx on port 80 reverse-proxies public traffic to it. You can exercise the proxy from the instance or from any client your security group allows:

curl -s -i 127.0.0.1:10000/ | head -20
curl -s -i http://<instance-public-ip>/ | head -20

The response is the demo backend page, returned through Envoy. Look for the x-envoy-upstream-service-time response header that Envoy adds. It shows that the proxy routes traffic end to end.

Inspect the upstream cluster health

Envoy continuously tracks the state of every upstream. The admin /clusters endpoint reports each cluster, its endpoints, connection and request counters, and health flags:

curl -s 127.0.0.1:9901/clusters

The health_flags::healthy line and the active connection counters confirm that Envoy considers the upstream reachable and is routing to it.

Envoy also writes an access log for every request it proxies. The access log and runtime content live on the dedicated data volume at /var/lib/envoy:

sudo journalctl -u envoy -n 20 --no-pager findmnt /var/lib/envoy

Build your own proxy

Edit /etc/envoy/envoy.yaml to define your own listeners, routes, clusters and filters. The sample, a single HTTP listener routing to one upstream cluster, is the foundation for most edge and service-proxy use cases. You can layer on rate limiting, JWT authentication, CORS, header transformation, retries, circuit breaking and gRPC support from Envoy's filter chain.

Always run sudo envoy --mode validate -c /etc/envoy/envoy.yaml before restarting the service. See the Envoy documentation for the full configuration reference.

Point the sample cluster at your own upstream services, and open whatever additional ports your listeners need in the instance security group. For public exposure, keep the nginx front (or your own TLS termination) on port 80 or 443. Alternatively, place Envoy behind an Application Load Balancer, or terminate TLS directly in Envoy with a TLS transport socket on the listener.

Support

Deploy on AWS

Launch Envoy Proxy on AWS with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on AWS