CloudFront is the AWS global content distribution network that is a pay- as- you- go service with minimum fees and no contracts that lock you into time- length windows.
CloudFront content is stored, or cached, at AWS edge locations. Edge locations are located throughout the world and contain large storage arrays to store the cached data. Edge locations also host AWS Lambda, DNS, API Gateway compression, and transfer acceleration endpoints.
AWS has more than 400 edge locations in more than 90 cities in 48 countries as of this writing. New edge locations are constantly being added as the network expands throughout the world.
The base design for publishing content on the Internet is to host the data in either a cloud or private data center and have users access the information over the Internet from these centralized locations. While this design has been the standard for many years, there are several limitations. Users who are in geographically distant locations might have to contend with network round- trip latency and sometimes slow Internet links causing poor transfer speeds.
By using content distribution networks (CDNs), this data can be distributed over the AWS backbone network and cached at locations worldwide that are closer to the people and systems requesting the information. Now, using the same connection strings including the URLs, the data is served much closer to the destination and does not have to go back to the originating location to fetch the content.
CloudFront is most effective when servicing frequently accessed content. This content can be either static or dynamic and can include web pages, images, software update files, and both audio and video media. Protocols sup- ported include HTTP, HTTPS, PHP, and WebSockets as well as live or on- demand video streaming services running over HTTP.
CloudFront Implementation
When creating a CloudFront implementation, sites are registered with CloudFront using configuration objects called distributions. Origins and all other configuration items are stored in the distributions.
The CloudFront distributions will be assigned a DNS name by AWS that uses the cloudfront.net domain. We can then map our own domain name to the distribution by creating a CNAME record in DNS that references the AWS CloudFront domain name. When connecting to the URL, connections are directed to the nearest location that can provide the best performance and not back to the origin, which may be on the other side of the world.
Origin redundancy can be configured to use a backup to your primary source of data. If your main source origin fails, a failover can occur based on HTTP status codes such as the 400 and 500 series. Both AWS hosted and on-premise origins are supported and will back up each other based on the design requirements.
Route 53 is the AWS DNS service. CloudFront domains will always use the cloudfront.net DNS name by default. However, you can use CNAME pointers to map your company DNS name to the CloudFront distribution DNS for clarity. Also, Route 53 supports the mapping of zone apex names free of charge. This allows you to map a top domain such as helloworld.com to your CloudFront distribution such as abcdef12345678
.cloudfront.net.
Caching and Object Retention
When a user makes a request, DNS will route them to the nearest edge location to serve the content. If this is the first request or if there has not been a request for the time-out period, there will be a cache miss. In this case, CloudFront will go back to the origin if it is S3 data or regional cache to retrieve all the other data. The data is delivered to the end user and stored locally in the edge cache. Any new requests at this location will be serviced quickly as the data is now stored at the CloudFront edge location.
There is also a regional CloudFront component that contains less frequently accessed data and has a larger storage capacity than edge locations.
Regional edge caches serve content to a subset of the edge locations. Regional edges have larger cache storage capacities and longer retention times than the smaller edge locations.
This way, if the content should time out on the edge storage sites because of the data not being requested for a period of time, the edge location does not have to request the data from the origin.
Instead, the edge will query the regional edge cache, and if the data is stored in the regional cache, then it is returned to the edge with a faster response than having to retrieve the information from the origin. If the data is not in the regional cache, then a regional fetch is performed to pull the object from the origin to the CloudFront regional cache and on to the edge location.
1. The user makes a request for an object from the CloudFront edge location.
2. If the object is not stored in the CloudFront edge, there is a cache miss; the edge will then check with the regional edge location to see if it is stored there, which is closer to the source.
3. If there is a cache miss at the regional edge, the regional edge will download the data from the origin and forward it to the edge location to reply to the requester and add to its cache.
4. There is an origin fetch of the object from the regional edge that then sends the object to the edge location where it is cached for future requests and also sent to the user requesting the object.
Data retention in the edge cache has a default value of 24 hours. It is a best practice to have a longer retention time if the content does not change very often and to use a versioning system to track updates to objects. If the edge receives a user request for an object that has been cached for more than 24 hours, the origin is checked to see if the content has changed. If it has, the new object will be uploaded and the expiration timer set back to the time- to- live (TTL) value.
File cache control headers are used to instruct the edge location on how often to check for a new object version at the origin or regional cache. If it is S3, then the origin location will be checked; however, for other content, the regional cache is checked first. If the value of the cache control header is 0, then the check for a newer object is made for every request
Each edge location views an object as current if it is within its TTL range.
When the TTL of an object stored in an edge location counts down to zero, it becomes stale but is not deleted from its local cache. Instead, the edge checks with the origin to see if there is an updated version of the object.
If the origin returns a response code of 304 Not Modified, the edge location marks the locally stored object as current. If there is a newer version, the origin will forward the data to the edge to replace the stale data stored locally and flagged as current data. The default validity period is defined for each distribution with the default value set at 24 hours.
Invalidations
There are only 2 hard things in computer science: cache invalidation and naming things.
Cache invalidations are configured for all edge locations at the distribution level. A cache invalidation will expire all objects in the edge cache even if there are TTL values that have not expired. It is a forced deletion of the object from cache. Invalidation can define a specific file or be expanded using wildcards (/*).
Since this is a chargeable operation, another approach that can be used is to rename the new files with a version number and change the application to point to the new version. This will force the edge cache to be updated and the older version to expire and eventually be removed from the edge cache without incurring any charges.
Other advantages of versioning include more accurate logging information given that the filenames are different when updated and that browser caches will automatically update to the new object. Also with versioning, you will be able to retain copies of the older objects since they will have a different version number in the object filename.
To clear the edge cache and remove unwanted objects, we can delete, or invalidate, the object from the origin and let it age out in the edge cache based on its expiration value in each object’s HTTP header. Forcing the cache removal of an object before its expiration time is accomplished by calling the invalidation API of the object.
AWS will charge you every time you invalidate an object. Up to 3,000 invalidation requests can be performed for each distribution at any given time. Up to 15 invalidation wildcards are supported simultaneously. The best practice is to limit the use of invalidation requests and instead use an object versioning approach or shorten the header’s expiration time.
Origin Shield
Using Amazon CloudFront Origin Shield — Amazon CloudFront
Origin Shield reduces the read load on the origin by adding an additional cache layer between the regional and edge locations and the origin.
This is accomplished by directing all requests for the same content from the edge and regional locations to a central cache server to increase the cache hit ratio of the edge locations. If the object is not in the Origin Shield cache, all of the requests for the same object will be consolidated into a single object request to the origin to reduce the traffic and workload from the origin. Origin Shield is enabled when creating a distribution and incurs additional charges
CloudFront Encryption Using SSL/TLS and SNI
Encrypting data in transit over the Internet is the recommended transport method for web traffic. This relies on the Secure Sockets Layer (SSL)/Transport Layer Security (TLS) services. SSL has been deprecated and replaced by TLS even though the SSL name lives on and is widely used in the industry even when TLS is actually the protocol being used.
SSL vs TLS — Difference Between Communication Protocols — AWS (amazon.com)
AWS includes a security certificate at all CloudFront edge locations that is bound to the cloudfront.net domain that is globally used by AWS as the default domain name for CloudFront. If you choose to connect to the edge nodes using this default domain, all you need to do is to enable it in the CloudFront distribution configuration settings.
However, it is common to use your own domain and map it to the CloudFront domain in DNS using a CNAME. This allows you to use
your company’s descriptive domain name and hide the rather convoluted AWS CloudFront domain that is in the format of https://a123456789abcd.cloudfront.net, as an example. By default, the *.cloudfront.net certificate is installed and supported.
To use your own certificate, such as www.fcj.com, for example, you can create it at any number of security authorities that offer certificates or choose to use the AWS certificate services called Amazon Certificate Manager (ACM). Regardless of how you create the certificate for your domain, you will need to import it into ACM.
ACM certificates are usually AWS region–dependent, which means you must create the certificate in the AWS region you intend to use it in. However, since CloudFront is a global service, all CloudFront certificates are managed in the AWS us- east-1 region in Northern Virginia.
CloudFront Security
AWS uses its Shield service in front of all edge locations. Shield will protect the edge from distributed denial-of-service (DDoS) attacks. Shield includes automatic inline attack mitigation support to protect your site from common attacks at no additional charge.
The Web Application Firewall (WAF) and many third- party firewalls can be combined with CloudFront for application- level perimeter security.
When you set up CloudFront and use an S3 bucket as the origin of your content, the S3 URL may still be exposed to the Internet, allowing users to bypass CloudFront and pull data directly from S3, which can be a major security violation.
Internet users can source data directly from the S3 origin if not blocked from doing so. This can be prevented by configuring Origin Access Identity (OAI). To restrict users’ direct S3 access and require them to use only CloudFront, a signed URL can be configured. Also, by forcing all requests through CloudFront edge locations, additional features can be leveraged such as restricting access by IP address or location.
Restricting access to an Amazon Simple Storage Service origin — Amazon CloudFront
Lambda@edge
Edge Computing|AWS Lambda@Edge
In addition to CloudFront serving content, it also supports the AWS Lambda microservice compute platform. Lambda@edge supports local processing at the edge location of Node.js and Python Lambda runtimes.
This allows processing to be done closer to the user requests and eliminates the need to provision servers at the origin. Lambda can also be used to modify CloudFront requests and responses at the endpoint closest to the user making the request. This results in a much faster response time.
For example, processing can be done locally at the edge origin to inspect cookies and take action based on the content and to rewrite URLs. Different objects can be returned to the requester based on header information such as the user- agent that identifies the device type such as a mobile phone or tablet. Lambda@edge is used for header inspection for authorization to perform access control closer to the source of the request. Headers can be modified by Lambda to direct the connection requests to different objects stored in the cache. Unauthenticated users can be redirected to sign-up pages by using Lambda to generate responses based on the viewer requests.
Geo-restriction and Geolocation
CloudFront is a global service with edge locations all over the planet. When a distribution is created, all the edge locations are included, and there are no restrictions placed on who can access that information at the CloudFront level. Access to the CloudFront CDN edge locations can be restricted for security or compliance reasons by using geo-restrictions.
CloudFront will monitor incoming connection requests and based on the geo- restriction configuration either allow or deny the connections. When the service is enabled, the edge location will query a GeoIP database to see if the source IP (which maps to a country) is either allowed or denied. If it is allowed, the connection is allowed to proceed as usual. However, if it is not allowed, a 403 forbidden status code is returned to the requester.
Third-party companies offer extensions to CloudFront that vary depending on each company’s offerings and that are often referred to as geo locations. CloudFront will check a database for restrictions that are provided by the services offered.
This can, for example, include attributes such as login status, profiles, header information, information in cookies, and licensing. Check the AWS Marketplace for current products being offered. Third-party geo-restrictions are much more flexible than the fixed-country-only geo-restriction model offered by AWS.
With geolocations, the architecture is significantly different than geo- restrictions. The third-party application servers receive the connection requests in front of the AWS edge nodes. These application servers terminate the connection and query their database to either allow or block with a 403 restricted error.
In this case, the third-party providers use CloudFront as a front end and use the AWS CloudFront network as a private backend network. If the connections are permitted, then a signed URL or cookie is returned to the requester, and a connection is made directly with the edge location. Given that they terminate the connection, they can allow for deep inspection of many different parameters beyond just the country code to allow you to granularly meet your geolocation requirements.
Pricing
Pricing is for the actual usage of CloudFront and does not require minimum charges or any time commitments. Billing is based on the amount of data you transmit out from the edge locations to the Internet and is charged by the gigabyte. Charges from the CloudFront services to the origins, either AWS or in a private data center, are also billed by the gigabyte transferred. The number of HTTP/HTTPS requests and, finally, invalidation requests made to remote objects from the cache are also chargeable.
The first TB of data transferred out each month is at no cost, and HTTP/HTTPS billing is in 10,000-request increments. Large volume customers transmitting more than 10TB per month are eligible for a discount with the AWS volume pricing plans.
Global Accelerator
When accessing AWS resources over the Internet, traffic is routed from your local connection over the Internet to the region requested over many hops and, often, across many different Internet providers and backbone carriers. This can cause additional latency and suboptimal performance.
AWS Global Accelerator service can greatly improve network performance by routing traffic to the nearest edge location and transporting the traffic over the AWS internal high-speed backbone network to its destination.
By using Global Accelerator, traffic flows are optimized from the requester to the AWS services being accessed by having users connect to the AWS at the closest location possible.
The service offers a single IP anycast address as an entry point that maps to multiple AWS regions and services. By using the same IP address at many locations, the user connections can be connected as close to the source as possible.
The global edge network is constantly being expanded by AWS and currently includes 117 Points of Presence in 94 cities across 51 countries.
AWS Global Accelerator features
The service offers two IP anycast addresses for redundancy; these act as entry points that map to multiple regions and services. This architecture also allows for resiliency by providing failover and rerouting should a service or availability zone go offline.
An Anycast address is an IP address that can be assigned to many different locations or devices and advertised simultaneously from all locations. This allows the routed public network to pick the closest Anycast address to the source thereby reducing hop counts and latency.
The Anycast IP addresses are injected into the Internet’s BGP tables to advertise each public interface into the AWS network. The same IP address is advertised for each edge location to allow traffic to enter the network at its closest entry point from the user by using BGP reach-ability metrics.
This reduces the number of hops over the public Internet to increase speed and decrease network latency by entering and traversing the AWS internal network as soon as possible.
These IP addresses are publicly accessible front ends to your AWS services such as EC2 instance, elastic and network load balancers, and Elastic IP addresses.
A normal IP unicast address would be assigned to only one device, whereas Anycast addresses can be assigned to any number of devices and the source requester selects the Global Accelerator edge location that is closest. This allows traffic to move off of the public Internet and onto the AWS backbone network at a closer entry point to increase network performance by reducing the delays and hop counts from source to the AWS destination. By using the AWS global backbone network, there will be fewer router hops and better performance.
When you configure a Global Accelerator service, two IP addresses for redundancy will be assigned for your use and advertised into the public Internet. Upon entering the AWS global backbone network, you will transit over the AWS high-speed inter-region network optical connections.
While this may sound a lot like CloudFront, there are significant differences between the two services.
- CloudFront moves the content closer to the users using edge location caching (it is a content distribution network), whereas Global Accelerator locates the AWS network entry point closer to your end users for a faster network connection to your content and services in AWS regions. Think of CloudFront as caching and Global Accelerator as data transport.
- CloudFront is used for caching HTTP/HTTPS data, whereas Global Accelerator transports any kind of TCP or UDP traffic. Since Global Accelerator is a network- layer product, it does not recognize service ports such as HTTP/80 or HTTPS/443, and it does not cache data at the edge.
A speed comparison tool is available to compare the advantages of using Global Accelerator over the public Internet:
Custom routing
Custom routing accelerators extend the capabilities to allow you to map specific application IP ports to destinations in one or more AWS regions that you define. This capability allows you to control the destination devices across the AWS network as compared to standard accelerators that do not support routing to a specific destination. Specific ports are configured on your accelerator, and that port gets mapped to a destination you define. Custom accelerators allow you to define global entry locations into the AWS network with Anycast, and then you control the destination region and service.
If your application requires that an incoming request to be connected to a specific EC2 instance, for example, a custom routing accelerator can be used to route that connection request, regardless of where it enters the AWS network, to that instance and the application running on it.
The connection coming into the custom accelerator gets statically mapped to a specific endpoint’s private IP address based on the entry point’s port number.
Introducing AWS Global Accelerator custom routing accelerators
AWS Global Accelerator Custom Routing with Amazon Elastic Kubernetes
AWS Global Accelerator Pricing
AWS Global Accelerator has two pricing components, a flat hourly rate and a premium data transport fee.
The hourly or partial hourly flat rate is charged regardless of the status of the accelerator; if it is either enabled or disabled, it will be charged. Traffic pricing is based on the dominant flow direction of the traffic.
If your traffic patterns are greater for outbound to the customer, then that is what the billing will be based on. Conversely, if inbound volumes are highest, then inbound will be dominant and used for billing.
Reference: AWS Certified Advanced Networking Study Guide
