Today marks an exciting development as Amazon CloudFront, our global content delivery network (CDN), begins accepting gRPC API calls. gRPC is a modern, efficient framework designed for building APIs that is language-agnostic. Utilizing Protocol Buffers (protobuf) as its interface definition language (IDL), gRPC allows developers to define services and message types in a way that’s independent of the underlying platform. This facilitates communication between services via lightweight and high-performance remote procedure calls (RPCs) over HTTP/2, making it particularly suitable for microservices architectures.
gRPC boasts several features, including bidirectional streaming, flow control, and automatic code generation for multiple programming languages. It’s particularly effective in scenarios that demand high performance, efficient communication, and real-time data streaming. If your application needs to manage large datasets or requires low-latency interactions between client and server, gRPC is an excellent option. However, it may present a steeper learning curve compared to REST APIs, as it requires developers to specify their data structures and service methods through .proto files.
Implementing CloudFront in front of your gRPC API endpoints offers two primary advantages. First, it significantly reduces latency between client applications and your API implementation. With a global network of over 600 edge locations and intelligent routing to the nearest edge, CloudFront can minimize response times. These edge locations also provide TLS termination and optional caching for static content, while transferring client requests to your gRPC origin via a private AWS network that is fully managed, low-latency, and high-bandwidth.
Second, your applications can leverage added security measures available at edge locations, such as encryption of traffic, validation of HTTP headers through AWS WAF, and AWS Shield Standard protection to guard against DDoS attacks.
To illustrate this, I will demonstrate using the gRPC route-guide demo available in the official gRPC code repository. For ease of deployment, I will run this example application within a container, although other deployment methods are also supported.
Sample Dockerfile
FROM python:3.7
RUN pip install protobuf grpcio
COPY ./grpc/examples/python/route_guide .
CMD python route_guide_server.py
EXPOSE 50051
I will also utilize the AWS Copilot CLI to deploy my container on Amazon Elastic Container Service (Amazon ECS). The Copilot command will prompt me to gather the necessary information to build and deploy the container. Subsequently, it will create the ECS cluster, ECS service, and ECS task automatically, as well as generate a TLS certificate and load balancer. To test the client application, I will modify line 122 to reference the DNS name of the load balancer listener endpoint and adjust the client code to use grpc.secure_channel instead of grpc.insecure_channel since the load balancer provides an HTTPS endpoint.
Once I am confident that my API is deployed correctly, I will proceed to configure CloudFront. In the CloudFront section of the AWS Management Console, I will select “Create Distribution.” Under the Origin settings, I will enter my gRPC endpoint DNS name, enable HTTPS only for the protocol (leaving the HTTPS port as 443), and choose a name for the distribution.
For the Viewer settings, I will select HTTPS only for the Viewer Protocol Policy and allow HTTP methods GET, HEAD, OPTIONS, PUT, POST, PATCH, and DELETE. I will also enable gRPC requests over HTTP/2.
In the Cache Key and Origin Requests section, I will select AllViewer as the Origin Request Policy. Since gRPC traffic is not cacheable, I will opt for CachingDisabled as the Cache Policy. AWS WAF can help mitigate common web exploits and bots that may threaten availability or security, inspecting request HTTP headers and enforcing access control, although it does not analyze the protobuf request body.
For this demonstration, I will choose not to enable AWS WAF, selecting “Do not enable security protections.” I will keep all other settings at their default values, ensuring HTTP/2 support is active, as it is necessary for gRPC. Finally, I will click “Create Distribution.”
Enabling gRPC is as simple as flipping a single switch on top of the standard setup. When activated, with HTTP/2 and HTTP POST enabled, CloudFront identifies gRPC client traffic and forwards it to your gRPC origin. After a few minutes, the distribution will be ready. I will copy the CloudFront distribution endpoint URL and adjust my client application to point to CloudFront rather than the previous load balancer.
Upon testing the application again, I can confirm that it functions correctly.
Pricing and Availability
gRPC origins are supported across all more than 600 CloudFront edge locations without any additional charges. Standard requests and data transfer fees still apply. You can start pointing your CloudFront origin to a gRPC endpoint today. For more insights, check out this other blog post about gRPC and CloudFront.
— Alex
Leave a Reply