Forem: Maciej Łopalewski

AWS CloudFront Explained: How Cache, Origin, and Response Policies Supercharge Your CDN

Maciej Łopalewski — Wed, 21 Jan 2026 09:00:00 +0000

If you have configured Amazon CloudFront in the past, you might remember wrestling with "Cache Behaviors" - a monolithic setting where caching logic, origin forwarding, and header manipulation were all jumbled together.

Those days are over.

Modern CloudFront architecture uses a modular Policy System. This approach decouples caching (what is stored) from origin requests (what is sent to the backend) and response headers (security/CORS).

For DevOps engineers and cloud architects, understanding these three policy types is the key to building performant, secure, and scalable content delivery networks. This guide breaks down the ecosystem of CloudFront Managed Policies and helps you choose the right tools for the job.

What is CloudFront?

Before diving into policies, let’s ground ourselves in the basics. Amazon CloudFront is a global Content Delivery Network (CDN). Its primary job is to sit between your users and your infrastructure (the "Origin" - like an S3 bucket or an EC2 load balancer).

Latency: It serves content from "Edge Locations" physically closer to the user.
Security: It terminates TLS connections at the edge and blocks DDoS attacks.
Scale: It absorbs traffic spikes so your backend doesn't crash.

The Policy Trio: How They Work

In the modern CloudFront request flow, three distinct policies interact to process a user's request. Understanding the distinction between them is critical for avoiding common pitfalls like "cache misses" or CORS errors.

1. Cache Policy

Where it sits: At the very front of the flow.
What it does: It determines the Cache Key.

When a user requests content, CloudFront uses this policy to decide if it already has a copy. It defines which headers, cookies, or query strings make a request "unique."

Strict policies = Higher cache hit ratio.
Loose policies = Lower cache hit ratio (more load on origin).

2. Origin Request Policy

Where it sits: Between CloudFront and your Backend (Origin).
What it does: It determines what data is forwarded to the backend during a cache miss.

This is the most misunderstood policy. It allows you to send data (like user-specific cookies) to your backend without including that data in the Cache Key. This keeps your cache efficiency high while still giving your application the data it needs to process logic.

3. Response Headers Policy

Where it sits: On the way back to the user.
What it does: It injects specific HTTP headers into the response.

Regardless of what your backend sends, this policy ensures the browser receives the correct Security (HSTS, XSS protection) and CORS headers.

Top Managed Policies: A Cheat Sheet

AWS maintains a library of "Managed Policies" that cover about 90% of use cases. Using these is a best practice - they are rigorously tested, updated by AWS, and require zero maintenance.

Here are the most essential managed policies for each category.

A. Managed Cache Policies

Control the Cache Key and TTL (Time To Live).

CachingOptimized

Best For: S3 Buckets, Static Websites, Images/Assets.

How it works: It ignores almost all headers and cookies. It aggressively caches content based solely on the URL path.
Why choose it: This provides the highest possible cache hit ratio. If your content doesn't change based on who is viewing it, use this.

CachingDisabled

Best For: Dynamic APIs, WebSockets, Real-time data.

How it works: It sets the Time-To-Live (TTL) to 0. Every request bypasses the cache and goes straight to the origin.
Why choose it: Essential for endpoints where data changes every second, or for write operations (POST/PUT) where caching would break functionality.

UseOriginCacheControlHeaders

Best For: CMS (WordPress/Drupal), Hybrid Apps.

How it works: It defers the decision to your server. It looks for Cache-Control headers sent by your backend to decide how long to store the file.
Why choose it: Perfect if you have a mix of static and dynamic content and want your application code, rather than CloudFront configuration, to control cache duration.

B. Managed Origin Request Policies

Control what the backend sees (without breaking the cache).

AllViewer

Best For: Legacy Applications, Complex Dynamic Apps.

How it works: Forwards everything - every header, every cookie, every query string - to the origin.
Why choose it: If your application relies on specific, obscure headers or client-side cookies to function, this ensures nothing is stripped out. Warning: This may expose internal origin details.

CORS-S3Origin

Best For: S3 Buckets serving assets to other domains.

How it works: Specifically whitelists the headers S3 requires to process CORS checks (Origin, Access-Control-Request-Method, etc.).
Why choose it: S3 handles CORS differently than a standard web server. Standard forwarding often fails with S3; this policy fixes those specific issues instantly.

UserAgentRefererHeaders

Best For: Analytics, Hotlink Protection.

How it works: It specifically forwards the User-Agent and Referer headers while stripping others.
Why choose it: If your backend needs to block requests from specific sites (hotlinking) or serve different content to mobile vs. desktop devices, but doesn't need full cookie visibility.

C. Managed Response Headers Policies

Control browser security and access.

SecurityHeadersPolicy

Best For: Everything. (Seriously, use this everywhere).

How it works: Automatically injects industry-standard security headers like:
- Strict-Transport-Security (HSTS)
- X-Frame-Options: DENY (prevents clickjacking)
- X-Content-Type-Options: nosniff
Why choose it: It instantly hardens your application against common web attacks without requiring code changes on your server.

CORS-with-preflight-and-SecurityHeadersPolicy

Best For: Single Page Apps (React, Vue, Angular) calling APIs.

How it works: Combines the security headers above with a permissive CORS configuration. It handles the OPTIONS pre-flight requests that modern browsers send before making API calls.
Why choose it: It solves the dreaded "CORS Error" in browser consoles for modern web applications.

SimpleCORS

Best For: Public, read-only data feeds.

How it works: Adds Access-Control-Allow-Origin: * to the response.
Why choose it: If you are hosting public data (like a weather feed or public JSON file) that you want anyone to be able to use on their website, this is the quickest way to enable it.

Common CloudFront Misconfigurations and How Managed Policies Fix Them

Even experienced DevOps teams run into the same CloudFront issues over and over. Almost all of them trace back to legacy cache behaviors or overly customized settings. Here’s how CloudFront Managed Policies solve the most common problems.

1. “My cache hit ratio is terrible.”

Cause: Your Cache Key is too loose - it includes unnecessary headers, cookies, or query strings.
Symptom: Every request is seen as "unique," forcing a constant stream of cache misses.
The Fix: Use the CachingOptimized managed policy. It strips almost everything from the Cache Key, restoring high hit ratios - perfect for static assets, SPAs, and S3 origins.

2. “CloudFront keeps forwarding too many headers to my origin.”

Cause: Legacy behaviors often forward all headers by default.
Impact: Increased origin load, slower responses, and potential "Request Header Too Large" errors on the backend.
The Fix: Switch to an Origin Request Policy like UserAgentRefererHeaders or CORS-S3Origin. This ensures you forward only what your backend actually needs to function.

3. “I’m still getting CORS errors in the browser.”

Cause: Missing or inconsistent Access-Control-* headers.
The Fix: Apply the CORS-with-preflight-and-SecurityHeadersPolicy response policy. It handles OPTIONS preflight requests and injects all required CORS headers at the edge - even if your backend forgets them.

4. “S3 CORS works on localhost, but not in CloudFront.”

Cause: S3 requires specific headers to process CORS. If CloudFront strips them, S3 treats the request as standard and omits the CORS response headers.
The Fix: Use the CORS-S3Origin Origin Request Policy. This explicitly forwards Origin, Access-Control-Request-Method, and Access-Control-Request-Headers so S3 knows to respond correctly.

5. “My dynamic API is being cached when it shouldn’t be.”

Cause: Your API path (/api/*) is falling through to a default behavior that has caching enabled.
The Fix: Create a specific behavior for your API path and attach CachingDisabled. This guarantees every request bypasses the edge and reaches your application.

Summary

Moving to Managed Policies allows you to operate with "Intent-Based Configuration." Instead of tweaking individual settings, you select a policy that matches your architectural intent.

Intent	Recommended Policy Combo
Static Website	Cache: `CachingOptimized` Origin Request: `None` (or `CORS-S3Origin`) Response: `SecurityHeadersPolicy`
Dynamic API	Cache: `CachingDisabled` Origin Request: `AllViewer` Response: `SimpleCORS`
Modern Web App (SPA)	Cache: `CachingOptimized` (for assets) Origin Request: `None` Response: `CORS-with-preflight`

Architecting Dagster at Scale: Navigating the Challenges of 50+ Code Locations on Kubernetes

Maciej Łopalewski — Mon, 20 Oct 2025 07:58:08 +0000

As your organization embraces Dagster for data orchestration, your projects will inevitably grow. What starts with a single, manageable code location can quickly expand into dozens, each owned by a different team or serving a distinct data domain. While this modularity is one of Dagster’s strengths, it introduces significant architectural challenges, especially when deploying on Kubernetes.

Managing 50, 100, or even more code locations is not just a matter of adding more entries to a YAML file. It has profound implications for resource consumption, deployment speed, and overall maintainability.

This article dives deep into the trade-offs of managing Dagster at scale on Kubernetes. We’ll explore different deployment models, discuss performance and observability, and share real-world patterns (and anti-patterns) to help you design a data platform that is both powerful and efficient.

First, What Are Dagster Code Locations?

In Dagster, a code location is a collection of Dagster definitions (like assets, jobs, schedules, and sensors) that are loaded in a single Python environment. Think of it as a self-contained package of data pipelines. By isolating code into distinct locations, you achieve several benefits:

Fault Tolerance: An error in one code location (e.g., a missing Python dependency) won’t prevent other code locations from loading.
Independent Deployments: Team A can update their pipelines without forcing Team B to redeploy.
Dependency Management: Each code location can have its own requirements.txt or pyproject.toml, avoiding conflicts between teams that need different library versions.

Dagster’s central components, like the webserver and the daemon, communicate with these code locations via a gRPC API to fetch definitions and launch runs. This separation is key to its scalability.

The Hidden Costs of Managing 50+ Code Locations

When you deploy Dagster on Kubernetes using the official Helm chart, the standard approach is to use user code deployments. This feature creates a dedicated Kubernetes Deployment and Service for each code location you define.

A typical Dagster architecture on Kubernetes, where each code location runs in its own pod.

This model works perfectly for a handful of locations. But as you scale past 50, you start to feel the pain points:

Resource Overhead: Each code location pod consumes resources just by running. A baseline Python process, the gRPC server, and health checks require a certain amount of CPU and memory. While a single pod might only need 100MB of RAM, 50 of them instantly consume 5GB - and that’s before they even load your code. This idle resource consumption can become a significant cost.
Deployment Bottlenecks: If you need to update a shared library or a base Docker image used by all code locations, you trigger a massive rollout. Kubernetes must terminate 50+ old pods and schedule 50+ new ones. In a resource-constrained cluster, this can lead to long deployment times, "Pod unschedulable" events, and service degradation.
The "Launchpad" Problem: It's crucial to remember that these code location pods do not run your data pipelines. Their primary role is to serve metadata to the webserver and provide the necessary code to the Dagster daemon, which then launches another pod (the "run pod" or "job pod") to actually execute the pipeline. This means your infrastructure must support both the standing army of code location pods and the transient pods for active runs, further compounding resource pressure.

Kubernetes Deployment Models: Trade-Offs and Strategies

Given the challenges, let's analyze the two primary architectural models for deploying Dagster code locations on Kubernetes.

Model 1: The Standard "Pod per Code Location"

This is the default and recommended approach using user-code-deployments in the Dagster Helm chart.

How it works: You define each code location in your values.yaml file, and Helm creates a separate Kubernetes Deployment for each.

# values.yaml
userCodeDeployments:
  enabled: true
  deployments:
    - name: "sales-analytics"
      image:
        repository: "my-registry/sales-analytics"
        tag: "0.2.1"
      # ... resources, env vars, etc.
    - name: "marketing-etl"
      image:
        repository: "my-registry/marketing-etl"
        tag: "1.5.0"
      # ...
    # ... 50 more entries

Pros:

Full Isolation: The best model for fault tolerance and dependency management.
Clear Ownership: Easy to map a code location pod to a specific team or project.
Granular Updates: An update to the sales-analytics image only triggers a rollout for that single deployment.

Cons:

High Resource Overhead: The primary driver of idle resource consumption.
Slow Global Deployments: Updating all locations at once is slow and resource-intensive.
Cluster Limits: Can strain clusters that have a low limit on the total number of pods.

Model 2: The Monolithic "Single Pod" Approach (A Workaround)

For teams struggling with the overhead of the standard model, an alternative is to consolidate all code locations into a single process. This is not officially recommended as it moves away from Dagster's core isolation principles, but it can be a pragmatic solution in specific, resource-constrained scenarios.

How it works: You can "hack" the official Helm chart to run all your code locations within the main Dagster webserver and daemon pods. This involves building a single, monolithic Docker image containing the code for all pipelines and providing a workspace.yaml that loads them from the local filesystem.

# In your monolithic Dockerfile
COPY ./pipelines/sales_analytics /opt/dagster/app/sales_analytics
COPY ./pipelines/marketing_etl /opt/dagster/app/marketing_etl
# ...

# workspace.yaml loaded into the webserver/daemon
load_from:
  - python_module:
      module_name: sales_analytics.definitions
      working_directory: /opt/dagster/app/sales_analytics
  - python_module:
      module_name: marketing_etl.definitions
      working_directory: /opt/dagster/app/marketing_etl
  # ... all other locations

You would disable userCodeDeployments and ensure this workspace file is used by the main Dagster pods.

Pros:

Minimal Resource Footprint: Dramatically reduces the number of standing pods, saving significant idle resources.
Fast Deployments: An update involves rolling out just a few pods (webserver, daemon), which is much faster than 50+.

Cons:

No Fault Tolerance: A single broken dependency or syntax error in one code location can bring down the entire system.
Dependency Hell: All teams must agree on a single, shared set of Python dependencies.
Massive Pods: The webserver and daemon pods become huge, potentially requiring very large and expensive Kubernetes nodes to run.
Coupled Deployments: Any change requires rebuilding and redeploying the entire monolithic image.

Strategies for Maintainability and Scaling

Instead of choosing one extreme, the best strategy often lies in intelligent application of the standard model.

Use a Separate Image Per Code Location: Avoid using a single base image for all your code locations. While it seems efficient, it creates tight coupling. Instead, build and version a Docker image for each code location independently. This ensures that only the code locations that have actually changed will be redeployed during an update.
Aggressively Monitor Resources: Use tools like Prometheus and Grafana to monitor the CPU and memory usage of your code location pods. Are they constantly sitting at 5% of their requested resources? You are likely overprovisioning. Adjust their resources.requests in your Helm chart to free up capacity for run pods.
Optimize Deployment Times: Keep your Docker images lean. A smaller image pulls faster, leading to quicker pod startup times. Use multi-stage builds and avoid including unnecessary build-time dependencies in your final image.

Real-World Patterns and Anti-Patterns

Theory is one thing, but production issues are the best teacher. Here are some patterns to emulate and anti-patterns to avoid.

Anti-Pattern: The Heavyweight Code Location

A common mistake is to load large models or initialize expensive clients at the module level of your Dagster code. Remember: everything you import and define globally in your code location gets loaded into memory the moment the pod starts.

Real-world example:
A team was using the libpostal library for address parsing. Simply adding import postal to their asset definitions caused the memory footprint of their code location pod to jump by 2GB. When several other teams copied this pattern, the cluster's memory usage skyrocketed, causing widespread performance issues.

# assets/address_parsing.py

from postal.parser import parse_address # <-- This import loads a large model into memory!

from dagster import asset

@asset
def parsed_addresses(raw_addresses):
    # This asset's code location pod now holds a 2GB model in memory,
    # even when the asset is not running.
    return [parse_address(addr) for addr in raw_addresses]

The Fix: There are two great ways to solve this problem.

Lazy Loading: The simplest fix is to lazily import or load expensive resources inside your asset or op functions. This ensures the resource is only loaded into memory in the short-lived run pod, not the long-running code location pod.

# A better approach
from dagster import asset

@asset
def parsed_addresses(raw_addresses):
    from postal.parser import parse_address # <-- Import inside the function

    return [parse_address(addr) for addr in raw_addresses]

Externalize as a Microservice: For an even more robust and scalable solution, you can externalize the heavy dependency entirely. You can deploy libpostal as a microservice (e.g., using a wrapper like libpostal-rest) to have more control over its resources. This centralizes the resource-intensive component into a single, dedicated instance that you can manage and scale independently, serving all your Dagster pipelines via a simple network call.

Pattern: Domain-Driven Consolidation

If you have many small, related code locations owned by the same team, consider consolidating them. Instead of having sales-team-daily, sales-team-weekly, and sales-team-hourly, merge them into a single sales-team code location. This reduces pod sprawl without creating a true monolith.

Conclusion: When to Split and When to Consolidate

Choosing the right architecture is a balancing act. Here's a simple heuristic:

Stick with the "Pod per Code Location" model as your default. The isolation and maintainability benefits are immense and align with Dagster's core design. Use the strategies outlined above to mitigate the resource overhead.
Consolidate code locations that are owned by the same team, share the same dependencies, and are deployed together. This is a pragmatic way to reduce pod count.
Only consider the "Monolithic" model as a last resort. If you are in a highly resource-constrained environment and suffering from cripplingly slow rollouts due to pod churn, it can be a temporary lifeline. But be fully aware of the trade-offs in stability and dependency management you are making.

Boost Your Medusa E-Commerce Development: Streamlined Local Setup Guide

Maciej Łopalewski — Fri, 27 Jun 2025 05:27:38 +0000

Medusa is a powerful open-source headless commerce engine that provides a flexible and robust foundation for building e-commerce applications. Getting started with a new framework often involves setting up various prerequisites and understanding configuration nuances. While the official documentation is excellent, having a pre-configured starting point can significantly accelerate the local development process.

This article will guide you through setting up Medusa locally, focusing on common requirements and helpful configurations. We'll also introduce a specific resource, the medusa-starter repository, designed to simplify these initial steps and provide valuable examples for future deployment.

The Standard Medusa Installation Path

The official Medusa documentation offers comprehensive guides for getting started. You can find the detailed installation instructions covering prerequisites like Node.js, PostgreSQL, and Redis on the Medusa Installation guide. It's highly recommended to familiarize yourself with these official steps.

Simplifying Prerequisites with `medusa-starter`

One of the initial hurdles in setting up a local development environment for Medusa is provisioning the necessary database (PostgreSQL) and caching layer (Redis). The medusa-starter repository addresses this by providing a simple Docker Compose file specifically for these services.

Within the repository, you'll find a compose.db.yaml file (link to compose.db.yaml). This file allows you to spin up ready-to-use PostgreSQL and Redis instances with a single command:

docker-compose -f compose.db.yaml up -d

This command brings up the necessary services in detached mode (-d), allowing you to quickly get your database and cache dependencies running without manual installation and configuration. Based on the configuration in compose.db.yaml, this will set up:

PostgreSQL: Available on localhost:5432. It will be configured with the user, password, and database name specified within the compose file or corresponding environment variables, ready for your Medusa instance to connect.
Redis: Available on localhost:6379. For this local development setup, authentication is typically not required, allowing for straightforward connection.

The medusa-starter repository includes environment variables tailored to connect to these services, making integration straightforward once they are running.

Understanding `NODE_ENV` and Its Implications

A critical aspect of configuring your Medusa application, both locally and in production, is the NODE_ENV environment variable. This variable significantly influences Medusa's behavior.

NODE_ENV=development: This is the standard setting for local development. In this mode, Medusa often provides more detailed logging and error messages, and certain security constraints are relaxed to facilitate rapid iteration.
NODE_ENV=production: This setting is intended for production deployments. Medusa enables stricter security measures and optimizes for performance. A key behavior change in production mode is the requirement for a secure connection (HTTPS/TLS) and a custom domain to access the Medusa Admin panel. This is because Medusa uses secure cookies for authentication, which browsers will only send over a secure connection to a specific domain, not localhost.

A `NODE_ENV` Workaround for Local Docker (Without TLS)

If you are trying to run your Medusa application locally within a Docker container without setting up TLS and a custom domain, using NODE_ENV=production will prevent you from logging into the admin panel.

As a workaround for this specific scenario (local Docker testing without TLS), you can set NODE_ENV to a different value, such as CI. While this allows you to bypass the secure cookie requirement locally, it is important to understand that this is a workaround and not a recommended practice for actual production deployments. For production, always use NODE_ENV=production and ensure proper TLS setup.

Beyond Local Development: Production Examples in `medusa-starter`

The medusa-starter repository isn't just for getting started locally. It also provides valuable examples to help you transition towards production deployments:

medusa-config.ts Example: The repository includes an example medusa-config.ts file (link to medusa-config.ts) that demonstrates how to configure modules and settings suitable for a production environment, often integrating with the Docker Compose database setup.
Example Dockerfiles: You'll find example Dockerfiles (link to Dockerfiles) that show you how to package your Medusa application into a Docker image, a common step for cloud deployments.
Example GitHub Actions Workflow: The repository includes a basic GitHub Actions workflow example (link to GitHub Actions) that you can adapt for your own projects. This workflow demonstrates a basic Continuous Integration (CI) pipeline, which is crucial for automating testing and building your application.

Conclusion

Setting up a development environment can sometimes feel like the first significant hurdle. The medusa-starter repository (v2) aims to lower that barrier by providing pre-configured examples for essential services via Docker Compose. By understanding the role of NODE_ENV and leveraging the provided configuration and Docker examples, you can not only streamline your local development workflow but also gain a head start on preparing your Medusa application for production deployment. Explore the repository, adapt the examples to your needs, and happy coding!