Forem: Anne

AWS Amplify + Amazon Cognito + AWS CDK: A Complete Setup Guide

Anne — Wed, 25 Feb 2026 21:22:12 +0000

Setting up AWS Amplify with Amazon Cognito using CDK is mostly straightforward. The tricky parts?

GitHub integration (PAT → GitHub App migration)
Cognito email configuration with SES
Automating login page branding (which isn’t supported in CDK yet)

This article walks you through the full setup with the important details without unnecessary boilerplate.

Amplify App with CDK

You can create your Amplify app in CDK using Level 1 Cloudformation constructs. That part is pretty simple if you know CDK. However, the GitHub integration still requires a Personal Access Token (PAT) for the initial setup in CDK. If you go to the Amplify console after your deployment, it will immediately suggest you to migrate to GitHub App authentication. This can be done easily following the steps in the console. From now on you can revoke the PAT and replace it with a random string in your CDK code (at least 1 char length).

Cognito User Pool (Email as Login)

Here’s a clean CDK example:

new cognito.UserPool(this, 'MyUserPool', {
  signInAliases: { email: true },
  autoVerify: { email: true },
  standardAttributes: {
    email: { required: true, mutable: true },
    givenName: { required: false, mutable: true },
    familyName: { required: false, mutable: true },
  },
  userInvitation: {
    emailSubject: 'Access to My App',
    emailBody: "Hello,<br>Your username: {username}<br>Password: {####}",
  },
  userVerification: {
    emailSubject: 'Verification Code',
    emailBody: 'Your verification code: {####}',
  },
  accountRecovery: cognito.AccountRecovery.EMAIL_ONLY,
});

A few notes to the user pool:

signInAliases set to email will allow your users to login via email instead of using a dedicated username. Also in the email templates the username will be rendered as the user's email in this case
The email templates are for inviting new users as well as password reset. Especially if your users don't speak English it can be very useful to replace the standard template. The templates also support basic HTML (e.g., for line breaks).
Custom attributes are also possible to define, however, keep in mind that they are not searchable in Cognito.

Custom Email Sender with SES

To send invitation and password recovery emails from your own domain, you need to configure Amazon SES:

new ses.EmailIdentity(this, 'Identity', {
  identity: ses.Identity.email('my@email.com'),
});

Please make sure, that SES in your account is out of sandbox mode, your identity is successfully verified and don't forget to grant permissions to send emails to the user pool:

emailIdentity.grant(
  new ArnPrincipal(myUserPool.userPoolArn),
  'ses:SendEmail'
);

User Pool Client for Nuxt

Your frontend needs a client:

new cognito.UserPoolClient(this, 'Client', {
  userPool,
  generateSecret: true,
  preventUserExistenceErrors: true,
  supportedIdentityProviders: [
    cognito.UserPoolClientIdentityProvider.COGNITO,
  ],
  oAuth: {
    callbackUrls: ['https://myapp.com/auth/callback'],
    logoutUrls: ['https://myapp.com'],
    scopes: [
      cognito.OAuthScope.OPENID,
      cognito.OAuthScope.PROFILE,
    ],
    flows: {
      authorizationCodeGrant: true,
      implicitCodeGrant: true,
    },
  },
});

Key settings:

generateSecret: true (needed for SSR (e.g., Nuxt))
authorizationCodeGrant (recommended secure flow)
preventUserExistenceErrors (avoids user enumeration leaks)

Nuxt OAuth Configuration

In your nuxt.config.ts you have to add the oauth configuration for using Cognito:

oauth: {
  cognito: {
    clientId: COGNITO_CLIENT_ID,
    clientSecret: COGNITO_CLIENT_SECRET,
    region: COGNITO_REGION,
    userPoolId: COGNITO_USER_POOL_ID,
    redirectURL: COGNITO_REDIRECT_URL,
    authorizationParams: {
      lang: 'en'
    }
  }
}

In here you can define a language parameter so that your users will see the login page in their native language. Currently supported language can be found in the AWS docs.

Custom Domain

In order to use your own domain instead of a default AWS cognito domain you can add one to your user pool like this:

myUserPool.addDomain('Domain', {
  customDomain: {
    domainName: 'auth.myapp.com',
    certificate: props.certificate,
  },
  managedLoginVersion: cognito.ManagedLoginVersion.NEWER_MANAGED_LOGIN,
});

The certificate in this case was created in another stack using the AWS certificate manager. Also, I am using the new AWS Managed Login (not the Hosted UI).

Automating the Styling of the Cognito New Managed Login

AWS provides a nice UI in the console to style the new managed login (logo, favicon, colors in dark and bright mode etc.), however, this can't be managed through CDK (yet?). But here's a workaround:

Style your managed login in the AWS console
Export the configuration with the AWS CLI and save the output into a JSON file.

aws cognito-idp describe-managed-login-branding \
  --user-pool-id YOUR_USER_POOL_ID \
  --managed-login-branding-id YOUR_BRANDING_ID

Apply the styling e.g. in your CI/CD pipeline after the deployment like this

aws cognito-idp update-managed-login-branding \
  --user-pool-id $USER_POOL_ID \
  --managed-login-branding-id $MANAGED_LOGIN_BRANDING_ID \
  --settings file://login-settings.json

Conclusion

Setting up Cognito with CDK can require a bit of fumbling around with the configurations. However, once set up Cognito is a strong reliable way to authenticate your users for your Amplify hosted app.

From Seconds to Milliseconds: Fixing Python Cold Starts with SnapStart

Anne — Mon, 27 Oct 2025 21:49:21 +0000

If you’ve built a Python Lambda that uses Pydantic heavily (or other heavy model initialization, schema loading, or framework bootstrapping), you’ve probably hit this painful boundary: cold starts are dominated by your app’s initialization time, not AWS’s runtime overhead. Even if AWS could spin up pods in less than 100 ms, your own code might spend 800 ms or more importing modules, constructing many Pydantic models, loading schemas, doing dependency injection, etc. That kind of latency becomes a dealbreaker for synchronous, latency-sensitive APIs.

With the availability of Lambda SnapStart for Python (runtime 3.12+), that barrier is now much lower: you can snapshot the fully-initialized environment and restore from it. In other words: the heavy startup cost of initializing your Pydantic models happens once during deployment, rather than every time the function runs.

What is Lambda SnapStart (for Python) and how it changes cold starts

Before SnapStart, Lambda cold starts involved:

Downloading your code package
Starting the language runtime (Python interpreter)
Running all initialization code (imports, global-level constructs, class definitions, module-level state, constructor logic, etc)
Finally handling the incoming event

If your startup logic is heavy (for example, constructing >100 Pydantic model classes, loading JSON or YAML schemas, instantiating global validators or caches, etc.), that initialization phase can be your bottleneck.

SnapStart changes that dramatically (for supported runtimes). The flow is:

You enable SnapStart on a published version of your Lambda (or via alias to a version).
When that version is published, Lambda “warms up” the function once, runs all initialization code, sets up your global state exactly as your code would do for a first invocation.
Lambda then takes a memory + disk snapshot (a Firecracker micro-VM snapshot) of that fully initialized state, encrypts and persists it in a cache.
Later, when a new environment is needed, (a cold) Lambda restores from that snapshot, essentially skipping the heavy init and resuming from the “post-init” state.
Your handler logic runs as-is.

In effect, a lot of the “cold start” cost is eliminated. AWS claims that you can get “sub-second” startup times even for heavy apps.

Snapshot safety, uniqueness, and runtime hooks

Because SnapStart literally reuses memory state, if your initialization code produces unique artifacts (for example, a new random UUID on startup, or a unique timestamp, or establishes network sockets), those may incorrectly get reused across invocations if not handled carefully.

To mitigate this, AWS provides runtime hooks for Python:

@register_before_snapshot: functions that run right before the snapshot is taken. Use this hook to “undo” or clean up any ephemeral or unique initialization state (e.g. close DB connections, clear caches, reset random seeds).
@register_after_restore: functions that run immediately upon restore from snapshot, before handling the first event. Use this to reinstantiate anything you can’t reuse (e.g. re-open connections, reinitialize entropy, refresh tokens).

These hooks help ensure your function remains correct even when operating from a snapshot.

Using SnapStart in CDK for Python Lambdas

Let’s get into how to configure SnapStart when deploying via AWS CDK (in Python). The high-level steps are:

Use a Lambda construct (e.g. aws_lambda.Function or the PythonFunction from the aws_lambda_python_alpha module).
Ensure your runtime is at least Python 3.12 (SnapStart is supported on Python 3.12+).
Enable the SnapStart property.
Add a version alias so that SnapStart can be applied to the published version.

Here is a sample skeleton (CDK in Python):

from aws_cdk import (
  Stack,
  Duration,
  aws_lambda as _lambda,
  aws_lambda_python_alpha as lambda_python,
  aws_iam as iam,
)
from constructs import Construct

class MyLambdaStack(Stack):
  def __init__(self, scope: Construct, id: str, **kwargs):
    super().__init__(scope, id, **kwargs)

    # 1. Define the Lambda
    my_fn = lambda_python.PythonFunction(
      self, "MyPydanticFn",
      runtime=_lambda.Runtime.PYTHON_3_12, # 2. Correct runtime
      handler="app.handler",
      entry="path/to/your/code",
      memory_size=1024,
      timeout=Duration.seconds(30),
      snap_start: lambda.SnapStartConf.ON_PUBLISHED_VERSIONS # 3. Enable SnapStart
    )

    # 4. Create a version
    version = my_fn.current_version  # forces a Version artifact

One thing to notice in that pattern:
We rely on my_fn.current_version to force CDK to emit a AWS::Lambda::Version resource (without that, there’s no version to attach SnapStart to).

Things to consider

The pre-snapshot initialization phase has a time limit (the INIT time limit of 10 seconds) as usual. Your before-snapshot hooks count toward that.
After snapshot restore, the @after_restore hook must finish within 10 seconds as well, else it might throw a SnapStartTimeoutException.
Whenever your code (or dependencies) change in a way that should invalidate the snapshot, you must force a new version so a new snapshot is captured. If CDK's version hashing doesn't catch something, you can call version.invalidate_version_based_on(...) with a changing token (e.g. content hash of certain files) to ensure version recreation.
At the time of writing, SnapStart is not supported with ephemeral storage > 512 MB, EFS, provisioned concurrency, or containers.

Conclusion

In summary, AWS Lambda SnapStart for Python removes one of the biggest hurdles to running complex, model-heavy applications in a serverless environment. By snapshotting your function’s fully initialized state at deployment time, it eliminates the repeated cost of initializing frameworks like Pydantic on every cold start. With a small configuration change in CDK and a few runtime hooks to manage transient state, you can achieve consistently fast startup times and make Lambda a practical, scalable choice even for Python applications that used to be too slow to launch.