
AWS Edge Services - CDN Migration
Best practices to migrate your Content Delivery Network (CDN) from 3rd party solutions to Amazon CloudFront
- [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
- 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.
- 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.
- 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.
- 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
- 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
- Increasing the cache hit ratio to offload the origin and improve end-user performance
- Reducing false positives in AWS WAF
- 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.