Just logged onto AWS Skills Builder like a minute ago, and within 20 seconds my uBlock Origin Lite blocked 181 ads/trackers. I'm not familiar with this side of tech to find out what it is about me that's being tracked by Skills Builder.

A single YouTube video has 27 ads/trackers blocked. Reddit has 25 so far as I'm writing. Skills Builder? Last I looked, it's up to 194 now.

OpenAI, Cursor, all down

Anyone brave enough to try it out?

• public.ecr.aws/amazonlinux/amazonlinux:2027.0.20260903.0-minimal
• public.ecr.aws/amazonlinux/amazonlinux:2027.0.20260903.0

We get a lovely

It's not you, it's us
We couldn't complete your request right now. Please try again later.

On our login page: https://us-east-1.signin.aws

The problem is I've been working on deploying a certificate authority in our environment.

It's an offline ROOTCA with two Issuing CAs.

They've been stood up, but we haven't started issuing certificates. They were stood up this week and everything has been fine for the past 2 days.

I log in today and find that certificates have been issued to the domain controllers, but they weren't being put into the Personal certificate stores.

The root CA was published and same with the issuing CA certificates. Those were appearing in the trusted stores.

I'm afraid I broke this and I need to figure out how to fix it.

I thought it was ldap not being encrypted so I got the certificates to the domain controllers and now ldap is encrypted. It was working unencrypted already, but now it's working encrypted.

Some additional information:

We are using our active directory to log into the the aws console, so we enter our username, page refresh, then our password, another refresh, we enter our "verification code" and then we get a DUO prompt on our devices.

We are setup through AWS to our domain controllers using directory services.

Any help to fix my fuck up, would be appreciated.

I had three AWS credit grants, all listing the following five as applicable products:

1. Amazon Bedrock
   
2. Amazon Bedrock AgentCore
   
3. Amazon Bedrock Service
   
4. Amazon Bedrock Managed Knowledge Base
   
5. AmazonBedrockFoundationModels
   

I used Bedrock (with Claude Sonnet 4.6/Haiku 4.5) and still got billed. I guess AWS considers its own models as foundation models, and external providers are not covered under credits, but I am unsure.

How can I find out which models are covered under these credits?

Hello all,

I am studying for the AWS SCS-C03 and am failing to understand one of the explanations in the review tests. It is behind a paywall so don't think I can share the actual content here but it asks about security controls for hardening ec2 instances in production.

The options essentially boil down to using a maintained AMI with security controls and configurations then using an SCP to enforce use. Or using Image Builder and AMI ID validation in launch templates.

The correct answer ended up being the image builder + AMI validation to limit Launch templates but from my understanding I would rather sack off the automation in favour of an SCP to stop ec2:* with a launchTemplate condition so then I can't just go to the instance dashboard -> launch ami-whatever right? For additional context, the question does not mention "least operational overhead" it just asks for comprehensive controls

Thought it would be interesting to get others opinions.

Many Thanks :)

Looking for input from people who've actually shipped custom domains for a multi-tenant SaaS, because I want to avoid picking the wrong path and regretting it later.

Current setup:

• Multi-tenant events platform on AWS
• Frontend is a React app — dist folder on S3, served through CloudFront
• Today every tenant gets a platform subdomain (tenant.stage.example.com) via a wildcard cert on CloudFront. Frontend reads the hostname, asks the backend "which event is this?", renders accordingly.
• API calls go to a fixed, separate domain (api.example.com) — so the custom domain is only needed for serving the static frontend, not the API.

What we want:
Clients want to bring their own domains (portal.clientbrand.com) instead of our subdomain. So I need per-domain TLS that issues + renews automatically, with no manual step per client.

Options I'm weighing:

1. CloudFront manual + automation — add each domain as an alternate domain name + ACM cert via a script. Works, but there's the ~100 CNAMEs-per-distribution wall, and one cert per distribution feels fragile at scale.
2. CloudFront SaaS Manager (the multi-tenant distribution thing from 2025) — looks purpose-built for this, up to ~2000 domains, per-tenant ACM. Since we're already on CloudFront this seems like the least-effort path, but I haven't found many real-world reports.
3. Caddy on-demand TLS — reverse proxy that issues certs on first handshake. Unlimited scale, but it's a new component to run/monitor, and I'd need the ask endpoint to avoid getting our Let's Encrypt limits burned by random hostnames.
4. Managed service (Approximated / similar) — lowest effort, but monthly cost + another third party in the traffic path.

Questions:

• For anyone running CloudFront SaaS Manager in production — is it solid? Any gotchas with cert provisioning, DNS validation, or pricing at scale?
• Given our API is already on a fixed domain (custom domain = static content only), is a reverse proxy like Caddy overkill for us?
• Anyone regret going the manual-CloudFront-automation route and wish they'd started with something else?

Expected scale is realistically low-hundreds of custom domains over time, not thousands. Trying to pick something that won't need re-architecting in a year.

Thanks in advance 🙏

I am trying to start a business and built everything on AWS and was really banking on the $200 AWS credits for new accounts to get my business started. As part of setting up everything safely, I set up IAM Identity centre for logins instead of unsafe root logins. And apparently, that internally forms an AWS organization and I’ve forfeited all my remaining credits 😭

I really tried to beg and ask for my credits back and they wouldn’t budge 🥺

I wish AWS gave a warning that my credits would be forfeited if I setup IAM Identity centre which in turn created an org

​

I’m researching whether there is room for another CDN product before I build anything.

This is mainly a question for people with meaningful CloudFront egress — video, images, downloads, large static assets, etc.

Hypothetical offer:

- ~$8/TB delivered

- flat rate worldwide

- no regional pricing

- no large monthly commitment

- broad global CDN footprint

- origin pull / reverse proxy

- custom domains + TLS

- configurable caching + purge API

- raw / near-real-time logs

The network underneath would be an established global CDN provider.

Obviously this isn't trying to beat every possible setup.

If you're doing hundreds of TB or PBs, you can negotiate pricing or architect around egress costs. And Cloudflare/R2/Backblaze-type setups may be dramatically cheaper for some workloads.

I'm trying to find the crossover point.

For people currently spending meaningful money on CloudFront:

At what effective $/TB would you seriously consider moving part of production traffic to another CDN?

And if ~$8/TB is attractive:

Would you actually move 1–5 TB to a pilot before considering a larger migration?

Would also love to know:

- approximate TB/month

- traffic geography

- video vs images/files

- current effective CDN cost

- biggest obstacle to switching away from CloudFront

I'm looking for reasons this wouldn't work as much as reasons it would.

I’ve been working with AWS since 2017. I got DevOps professional certification. I’ve built a few dozen CI/CD pipelines, planned, built and maintained several AWS architecture. Id like to believe I’m quite good at it to be honest.

I’ve also been a software engineer for 16 years. Worked on a handful of multi year successful projects.

Recently I joined a company that builds a platform where our customers don’t need to know or worry about DevOps. They are very niche on a very specific product (the company sells this product and also sells a hosting solution for this product) so it’s not a generic DevOps as a service sort of thing, which can get very tricky very fast. It’s quite repetitive, repeatable. The product requires an Http Server, S3 bucket, Relational database,
Background worker. Nothing exotic or fancy. In fact, if you were to handcraft the AWS infrastructure for one instance of the product it would be quite trivial and simple. Yet, building a platform that does it has been giving me a huge beating for the better part of 1 year. So many things are intertwined, changing one little thing anywhere has side effects far away. Automation testing of a platform that provides you with a CI/CD which builds a docker image for you is extremely convoluted. Overall it’s been a very humbling experience.

I believe there might be tech content somewhere that might help me build a better architecture that is fit for purpose. I’ve read a bit about Control Plane / Cell architecture and I think I’ve implemented it but maybe there is more to the story. Anyway, looking for some terminology, context, guidance on who to follow; what to read, etc

As a long time AWS user (over 15 years) I’m nearing the point of being done. AWS support isn’t support anymore, and getting access to anything requires near TAM level support plans. I don’t think they remember what businesses got them to where they are today (hint: it wasn’t enterprise customers). Access to just about any models via Bedrock is hopeless. I get errors that are about sales, not even quotas, but there is no way to fix it. Support doesn’t answer and when they do it’s automated and irrelevant to what was asked. Mind you, these aren’t even new accounts. No, they don’t spend much, but they have been around for several years in most cases, and the org has been around for at least six years. I don’t get how I am supposed to use it anymore, much less recommend others do so.

I opened an AWS account years ago to play around. I've been billed a small amount each month since (40-50 cents) but have decided I no longer am going to ever use this account for anything. When I try to sign in, I get endless errors, "we identified unusual activity" emails and messages that I have to go through additional security (probably because I haven't used the account in ages). I enter codes, complete captcha's, etc.

I reset the password but keep being told to "switch to the us-east-1 region to sign in", WHICH I AM DOING.

Is there any way to close this account other than either challenging the charge with my credit card company or simply closing the credit card it's attached to?

This is what drives me nuts about using large service providers. You can't ever just get ahold of someone. There's obviously an issue with my account, and I can't start any of my instances. Now my sites are offline for an unknown amount of time. I have no past due balance, there's no weird shit going on with my identity, and more than likely it's just an error on their end. That's fine. Mistakes happen, however... when I can't even get ahold of anyone to resolve that mistake is when it gets incredibly frustrating. The only recourse is to open a support ticket and wait 24 hours for someone to get back to you. All because I don't have a "paid support plan". This is why I like smaller service providers. Ones where you can call, and someone picks up.

It's been over 48 hours and no response from customer support and still unable to progress

Account ID: 057945500197

Case ID: 178821141700682

I’m planning to move an existing production backend from managed Supabase to a self-hosted Supabase deployment on AWS.

The Next.js frontend will remain on Netlify/CDN, so EC2 would only handle the backend.

Current backend workload includes:

• PostgreSQL 17
• Auth + Google OAuth
• PostgREST / RPCs
• Storage API
• Edge/background functions
• scheduled jobs
• remote job ingestion
• AI summary processing
• job alerts
• apply-link validation

The application is mostly read-heavy and public traffic is heavily cached at the CDN layer.

The ingestion workload is also intentionally bounded. It processes one source at a time with concurrency 1 rather than running many ingestion jobs in parallel.

My current plan is:

EC2: t4g.large - 2 vCPU - 8 GB RAM - Graviton / ARM64

Storage: - 60–80 GB gp3 EBS for PostgreSQL - S3 for uploaded/static objects

I’m trying to avoid overprovisioning because this is still an early-stage product.

The alternatives I’m considering are:

t4g.xlarge - 4 vCPU - 16 GB RAM

or moving to an M-series Graviton instance if sustained PostgreSQL/background workloads make burstable T-series instances a poor choice.

For people running PostgreSQL or similar Docker-heavy production workloads on EC2:

Would you start with t4g.large and resize when metrics justify it, or is 2 vCPU / 8 GB too aggressive for a production database + API + workers on the same instance?

I’m particularly interested in:

• T4g CPU credit behavior with PostgreSQL
• whether sustained DB workloads make T-series a bad choice
• real-world memory usage on 8 GB instances
• Graviton/ARM64 reliability for Docker workloads
• gp3 configuration recommendations
• whether m7g is worth the additional cost
• metrics/thresholds you use before resizing
• whether you would separate workers from the DB immediately or keep them together at this scale

I’m aiming for the most cost-efficient architecture that still has enough production headroom, rather than starting with a much larger instance unnecessarily.

Would appreciate real-world EC2 experience rather than theoretical maximum capacity.

Hi everyone,

I applied for the AWS Activate Founders Package (1,000 USD in credits) and got this rejection message:

"We are unable to approve your application, because it doesn't meet program requirements. Applications require that the email used on your AWS account matches the domain used in your application. Free email providers are not accepted for business applications."

The thing is, I already have an email on my own domain (@mydomain.com), which I got through Zoho, and I have everything related to DNS perfectly configured. My AWS account's root email is the same one on that domain, and it's the same one I used in the application. So I don't understand why it's telling me this, because that shouldn't be the problem.

Has anyone run into something similar? How did you solve it?

Thanks!

Hi everyone ! My Free plan is ending soon with almost 150 $ credits, does upgrading to a paid plan with a credit card will extend the life of the free Plan?

I only used AWS 4 years ago and haven't touched it since. I got charged just now; is someone trying to use my credit card for the service?

I am looking for some guidance on database hosting with AWS.

I currently have 7 RDS instances running PostgreSQL. 3 in US, 3 in EU and 1 in Australia.

Each RDS instance has around 3,000 databases on them, most of them are small.

Since the upgrade cycle for PostgreSQL on RDS is quite aggressive, we are forced to upgrade each RDS on an annual basis. This process is currently quite cumbersome as it requires exporting each database from the old RDS, in turn, and importing it into a brand new PostgreSQL on RDS on the new version. This is clearly prone to error and requires a lot of babysitting.

I am investigating into the benefits of Aurora and in particular if blue/green deployments with Aurora would be a good option.

In-place PostgreSQL major version upgrades on RDS for 3,000 is a non-starter as it takes around 7 hours which is downtime we cannot wear.

Is anyone willing to share the upgrade experiences with PostgreSQL on Aurora for major engine versions?

I got a +$1 and -$1 charge on my credit card from AWS, and I haven't made any changes on my AWS free tier account, and also haven't been using it. I'm not sure if they're just regularly checking if my card is still valid, or if my credit card has been compromised.

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?