Billing 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.
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, as shown in Figure 1.6. 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.
FIGURE 1.6 Lambda@edge
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, as shown in Figure 1.7. 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.
FIGURE 1.7 Geo-restriction
The first and most basic feature that is built into the standard CloudFront service allows for either a whitelist (permit only what is on this list and deny all others) or blacklist (deny based on the blacklist and allow all others). The GeoIP database uses restrictions based on country codes that map to assigned IP address blocks for each country. With the basic geo-restriction service, either you define all country codes allowed with a whitelist or you define the country codes that are blocked and allow all others with a backlist. These apply across all edge nodes in the distribution.
Third-party companies offer extensions to CloudFront that vary depending on each company’s offerings and that are often referred to as geolocations. CloudFront will check a database for restrictions that are provided by the services offered, as shown in Figure 1.8. 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.
FIGURE 1.8 Geolocation
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
