AWS Edge Services - CDN Migration
Best practices to migrate your Content Delivery Network (CDN) from 3rd party solutions to Amazon CloudFront
Achraf Souk
Amazon Employee
Published Apr 29, 2025
Content Delivery Networks (CDNs) play a crucial role in web application delivery by distributing content across globally dispersed servers. By doing so, CDNs increase the application's performance, security and availability. AWS provides customers with its native CDN, Amazon CloudFront, built with the highest standards of reliability on top of the AWS global network.
It's based on a pay-as-you-go single model for different types of applications, ranging from video streaming to dynamic API delivery, that can be optimized with private pricing agreements. CloudFront's developers appreciate the native integration with familiar AWS DevOps tooling, such as CloudWatch for observability, AWS Identity and Access Management (IAM) for access control and the AWS Cloud Development Kit (CDK) for Infrastructure as Code (IaC) based deployments.
If you decide to migrate your CDN from a 3rd party provider to CloudFront, consider the following steps to increase the chances of a successful migration.
The planning step is a project management exercise where the project is defined.
First, you need to scope the web properties that are included as part of the migration. For example, you might decide to keep the website of a streaming service with a 3rd party CDN for the time being, while migrating the video delivery itself to CloudFront. Then, define the main project milestones with their respective timeline, for example:
- [1 week] Create a target design using AWS services that meets your requirements
- [1 week] Stage configuration and validate it
- [3 weeks] Roll out production traffic to CloudFront progressively
- [1 week] Fine tune to optimize cost, security and performance
The duration of rolling out production traffic to CloudFront depends on the complexity of the migration. Consider the following rollout strategies:
- Start with low risk web properties - It could be a domain with low traffic, or low impact to your business. This approach minimizes risk to your business and enables you to troubleshoot without much pressure. It also gives you more confidence in moving more critical web properties.
- Progressively migrate geographies - If you operate across different countries, you can phase the migration across those countries, starting with countries with the least amount of user traffic. This can be achieved using DNS features such as Route 53's geolocation routing.
- Shift traffic gradually - For your most critical web properties, route traffic in smaller increments using DNS features such as Route 53 weighted routing. Start by routing 1 to 5% of your production traffic to CloudFront, then wait for a soaking period (e.g., 24 hours) to warm the CDN and surface any potential issues, then progressively increment.
- Enable features incrementally - To reduce the moving parts of a migration, you can enable functionalities in an incremental way. For example, you can add protections using AWS WAF from the beginning, but keep them in monitoring Count mode to avoid inadvertently blocking legitimate traffic (false positives). You can later change the actions to their target setting.
The timeline of the project should align with the expiration dates of existing 3rd Party contracts, giving enough time ahead to send notice, and have enough overlapping time between contracts to safely roll out the change.
At this stage, it’s important to decide about the required human resources to undertake the migration, whether it's in-house engineers or with the help of AWS partners who have competencies in CloudFront and AWS WAF.
This step is led by your system architects, in collaboration with security and applications teams, to produce a target Content Delivery Network design using CloudFront and other AWS services. Every CDN has a different approach in its configuration building blocks and default settings, so it's recommended to first understand the mental model of configuring CloudFront with AWS WAF to produce the most optimal target design on AWS.
For each of your web properties, break it down into different parts according to the content being served. For every part identified by a specific path or route (e.g., /api/*), define the technical requirements and how you will satisfy them using AWS services:
- How do I secure the connection to the origin server? Consider different origin cloaking techniques.
- Is caching needed? If so, for how long and using which cache key? Use CloudFront cache policies.
- What functionalities are required on this path? Some, like text compression using Gzip/Brotli, or API acceleration, can be fulfilled natively using CloudFront. Others would require writing custom code using CloudFront edge functions, such as image optimization, HTTP Redirections, and A/B testing.
- What security controls are needed? Based on your threat modeling, you can implement most of your security controls using AWS WAF, such as geoblocking, bot management and protections against DDoS attacks.
The following is a simplified high-level target design for one web property:
Migrating your CDN to CloudFront is a great opportunity for your architects to modernize your existing setup away from legacy configurations and benefit from the latest technology advancements in the content delivery industry.
Finally, consider how you will enable observability to quickly detect and react to issues during the migration, and to validate that the migration is meeting its intended business goals. You can monitor the different components of your architecture using CloudWatch metrics and create alarms based on them. An example could be alarming when 5xx error rates on CloudFront increase beyond a certain threshold. You can also create custom dashboards using AWS managed analytics services based on access logs generated by CloudFront and AWS WAF.
Customers usually move to CloudFront to achieve business goals such as:
- Reduce the overall content delivery and security costs - Use AWS Cost Explorer to monitor such costs and validate that you are meeting your financial goals of the migration.
- Improve the stability and performance of web application - Use CloudWatch RUM to measure the performance of your web application with your own users using KPIs such as Google Core Web Vitals. Other CDN performance KPIs include Cache Hit Ratio that can be monitored using CloudWatch metrics. Note that CHR can be calculated differently by CDNs.
- Increase security coverage - Conduct penetration testing, such as DDoS simulation, to validate how your AWS WAF protections have increased your security coverage. CloudWatch emits metrics for every configured AWS WAF rule.
In this step, your DevOps team will take ownership of preparing the needed configurations (e.g., CloudFront distributions, AWS WAF WebACLs, and new Load Balancers) before actually starting the migration. Changes can be made manually using the AWS Console. However, if you are familiar with IaC tools such as CDK, CloudFormation, or Terraform, it's better to automate the deployment and future changes using these tools.
Note that new features in AWS takes weeks to be available in CloudFormation, followed by CDK. To deploy AWS WAF WebACLs at scale across different teams in an organization, consider using AWS Firewall Manager as an alternative. It allows you to build a security governance where central security teams can audit, enforce compliance, and react quickly to emerging threats. Read this article to learn more about AWS WAF governance possibilities using Firewall Manager.
Typically, you need to prepare the following configuration artifacts:
- The configuration of CloudFront, such as caching, routing, etc.
- The code for any edge function you are using
- The configuration of other infrastructure components, such as S3 for storage, or Lambda for image processing
- Changes to your existing infrastructure, such as implementing origin cloaking
- The rules in your AWS WAF WebACL
- Observability (Logging, dashboards, alarms, etc.)
- The CI/CD pipeline for deploying CDK-based configuration if you are using CDK
- IAM permissions to your team members or partners in order to carry out the relevant tasks
By applying the concept of least privilege, AWS IAM enables you to allow specific actions against relevant resources to avoid human errors leading to misconfigurations. For example, you can grant UploadServerCertificate permissions to an operator performing a certificate-related migration task only during office hours. Note that in CloudFront, when an operator has IAM permissions to access a CloudFront distribution, they can make changes to all routes of its configuration.
Finally, test and validate the configuration in a staging environment prior to promoting them to production. To conduct tests, you can artificially route your test clients to CloudFront using the following popular methods:
- Changing your OS local hosts file (e.g., /etc/hosts) to point to your nearest CloudFront edge IP. You can discover your nearest edge IP by running a DNS query against your distribution's domain name, which looks like *.cloudfront.net
- Configuring your test clients to use a private DNS that already has a modified CNAME record pointing to CloudFront
Before you start the migration, it's advisable to reduce in advance the DNS Time to Live (TTL) for records that have been marked for migration to a short duration (e.g., 1 minute). It will help you roll back quickly to previous CDN should you encounter issues during migration that impact your users. You can use tools such as ThousandEyes or Catchpoint to verify that the DNS change has propagated across to DNS resolvers, past the existing configured TTL.
Now it's time to start the progressive shift of production traffic to CloudFront according to the migration strategy you selected. During the migration, if you need to make a change to a CloudFront configuration while proxying production traffic, consider using CloudFront continuous deployment to test changes safely before.
If issues arise where there is significant impact to your viewers or business-critical services, rollback in a controlled manner by reverting back your DNS records. If the issues surfaced are not critical, consider keeping it in place and troubleshooting with the help of your Account Team and/or AWS Support.
It may sometimes be unrealistic to have all settings perfectly configured due to time constraints. Previous steps may have mostly addressed the core functionality of your web application, but there can be plenty of opportunity to fine-tune your configuration. For example, you might look for:
- Increasing the cache hit ratio to offload the origin and improve end-user performance
- Reducing false positives in AWS WAF
Finally, you must now review your redundant CDN resources. You may want to keep all or some parts of them for a limited time, for example, to go through audit/native logs that you cannot export. However, these resources will eventually fall out of use, at which point it is recommended that you clean up any residual configurations and settings that were associated with them. Some examples include:
- Disabling resources from the previous provider that are no longer serving traffic
- Removing obsolete integrations, certificate stores, or third-party monitoring services
- Disabling any unused CNAMEs and certificates
Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.