AWS Partner Network (APN) Blog
Optimizing Customer Experiences for Speed Using AWS and Crownpeak
By Paul Taylor, VP Solutions Engineering at Crownpeak
One of the biggest obstacles for brands today is improving the performance of their digital properties.
Amazon’s 10-year-old study showed that every 100ms of latency cost them 1 percent in sales. Fast forward and Akamai’s study showed the same 100ms delay was now hurting conversion rates by as much as 7 percent. Over the last decade, consumers have become more and more sensitive to wait times.
While much of today’s marketing technologies leverage modern advances in cloud computing, many of the technologies powering digital properties (for example, web and mobile sites) still use the prior generation of server-based technologies.
In this post, I will detail how to modernize your digital technology stack to optimize customer experiences for speed, and ultimately improve performance for your brand.
Crownpeak is an AWS Partner Network (APN) Advanced Technology Partner with the AWS Digital Customer Experience Competency. We deliver elastically scalable and performance-centric digital experiences across our customer base, deployed from the Digital Experience Management (DXM) CMS platform.
Why Decoupled CMS for Today’s Customer?
The cornerstone of today’s digital experiences is content. These experiences are often managed by a content management solution (CMS) that publishes to a delivery environment where it’s then served to a consumer.
Over the last 15 years, many traditional CMS platforms used a “just-in-time” content generation model to build content upon requests. This traditional approach is based on a server-centric model and made perfect sense once upon a time, as many home computers weren’t as powerful as they are now. Pushing the workload to large servers in data centers was ideal.
Today’s marketing technologies execute in client-side browsers, while audiences are increasingly larger and global. The just-in-time approach creates bottlenecks at the origin servers, which can then struggle to scale elastically.
Moreover, this approach creates a time penalty. While the roundtrip is made, the experience is assembled on the fly and then delivered to the consumer. In a world where every millisecond matters, the time this approach takes is no longer desirable.
In contrast, the modern-day browser exists in devices that are a celebration of ever-increasing power, coupled with elastically scalable services from cloud providers like Amazon Web Services (AWS).
Now, the device itself can more than handle the processing required to generate modern-day digital experiences, without having to rely on the heavy, slow, server-side processing of yesteryear. Given this, what’s important now is the speed in which you can optimize for rapid delivery to these devices.
Now that the customer’s browser does all the heavy lifting, the optimal CMS can pre-render digital experiences and leave dynamic elements to render within the client. This approach is known as decoupled content delivery.
A CMS designed to support decoupled content deployment architecture means the interface where marketers author and manage content is separate from where customers are visiting. This has many benefits, from increasing the levels of security associated with a digital experience (there’s no CMS application to hack), to allowing lighter-weight technology to be deployed, which can ultimately increase customer-facing experience performance.
Figure 1 – Crownpeak DXM decoupled content deployment architecture.
AWS Takes Decoupled CMS to the Next Level
Recent advances in edge computing have opened up new opportunities for delivering digital experiences to consumers anywhere in the world, and at blistering speeds.
While the types of digital experiences you deploy can be much lighter-weight, most legacy CMS tools required extensive cloud engineering or were relegated to being served locally from a set of static data centers.
One of the many deployment options any natively decoupled CMS should have is direct integration with Amazon Simple Storage Service (Amazon S3). This allows customers to deploy their content directly into AWS’ highly-available, globally-scalable object storage service, and at the click of a button.
Globally Scaling with AWS
Amazon S3 buckets are architected to scale on their own, but they’re designed for delivering individual content items and not for the delivery of digital experiences to a worldwide audience. To make this possible, we can leverage other AWS services such as Amazon CloudFront.
Amazon CloudFront can be configured to use an S3 bucket as its origin, adding several capabilities suitable for a globally diverse, distributed digital experience:
- Distributed caching at the edge: As long as we’re smart about the cache behavior and headers we are sending with each object, we can take advantage of both local (user-agent) and CDN-based caching.
- HTTPS/TLS encryption: CloudFront upgrades the standard HTTP connection to an S3 bucket to HTTPS/TLS, ensuring all requests and responses are encrypted.
- Executing dynamic functions at the edge: Using AWS Lambda, dynamic functions can be distributed globally to the same edge locations as CloudFront, presenting dynamic content at pace. This includes things like rewrites, redirects, and surfacing filterable data for your digital experiences.
Figure 2 – Typical Crownpeak DXM serverless decoupled deployment architecture.
By leveraging a decoupled deployment architecture with AWS services, customers can deliver scalable experiences that are delivered “at the edge” from the hundreds of geographically diverse CloudFront nodes around the world. Every experience feels native. Every experience feels local. Every experience feels rewarding. Every customer wants to stay!
Configuration Using Decoupled Deployment Architecture
In a typical reference architecture at Crownpeak, we leverage Amazon S3, Amazon CloudFront, AWS Lambda, Amazon Route 53, and AWS Certificate Manager (ACM) to create a serverless, edge-optimized deployment topology that’s fast and scalable.
We use cloud orchestration to provision this delivery topology to our customers. For some examples, see the AWS CloudFormation template example library documentation.
The first thing you will configure is an S3 bucket to persist the content that’s deployed from your CMS platform. In this example, we have used the us-west-1 (Oregon) Region.
Figure 3 – Amazon S3 bucket created to hold CMS-deployed content.
The S3 bucket should be configured to use Static Website Hosting. Note that in a production-level deployment, additional configuration relating to encryption is enabled.
Figure 4 – Amazon S3 bucket configured for static website hosting.
Next, you’ll need to tell S3 that it’s OK to serve this content publicly to anyone requesting it. You can do this via the Bucket Policy.
Figure 5 – Amazon S3 Bucket Policy created to allow anonymous access to objects.
Finally, provide your Cross-Origin Resource Sharing (CORS) configuration to restrict the methods upon which content can be retrieved, as well as setting cache configurations and allowed headers. Note that in a production-level deployment, “MaxAgeSeconds” value will be set much higher.
Figure 6 – CORS configuration set to limit cachability of content.
Now, you can configure AWS Certificate Manager to handle our SSL certificate for the chosen domain. In this case, as the DNS is fully managed by Amazon Route 53, the domain validation is easily deployed directly from the ACM by adding TXT records to the RecordSet.
Note this certificate has multiple names associated with it, including several wildcard entries, providing scope for various use cases with AWS.
Figure 7 – ACM showing AWS-managed SSL certificate for multiple sub-domains.
Amazon CloudFront, providing edge-availability for your S3 bucket, can be configured to use all global edge locations and upgrade the transport mechanism to HTTPS.
The following configuration states show:
- Amazon CloudFront distribution, deployed to all edge locations.
- Origin of CloudFront distributions set to S3 bucket’s public static site hosting endpoint.
- Default cache behavior settings to redirect all HTTP traffic to HTTPS and only accept GET and HEAD methods.
Figure 8 – Amazon CloudFront distribution, deployed to all edge locations.
Figure 9 – Origin of Amazon CloudFront distributions set to S3 bucket’s public static site hosting endpoint.
Figure 10 – Default cache behavior settings to redirect all HTTP traffic to HTTPS and only accept GET and HEAD methods.
Optimize for Search
Now you can use AWS Lambda to help with search-friendly URLs. As Amazon S3 is an object store, you have to specify a document reference explicitly, such as index.html. In a search-optimized world, you want to provide it with folder paths and have the default document automatically recognized.
There are many other use cases for Lambda functions during the request/response pipeline. To learn more, check out AWS Lambda@Edge Example Functions.
The following example is a Lambda function that I use to programmatically replace any request for a Uniform Resource Identifier (URI) ending with a folder (/), by appending the default document, in this case /index.html.
Figure 11 – AWS edge-deployed Lambda to replace any incomplete URL with a call to the default document.
Once a version of the Lambda function has been published, it can be reference within the CloudFront distribution’s “Behavior” settings.
Note that I am using “Origin Request” to allow the returning value to be cached by the default policy.
Figure 12 – AWS Lambda called upon “Origin Request” from within the CloudFront distribution’s default cache behavior.
Next, ALIAS your CloudFront distribution to your CNAME within Amazon Route 53.
Figure 13 – Using Amazon Route 53 to ALIAS your domain at the Amazon CloudFront distribution.
Figure 14 – Native Amazon S3 bucket publishing from Crownpeak DXM.
And there you have it—a statically-deployed, scalable, edge-optimized digital experience that’s ready to go!
You will likely want to restrict access to your Amazon S3 bucket from anywhere other than Amazon CloudFront. To do this, use Origin Access Identity controls within AWS.
For those of you who said, “Well, yes, that’s great if you only want to serve static content,” the example in Figure 15 shows the Crownpeak blog page retrieving headless JSON from our RESTful Content API.
Transforming your digital experiences to a model where you can deliver static content to an endlessly scalable, hyper-available platform can be trivial, if you adopt the right content management platform.
The AWS platform makes deployment and management of your digital experiences simple, yet very flexible. Ultimately, the adoption of a digital experience platform like Crownpeak deployed to a serverless infrastructure like AWS Lambda allows you to deliver experiences that are content-rich and optimized for speed and scalability. Now, all you have to think about is the content itself.
If you’re interested in learning more, contact Crownpeak with any questions, get a demo, or ask a dev question in the Crownpeak Community.
The content and opinions in this blog are those of the third party author and AWS is not responsible for the content or accuracy of this post.
Crownpeak – APN Partner Spotlight
Crownpeak is an AWS Digital Customer Experience Competency Partner. They deliver elastically scalable and performance-centric digital experiences, deployed from the Digital Experience Management (DXM) CMS platform.
Contact Crownpeak | Solution Overview | AWS Marketplace
*Already worked with Crownpeak? Rate this Partner
*To review an APN Partner, you must be an AWS customer that has worked with them directly on a project.