Fastly customers + friends,

Another quarter has flown by and we are delighted to announce the following Compute@Edge and security additions to our product portfolio. Compute@Edge users can now locally test applications and access eight new health metrics. On the security side, next-gen WAF customers can request health checks on their service and receive expert advice on how to improve their deployment. Rate limiting is now available in two options: Fastly’s Edge Rate Limiting and Non-IP Rate Limiting. Fastly’s Edge Rate Limiting helps to sustain uptime during automated attacks. Non-IP Rate Limiting enables customers to include non-IP values such as cookie value to the rate limit. Lastly, Subscriber Provided Prefix has graduated to General Availability, allowing users to maintain their own IP addresses.

Table of Contents

Compute@Edge Local Testing

Compute@Edge Local Testing is now available for developers to safely test their applications locally without deploying broadly. Customers of Compute@Edge often cite having a local testing environment as a must when considering edge serverless solutions because integrating and setting up a local testing environment is non-trivial and time-consuming. Fastly’s Compute@Edge Local Testing feature addresses this concern and greatly improves the overall developer experience, resulting in a quicker path to launch customers’ experiments. Local Testing is also invaluable in providing a scalable and repeatable regression testing path for new releases of an existing Compute@Edge service.

Compute@Edge Stats

New real-time and historical health metrics are now available for Compute@Edge users. This highly-requested functionality provides additional visibility into runtime errors and helps customers debug their deployed code. For example, the limits exceeded stat shows customers how their workloads affect their resource usage budget and empowers them to tweak their code to improve efficiency.

Newly Available Compute@Edge Stats include:

  • compute_bereqs: Number of backend requests started

  • compute_bereq_errors: Number of backend request errors including timeouts

  • compute_resource_limit_exceeded: Number of times a guest exceeded its resource limit (includes heap, stack, globals, and code execution timeout)

  • compute_runtime_errors: Number of times a service experienced a guest runtime error

  • compute_heap_limit_exceeded: Number of times a guest exceeded its heap limit

  • compute_stack_limit_exceeded: Number of times a guest exceeded its stack limit

  • compute_globals_limit_exceeded: Number of times a guest exceeded its globals limit

  • compute_guest_errors: Number of times a service experienced a guest code error

Next-gen WAF Health Check

As part of our Signal Sciences Professional Services menu, Fastly can perform a health check of customers’ deployments of cloud WAF or next-gen WAF to verify that their deployment is in a "good" state and being fully utilized. Our team will work to understand how the customer currently uses our cloud WAF or next-gen WAF and then provide an assessment that summarizes how the customer can gain more value from their deployment.

Rate Limiting Releases

Rate limiting is a platform-based feature that enables customers to control the rate of requests coming into any Fastly service. This practice prevents attack traffic from impacting latency and end-user experience. We offer Edge Rate Limiting in Limited Availability and Non-IP Rate Limiting in General Availability.

Edge Rate Limiting
Fastly’s Edge Rate Limiting allows customers to identify and rate limit abusive attack traffic at the Fastly network edge. This feature is designed to help customers control the rate of requests sent to their Fastly services and origin servers and has UI, API and VCL interfaces for maximum flexibility. Edge rate limiting can help ensure availability and uptime during periods of excessive traffic by slowing down automated attacks at the edge. This service complements the core cloud protection offered by our next-gen WAF and fortifies the customer’s security posture with an additional layer of defense. The feature is available at no additional charge as part of the Secure Premier Plan.

Non-IP Rate Limiting
Non-IP Rate Limiting allows users to specify non-IP values, such as subject header value or cookie value, to count towards the rate limit rather than just IP addresses. This provides even more effective protection against sophisticated attackers cycling through IPs with adaptive attacks to evade rate limiting. With Fastly rate limiting, customers can detect and block excessive web request traffic and maintain uptime and reliability for their sites and services—all without impacting app or API performance. Any Signal Sciences customer can now use this feature if their agents and modules are supported.

Subscriber Provided Prefix

Fastly's Subscriber Provided Prefix service allows customers to have their IP spaces announced, routed, and served by Fastly infrastructure for use with production services. When enabled, customers can provide their own IP address space to Fastly rather than use Fastly IP addresses. Customers can then direct traffic to their own IP addresses, which are reachable via HTTP Anycast on Fastly's infrastructure. We recommend this service for customers who want to control their address space by separating their network layer concerns from their content delivery concerns. Fastly's Subscriber Provided Prefix service can be combined with Origin Connect and our DDoS Protection and Mitigation service, to protect customers’ origin servers by directing traffic through Fastly's global network.

Ready to get started?

Get in touch or create an account.