Envoy Proxy on AWS User Guide

Overview

Envoy is a high-performance, cloud-native Layer 7 edge and service proxy. Originally built at Lyft and now a graduated CNCF project, it is the data plane behind Istio and many service meshes, and is widely used for API gateways, edge routing, load balancing, observability and zero-trust service-to-service traffic. The cloudimg image installs the official Envoy binary, runs it as a systemd service under a dedicated envoy user, and ships a clear ready-to-run 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. Backed by 24/7 cloudimg support.

What is included:

• 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 cloudimg 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 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

An Amazon Web Services account where you can launch EC2 instances, an EC2 key pair in the target Region, and a VPC + subnet. m5.large is a good starting point. Security group inbound: allow 22/tcp from your management network and 80/tcp from the clients that should reach the proxy through the nginx front.

Step 1: 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 cloudimg. Select the cloudimg listing and choose Select, then Continue on the subscription summary. Pick your instance type and EC2 key pair, and under Network settings select a security group that allows inbound ports 22 and 80 as described above. Select Launch instance.

Step 2: Launch the Instance from the AWS CLI

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}]'

Step 3: Connect to your Instance

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

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

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

Step 4: Confirm Envoy is installed and running

Check the version and 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 ready-to-run 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:

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

A valid configuration prints configuration '/etc/envoy/envoy.yaml' OK. Run this every time you edit envoy.yaml, then 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

Use this endpoint for your Application Load Balancer health probe (proxied appropriately, since the admin interface is loopback-only by design). The admin interface also exposes /stats, /clusters and /config_dump for observability.

Step 7: 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, so you can exercise the proxy from the instance or from any client allowed by your security group:

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 back through Envoy - look for the x-envoy-upstream-service-time response header that Envoy adds, proving the proxy actually 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

The health_flags::healthy line and active connection counters confirm 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

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 - is the foundation for most edge and service-proxy use cases; 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/443, or place Envoy behind an Application Load Balancer, or terminate TLS directly in Envoy with a TLS transport socket on the listener.

Support

This image is maintained by cloudimg with 24/7 support. Envoy is licensed under the Apache License 2.0. Envoy and Envoy Proxy are trademarks of The Linux Foundation / CNCF; cloudimg 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 support@cloudimg.co.uk.