🦄 Making great presentations more accessible. This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - Scaling Globally: Priority Pass’s Journey with AWS Amplify (DVT319)

In this video, Fred Hoskyns and Richard Reid explain how Priority Pass modernized their web platform using AWS Amplify to serve millions of global users. Richard details their migration from legacy Sitecore CMS on EC2 to a Next.js-based architecture with Contentful headless CMS hosted on Amplify. The project achieved remarkable results: hosting costs dropped from $180,000 to $20,000 annually, deployments increased from twice weekly to hundreds per month, and traffic-related outages were eliminated. Key technical decisions included using a mono repo with NX tooling, Terraform for infrastructure management, and GitHub Actions for CI/CD. Richard emphasizes the value of direct collaboration with AWS Amplify product team, which accelerated their go-to-market timeline. The session demonstrates Amplify’s capabilities in supporting server-side rendering, providing ephemeral environments, and abstracting infrastructure complexity while maintaining global performance through CloudFront.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

The Challenge of Scaling Airport Lounge Access: Introducing AWS Amplify

Alright, I’ve got a question. What comes to mind when you think of an airport? I’ll let you think about this one. Queues, people dragging your heavy suitcase along, rushing for your flight. Scenes like this or scenes like this, or if you’re really unlucky, scenes like this. Yeah, we’ve all been there. Wouldn’t it be nice if your airport experience could be a little more like this? Well, thankfully, with services like Priority Pass, which offers airport lounges and access to those airport lounges across the globe, it can be. But because this is such a superior travel experience, Priority Pass has gained millions of customers enjoying its lounges. However, this comes with its challenges.

There was a point where their web platform was not scaling to meet the needs of those customers. It was not globally performing for its international traveler base. That is why we’re here today. We’re here to tell you the inside story of how Priority Pass modernized their web platform to scale to millions of global users using AWS Amplify. I’m Fred Hoskyns, Sr. Account Executive here at AWS. I’m here with Richard Reid, who leads engineering for Collinson Group, who manages the Priority Pass brand, and we’re really excited to tell you this story today.

Before we dive into the Priority Pass story, I think it’s worth just setting the level on AWS Amplify for those who aren’t as familiar with the service. What is AWS Amplify? Simply put, we built Amplify to make it easier for developers to build full stack web applications. What does that actually mean? Amplify abstracts away a lot of the complexity of building web and mobile applications and deploying them. With Amplify, you can develop, ship, and scale your application with just a few lines of code.

Let’s look at some of the features of Amplify. You can take a front end that you’ve built and deploy it with Git-based workflows that support pretty much any server-side framework. Once you’ve deployed that app, it’s served globally with really low latency via Amazon CloudFront. Because Amplify gives you full TypeScript capabilities, you can bring the breadth of AWS services to a front-end developer experience that’s already really familiar. You can author app requirements, things like data models, business logic, and author rules, all in TypeScript.

You can spin up new app environments by connecting branches from Git. Here, for example, we’ve got a main branch and a dev branch, but with Amplify, we’ve connected those into a production environment and a staging environment, each with its own isolated front-end code and backend resources. This makes it really easy to iterate, test out new functionality, and keep those environments separated. You get fully managed CI/CD pipelines out of the box.

It doesn’t matter if you want to bring backend features like a database, whether it’s NoSQL or SQL through DynamoDB or RDS. Whether you want fully managed APIs, functions, ML services, storage, or real-time functionality, you can tap into Amplify libraries that help you build those backend resources really easily. If you want your own custom resources, you can use AWS CDK, which gives you access to 175 or more services. If you haven’t used AWS CDK, the Cloud Development Kit, I really recommend it. It’s a great way to define your applications and infrastructure as code.

We talked a little bit earlier about frameworks, so it doesn’t matter whether you’re building a server-side rendered app through Next.js, Nuxt, or Svelte, or you’ve got a single-page web application through Angular, React, Vue, or JavaScript, or you might be building mobile applications, native ones in Android or Swift, or you might be building cross-platform ones in Flutter or React Native. Amplify supports all of these frameworks and more. This is not an exhaustive list. Hopefully, that’s a helpful overview of how Amplify works. It’s one thing to talk about it theoretically.

Priority Pass: A High-Traffic Global Platform in Need of Modernization

It’s much more helpful to actually understand how you go and build and how a customer’s done that, so for that I’ll hand over to Richard. Thanks, Fred. One of the products that Collinson, the company I’m from, builds is and the one we’re most famous for is Priority Pass. Now some of you might actually have this service already, so if you have a particular AmEx card or a Chase card or another high value credit card, it’s likely that it comes with a number of benefits, and one of those benefits is often airport lounge access. And chances are if you’ve got that, it’s Priority Pass because we’re the market leader in pretty much every region.

More generally, Priority Pass gets you into an airport lounge, so if you fly a lot and you don’t get into a business or first class lounge from your airline, Priority Pass gives you an alternative. Now systematically, our traffic is extremely bursty because it mirrors global flight patterns across multiple time zones in every continent. So we see users every second. Unfortunately that does mean that we can’t optimize traffic around a single region. As a result, we rely on a CDN first architecture that gives you consistent performance characteristics everywhere. I mention it because that sets the context for why we’ve leveraged Amplify.

Now we actually support hundreds of millions of members and we get historically more than 100 million people visiting our website every year and then several hundred million more using our app, so it’s pretty high traffic. Our mobile app and our website is the primary way our customers interact with us. On there, users can do things like generating a digital membership card, which is basically a QR code that you scan to get into the airport lounge. You can pre-book lounge access in advance. You can search for services in a location that you’re currently at. You can make payments. There’s a personal profile section as well, and customers basically register and activate for the service through our website.

From a traffic perspective, our site isn’t actually just one workload, so whether it’s search, pre-booking, profile pages, or digital card display, they all generate different patterns, and some of them are anonymous and CDN friendly, while others require fairly extensive API calls and dynamic rendering. So our hosting layer needs to support both static and server side rendering paths without becoming operationally burdensome or too heavy. Over the last year and a half or so, we’ve been looking at our platform more generally and have been working on a fairly substantial rearchitecture, covering everything end to end, but our web technology was frankly our most dated.

We use a legacy CMS called Sitecore with a lot of custom integration into our internal backend APIs and services. Our hosting was largely compute driven, just standard EC2. And it was expensive. Deployments were slow and pretty brittle. When we get traffic peaks, that would require a degree of manual scaling and tuning, even if it’s just adding and removing things to a load balance pool, and that’s just not great for a platform with a large, high volume global consumer base. Our revised wider rearchitecture is Node based and therefore we wanted to align our web apps for that as well.

Evaluating Solutions and Proving the Concept: From POC to AWS Partnership

We also wanted to drastically simplify our hosting and make that a little more scalable, and then finally we wanted to replace our legacy conventional CMS with a headless option. We had four business requirements as well from that which were ship quickly, watch the costs, ideally reduce them. It has to be fast and stable and less infrastructure to manage. We looked at a couple of options and we ended up with two front runners which were Amplify and Vercel. Now we actually already had apps that were Vercel based and we have others that are Next.js based, so we thought both were viable. And both offered enterprise level security, which is what we were looking for as well. We thought Amplify might be more cost efficient, and we weren’t sure, but it definitely aligned better with the rest of our hosting, which is we’re exclusively AWS.

To start with, we did what everyone usually does is start with a proof of concept, just to make sure that either option was viable, and what we did was we created a proof of concept using a service called Tokenex, which is our card tokenization provider. So we actually store cards on file for customers.

The reason for this approach is that if you go to an airport lounge and you run out of access or entitlements that your credit card gives you, but you still want to get in, we can charge your card directly. This would be much cheaper than paying the lounge to get in directly. However, we don’t want to store actual card details, so we tokenize them. That’s the service we used for this proof of concept.

This POC was effectively just making that tokenization process end to end, embedding it into our website, and hosting it to see if it would work. We did it on both Amplify and Vercel. We would consider the POC successful, and the only difference we found was that Amplify was just cheaper—quite a lot cheaper, about 900% cheaper.

Next, we moved on to a trial. With the technology proven, we decided to migrate a couple of lower traffic web apps. We rebuilt two services in Next.js using Contentful as the headless CMS option and hosted them in Amplify. These were a support page with FAQs and our primary parent company’s corporate website as well, both relatively low traffic. Once that was done, we thought this was successful and safe enough to move our Priority Pass website, which is our high value IP, over to it.

Throughout the process, we knew that we were undertaking technology that we were unfamiliar with, and we thought the safest way of doing it was engaging directly with AWS. We partnered with our account solution architect who put us in touch with the Amplify product development team themselves, which was awesome. It was incredibly useful because we did run into some issues like cache invalidation that didn’t behave in the server-side rendering for pages as we expected. At the time, there was no WAF integration with Amplify, but working with the team, they were able to put that in for us, which was amazing. There were some quirks with DNS redirects as well.

By and large, the most useful part was that this was effectively free consultancy. You don’t pay for this; it’s just available if you’re an AWS customer. It massively reduced our go-to-market time because these are not issues that we would have been able to solve by ourselves.

Implementation Architecture and Results: Dramatic Cost Savings and Performance Gains

From an architecture perspective, there are three principles. One, we used a mono repo and we used NX for tooling. Apps live under a slash app directory, and shared libraries live under slash libs. We have a design system which is a Storybook with visual regression, and we use version NX tags to avoid any accidental breaking changes. Each app is a separate Amplify app with its own branch pointing to a subfolder with its own build spec. Although it was a mono repo, we’re still able to deploy individual Amplify apps by themselves without having to deploy everything, which is useful.

From a continuous delivery and deployment perspective, everything in Amplify, at least for us, is managed in Terraform. This includes branches and environment variables. We use GitHub Actions across the board for linting, security checks, and running test packs. Probably the most useful thing from a developer experience is getting ephemeral environments out of the box. Amplify creates its own unique isolated year-round environment that mirrors production for each branch, and it generates that ephemeral environment about six minutes from creating the branch, which is awesome. Getting ephemeral environments with next to no infrastructure and next to no code is amazing, and it’s particularly useful for testing changes before you want to merge them in an environment that mirrors production.

This is the architecture, and it’s fairly simple. We have a number of Next.js apps, some shared libraries, and some Lambdas piping that through to GitHub Actions where we run code profilers and use SonarCube. We leverage the Amplify CLI to create a project with a number of Amplify apps under that, each with their own domain name and their own firewall. We can propagate through to internal or external API calls that we use, whether it’s Contentful, Salesforce, or anything else we’ve got, and then Data Dog for monitoring. It’s fairly simple, and the main point I would put here is that the amount of config to get started is minimal. You end up with a fairly simple web architecture with very little work.

From a deployment standpoint, everything is fully automated for us using GitHub Actions, which is triggered on merges. We automatically push changes once something’s merged into main, and we run our internal quality gates before pushing to Amplify. At that point, Amplify handles the build, deploy, and versioning through its own internal CI/CD.

Amplify does have some backend capability as well, so it can deploy backend services like Lambdas, API Gateways, and DynamoDB through the same pipeline. We didn’t use that—we kept it front end only because the rest of our backend infrastructure is in a completely separate environment.

Under the hood, Amplify sites are served through CloudFront, and there’s optional server-side rendering with Lambdas behind the scenes, but that’s all abstracted away. You don’t really need to worry about it. However, there are some drawbacks. You get reduced observability, so you don’t get access to the same level of raw CloudFront logs or Lambda logs that you would get, which makes troubleshooting a pain if you need to do that.

There are some features that are just not there yet. For example, ISR isn’t supported, so there are trade-offs, especially if you’re using a framework like Next.js and you expect to get incremental static regeneration of content. That’s something to be aware of. Looking back on what we learned, the first point was collaborating directly with AWS, which was definitely useful, especially because it doesn’t cost anything, so it’s worth taking advantage of that.

As I said before, it reduced our go-to-market time fairly substantially. The main thing is cost savings. Our hosting shrunk from $180,000 a year to $20,000 a year by moving off legacy EC2 servers and legacy database servers and the licenses that came with that, moving to Amplify and then ahead of the CMS option. The costs plummeted as a result, which was really good.

Our build time went down quite a lot, and our release cadence went up substantially as well. We actually ship our web apps now much faster than any other part of our platform, so we have hundreds of deployments a month in comparison to once or twice a week before. Some of this is admittedly down to the fact that we’ve changed programming language, running it in TypeScript versus a proprietary CMS, which will have some benefits as well, but the hosting will have made a big difference too.

Our platform stability has increased substantially, so we’re not dealing with traffic spikes that would have caused an outage before. In fact, we haven’t seen any traffic-related outages since moving, and we have had to do zero manual tuning. Thanks to Amplify as well since migrating, from a general experience point of view, things are substantially improved for the quality of life of the engineers that support it.

Finally, Amplify does have its own JavaScript framework for greater integration, so it provides tooling for authentication, some UI components, some storage, and some analytics. It essentially makes it easier to build Amplify apps. We didn’t use that at all. We wanted to stay as framework-agnostic as possible and didn’t want to be too coupled to Amplify’s fairly opinionated view of how projects should be structured.

In hindsight, we probably could have done it differently. If we were to start this again, we’re probably looking at a rewrite anyway, in which case we probably should have just leveraged Amplify’s APIs and frameworks that would have sped up the initial migration in the first place. But really to conclude, build time went down, developer experience improved massively, and costs plummeted substantially as well. From our point of view, the project was a monumental success, and now I’m handing back to Fred.

Thank you, Richard. I appreciate it. Thank you so much for sharing the story all the way from the UK with our re:Invent guests. So look, next time you think of an airport and the queues and the people and the dragging of your luggage for miles and the heavy lifting, remember that there is a better way. Just like when you’re building and hosting your web and mobile apps, you can reduce all that heavy lifting by building with AWS Amplify, and that gives you time to focus on what is really important: building new features, delighting your customers, and writing great code.

It’s been an absolute pleasure to talk to you today about this topic. I really appreciate you all attending. I know you’ve already been asked this probably at least ten times, and you will be asked another seven hundred times before the end of the week. Please, please, please do fill out the survey. It’ll take you thirty seconds. Get out your phones now. I’m watching all of you. The reason is, if you don’t fill out the survey, we have no idea if you enjoyed this talk and what we can do to improve it next time and make good use of your time. Thank you all so much. Enjoy the rest of re:Invent.

---

; This article is entirely auto-generated using Amazon Bedrock.