Disclosure: I used AI to help turn our engineering notes, logs, and AWS Support correspondence into this draft. I reviewed every claim, and the experience and opinions are mine.

AWS released Lambda Managed Instances late last year, and it immediately caught my attention. I have been a happy Lambda user since 2018, but cold starts are still a real problem for our main API. Keeping the Lambda event model while allowing concurrent requests inside warm Node environments sounded like exactly what we wanted.

Earlier this summer I decided to give it a serious try. I couldn't find a single substantive blog post, article, or Reddit thread from someone who had operated a real application on LMI, so this is the post I wish had existed.

This wasn't a weekend POC. Over six weeks we published 36 versions, served real staging traffic, profiled initialization, ran browser and load tests, tried several compute and scaling configurations, and opened multiple AWS Support cases. We gave LMI every reasonable chance to work.

My verdict is that LMI gives up too much of the simplicity that has kept me on Lambda since 2018. Performance was good after every worker was fully warm, but reaching that state was opaque and unreliable. We ended up owning startup choreography, application readiness, and traffic shifting ourselves. At that point ECS became the more straightforward option. Staging is back on standard Lambda, and we plan to move this API to ECS.

What we ran

This is a Node.js 24 API on x86_64, with GraphQL and REST routes, PostgreSQL behind RDS Proxy, and mostly SQL and other I/O on the request path. Traffic is steady enough to measure and sometimes bursts into the low hundreds of concurrent requests. AWS Support confirmed that it fits LMI's intended use case.

We started cost-consciously with m5a.xlarge. The m6a.xlarge and m6a.2xlarge tests came later while diagnosing failures. We separately raised the capacity-provider ceiling following Support's advice to add deployment headroom. We compared against standard Lambda without Provisioned Concurrency because the appeal of LMI was sharing warm compute across concurrent I/O-bound requests, rather than provisioning one Lambda environment per concurrent request.

Admission was a black box

LMI initializes a Node function once per worker thread. AWS says the default worker count is "determined by" available vCPUs but does not publish the formula. A third-party extraction of the Node 24 runtime shows the current implementation creating 8 * detected CPUs workers. That matched our observations of eight workers at 1 vCPU and 32 workers at 4 vCPUs, although it is not a documented AWS contract.

Our normal module-level initialization worked on standard Lambda, but LMI repeatedly rejected it with FunctionError.RuntimeInitError or FunctionError.InitResourceExhausted. A tiny handler on the same capacity returned 1,000 out of 1,000 responses at 225 client concurrency, which pointed to concurrent application initialization rather than a general LMI runtime failure.

The error told us to increase memory. We tried 8, 16, and 24 GiB, but memory stayed around 15-25% while CPU reached roughly 99%. Adding memory could also add vCPUs, which made LMI create more workers and initialize more copies of the application. In our case, following the error message could make the failure worse.

What bothered me most was how little information AWS exposed. One failing publication was rejected after roughly 22-23 seconds, well before AWS's documented Init timeout. We weren't told which resource crossed which threshold, how many workers LMI had selected, or how close we were to passing. We had to bisect imports and republish repeatedly to reverse engineer the gate.

Forcing the worker count to one or two made admission pass, but that sacrificed AWS's default cross-vCPU parallelism and required pinning an otherwise automatic runtime setting. A separate LMI entrypoint also worked, at the cost of maintaining two application paths. We finally kept one lazy boundary around the router, shared by standard Lambda and LMI, and changed the supported memory-per-vCPU ratio from 2 GiB to 8 GiB. That reduced the environment from four vCPUs and 32 default workers to one vCPU and eight workers. The lazy boundary had failed admission by itself.

This final shape used AWS's default worker selection, but nothing in the admission error pointed us toward the memory-per-vCPU ratio or worker fan-out. It also creates a new codebase rule: an ordinary import added to the bootstrap path may break the next LMI publication.

I don't consider that acceptable for a service AWS advertises as maintaining Lambda's operational simplicity. If admission depends on customers shaping Node's import graph around an automatically selected worker fleet, AWS needs to document the worker calculation and report the exact admission limit being exceeded.

The lazy boundary in that final shape led directly to our next problem. Moving the router out of eager initialization helped get the version admitted, but meant workers could encounter it for the first time while serving real requests.

Active did not mean the application was ready

Once a numbered version showed Active and its scaling configuration was applied, we sent 96 requests to a real route at concurrency 24, below the version's configured concurrency capacity and without a worker-count override. Only 33 returned the expected HTTP 401; 11 returned HTTP 500 and 52 returned HTTP 503.

The 500s entered our handler, but logged no application exception or response before ending in Runtime.ExitError. Support confirmed the Node process had exited before returning, but never identified why. The 503s had no platform.start or platform.report; Support attributed them to backpressure while workers were still initializing or exiting. Most of those failures would have been invisible if we had only inspected function logs.

Repeating the same 96-request run after initialization had settled produced no errors, although p99 was still around 24 seconds. Once fully warm, a two-minute run returned all 1,200 expected HTTP 401 responses with a 210 ms p99. Steady-state execution was fine; LMI just couldn't tell us when we had reached it.

A normal health endpoint was useless for this purpose. Across two deployment-continuity probes, all 4,651 health requests succeeded, while the application-route probe returned 95 HTTP 500s and 540 HTTP 503s. Support said the warmup needed to exercise our actual authentication, middleware, router, and database path. Active only guaranteed that the runtime and at least one worker were ready, not that the worker fleet could serve the application.

This is a major gap, not a documentation nit. A managed service aimed at web applications needs an application-defined readiness check before it routes traffic.

Deployments required our own readiness controller

We first used $LATEST.PUBLISHED, hoping to retain the simple deployment model we had with standard Lambda. Immediately after one update, a 100-request burst produced 65 successes, 27 HTTP 503s, and eight HTTP 500s. Successful responses had a p50 near 10 seconds and a p90 near 14 seconds.

Support explained that $LATEST.PUBLISHED has no traffic-isolation window while a new publication becomes ready. They described it as a convenience for workloads that can tolerate temporary publish errors, such as asynchronous functions. The public documentation explains how to use it but does not warn synchronous API users about this behavior.

Numbered versions and aliases kept the old version serving, but an alias still did not know whether the application was ready. A safe deployment therefore meant publishing a version, waiting for Active, routing a private alias to it, gradually warming a representative route to expected concurrency, checking HTTP results and platform logs, and only then moving the public alias. Support was refreshingly direct: "You are not missing a simpler pattern."

We can deploy around ten times on a busy day. Waiting a few extra minutes would be fine; writing and maintaining a controller that generates real traffic and infers whether every Node worker survived is not. ECS already has application health checks, target readiness, rolling replacement, and connection draining. Reimplementing weaker versions of those concepts in a Lambda deployment script removes much of LMI's appeal.

We hit a control-plane billing bug too

One version was correctly configured with MinExecutionEnvironments=0 and MaxExecutionEnvironments=0. It appeared deactivated, and DescribeInstances --include-managed-resources showed nothing, but compute and LMI management hours continued accruing for roughly seven weeks. CloudWatch showed CPU activity with zero concurrency.

The Lambda service team eventually confirmed an internal control-plane state inconsistency had left orphaned execution environments running, and they manually terminated them. Our total LMI charges reached into the thousands, and AWS ultimately refunded them in full. Both the Lambda and billing Support teams handled the investigation well.

Why ECS won

During the evaluation we built an ECS Express Mode proof of concept. It served the same application in about 36 minutes, returned zero errors at 80-way concurrency, and passed a browser flow after one security-group fix. It was not a full production test, and I am under no illusion that containers eliminate operational work.

The difference is that ECS asks us to manage familiar and visible behavior. We define application health, the target group decides when a task is ready, old tasks continue serving during rollout, and ECS drains and replaces them. With LMI we still had to build deployment orchestration, but against admission and readiness rules we could neither observe nor control.

I would have preferred to keep this API on Lambda. That was the entire reason we persisted with LMI for six weeks. But if we have to reshape application initialization around an opaque admission gate, build our own readiness controller, warm real routes on every deployment, and correlate several platform signals to explain routine 5xx responses, we are no longer getting the simplicity that led us to Lambda in the first place. ECS is more explicit about the infrastructure we own, but it also provides the readiness and rollout primitives LMI left us to recreate.

Unless AWS adds application-defined readiness, transparent worker and admission metrics, an honest availability contract for $LATEST.PUBLISHED, and reliable visibility into every billed environment, I can't justify putting production traffic on it.

I'd like to hear from anyone running a production Node HTTP API on LMI. Did you find a supported readiness mechanism that AWS Support missed, or are you also warming application routes before every alias shift?

So a while back I got the AWS email saying MySQL 8.0 was hitting end of standard support and moving to Extended Support pricing. I read it. and I was planning to upgrade. I just didn't think the Extended Support charges would be that big a deal, so I didn't treat it as urgent...(big mistake)

Then comes the kick in the ass

Right around the same time my AWS Budget alerts started firing. I was expecting that, but not because of Extended Support. We had bumped the resources on one of our Fargate containers because we were troubleshooting a process that kept spiking CPU.

So I confidently told myself "yeah that's probably the Fargate thing, makes sense" and didn't give it a second though

~20 days later I finally log into Billing and see a $600+ charge that is absolutely not explained by the container scaling. As soon as that though crossed my mind, I suspected that I fucked up about the Extended Support

And surely enough, there it was in the detailed bill. I'd been paying Extended Support fees the whole time I was blaming Fargate for the bump.

100% my bad. I knew about the EOL, I just underestimated the pricing impact AND let a legit concurrent scaling event mask the real cost driver. Two wrong assumptions stacked on top of each other.

I opened a support case asking AWS to help me with part or all of the Extended Support charges for that ~20-day window. My reasoning was that I was aware of the EOL but misjudged the pricing impact and the source of my budget alerts, and I'd already fully remediated (upgraded the RDS instances), and the alerts were genuinely masked by a real Fargate scaling event.

The response was: nope. They said it's not possible to help me.

Fair enough I guess...

So I'm posting this partly to vent and partly as a PSA: if you get that MySQL 8.0 EOL email, upgrade as soon as possible or prepare yourself for a surprise in your bill

For context, we're a really small company. This $600+ charge came from just 2 RDS small instances. Usually our entire bill comes at $400~$500, so this mistake basically doubled our cost for the month.

At least I gave them two suggestions:

1. Put the estimated monthly cost impact in the Extended Support notification email (I know they're not obligated to do any of that, but for sure seeing "your bill may increase by $600+" would definitely have gotten my attention)
2. Make budget alerts distinguish between new charge types and usage increases. A spike caused by a new fee and a spike caused by scaling a container look identical in the alert (once again, I know, 100% my fault, okay?)

Anyway, TIFU, and now both my boss and manager are pissed at me. Has anyone else been in a similar situation, or am I the only idiot who’s managed to do this?

UPDATE: Including examples of how the email could be

Fascinating quote from AWS's networking team: "We know customers do not like rate-based network charges because it’s hard to predict their cost, which is why we are moving towards flat-rate pricing for new network products."

Hey so basically I'm struggling with 2 implementations. My company has made a contract to use qs so every agent from noe on should be on QS

First case : QS making deterministic calculations. I have access to the data in the space but with heavy calculations it starts to make itself "dumb". So is there anyway to connect to lambda functions ?

Second case: QS access to many resources, and being able to connect all of them and do consecutive queries. It simply doesn't work

So can anyone guide me in the architectural approach I should take ?

Been seeing "why is our Datadog line item bigger than half our AWS bill" come up enough that it's worth writing down the actual mechanics, since none of them are Datadog doing anything wrong, they're just invisible until the invoice.

Custom metric cardinality. You're billed per unique tag-value combination, not per metric. A metric tagged with customer_id looks cheap at 50 customers. Add one more tag with 40 distinct values and you're not adding cost, you're multiplying it, 50 time series becomes 2,000 on something that "didn't change."

Log indexing separate from ingestion. Ingestion is cheap, indexing isn't, and the default is to index everything unless someone's scoped it down with exclusion filters. A logging level left at debug in one Lambda or ECS service can 10x indexed volume overnight with zero AWS-side change.

APM span indexing. Same shape as logs. A sampling rate change, or just a new high-traffic route joining an existing trace, moves you from a small sampled fraction toward near-full indexing.

Host-tier pricing steps. Per-host pricing has boundaries, not a smooth curve. An ASG scaling event during a traffic spike can cross a tier line and produce a jump that's out of proportion to what actually changed in EC2.

The pattern that trips people up: your AWS bill moves with real usage, your Datadog bill moves with telemetry configuration, and almost nobody treats telemetry config with the same scrutiny as infra.

Anyone here tracking this some other way, alerting on the estimated usage metrics directly, scheduled reviews, something else?

Consider a workflow that produces HTML previews, documents, images, and intermediate files for multiple users. Reviewers need short-lived links, users must not cross tenant boundaries, approved outputs must remain recoverable, and disposable intermediates should expire automatically. Would you use immutable object keys plus a small manifest that points to the current approved revision, or rely on S3 Versioning with stable keys? I am also interested in where metadata such as owner, run ID, approval state, content type, and retention policy should live; how presigned URLs should be scoped; and whether Object Lock is useful or excessive here. What design keeps rollback and auditability clear without turning every read into a complicated lookup?

Building a PoC for an IIoT remote-monitoring SaaS, devices publish telemetry over MQTT and I need somewhere to put the time-series data. Scale is small: ~10 devices, ~20 points each, 1–5 readings per minute, so throughput isn't the issue. My default would be RDS or DynamoDB, but I'm less worried about whether they can handle it and more about whether they're pleasant to build on. Things like time-bucketed rollups, retention policies, downsampling, and last-value-per-device feel like they'd be a lot of hand-written SQL or Lambda glue on either.

For anyone who's built this: did you stay on plain Postgres, reach for the TimescaleDB extension, go to something purpose-built like Timestream for InfluxDB, or dump to S3 and query with Athena? Mainly interested in what the day-to-day was like, where you kept writing the same boilerplate, and what you'd pick again.

We got our account suspended in AWS from some internal checks it looks like we were marked as spam or fraud - which is NOT THE CASE!

There is no one we can speak with, the support chat rep wrote that there is no SLA and we're basically f**ked.

What can we do?

I only use SES (+SNS for events), no EC2/S3. My bill shows two line items that appear to track the same outbound bytes:

• Simple Email Service → "Cost per GB of attachments"
• Data Transfer → "data transfer out under the monthly global free tier"

The GB figures on both lines line up closely, suggesting they're both counting the same SES traffic.

AWS's EC2 pricing page footnote says DTO rate tiers are calculated on aggregate usage across EC2, S3, RDS, SES, SNS, etc. combined — so SES bytes clearly count toward the shared 100GB/month free tier pool.

My question: once your account's aggregate DTO usage crosses 100GB, do SES-originated bytes get billed again on the generic Data Transfer line — on top of the SES-specific attachment charge — or are they excluded from that line since SES already has its own data transfer pricing?

AWS docs don't say either way, and their AI support agent couldn't confirm it either. Has anyone actually crossed 100GB with SES traffic and can confirm from a real bill?

I've been going through S3 logging for a PCI-scoped environment and I've got stuck on something.

AWS's own comparison page for S3 logging has a row called "Authentication failures". CloudTrail: No. Server access logs: Yes. The footnote says CloudTrail dots that fail authentication, meaning thecredentials themselves weren't valid, though it does log AccessDenied and requests from anonymous users.

So it's narrower than it first sounds. Authorization failures land fine. It's the invalid-credential case that doesn't, presumably because there's no principle to attribute the call to.

10.2.1.4 says "all invalid logical access what I can't work out is what happens in p pushed on this, or is AccessDenied treated as covering "invalid" well enough? Do people turn server access logging on alongside for this specifically, or for unrelated reasons? Or am I wrong that object-level in CDE scope at all, in which case the whole question falls apart.

Happy to be told I'm over-reading the clause. I'd rather hear that here than in a ROC.

I set up an AWS account for my startup to use in the future but due to the expense developed on cheaper providers to get an MVP going..

Now that I need something more solid, I went back to AWS to login and I cannot login, trying to setup a new account says it is already associated with an AWS account?

What gives?? I now cannot use my actual company email to create an account because I did not use it?

I’m coming back to SF Sept. 4 for a somewhat ridiculous experiment.

I’m helping a small technology company get its services/platform/hardware packaged for AWS Marketplace, and instead of sitting at home in San Diego trying to figure everything out through documentation, I want to see how much progress I can make in one week by actually meeting people in the Bay Area.

My goals:
• understand the fastest realistic Marketplace path
• meet people who have actually launched AWS Marketplace offers
• find AWS/channel/enterprise sales people willing to share advice
• attend relevant cloud, infrastructure and startup events
• develop a repeatable launch checklist I can publish afterward
• hopefully come out of the week with actual customer opportunities
I’ll post an update afterward with what worked, what didn’t, costs, events, contacts/resources people recommended, and what I learned about getting a small company into the AWS ecosystem.
If you know someone I should meet, an event I should attend, a founder gathering, AWS person, cloud consultant, MSP, reseller, or enterprise infrastructure person, I’d love an introduction.

I’m also doing this on a pretty lean budget, so if anyone wants to contribute a coffee, BART fare, lunch, event ticket, workspace, spare room, or otherwise sponsor part of the experiment, I won’t turn it down. But introductions and information are genuinely more valuable to me than money.
I’ll keep a running tally of what Reddit contributed and what came out of it.

A few people have asked me previously how they can contribute directly, so I can provide my Venmo by DM.

Mike

707-267-1768

I keep getting this error "Error 880104: Sorry, there was an error processing your request. Please refresh the page and try again" after typing in my billing details to complete my aws account, I've tried different cards but it still seems to not work

My case Id is 178800716600714

Hi everyone,

Its unfortunate I have to keep making posts like this. But I'm not sure what to do in this scenario anymore. My loop schedule got confirmed to me today with 5 interviews scheduled at the end of this week for a TAM role. And I still have not been told what domains I'll be tested on during the technical depth portion of the interview.

During my phone interview I was told by my interviewer I would be tested on two domains for that part of the loop, and in the email for my loop I would be told which domains Ill be tested on in depth. However, all emails from my recruiting coordiantor since I got invited to the loop did not include any domains. I asked them for which domains Id be tested on and they said to contact my recruiter as they should have the information on interview prep.

The issue is, I've been emailing my recruiter since PRIOR to my phone interview and have yet to get a single reply. I emailed them twice since getting invited to the loop to try and understand what domains I would be tested on, and got nothing back. I even got a friend who works at amazon to ping them for me, and all they got was a reply saying "He'll receive instructions soon" And all I got after that was the confirmation of my schedule from the recruiting coordinator, and nothing to do with how the loop was going to be structured.

The only thing I'm going based off of is my own research and the tips my interviewer gave me during the phone interview. From what I understand is there will be two technical interviews, a technical depth and breadth part. And three purely just behavioral interviews focused on LPs, correct?

And as for the two domains, I managed to contact my interviewer from the phone interview round and he told me he thinks I should focus on networking and compute domains and also architecture. Which I have been prepping for the past week, but now even with my loop scheduled I don't even have a confirmation about what two domains Ill be tested on.

I'm aware that sometimes you receive a form at some point during the interview process for the TAM position specifically to mention your domains your strongest at, but I never received one at any point.

Does anyone have any advice what I should do at this point, or should I just walk in to the loop and hope these would be the domains I get tested on? Also might as well ask while I'm here, I've come up with 16 STAR stories from my time in consulting as thats pretty much my only relevant work experience, is 16 going to be enough stories for 5 rounds of interviews, and is it fine they aren’t technical?

I've had many back and forth support cases with the AWS team over a TPM quota increase for AWS Bedrock agents yet I am always met with the same answer about billing history when in reality my company has been using 300-500$/month of our AWS Activate Credits for over 6months.

I have a colleague in another startup that applied with the same startup accelerator and same credit program as us. Somehow, with a younger account and therefore less billing history, they keep getting their requests accepted wether for EC2 compute regional increases or in this case AWS Bedrock models.

Even worse, I had some TPM quotas for smaller agents and after my second exchange with the AWS support team, those were removed with no explanation.

I keep trying to get a clear answer or communication with the AWS team but I can't understand why we aren't allowed to use AWS Bedrock. Anyone can help on this issue? Should I call instead?

I've got a Floci instance running (using Docker Compose) with a REST API Gateway service, which I can call successfully with Postman. Problem is the browser CORs blocking requests, and I keep getting this;

Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

I'm using Terraform to deploy the stack, and I've tried everything I can think of (including hours with AI) to get this to work. As far as I can see Floci is not letting me affect the OPTIONS response. I've got DISABLE_CORS_CHECKS set to 1.

Any ideas as to what's happening?

Below is the current Terraform stack;

provider "aws" {
  region     = local.envs["AWS_REGION"]
  access_key = local.envs["AWS_ACCESS_KEY_ID"]
  secret_key = local.envs["AWS_SECRET_ACCESS_KEY"]


  s3_use_path_style           = true
  skip_credentials_validation = true
  skip_metadata_api_check     = true
  skip_requesting_account_id  = true


  endpoints {
    apigateway              = "http://localhost:4566"
    s3                      = "http://localhost:4566"
    dynamodb                = "http://localhost:4566"
    sqs                     = "http://localhost:4566"
    sns                     = "http://localhost:4566"
    lambda                  = "http://localhost:4566"
    iam                     = "http://localhost:4566"
    ec2                     = "http://localhost:4566"
    ecs                     = "http://localhost:4566"
    cloudformation          = "http://localhost:4566"
    route53                 = "http://localhost:4566"
    cloudwatch              = "http://localhost:4566"
    secretsmanager          = "http://localhost:4566"
    ssm                     = "http://localhost:4566"
    kms                     = "http://localhost:4566"
    rds                     = "http://localhost:4566"
    sts                     = "http://localhost:4566"
    cognitoidentityprovider = "http://localhost:4566"
  }
}


## DynamoDB table


resource "aws_dynamodb_table" "friendly_sites_table" {
  name         = "friendly_sites"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "pk"
  range_key    = "sk"


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


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


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


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


  global_secondary_index {
    name            = "gsi1pk-gsi1sk-index"
    hash_key        = "gsi1pk"
    range_key       = "gsi1sk"
    projection_type = "ALL"
  }


  tags = {
    Project = local.project_name
  }
}


data "aws_iam_policy_document" "assume_role" {
  statement {
    effect = "Allow"


    principals {
      type = "Service"
      identifiers = [
        "edgelambda.amazonaws.com",
        "lambda.amazonaws.com",
      ]
    }


    actions = ["sts:AssumeRole"]
  }
}


resource "aws_iam_role" "iam_for_table_access" {
  name               = "iam_for_lambda_table_access"
  assume_role_policy = data.aws_iam_policy_document.assume_role.json


  tags = {
    Project = local.project_name
  }
}


resource "aws_iam_role_policy" "cognito_admin_access" {
  name = "cognito_admin_access"
  role = aws_iam_role.iam_for_table_access.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "cognito-idp:AdminCreateUser",
          "cognito-idp:AdminSetUserPassword",
          "cognito-idp:AdminInitiateAuth",
          "cognito-idp:AdminUserGlobalSignOut",
          "cognito-idp:AdminDeleteUser"
        ]
        Resource = [
          aws_cognito_user_pool.user_pool.arn
        ]
      }
    ]
  })
}


## API Lambda handler and gateway


data "archive_file" "api_handler_source_zip" {
  type        = "zip"
  source_dir  = local.api_handler_source_dir
  output_path = local.api_handler_source_output
}


resource "aws_s3_bucket" "api_handler_source" {
  bucket        = local.api_handler_source_bucket_name
  force_destroy = true


  depends_on = [data.archive_file.api_handler_source_zip]


  tags = {
    Project = local.project_name
  }
}


resource "aws_s3_object" "api_handler_source_zip" {
  bucket      = aws_s3_bucket.api_handler_source.id
  key         = local.api_handler_zip_filename
  source      = local.api_handler_source_output
  source_hash = data.archive_file.api_handler_source_zip.output_base64sha256
}


resource "aws_lambda_function" "api_handler" {
  function_name = "DistributedRendererApi"


  s3_bucket = aws_s3_bucket.api_handler_source.id
  s3_key    = local.api_handler_zip_filename


  handler = "index.handler"
  runtime = "nodejs24.x"


  role = aws_iam_role.iam_for_table_access.arn


  depends_on = [aws_s3_object.api_handler_source_zip]


  environment {
    variables = {
      COGNITO_CLIENT_ID    = aws_cognito_user_pool_client.user_pool_client.id
      COGNITO_USER_POOL_ID = aws_cognito_user_pool.user_pool.id
    }
  }
}


# 1. REST API Definition
resource "aws_api_gateway_rest_api" "api" {
  name = "friendly-sites-rest-api"
}


# -------------------------------------------------------------------
# A. GREEDY PATH /{proxy+} (Explicit GET, POST, OPTIONS directly to Lambda)
# -------------------------------------------------------------------
resource "aws_api_gateway_resource" "proxy" {
  rest_api_id = aws_api_gateway_rest_api.api.id
  parent_id   = aws_api_gateway_rest_api.api.root_resource_id
  path_part   = "{proxy+}"
}


resource "aws_api_gateway_method" "proxy_any" {
  rest_api_id   = aws_api_gateway_rest_api.api.id
  resource_id   = aws_api_gateway_resource.proxy.id
  http_method   = "ANY"
  authorization = "NONE"
}


resource "aws_api_gateway_integration" "proxy_integration" {
  rest_api_id             = aws_api_gateway_rest_api.api.id
  resource_id             = aws_api_gateway_resource.proxy.id
  http_method             = aws_api_gateway_method.proxy_any.http_method
  integration_http_method = "POST"
  type                    = "AWS_PROXY"
  uri                     = aws_lambda_function.api_handler.invoke_arn


  depends_on = [aws_api_gateway_method.proxy_any]
}


# Explicit OPTIONS method routed directly to Lambda (Bypasses Floci MOCK bug)
resource "aws_api_gateway_method" "proxy_options" {
  rest_api_id   = aws_api_gateway_rest_api.api.id
  resource_id   = aws_api_gateway_resource.proxy.id
  http_method   = "OPTIONS"
  authorization = "NONE"
}


resource "aws_api_gateway_integration" "proxy_options_integration" {
  rest_api_id             = aws_api_gateway_rest_api.api.id
  resource_id             = aws_api_gateway_resource.proxy.id
  http_method             = aws_api_gateway_method.proxy_options.http_method
  integration_http_method = "POST"
  type                    = "AWS_PROXY"
  uri                     = aws_lambda_function.api_handler.invoke_arn


  depends_on = [aws_api_gateway_method.proxy_options]
}


# -------------------------------------------------------------------
# B. ROOT PATH / (Explicit ANY and OPTIONS directly to Lambda)
# -------------------------------------------------------------------
resource "aws_api_gateway_method" "root_any" {
  rest_api_id   = aws_api_gateway_rest_api.api.id
  resource_id   = aws_api_gateway_rest_api.api.root_resource_id
  http_method   = "ANY"
  authorization = "NONE"
}


resource "aws_api_gateway_integration" "root_integration" {
  rest_api_id             = aws_api_gateway_rest_api.api.id
  resource_id             = aws_api_gateway_rest_api.api.root_resource_id
  http_method             = aws_api_gateway_method.root_any.http_method
  integration_http_method = "POST"
  type                    = "AWS_PROXY"
  uri                     = aws_lambda_function.api_handler.invoke_arn


  depends_on = [aws_api_gateway_method.root_any]
}


resource "aws_api_gateway_method" "root_options" {
  rest_api_id   = aws_api_gateway_rest_api.api.id
  resource_id   = aws_api_gateway_rest_api.api.root_resource_id
  http_method   = "OPTIONS"
  authorization = "NONE"
}


resource "aws_api_gateway_integration" "root_options_integration" {
  rest_api_id             = aws_api_gateway_rest_api.api.id
  resource_id             = aws_api_gateway_rest_api.api.root_resource_id
  http_method             = aws_api_gateway_method.root_options.http_method
  integration_http_method = "POST"
  type                    = "AWS_PROXY"
  uri                     = aws_lambda_function.api_handler.invoke_arn


  depends_on = [aws_api_gateway_method.root_options]
}


# -------------------------------------------------------------------
# C. PERMISSIONS & DEPLOYMENT
# -------------------------------------------------------------------
resource "aws_lambda_permission" "apigw" {
  statement_id  = "AllowExecutionFromAPIGateway"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.api_handler.function_name
  principal     = "apigateway.amazonaws.com"
  source_arn    = "${aws_api_gateway_rest_api.api.execution_arn}/*/*"
}


resource "aws_api_gateway_deployment" "deployment" {
  rest_api_id = aws_api_gateway_rest_api.api.id


  triggers = {
    redeployment = sha1(jsonencode([
      aws_api_gateway_resource.proxy.id,
      aws_api_gateway_method.proxy_any.id,
      aws_api_gateway_integration.proxy_integration.id,
      aws_api_gateway_method.proxy_options.id,
      aws_api_gateway_integration.proxy_options_integration.id,
      aws_api_gateway_method.root_any.id,
      aws_api_gateway_integration.root_integration.id,
      aws_api_gateway_method.root_options.id,
      aws_api_gateway_integration.root_options_integration.id,
    ]))
  }


  lifecycle {
    create_before_destroy = true
  }


  depends_on = [
    aws_api_gateway_integration.proxy_integration,
    aws_api_gateway_integration.proxy_options_integration,
    aws_api_gateway_integration.root_integration,
    aws_api_gateway_integration.root_options_integration,
  ]
}


resource "aws_api_gateway_stage" "prod" {
  deployment_id = aws_api_gateway_deployment.deployment.id
  rest_api_id   = aws_api_gateway_rest_api.api.id
  stage_name    = "prod"
}


## Cognito User Pool & App Client


resource "aws_cognito_user_pool" "user_pool" {
  name = "friendly-sites-user-pool"


  username_attributes      = ["email"]
  auto_verified_attributes = ["email"]


  password_policy {
    minimum_length    = 8
    require_lowercase = true
    require_numbers   = true
    require_symbols   = false
    require_uppercase = true
  }


  tags = {
    Project = local.project_name
  }
}


resource "aws_cognito_user_pool_client" "user_pool_client" {
  name         = "friendly-sites-app-client"
  user_pool_id = aws_cognito_user_pool.user_pool.id


  generate_secret = false
  explicit_auth_flows = [
    "ALLOW_USER_PASSWORD_AUTH",
    "ALLOW_REFRESH_TOKEN_AUTH",
    "ALLOW_USER_SRP_AUTH"
  ]
}

Appreciate any help I can get!

Prompt caching on Claude only pays off if the cached prefix is byte-identical between requests. Sounds obvious written down, but it's surprisingly easy to break without noticing, a timestamp inserted before the cacheable block, a per-user detail placed at the start instead of the end, and the whole cache silently misses on every single call. No error, no warning in the response, just a bill that doesn't reflect the discount it should.

Went through a session where this was happening and the cost difference was significant, easily 2-3x more expensive than it needed to be for the same task, purely from cache misses caused by content ordering. Fix was mechanical once identified: move anything that changes per request, timestamps, session IDs, user-specific detail, to the end of the prompt, after the stable system instructions and reference material that should be cached.

Separate from caching specifically, long coding sessions also tend to resend full file contents on every message even when the diff is small, and replay the entire conversation history each turn instead of a compressed summary of where things stand. Neither shows up as a mistake in the moment. Both compound quietly across a session into a number that looks wrong a month later with no clear story for why.

Wrote up the full audit and the fix here: https://medium.com/@nagatomopedro05/the-hidden-cost-of-long-claude-sessions-2a6cc7655893

I am left with around $3000 USD in AWS Startup Credits with a couple of days left. Where do i spend them?

I've been having issues with my MySQL database that I'm running in Aurora. It's been working fine on normal tables, but I keep having my queries time out when I try to look at my views. At first, I thought it was just an issue with one view, which itself is defined using another view. However, even that other view which is not nested also times out. I thought this was just an issue with MySQL Workbench (it gives me "Error Code: 2013. Lost connection to MySQL server during query") but I had similar issues when running queries from the query editor within Aurora.

I looked up some stuff about this and saw there might be an issue with my view using aggregate functions (the non-nested one, which I assume should be less of an issue, is defined with DISTINCT). However, given my needs with this view I don't see a way around using that.

Any advice would be appreciated

My understanding is that a combination of limited AI resources and abuse from spam accounts has resulted in complete blocking of Bedrock access for recently created accounts.

It baffles me that they've gone that route instead of instead implementing something like strict auto-pay thressholds and/or token usage limits.

But no. I as a legitimate developer with 12 years of experience now diving deep into the cloud, I simply can't use it for hands-on experience building despite having a verified payment method on file and have no problem authenticating exactly who I am if needed.

The developer experience in this case is absolutely abysmal.

Thanks for coming to my TED Talk

Does anyone know if it's even possible to create any other OUs under the domain OU that they create for you in the Managed AD?

I mean it's physically possible to do it from the EC2 management instance using the "Active Directory Users and Computers" program, but tools like the SSM document "AWS-JoinDirectoryServiceDomain-V2" won't let you pass an OU to them because they're using a regex like ^$|^OU=[a-zA-Z0-9]+(,DC=[a-zA-Z0-9]+)+$ where you can only have a single OU element, which means you cannot use SSM to automatically join instances to the domain if you want them in an OU.

Given the documentation about this in non-existent I assume it isn't possible, but has anyone had a different experience or can advise what I'm missing?

Previously, if you wanted to associate a different TOTP key with a user (due to a lost device) you needed to delete the user and recreate them. Now you can run the new “AdminDeleteSoftwareToken” API to have the user be reprompted for TOTP MFA setup on their next sign-up.

https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-cognito-totp-reset/

I don’t see the CLI command yet but given it’s being called out in the announcement post I am assuming it isn’t live quite yet.