DEV Community: Lucas Tonelli

Easily secure your non-prod environments from external users for free

Lucas Tonelli — Tue, 06 Oct 2026 13:00:00 +0000

If you have a private domain sitting on the public internet, chances are anyone can reach it. Search engines index it, curious people poke at it, and bots scan it all day long. The usual fixes are a VPN (complex and annoying to maintain), IP allowlists (break the moment someone works from a coffee shop), or basic auth (everyone shares the same password forever). However, the good thing is that there's another way.

Cloudflare Access

The idea is simple, your DNS record for the environment must be proxied through Cloudflare (the orange cloud), so every request passes through their edge. Then you create a self-hosted Cloudflare Access application pointing to that domain, and attach a policy to it, for example, allowing only emails ending in @mycompany.com or a specific list of addresses.

From that point on, anyone hitting the gated address gets redirected to a login page, with an input to enter an email. Once the email is submitted, Cloudflare sends a one-time PIN to it, if it matches the conditions in the policy, then the user gets a session cookie and goes through. If the email doesn't match, the user never touches your servers.

Code example

You can click this together on the Cloudflare dashboard, but you can also do it through Terraform with two resources:

resource "cloudflare_zero_trust_access_application" "development" {
  account_id                 = local.cloudflare_account_id
  name                       = "development.${var.project_name}"
  domain                     = "development.${var.apex_domain_name}"
  type                       = "self_hosted"
  session_duration           = "12h"
  http_only_cookie_attribute = true
  app_launcher_visible       = false
  policies = [{
    id         = cloudflare_zero_trust_access_policy.default.id
    precedence = 1
  }]
}

resource "cloudflare_zero_trust_access_policy" "default" {
  account_id       = local.cloudflare_account_id
  name             = "Default"
  decision         = "allow"
  session_duration = "24h"
  include = [{
    email = {
      email = local.default_email
    }
  }]
}

Worth noting

session_duration controls how long the cookie is valid, so people are not logging in on every request;
http_only_cookie_attribute keeps the session cookie away from JavaScript;
app_launcher_visible hides the app from Cloudflare's app launcher page, since this is just an internal environment; The policy is separate from the application, so you can reuse the same default policy across multiple apps. Do you need to protect staging and QA too? Duplicate the application resource (or use for_each) pointing to each subdomain, and reference the same policy.

Costs

This is the best part, it's free. Cloudflare's Zero Trust free tier covers up to 50 users, which is plenty for protecting internal environments of most teams.

There is only one catch (of course there would be a catch). The free Universal SSL certificate covers the root domain and one level of subdomain. So development.myproject.com, potatochips.myproject.com and whatever.myproject.com are all fine. But if you go one level deeper, like api.development.myproject.com, that's a second-level subdomain and the free certificate won't cover it, so you'd need Cloudflare's paid Advanced Certificate Manager for that.

Wrap-up

For such a simple setup and a proxied DNS record, your non-prod environments stop being public. No VPN, no shared passwords, no drastic changes, just an email check at the edge. It's one of those rare cases where it seems too good to be true, but it actually is pretty good.

This article was created with the help of AI because, while I'm good at being a software engineer (I hope so), I suck at being a writer. On the other hand, the silly jokes and wordplay are completely mine because I'm really good at those. Also, the content comes from things I've done or learned, has been verified and is edited to be straight to the point, since AI loves to stall, but I hate it.

Reduce SQS costs with these three strategies

Lucas Tonelli — Tue, 29 Sep 2026 13:00:00 +0000

SQS is a very popular and cheap service from AWS which seems pretty inoffensive to your monthly bill. However, it charges per request, not per message, and that detail is where most of the waste hides. Things like racking up old and unused queues with live consumers, using FIFO indiscriminately and being careless about polling will surely make AWS very happy and your pockets lighter. The good news is: there are a few ways which will help you save some money.

Enable Long Polling

By default, SQS uses short polling: your consumer calls ReceiveMessage, SQS answers immediately (even with an empty response), and your consumer calls again. Every one of those calls are billed, including the empty ones. A worker polling in a tight loop can easily generate millions of requests per month just to hear "nothing new".

With long polling, SQS holds the connection open for up to 20 seconds and only responds when there's a message (or when the wait time expires). One call every 20 seconds instead of dozens per second - same behavior for your application, but a fraction of the requests on your bill. Also, enabling it is a one-liner at the queue level:

aws sqs set-queue-attributes \
  --queue-url $QUEUE_URL \
  --attributes ReceiveMessageWaitTimeSeconds=20

Or per request, by passing it on the ReceiveMessage API request. There might be no downsides for most workloads, but be sure to check if it fits your use case.

Prefer standard queues to FIFO

FIFO queues are convenient, exactly-once processing and strict ordering out of the box, but that convenience costs more per request than standard queues, and it also caps your throughput (you'll also have to pay more to increase it). The thing is, for a lot of systems you can get the same guarantees in the application layer.

Handling duplicates

Standard queues offer at-least-once delivery, so the same message may arrive more than once. Instead of paying FIFO to deduplicate for you, make your consumer idempotent. Give each message a unique ID and record it when processed (a unique constraint in your database or a key in Redis). If the same ID shows up again, skip it (or do something else, I don't know).

Ensuring ordering

Standard queues also don't guarantee ordering, but in practice you might not need the global ordering from the queue. To circumvent that issue, add a timestamp (or version number) to each message at the producer, generated by the application. Then, when consuming, compare it against the last message processed: if the incoming message is older, skip it. An out-of-order message becomes a no-op instead of a bug.

Migrating from FIFO to standard

This is the sad part, where there's no configuration, nothing simple or even magical to do that. To go back to using standard queues you need to create another queue and migrate your application to the newly created one. If you have a lot, like an enormous amount of FIFO queues, and you need to migrate them, I feel for you, I really do.

Delete unused queues

This one sounds obvious, but it's pretty easy to forget a queue created for a feature that was deprecated, an experiment, an old environment and, along with it, a consumer somewhere still polling it 24/7. Since empty receives are billed like any other request, you're literally paying for API calls that will never return anything.

A quick way to find these zombies is to look at the NumberOfEmptyReceives metric in CloudWatch. A queue with a high count of empty receives and zero messages sent is a strong candidate for deletion.

Wrap-up

None of these strategies require redesigning your architecture. Long polling is a configuration change, idempotency and timestamps are small additions to your application code, and cleaning up unused queues is just housekeeping. So, keep up with these tips, and make every SQS request count.

Host your async app without spending a dime using AWS Lambda

Lucas Tonelli — Tue, 22 Sep 2026 13:00:00 +0000

If you have an async app, an internal tool, side project or PoC, there's no reason to pay for a machine that's awake all day for a job that takes so little time. That's where AWS Lambda comes in, charging you only when your function gets executed, with a generous free tier. So how do you take what you have, written with FastAPI, Express, Django, Fastify or whatever, and drop it into Lambda without a lot of refactoring?

AWS Lambda Web Adapter

AWS maintains an open source project called the Lambda Web Adapter which is a small proxy that sits in front of your app. Lambda invokes the adapter, the adapter translates the event into a plain HTTP request, forwards it to your app and translates the response back into whatever shape Lambda expects. Your app has no idea it's running inside Lambda. It just sees an HTTP request on a port, like it always did.

This means you don't have to refactor anything (not this time at least), you just add the adapter (copying the binary into your image if you're using a container or adding a Lambda Layer) and point it to your app's port. Here's a minimal Dockerfile example for a NodeJS app:

FROM public.ecr.aws/lambda/nodejs:24 AS base

# This is required to make the adapter work as expected
ENTRYPOINT []

# Copy the Lambda Web Adapter binary from its distributed image
COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:1.0.1 /lambda-adapter /opt/extensions/lambda-adapter

# Tells the adapter which port to listen
ENV AWS_LWA_PORT=3000

COPY package.json ${LAMBDA_TASK_ROOT}/package.json
COPY package-lock.json ${LAMBDA_TASK_ROOT}/package-lock.json

RUN npm ci --production

COPY . .

CMD ["node", "app.js"]

The adapter handles that translation transparently, including support for streaming responses if your app relies on them. For instance, this very website is running inside a Lambda function (yup).

Packaging your app

I've given an example using Docker images, but there are a few other options for you to package your app, and they all fit different needs.

ZIP

The simplest option. You zip your code and dependencies, upload it directly (through the console or CLI), and Lambda runs it on its own managed runtime. There's no image to build or registry to manage, but you're capped at 250 MB unzipped (50 MB zipped), and native dependencies need to match Lambda's underlying OS.

S3

Practically the same as the ZIP approach, but it can accept packages greater than 50 MB zipped. You push the zip to a bucket and point Lambda at that object instead of uploading it inline. Same 250 MB limit applies.

Docker

The option to reach for once you outgrow the other limits, need OS-level dependencies that aren't in the standard runtimes, or just want your Lambda environment to look like everything else you already run in containers. Also, the images can go up to 10 GB.

Once the application is packaged and the Lambda function is deployed, you need something in front of it that speaks HTTPS.

Getting an endpoint: Lambda Function URL

Function URLs are the fastest option. Every Lambda function can have a dedicated HTTPS endpoint enabled with a single setting, no extra resources to create. You get a generated URL and requests are forwarded straight to your function. If you just need an endpoint for a webhook, an internal service, or a quick prototype, this is usually all you need.

Getting an endpoint: AWS HTTP API Gateway

HTTP API Gateway makes sense once you need more than a bare endpoint: custom domains, request throttling, built-in authorizers, etc. It's a small extra piece of infrastructure to manage, but it's also cheap and pay-per-request, so it doesn't break the "free unless you're actually getting traffic" (or a DDoS attack lol) model.

Worth knowing before you commit

Lambda has a hard execution limit, so this isn't a fit for long-lived connections;
Cold starts are real, especially with container images, but they shouldn't be such a problem in a function with more frequent traffic. So, keep the image lean and consider using provisioned concurrency if it matters. However, this is basically spinning up a server and paying for the time it's up;
A single Lambda function reserved concurrency serves a single request, so plan your concurrency accordingly, to avoid being surprised by throttling;

Wrap-up

For various async apps out there, some idle, others with spiky traffic or without persistent connections, this setup gets you a real production app with an endpoint to receive requests that'll cost you nothing until someone actually uses it! So, what are you going to build with it?!

Avoid these mistakes when using Terraform with S3 backend

Lucas Tonelli — Tue, 15 Sep 2026 13:00:00 +0000

Using an S3 backend for Terraform is a popular choice because it's cheap, reliable and widely understood. However, it's pretty easy to configure the bare minimum and move on, forgetting three small things that, in the long run, will very likely make someone's life miserable.

Table for locking

Without a lock table, two engineers (or two CI/CD pipelines) can run terraform apply at the same time, both reading the same state, and then both writing conflicting results back. It can corrupt your state file silently, leaving your real infrastructure, and the recorded state, permanently out of sync and you rethinking your life choices.

Adding a DynamoDB lock table

resource "aws_dynamodb_table" "tf_lock" {
  name         = "terraform-state-lock"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

terraform {
  backend "s3" {
    bucket         = "my-tf-state"
    key            = "terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}

Versioning S3 bucket

Your state file is not code, it's a live record of everything Terraform believes about your infrastructure (that's a beautiful quote). Without versioning, a bad apply, a manual edit or an accidental terraform state rm overwrites the state with no way back. Enabling versioning keeps a full history of every state revision, turning recovery from a crisis into a five-minute rollback instead of a life of suffering.

Enabling versioning on the state bucket

resource "aws_s3_bucket" "tf_state" {
  bucket = "my-tf-state"
}

resource "aws_s3_bucket_versioning" "tf_state" {
  bucket = aws_s3_bucket.tf_state.id

  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_lifecycle_configuration" "tf_state" {
  bucket = aws_s3_bucket.tf_state.id

  rule {
    id     = "expire-old-versions"
    status = "Enabled"
    noncurrent_version_expiration {
      noncurrent_days = 90
    }
  }
}

It's worth having a lifecycle rule to keep storage costs in check, in cases where there are a lot of changes.

Enabling cross-region bucket replication

While it's rare for an AWS region to go down, when it does, your S3 bucket goes with it. If your state file is only in one region, you can't run Terraform at all during the outage, even to fix the very infrastructure that's affected. Cross-region replication keeps a live copy of every state version in a second region so your operations don't have a single geographic point of failure. Also, for the paranoid ones, if you want to add to the already humongous durability of S3 objects, having another region is a way to do that.

Replicating state to a second region

resource "aws_s3_bucket" "tf_state_replica" {
  bucket   = "my-tf-state-replica"
  provider = aws.us_west_2 # Secondary region
}

resource "aws_s3_bucket_versioning" "tf_state_replica" {
  bucket   = aws_s3_bucket.tf_state_replica.id
  provider = aws.us_west_2

  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_replication_configuration" "tf_state" {
  bucket = aws_s3_bucket.tf_state.id
  role   = aws_iam_role.replication.arn

  rule {
    id     = "replicate-state"
    status = "Enabled"
    destination {
      bucket             = aws_s3_bucket.tf_state_replica.arn
      storage_class      = "STANDARD"
      replica_kms_key_id = aws_kms_key.replica.arn
    }
  }
}

Replication requires versioning enabled on both source and destination buckets.

Wrap-up

These three settings are pretty quick to set up and they help mitigating a class of incidents that make software engineers wake up at 3 am. So, ensure you're locking, versioning and replicating your state - sleep tight.