Mastering Full Request and Response Logging on Amazon EKS

Full request and response compliance logging is essential for maintaining transparency and accountability in microservices architectures. It allows you to capture all aspects of HTTP interactions, which is vital for debugging, auditing, and regulatory compliance. By leveraging Envoy’s External Processing filter, you can log complete request and response data seamlessly, without touching your application code.

When an HTTP request enters your system, it follows a defined path. The client sends an HTTPS request, which is resolved by DNS to a Network Load Balancer (NLB) in your VPC. The NLB forwards this request to the Istio Ingress Gateway within your Amazon EKS cluster. The Ingress Gateway routes the traffic into the service mesh based on Gateway and Virtual Service resources. Once matched, the request hits the Envoy sidecar proxy, which is automatically injected into each pod by Istio. The Envoy sidecar then opens a bidirectional gRPC stream to the external processing service, a standalone Kubernetes Deployment running a gRPC server that implements the Envoy External Processing API. After the ext_proc server approves both the request and response phases, Envoy forwards the complete request to the application container, processes it, and returns the response. This entire interaction culminates in a single audit log entry, correlating all four phases—request headers, request body, response headers, and response body—using the x-request-id header.

In production, ensure you have the necessary tools installed, including AWS CLI, Terraform, and kubectl. The setup involves cloning a sample repository and initializing Terraform to manage your infrastructure. Be aware that you are working with an Amazon EKS 1.35 cluster in Auto Mode, which simplifies node provisioning and scaling. Pay attention to the integration of Envoy and Istio, as misconfigurations can lead to logging gaps or performance issues.