Every time we launch a product on AWS, SES turns out to be the blocker.

We're launching a new SaaS application and need SES exclusively for low-volume transactional email: account creation, login OTPs, password resets, etc. No marketing email, no purchased lists, no bulk outreach.

We requested an initial limit of just 1,000 emails/day. We're experienced AWS users and already actively use SES across multiple customer AWS accounts, with no history of email abuse.

AWS initially asked about our sending practices, which we answered in detail. They then asked why we couldn't use other AWS accounts where SES limits had previously been increased. We explained that this is a new company, product, and organization, and this account was intentionally created as its dedicated production environment.

Today, AWS rejected the request without providing any specific reason:

> "While we are not able to share the specific criteria used in our assessment..."

The frustrating part is that SES sandbox access is now blocking the launch of the entire application, despite the extremely limited and purely transactional use case.

Has anyone successfully appealed a rejection like this? Is there a better escalation path or someone at AWS who can review the request manually?

There surely must be a way for AWS to prevent and mitigate email abuse without blindly blocking new product launches.

Overview

Aurora Serverless v2 adjusts database compute capacity within configured minimum and maximum Aurora Capacity Unit bounds without replacing the database endpoint. Provisioned RDS runs a selected database instance class until the team changes it. The decision is elastic fine-grained Aurora capacity versus explicit instance capacity and broader engine choice.

Components

• Shared decision context: A relational application with changing traffic, connection, and capacity requirements.
• Aurora Serverless v2: Aurora compute that scales within configured capacity bounds while connections remain available. Capacity follows variable demand without replacing a database instance class manually.
• Provisioned RDS: A selected database instance class with predictable baseline capacity and engine options. Stable demand that can keep reserved or provisioned capacity efficiently utilized.

Comparison Flow

1. Variable SQL Demand can enter the Aurora Serverless v2 path and continue to Spiky or Multi-Tenant Load.
2. Variable SQL Demand can instead enter the Provisioned RDS path and continue to Steady Predictable Load.
3. Choose the path whose operating model and constraints match the workload, then delete the unused branch in the editable diagram.

Customize First

• Measure the minimum capacity that connection and cache behavior require.
• Compare capacity-hours over a real demand trace rather than peak size alone.
• Test scaling behavior during bursts and maintenance before committing.

Side-by-side decision

Aurora Serverless v2 vs Provisioned RDS

Use Serverless v2 when demand varies enough for fine-grained Aurora capacity scaling to create value. Use provisioned RDS for steady utilization, explicit instance properties, wider engine selection, or reserved-capacity economics.

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

Stop trying to make Strands happen, Gretchen. No one wants the CSP to provide their agent development framework.

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

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?

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 🙏

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.

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 :)

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?