r/aws

Eu-west-2d showed up in our consoles today.

It took our TAM by surprise too. :)

I have a process that looks like this:

GetDataLambda -> ProcessDataLambdaA1 -> ProcessDataLambdaA2 -> ProcessDataLambdaB1 -> ProcessDataLambdaB2

Basically, GetDataLambda needs to run first to actually get the data I need. There are two separate sets of lambda functions to process it (A and B). Both rely on the data from the get function, but they're entirely independent of the other. So that's why I wanted to set it up where GetDataLambda runs first, but then there's a parallel step with one path doing the "Process A" functions and the other doing the "Process B" functions. However, with the way parallel stages work, if one branch fails, the entire thing fails.

What's the best way around this? If "Process A" fails, I still want the "Process B" branch to keep going, for example.

hi so i am a comp fortnite player and i was wondering if theres any updates on the AWS bahrain servers or when people think they will come back since its the only servers i get good ping to

Hey all, looking for a sanity check on our approach.

Stack: AWS + Kubernetes. We deploy with plain helm install (no GitOps tool like Argo/Flux).

Current setup: Our Helm values.yaml has hardcoded secrets (env vars) in it. Right now this file lives on our Jenkins server, not in any repo.

The plan: We want to move values.yaml into our Git repo so we can version it properly. The obvious problem — we can't commit hardcoded secrets in plain text.

Our idea: Use git-crypt to encrypt the file at rest in the repo, so secrets are scrambled on the remote and only unlock for people with the key.

Questions:

• Any real-world gotchas we should know before committing to it?
• Since we're already on AWS, would you skip file encryption entirely and go with something like External Secrets Operator + AWS Secrets Manager? Or is that overkill for a small team? Also curious where SOPS (with AWS KMS) or Sealed Secrets fit in.

For context: we're a small-ish team and just want a clean, low-friction way to keep secrets versioned without leaking them.

Appreciate any input 🙏

I have an internal debate going with a colleague about whether the following is possible:

AWS Region 1 > Dedicated Direct Connect > Cross Connect > Third-Party Fiber (Long Haul) > Cross Connect > Dedicated Direct Connect > AWS Region 2

The catch is whether we can do this with a straight Layer 2 connection and handle all BGP and routing via the AWS Control Panel, or if we need to have a separate router in-between the regions to handle BGP and routing between each end.

Anyone have real-world experience with this? We can't be the first.

The idea is to provide provably-diverse connectivity between regions that does not depend on Amazon's network. Yes, AWS is plenty reliable, but it is not deterministic, and we want a higher level of control of our backend network, especially how it integrates with other non-AWS aspects. TL;DR - we have reasons for a custom design.

EDIT: Not a single person has bothered to answer the question. All anyone wants to do is say "AWS is best, and you're clearly wrong for having different requirements than bog standard commodity". Here I'm trying to design a network that's different from Amazon's because no, it is not the best for every use case, and I asked a very simple question - one that's been ignored.

EDIT THE SECOND: I'd love to go more into detail on the use-case, but that's where NDAs and such come into play. Yes, it's a real client with a unique need that is not met by the AWS network, and can measurably be met off their network. No, I cannot go into it, because I do like keeping my job.

I don't have a query or anything, it's already lost and I made peace with it.
I needed more computing so I changed the instance type, then when I reboot I notice the IP change. I check, and indeed, no Elastic IP was associated and so the previous public IP is gone to the pool, never to be seen again.

So now I can only mourn it as I spend the next few hours emailing clients who were using it instead of the domain it had associated (Because of course) to allow it again.

I'll miss that IP.

For anyone based in/near Central & Eastern Europe (or looking for an excuse to visit Budapest in September), AWS Community Day CEE is returning for its second edition in September.

See useful links as a comments.

It’s 100% community-organized by regional AWS User Groups rather than AWS corporate. Last year had ~300 attendees, and this year is stepping up the scale.

Quick Details

• Date: September 17, 2026
• Location: Kristály Színtér, Margaret Island (Margitsziget), Budapest
• Format: 3 parallel tracks, 20+ speakers from 10+ countries, and 4+ hours of hands-on workshops
• Tickets: €25 / €45 / €100 tiers on Eventbrite (link in comments)

Exciting lineup

• Opening Keynote: Liam Greenamyre (Principal PM at AWS, Agent Toolkit & AWS MCP servers), who will be covering where AI assisted software development actually stands as of September 2026.
• Closing Keynote: Meridith Grundei (creator of Amazon New Voices, 3 years coaching re:Invent speakers) focusing on tech communication—a solid palate cleanser after a technical deep-dive day.

Last year's speakers included Massimo Re Ferrè (Kiro) and María Encinar (who runs the global AWS User Groups program), so the bar for "people you'd otherwise have to fly to Vegas to see" is already established.

Bonus Context
The day after (Sept 18), Budapest is hosting the first EMEA User Groups Summit, so expect a solid turnout of EMEA/CEE cloud community leads and builders floating around for both days.

(I am not affiliated with the organizing team—just a local engineer excited to see solid re:Invent-caliber speakers coming to CEE without the 12-hour flight to Vegas).

I am new to AWS, and currently working on a project with strict compliance regarding data. So my question is - Is it possible to lock location for CloudFront, WAF and Route53 to be strictly in ca-central-1 region? I understand these are global services, but I am not sure if the can be geo-locked?

Any help, advice or suggestions are highly appreciated!

I raised a request for SES prod access. Following was the reply to additional details:

We publish an education site for couples: long-form written guides on intimacy, communication and consent, with no explicit imagery. We want to send a low-frequency newsletter and a small number of requested downloads (worksheets that accompany our guides) to readers who have explicitly asked for them.

Expected volume is low: fewer than 100 recipients initially and under 2,000 emails per month in about an year time. We are starting from zero subscribers. We are not migrating, importing or re-using any existing list; a small number of addresses collected years ago under a previous plugin were deleted outright rather than carried over, because they never went through the confirmation process described below. Every address we mail will have been collected and confirmed under the current flow.

How recipients sign up: only through a form on our own site, which a reader fills in deliberately. There are no pre-ticked boxes, no signup bundled into any other action, and we do not buy, rent, scrape or import lists from any third party.

How we confirm consent: double opt-in. On submission the address is stored with status "pending" and sent a single confirmation email containing a unique,
expiring, single-use link. Nothing further is ever sent until that link is clicked. Unconfirmed addresses are purged automatically after 14 days.

Quality controls at capture: format validation, live MX record check, disposable-domain blocking, typo detection on common domains, a honeypot field, and per-IP rate limiting. Rejections are logged domain-only so we can audit the filter without storing addresses we refused.

How recipients unsubscribe: every email carries a one-click unsubscribe link in the body and List-Unsubscribe / List-Unsubscribe-Post headers. Unsubscribes take effect immediately and are honoured permanently; the address moves to a suppression list that every send checks before dispatch.

How we handle bounces and complaints: bounce and complaint notifications are delivered via Amazon SNS to an endpoint that writes to the same suppression list automatically, with no manual step. Hard bounces and any complaint suppress the address permanently and immediately. We monitor bounce and complaint rates and will pause sending if bounces approach 5% or complaints approach 0.1%.

Content: educational writing about relationships and sexuality, aimed at adults, with no explicit images. We are stating the category plainly so there is no surprise on review.

>And the response that I got is:
Thank you for providing us with additional information regarding your sending limits. We are unable to grant your request at this time.

Your success with Amazon SES matters to us, and we want to ensure your email program operates at the highest level of deliverability and reliability. After a thorough review of your request, we are unable to approve a sending limit increase at this time.

Questions:

How do I know what exactly is wrong? What do I change or improve? Similar thing happened to a friend who runs a company and they need to send transactional emails to their clients. Tried SES couple of times but got only NO with no reasons.

What options do I have?

In case it matters to this question - this is a small, single user account. The majority of my AWS spend is domain registry costs, a couple of lambdas, dynamodb and some R53. That's about it. Average monthly spend is around $10.

I use a password manager (1Password in this case).

I have my root account separate from the main admin-level account I use day-to-day. Haven't needed to login to root account for a long time.

I have no problem logging into my admin account (IAM), which of course also has 2FA, and I use 1Password to store the credentials. Sign-in works.

I wanted to make some account/organizational changes, so I attempted to login to my root user. User & password accepted, but keep failing on MFA.

I'm not signed up for any support plan, so not sure how to proceed here.

I came across the AWS Partner Certification Readiness program, which seems to offer a free AWS certification voucher after completing the requirements.
I’m wondering if college students with a valid student email ID are eligible for this or if it’s strictly for AWS Partner employees assigned by an AWS Partner organization.

I couldn’t find the student eligibility clearly mentioned on the AWS site, so I’m thinking it might be worth trying.

Almost lost a chunk of a client's account to a bad Terraform apply last week. Someone ran the wrong workspace against the wrong environment and it took down a good chunk of a staging-adjacent VPC before anyone caught it.

Made me realize our backup strategy covers data stores but nothing else, IAM roles, networking, cross-service dependencies were all missing from the recovery plan. We got lucky it wasn't prod.

This is apparently the exact gap the new CAIRS category is meant to close: infra as rebuildable code, not just restorable data. Reading about it made me realize how much we've been conflating "we have snapshots" with "we can actually recover.

How often is everyone actually testing full-account recovery for clients, and does anyone have a realistic cadence that doesn't eat a ton of engineering time?

https://preview.redd.it/s7ejbb012wjh1.png?width=654&format=png&auto=webp&s=1cca9c862316d3e1bba10aaed5445bb7bc9a62f1

Case ID: 178633616200405

AWS charged my debit card $600 for a transaction that does not belong to my AWS account. My normal AWS bill is about $3.40/month, and this $600 charge appears nowhere in my billing history. I opened a support case with all the transaction details, and AWS still has not meaningfully investigated it.

After multiple calls, one Amazon/AWS support agent told me they could see that the charge came from another AWS account that had already been suspended. Despite that, AWS's fraud department later emailed me saying they found nothing wrong with my account, completely missing the issue. Another agent told me the $600 had already been refunded, while another told me the refund was rejected.

Wise is refusing to treat the charge as unauthorized because I have legitimately used AWS before and says AWS needs to provide information about the transaction. AWS keeps claiming another department will investigate, but nothing actually happens.

At this point, AWS has acknowledged that the charge came from another account, has apparently suspended that account, and still will not properly resolve or document the fraudulent $600 charge they processed against my card.

The complete lack of ownership, contradictory information, and failure to investigate is unacceptable.

Hi everyone, so I recently made it to the final round for an L5 TAM role and have 5 interviews to prepare for. If anyone could help provide me some advice on these few things that would be amazing.

Scheduling: I’ve seen online that AWS interviews candidates at the same time so it would be better to schedule your interview earlier in your scheduling window than later. And the realistic times I have to schedule would give me 17 days to prepare or 24 days. I obviously want as much time as possible to prepare but is the extra week worth that risk?

1 or 2 days: Should I go for all interviews on the same day, split it across two?

STAR Stories: How many star stories should I come up with? I’ve seen online advice as low as 8 and as high as 25. I only have two years of work experience in consulting so coming up with anything more than 15 is a bit of a struggle. ALSO, my time in consulting has not been really technical so a lot of my stories are mostly to do with advisory and not troubleshooting like the role would want. Would that doc points off me? I would use technical stories from back in university but that was 3+ years ago

Technical interviews: From what I understood the technical breadth interview would be similar to the phone interview where they ask a wide range of fundamental questions on different domains. Is that correct?

As for the technical depth interview I was told by my interviewer in the previous round that they would select two domains for me to go in depth on, but how much depth would it actually get to? And they didn’t send me in the email what domains I would do, and how could I best prepare myself for that when I do find out?

Thanks in advance for any advice you guys are able to give!

Hi everyone, quick sanity check regarding a closed AWS account.

I closed my personal AWS learning account on July 13 after attempting to terminate all resources across regions. On August 1, I got my monthly invoice for $0.00.

However, I just received an automated email saying my Free Tier and remaining $105 in promo credits will expire on August 24.

I'm unexperienced, im afraid of making a mistake and since I can no longer log in, I want to double-check:

• Does closing the account on July 13 completely freeze pay-as-you-go billing, even if I accidentally missed a small resource (like an EBS volume or Elastic IP)?
• When the $105 credits expire on August 24 during the 90-day post-closure window, is there any possibility of my credit card getting charged?
• Is the $0.00 invoice from August 1 solid proof that no ongoing balance is accruing?

Just want to make sure I won't get any surprise charges. Thanks!

https://preview.redd.it/7xdplz8unsjh1.png?width=1901&format=png&auto=webp&s=53a18db5e2c546a4ff5b9f48d021719afc0d7a78

Any reason why some AMI's are not shown in the Pricing Calculator? I need to estimate how much I might need to run my cluster.

we had a webhook endpoint that would spike to 5x baseline traffic in under a minute with no warning, saturating the origin and dropping events during the spikes.

the fix was a small edge function in front of it doing three things in order: return an instant 200 to the caller so the upstream never sees our latency, forward the payload to origin asynchronously after responding, and if that forward fails, buffer the event to durable storage at the edge instead of losing it.

we're now absorbing about 195 million requests a month at the edge for roughly $92, origin only ever sees successful-forward traffic, and there have been zero dropped events since, verified up to 10mb payloads.

the trap that cost a day building it: you cannot read the request body after you've already returned the response, the runtime throws. tiny test payloads pass because they fit in the initial chunk, real payloads over a few hundred bytes fail, so it only breaks in prod.

anyone running a similar pattern in front of an origin on a major cloud, and where do you draw the line between edge-buffering it versus needing a real queue behind origin?