The Frontend That Never Touches a Password

With requirements written down, the design starts at the edge, the piece the user's browser actually talks to first.

There's no single correct way to build this. Every service choice below is a fit for these specific requirements, not a universal answer. A different budget, a different traffic pattern, or a different security bar would change some of these picks.

Hosting the app itself

The fuel pass frontend is a static application: HTML, JS, CSS, nothing that needs a server to render. That points straight at S3.

• S3 static hosting scales on its own. There's no server to size, no fleet to add capacity to when traffic spikes.
• S3 is about the cheapest storage AWS offers, which matters directly for the minimal-cost requirement.
• The bucket sits in the AWS region closest to the users, in this case Mumbai, close to Sri Lanka.

CloudFront sits in front of that bucket, and it earns its place doing three separate jobs at once.

1. Content delivery network. CloudFront caches the static app at edge locations near users, so most requests never travel back to Mumbai at all.
2. Reverse proxy. Every request, whether it's for the static app or the backend API, goes through CloudFront first. The user's browser never talks to S3 or the API directly.
3. Security checkpoint. Because every request already passes through one place, that's the natural spot to attach a Web Application Firewall. A WAF rule set can catch OWASP Top 10 style attacks before they ever reach your application code.

ExpandEvery request passes through CloudFront and WAF before reaching either the S3 static site or the backend API

One detail worth keeping in mind on caching: the further out from your application you cache, the cheaper it is. Edge caching at CloudFront costs less than caching at the API layer, which costs less than caching at the database layer. Push caching as far outward as it can go before adding it anywhere closer in.

Authentication without a user database

Registering and logging in with an OTP instead of a password is a functional requirement from the last post. Building it yourself means writing OTP generation, storage, expiry, and verification code, plus a table of users to secure. Amazon Cognito replaces all of that.

Cognito acts as a managed user pool sitting outside your application. That separation matters more than it looks like at first: your user base can now grow into the millions without ever touching how your application itself scales, because the two scale independently. Cognito is billed by monthly active users, not by infrastructure you provision and pay for whether it's busy or not.

The OTP itself runs through a sequence of Lambda triggers Cognito calls a custom authentication challenge, ending in a set of tokens the user carries for every request after. The exact mechanics are worth a page of their own: see Amazon Cognito for the trigger-by-trigger breakdown.

What the frontend does with those tokens

The frontend uses the AWS Amplify library to talk to Cognito instead of handling tokens by hand, storage, silent refresh, and request signing all come for free. Details on what that actually does: AWS Amplify.

Getting the OTP itself to the user's phone is Amazon SNS's job, another managed service, so nobody on this project is running an SMS gateway either.

None of these five services (S3, CloudFront, Cognito, Amplify, SNS) does anything exotic on its own. What makes the design work is that none of them requires you to manage servers, users, or message delivery yourself, which is exactly what the cost and scale requirements from the last post were asking for.

Next up: where the registration and vehicle data itself actually lives, and why a NoSQL store fits this shape of data better than a relational one.

Here's the complete picture this piece belongs to, including the API Gateway, register Lambda, and DynamoDB table the next post covers in detail.

ExpandThe full user registration flow: WAF and CloudFront in front, the web app and API Gateway behind it, Cognito handling the OTP challenge loop, and API Gateway writing to a DynamoDB user table

The Essentials

1. Static frontends belong on S3 behind CloudFront, not on a server that has to be sized for traffic it can't predict.
2. CloudFront isn't just a CDN here. It's also the reverse proxy for the API and the one place a WAF can inspect every request.
3. Cache as far from your application as you can. Edge caching is cheaper than caching closer to your API or database.
4. Cognito decouples users from the application, so the user base can scale independently of the app itself.
5. A managed auth service beats building OTP generation, storage, and verification yourself. The mechanics are worth understanding, but not worth building.

Further Reading and Watching

• Video: AWS re:Invent 2017 - Identity Management for Your Users and Apps: A Deep Dive on Amazon Cognito (SID332)
• Docs: Customizing your user pool authentication flow with Lambda triggers (AWS Cognito docs)