Forem: László Tóth

Scaling Carmen Cloud: From Containers to Lambda SnapStart

László Tóth — Mon, 15 Sep 2025 14:40:59 +0000

At Adaptive Recognition, we run Carmen Cloud for ANPR & MMR recognition. Our neural-network engines have been evolving for 30+ years – for us, "AI" is business as usual.

The real challenge: scaling. On ECS Fargate + EC2, startup + engine init took ~60 seconds. Not acceptable.

The Fargate/ECS Approach

Our first deployment ran on ECS Fargate.

For predictable workloads, this is often good enough. You can define scaling rules or even schedule tasks so that capacity matches traffic (e.g. higher during business hours, lower at night).

But our workload is the opposite of predictable. Recognition requests come from many customers, across multiple regions, at almost random times. Bursts can hit at 2 a.m. from one continent and spike again an hour later from another.

With that traffic pattern, Fargate's trade-offs became painful:

Scale-up lag: EC2 boot + engine init ~60s.
Idle cost: keeping containers pre-warmed all the time.
Ops overhead: building/pushing images, patching, managing ECR.

That's when we started looking for a new approach.

Early Adoption of SnapStart

When AWS Lambda SnapStart (Java 21) was released, we migrated immediately.

That made us among the first to see just how well it scales – and how much money it saves.

Years later, those benefits are still holding true.

The Shift: API Gateway + Lambda SnapStart + CRaC

Key trick: CRaC (Coordinated Restore at Checkpoint) pre-initializes our engines at checkpoint time.

But SnapStart has a serious limitation: it doesn't support >512 MB of ephemeral storage, nor EFS. Our recognition engines for a single region (EUR, NAM) are much larger than that.

So we built a staged engine loading mechanism:

During handler initialization, we download a batch of engine data from S3.
Engines are initialized into memory (via our VehicleHandler class).
Temporary .dat files are deleted to free up space.
The next batch is downloaded and initialized.

This keeps us under the 512 MB limit while still giving us full coverage. Initialization is more complex, but the scalability and cost benefits make it well worth it.

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyRequestEvent;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyResponseEvent;

public class VehicleHandler implements RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent>, org.crac.Resource {

    static {
        // Load engines in batches at checkpoint time from S3
    }

    @Override
    public void beforeCheckpoint(org.crac.Context<? extends org.crac.Resource> ctx) throws Exception {
        // Close network connections – CRaC cannot persist them
    }

    @Override
    public void afterRestore(org.crac.Context<? extends org.crac.Resource> ctx) throws Exception {
        // Re-open connections on restore
    }

    @Override
    public APIGatewayProxyResponseEvent handleRequest(APIGatewayProxyRequestEvent input, Context context) {
        // Process image with the chosen engine
        return new APIGatewayProxyResponseEvent();
    }
}

Supporting AWS Stack

API Gateway – entry point
Lambda (SnapStart) – recognition engines
Cognito – user auth
DynamoDB – API keys, billing records
SNS/EventBridge – async billing + subscription events
S3, SSM, CloudFront, WAF, Route53 – storage, config, delivery, security

Takeaways

Even heavy neural engines can scale serverless.
CRaC makes SnapStart viable by restoring pre-initialized state.
Closing & reopening network connections is essential.
Staged loading solves ephemeral storage/EFS limits.
Being an early adopter of SnapStart saved us both time and cost from day one.

👉 More about Carmen Cloud: carmencloud.com
👉 Corporate homepage: adaptiverecognition.com
👉 My side project for WordPress + Cognito login: Gatey

Add Social & Enterprise SSO to WordPress (Even on Static Sites) with Amazon Cognito + Gatey

László Tóth — Sun, 14 Sep 2025 12:38:17 +0000

WordPress was never built for OIDC or SAML. Export it as a static site to S3 + CloudFront and the built-in login system stops working completely.

The fix? Amazon Cognito + Gatey:

Configure Cognito User Pools & Hosted UI (no client secret needed, SPA app type)
Connect Social IdPs (Google, Facebook, Apple, Amazon)
Add Enterprise IdPs (OIDC, SAML: Okta, Azure AD, Auth0, Ping)
Wire it into WordPress with Gatey (User Pools, General, Custom Providers)
(Optional) Enable IAM so authenticated users can call your AWS APIs directly

🔗 Full guide with screenshots on wpsuite.io.

Static-friendly, secure, and no secrets stored in WordPress.

Behind the Scenes: Building WordPress Static Site Guardian with Kiro

László Tóth — Wed, 10 Sep 2025 12:00:00 +0000

In a recent post I explained how to secure static WordPress exports on AWS with Cognito, CloudFront, and signed cookies. This is the follow-up: a look at how the project itself came together with the help of Kiro.

Starting point

I'm comfortable working with AWS architecture, but I had little hands-on experience with CloudFormation. Writing a full stack by hand would have been slow and error-prone. For the hackathon I wanted to see how far I could get by asking Kiro to generate the stack for me.

The initial prompt described the core idea:

S3 bucket for the static export
CloudFront with signed cookies for protection
API Gateway + Lambda to issue cookies
integration points for Cognito through the Gatey plugin

The first generated template wasn't perfect, but it was good enough to get the stack running within a few hours. I only needed to fix some details and adjust resource lifecycles.

Reverse specification

Once the implementation was working, I asked Kiro to generate a "reverse spec" of the actual system. This produced requirements, design, and task lists that matched what I had already built. It might sound redundant, but it was valuable:

it confirmed the design was consistent,
it gave me a checklist of remaining tasks,
and it created documentation that I could share later.

Extra features and validation

Using the spec as a guide, I added missing pieces: cache policies, end-to-end tests, and deployment cleanup checks. I also asked Kiro to validate the system against the spec, which helped catch a few oversights.

What I took away

Kiro didn't magically solve everything, but it accelerated the boring parts - large CloudFormation scaffolds that I wasn't used to writing.
Having a generated spec after the fact turned out to be a useful way to organize and document the project.
With only limited CloudFormation background, I could still publish a complete SAR template in a short amount of time.

If you're curious about the solution itself, see my earlier post: Static WordPress authentication with Amazon Cognito and AWS SAR template.

Static WordPress Authentication with Amazon Cognito and AWS SAR Template

László Tóth — Fri, 05 Sep 2025 10:13:32 +0000

Static sites are great. They're fast, cheap, and secure by default.

But if you've ever tried to add login or user-only content to a static WordPress export… you know the pain.

/wp-login.php doesn't exist anymore. PHP is gone. And yet, users still expect a sign-in flow that feels smooth and professional.

That's exactly the challenge we faced - and here's how we solved it with Amazon Cognito + API Gateway + Lambda + CloudFront signed cookies.

Why Even Bother With Static WordPress?

Static WordPress exports (via plugins, S3 + CloudFront, or Netlify) are becoming popular because:

Speed: HTML served directly from a CDN
Cost: no dynamic servers to manage
Security: surface area is tiny

But the trade-off is obvious: all the built-in WP authentication features vanish.

We wanted the best of both worlds: keep WordPress static and fast, but add real authentication powered by AWS.

The AWS Approach

Instead of bending WordPress to handle login, we let AWS handle it at the edge.

Here's the high-level design:

Amazon Cognito handles user sign-up, login, MFA, and tokens.
API Gateway + Lambda exchange Cognito tokens for CloudFront signed cookies.
CloudFront enforces access, serving protected resources only to users with valid cookies.

No PHP callbacks, no secrets stored in WordPress. Just clean, serverless authentication.

How It Feels for Users

From the user's perspective:

They click Sign In on the WordPress site.
They see a branded Cognito-powered login (integrated with Gatey blocks).
On success, they get signed cookies behind the scenes.
CloudFront now lets them access members-only pages, media, or even entire routes.

It feels just like a "normal" site, but under the hood it's 100% serverless.

A Quick Architecture Sketch

[ User ] → [ WordPress (static) ]
       ↘ Sign-In → [ Amazon Cognito ]
                    ↘ Tokens → [ API Gateway + Lambda ]
                                  ↘ Issue Signed Cookies → [ CloudFront ]

CloudFront becomes the gatekeeper. If your cookies are valid, you're in. If not, you're redirected to login.

Why This Rocks

Performance - static WordPress stays lightning-fast
Security - Cognito & signed cookies > old-school PHP sessions
Scalability - runs natively on AWS infra
Flexibility - protect full sites or just specific routes

And most importantly: it keeps your WordPress database completely out of the authentication loop.

Real-World Use Cases

Membership sites hosted statically
Documentation portals with role-based access
Hybrid sites where only certain routes need login
SaaS dashboards powered by WordPress as the frontend

If you're already using CloudFront, this pattern feels very natural.

Full Tutorial with Code & Screenshots

This post was just the overview.

We wrote up the step-by-step guide with SAR template, Lambda code, and WordPress integration here:

Static WordPress Authentication Made Simple - Deploy with the AWS SAR Template

Closing Thoughts

Static WordPress doesn't mean static functionality.

With Cognito + CloudFront signed cookies, you can have speed, security, and scalability - without giving up authentication.

Curious what you think: would you ever run WordPress in static mode if authentication "just worked"? Drop your thoughts below.