Written by Lucas Marsala, DevOps Engineer at TrackIt
Content delivery networks power modern digital experiences, yet each platform takes a different approach to configuration and edge logic. Fastly relies on Varnish Configuration Language (VCL) files to define edge logic, caching rules, and request handling. Amazon CloudFront, by contrast, uses a combination of cache behaviors, origin configurations, and AWS-native services such as CloudFront Functions and Lambda@Edge to achieve similar results. CloudFront configurations can also be managed declaratively through Infrastructure-as-Code (IaC) frameworks such as AWS CloudFormation or Terraform, giving teams flexibility in how they define and maintain delivery infrastructure.
Fastly is also more flexible at the edge, with extensive conditional logic capabilities that must be accounted for during migration. At the same time, VCL can be less intuitive to read and interpret compared to declarative IaC approaches such as Terraform, adding another layer of complexity.
Contents
Reducing Risk in CDN Migrations: Fastly VCL to CloudFront
The sections below highlight the key points and challenges of migrating from Fastly to CloudFront. They explain how VCL-based rules can be translated into CloudFront behaviors, how AWS services such as CloudFront Functions and Lambda@Edge can be leveraged, and how to ensure a smooth cutover with minimal impact on performance or availability.
Understanding the Challenges of CDN Migration
Migrating from Fastly VCL to Amazon CloudFront involves translating Fastly’s flexible edge logic and caching rules into CloudFront’s configuration model. This is challenging due to architectural and capability differences. Fastly allows granular control over request handling, header manipulation, and caching behaviors directly at the edge using VCL. CloudFront, on the other hand, relies on cache behaviors, origin configurations, and Lambda@Edge functions to achieve similar outcomes.
To ensure a successful migration, the first step is to gain a clear understanding of the current environment. This involves taking stock of caching rules, endpoints, SSL certificates, custom headers, DNS records, origin configurations, and delivery requirements. Once the baseline is established, the features and limitations of the target CDN should be reviewed to determine how existing rules and behaviors can be mapped. This process helps identify potential gaps and adjustments early.
Why Planning Matters
A CDN migration demands careful, detailed planning. Even small oversights can result in broken links, degraded performance, or unexpected downtime once live traffic is introduced. The effort often spans multiple environments, requires coordination across teams, and demands a clear understanding of how traffic will behave during and after the switch.
Translating VCL Logic Manually
Manual migration from Fastly to Amazon CloudFront begins with a detailed audit of existing VCL files. The objective is to document every functional component—caching rules, conditional logic, header rewrites, redirects, and routing flows—before making any changes.
Once the baseline is established, each rule can be mapped to CloudFront’s configuration model. Cache Behaviors handle path- and header-based conditions, while CloudFront Functions and Lambda@Edge enable advanced logic and header manipulation directly at the edge. Origin settings and associated policies allow fine-tuning of caching, TTLs, compression, and redirect handling.
Not every VCL feature has a direct equivalent in CloudFront. In such cases, additional AWS services such as API Gateway or AWS WAF can be integrated to replicate the desired behavior.
The following examples illustrate some of the most common Fastly rules and how they can be translated for CloudFront. These examples provide a practical reference for teams performing manual migrations or seeking a deeper understanding of the mapping process.
The most common rule categories include:
- Cache Control: Defines what content is cached, for how long, and under which conditions.
- Header Manipulation: Adds, modifies, or removes HTTP headers in requests and responses.
- Redirect Rules: Direct users to alternative URLs or domains based on specific conditions.
- Access Control: Restricts or permits access to certain content according to criteria such as IP address, geographic location, or authentication status.
Cache Control Rule
In the example provided above, the VCL configuration defines a simple caching rule. All requests for files ending with “.html” are cached for ten minutes, while any requests beginning with “/api/” are never cached.
To replicate this behavior in Amazon CloudFront, an ordered cache behavior must be created for the /api/ path to ensure those requests bypass caching. The following snippet illustrates how both rules can be implemented in CloudFront using Terraform.
Both rules are nearly identical; the main difference lies in the cache_policy_id and TTL settings. For the /api/ path, caching is disabled, while the .html files are configured to be cached.
For those unfamiliar with Terraform, the same configuration can be achieved directly through the AWS Management Console. Within the Behaviors section of a CloudFront distribution, a rule can be created for the pattern /api/ with the cache policy set to CachingDisabled. The remaining configuration primarily involves defining the Origin and Origin Groups, which in most cases will point to an Amazon S3 bucket.
Geographic Rule
CloudFront cannot natively replicate every rule supported in Fastly. In certain cases, additional AWS services are required to achieve equivalent functionality. One common example involves geographic rules, where content availability must vary by region. In some parts of the world, it may be necessary to restrict or modify specific content based on local regulations. In such scenarios, the AWS Web Application Firewall (WAF) can be used to manage geographic restrictions.
For instance, if a website contains information that cannot be displayed in countries such as Russia or China, WAF can be configured to block access from those regions. Below is an example of the corresponding VCL file.
If a client request originates from Russia or China, it will be blocked. To identify the client’s location, the configuration relies on ISO country codes.
When working with AWS WAF, several key parameters must be defined. In this example, the rule is named BlockSpecificCountries. The rule name serves primarily for identification and documentation purposes—it does not affect the configuration’s functionality.
There are three main components in a WAF rule:
- Priority: Defines the order in which rules are evaluated. Rules are processed from the lowest priority number to the highest.
- Statement: Specifies the condition or logic that determines when the rule applies.
- Action: Defines what WAF should do when a request matches the rule condition.
In this simple WAF configuration, the priority is set to 1. The statement uses a GeoMatchStatement, which matches requests originating from Russia or China using their ISO country codes. Finally, the action section instructs WAF to Block the request and return a 403 response with custom HTML content.
Compared to VCL, implementing this type of rule in CloudFront requires additional services, which can make the setup slightly more time-consuming. While maintaining separate services may seem complex, it actually simplifies debugging and troubleshooting in large infrastructures. By isolating logic across dedicated components, issues become easier to identify and resolve without sifting through excessive configuration details.
Header Manipulation Rule
This next example focuses on header manipulation rules, which involve removing or modifying headers to enhance security and protect sensitive information.
The goal is to minimize the exposure of implementation details. Headers that reveal server technology or version—such as Server—can allow attackers to target known vulnerabilities (CVEs). The same applies to X-Powered-By, which may disclose the framework or platform used to build the site. Similarly, the Via header can expose proxy or caching layers, potentially helping attackers infer request flows and attempt evasion.
On CloudFront, header removal is commonly implemented with a lightweight edge function. Lambda@Edge or CloudFront Functions can strip or rewrite response headers before they reach the client, thereby reducing the attack surface without modifying backend logic.
It is important to consider that introducing additional services can affect overall infrastructure costs. Although Lambda functions are not among the most expensive AWS services, their usage still contributes to the total operational spend. Each added component—whether for logic, monitoring, or automation—should be evaluated as part of the broader cost analysis before initiating the migration.
Conclusion
Migrating from Fastly VCL to Amazon CloudFront requires translating custom edge logic into CloudFront’s configuration model. While VCL scripts provide direct control over caching, routing, and headers, CloudFront achieves similar functionality through cache behaviors, origin settings, and edge compute options such as CloudFront Functions and Lambda@Edge.
Successful migration depends on accurately mapping each VCL rule to its CloudFront equivalent and bridging any gaps with supporting AWS services like AWS WAF for security and API Gateway for routing. Managing the deployment through Terraform or AWS CloudFormation ensures automation, consistency, and version control across environments.
Ultimately, the objective is to preserve Fastly’s flexibility while leveraging CloudFront’s scalability, reliability, and deep integration within the AWS ecosystem.
About TrackIt
TrackIt is an international AWS cloud consulting, systems integration, and software development firm headquartered in Marina del Rey, CA.
We have built our reputation on helping media companies architect and implement cost-effective, reliable, and scalable Media & Entertainment workflows in the cloud. These include streaming and on-demand video solutions, media asset management, and archiving, incorporating the latest AI technology to build bespoke media solutions tailored to customer requirements.
Cloud-native software development is at the foundation of what we do. We specialize in Application Modernization, Containerization, Infrastructure as Code and event-driven serverless architectures by leveraging the latest AWS services. Along with our Managed Services offerings which provide 24/7 cloud infrastructure maintenance and support, we are able to provide complete solutions for the media industry.