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.
The Origin Shield service reduces the read load on the origin by adding an additional cache layer between the regional and edge locations and the origin, as shown in Figure 1.5. 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 supports the WebSockets protocol that enables real-time bidirectional communications that are used by chat, multimedia meeting applications, collaboration applications, gaming, financial trading systems, and many other newer Internet-based services. WebSockets connections are often active for long periods of time, which enables low-latency bidirectional HTTP connections since there is no need to constantly create new connections. WebSockets connections are enabled using the upgrade: WebSockets header value. The server will accept the WebSockets request by returning an HTTP status code of 101 to signal a switch to use WebSockets. SSL/TLS encryption is supported in CloudFront when using the WebSockets protocol if requested at the initial connection request.
HTTP responses to errors can be customized using your corporate branding and messaging. These are supported for 4xx and 5xx response codes.
CloudFront supports compression by enabling automatic object compression in the CloudFront console. The compression format is gzip and works for both text and binary data. The client must include, in the HTTP header, accept-encoding: gzip to complete the process, which is the default value for all newer browsers.
Streaming content is another supported CloudFront feature. HTTP real-time streaming using Adobe, Apple, MPEG, and Microsoft delivers data in real time and includes bidirectional services for stop, forward, rewind, and other controls for both video and audio streams.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
