Skip to content

Use S3 For Cache Instead of EFS To Eliminate Default NAT Gateway? #127

@bestickley

Description

@bestickley

Using EFS as cache for data cache, full route cache, and image optimization cache means we must use NAT Gateway to access internet for Nextjs*Functions whereas if we used S3, NAT Gateways would not be required. By default, NAT Gateways cost $65/mo for 2 AZs which is cost prohibitive for some customers. Nextjs*Containers constructs already require VPC and NAT Gateway to access internet so it cannot be avoided for those constructs.

Should we do this?

To do so, we'd need to update src/nextjs-build/cdk-nextjs-cache-handler.ts to handle data cache and full route cache updates to S3 instead of EFS. How to update image optimization cache? Types on exported IncrementalCacheValue type from Next.js (next/dist/server/response-cache) seems to indicate images are set in the custom cache handler but are they fetched? Would we need to provide a custom next.config.js#images.loaderFile? I'd prefer to use Next.js' default sharp image optimization. Shouldn't be too complicated.

We'd also need to account for revalidateTag and keep track of when they expire. We could use DynamoDB for this or try to just use S3 metadata? Lifecycle policies fastest expiration time in 1 day, but that's fine - we could check to see if it expired before returning in set function.

Resources:

@chxlloyd , @coltenkrauter, @gbone-restore, @LaurenceGA, @mohsen1, curious about your opinions on this. Please chime in if you have any thoughts. Thank you!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions