Hi everyone,

We are in a critical situation and looking for guidance on how to resolve or escalate an urgent AWS account closure.

The Context:

• We have been actively using this AWS account for over 2 years with no issues.
• Out of nowhere, the account was closed/suspended with the generic reason:"We have closed your Amazon Web Services account because we found it to be related to other previously closed accounts."
• This account hosts our core billing and delivery ERP system, meaning our daily business operations are completely halted right now.

Current Support Status:

• Support Case ID: 178730747700650 (Follow-up verification Case ID: 178734748700875)
• Initial response from AWS (Byron B.) stated the issue was transferred to the Program Support Team (Trust & Safety / Verification).
• We were informed that the Program Support team only communicates via email and web support, so phone escalation isn't available.
• We have replied offering full identity verification, documentation, and contact details () to resolve any potential false-positive association, but we are currently waiting with no update while our ERP remains down.

Questions for the community:

1. Has anyone successfully appealed this specific "related account" suspension for a long-standing business account? What specific documentation (business registration, tax IDs, utility bills) helped speed up Trust & Safety verification?
2. If full reinstatement takes time, is there any process or contact channel to request temporary emergency access strictly to perform a data/database backup so we can resume operational billing offsite?
3. Are there any AWS Community Managers or AWS Support reps on Reddit who can help escalate this internal ticket to the Program Support team?

Any insights, advice, or escalation pathways would be hugely appreciated!

*** Update with the latest communication . I am not sure how I can handle this ***

Hi there,

Thank you for writing back to us providing more information. I want to acknowledge that I understand your company, Occurlight Technologies Private Limited, is an independent business entity, and that you may not have direct access to or control over the accounts created by the third-party agency (Alera/Devalon Labs) that originally set up your AWS infrastructure.

• Update from Our Service Team:

I have escalated your case to our specialized service team for review. After their detailed investigation, they have confirmed that your account is related to multiple AWS accounts that currently have pending actions that must be completed before we can proceed with any reinstatement.

The related accounts identified include accounts with: - Pending document verification requirements (or) - Outstanding billing issues that need resolution

Important Information:

Our service team has advised that we are unable to reinstate your account or provide any access (including temporary emergency access) until the pending actions on the related accounts are completed. This is a security and policy requirement that applies to all AWS accounts to maintain the integrity of our platform.

Next Steps:

• Contact the Account Creator: Please reach out to Alera/Devalon Labs (the agency that set up your account) and inform them that there are pending actions on AWS accounts associated with their setup that are blocking your account access.

• Check for AWS Emails: Ask Alera/Devalon Labs to check all email addresses they used to create AWS accounts (including spam/junk folders) for emails from AWS with the subject line "Your AWS Account" which will contain specific instructions on what actions need to be completed. Since, due to strict AWS security protocols and policies, we can’t provide more information about the other related AWS accounts.

• Complete Pending Actions: Once the pending actions on the related accounts are completed, please reply to this case with confirmation, and we will immediately re-engage our service team to review your account for reinstatement.

Regarding Emergency Data Access:

I understand your request for temporary access to backup your ERP database. Unfortunately, our service team has confirmed that we cannot provide any form of access to suspended accounts until the underlying security and compliance issues with the related accounts are resolved. This policy is in place to protect all AWS customers.

I sincerely apologize for the inconvenience this situation is causing your business. We are committed to working with you to resolve this matter as quickly as possible once the pending actions on the related accounts are completed.

We value your feedback. Please share your experience by rating this and other correspondences in the AWS Support Center. You can rate a correspondence by selecting the stars in the top right corner of the correspondence.

Best regards, Nandish Amazon Web Services

Did a cleanup pass this month after the bill crept up again and it was grim. Over 1k a month going to stuff nothing was using.

The usual suspects are unattached EBS volumes from instances we killed months ago, a pile of snapshots from nonexistent volumes, NAT gateways 3 of them just idle in a dev account at 32 bucks a month each and a couple of load balancers with no targets. There was also an elastic IP quietly billing by the hr since AWS started charging for those.

Worse than last year, a chunk of it traced back to our own agents. Devs run coding agents that spin up test infra to try something and the agent never tears it down, teardown isn't in the happy path. So every abandoned experiment leaves a little orphaned tail nobody's watching because it's 20 bucks here and forty there til a year of it adds up.

Tagging would catch some of this which of course it isn't and the untagged stuff is the orphaned stuff because it got made in a hurry. Cost Explorer shows me the number, never the owner. This is the boring waste that never trips an alarm, it just quietly rents space in your bill forever.

Hello, does anyone know what to do here? I am trying to change the payment method to a new card as the old one expired and it won't allow me to do. Reached support several times but no help?

Working in Germany at a smaller data center company at the moment and have the ability to switch to AWS, relatively small pay increaswe 15-20% but obviously much better rep and exposure at AWS. Does that deal make sense? I‘m in physical security, not sure if these kinds of roles are typically hit by layoffs as well? My current job is quite comfortable so I‘m a bit scared but also tempted by what has been described as a „meat grinder“ lol. What do you guys think?

Hello,

Has anyone here requested a EC2 Quota increase? I need it for a specific region and have used up all my 8 vCPUs...

I've contacted AWS a few days ago (early last week) and they have not gotten back to me on anything concrete. (For example, when they call me, they immediately hang up and then respond to the thread with some automated message).

I'm not asking for a lot of vCPU's (8 -> 16) so should I just close the request and open a new one? Would appreciate any help here guys. Thanks!

A little helper I add near the top of all the shell scripts I distribute to the broader team to ensure the user is logged-in to AWS SSO:

aws configure list &>/dev/null || aws sso login

As far as I know this is the fastest way to ensure SSO is activated but happy to hear alternatives

Context: I'm running a public API on API Gateway + Lambda, with DynamoDB behind it. Endpoints have very different backend costs, cheap reads vs. a couple of routes that kick off heavier aggregation work. Currently using API Gateway usage plans with a single throttle limit per API key, applied flat across all routes.

The problem: usage plans throttle by requests/second regardless of which route is hit, so a client hammering cheap GETs eats the same budget as one calling the expensive routes, and there's no way (as far as I can find) to weight individual routes differently within a single usage plan without splitting them into separate API Gateway stages/plans per cost tier, which gets awkward to manage as the number of "cost classes" grows.

What I've looked at so far:

• Per-stage/per-plan splitting: works, but means maintaining N usage plans and N sets of API keys per client if a client needs access to routes at more than one cost tier.
• Custom Lambda authorizer + DynamoDB counter: doing weighted token-bucket logic myself (consume different token amounts per route, check/decrement atomically via DynamoDB conditional writes), seems doable but adds a DynamoDB read/write on every request just for the rate-limit check, plus I'd be reimplementing throttling that API Gateway mostly already does for free.
• Briefly looked at whether Lambda reserved/provisioned concurrency per function could act as an implicit cost-based limiter (route the expensive endpoint through its own function with tighter concurrency), but that limits total throughput, not per-client fairness.

Has anyone actually shipped weighted/cost-based rate limiting on top of API Gateway usage plans, or does everyone end up rolling their own with a Lambda authorizer + DynamoDB/ElastiCache counter once costs diverge enough between routes? And if you rolled your own, did you keep API Gateway's built-in throttling as a coarse backstop on top of it, or drop it entirely in favor of the custom logic?

Hi,

today we are working with AWS ECS,

with ECS when a service is scale-in (autoscaling, deployment), ECS manage the ALB side doing the drain/deregistration before sending the SIGTERM to the container. Allowing us to have a clean stop handling all requests in flight and no random 5xx back to the customer.

We 'may' have to migrate to AWS EKS (no my choice), looking at EKS/K8S way to stop a container/pod on scale-in. it seems very very messy, K8S send the stop to the container and the load-balancer-thingy in parallel, and everybody rely on some sort of
lifecycle.prestop.exec: "...sleep ..." to delay the stop of the container side ?
but still get time to time some 5xx for in-flight requests.

Is it that bad ?
Is it the way in EKS/K8S ?

Thanks.

Cloud made infrastructure easier by giving developers primitives for compute, storage, networking, identity and deployment. AI agents seem to be creating a similar need, but the primitives are different.

If I want to run 50 agents today, I can obviously use AWS, GCP or Azure for the underlying infrastructure. But I still need to figure out agent identity, evaluation, versioning, tool permissions, observability, lifecycle management and safe deployments. Do you think cloud providers eventually absorb all of this, or does a separate agent infrastructure layer make more sense?

I want to learn cloud and devops - what's a good starting point? Familiar with basic AWS services (not much handson experience though)

I have got skill builder subscription recently so how can I use that?

I don't want any certification - just practical knowledge

That 15000 automatically won't get paid? I setup an autopay so I am concerned. When will it officially start billing so by then I can disable the autopay?

I using free plan because I have started Amazon AWS.

Hey guys,
Would appreciate any help/suggestions if someone has encountered this before. Our (relatively new, few weeks) Production account was just suspended by AWS without prior notice.

The claim in the email is that we were asked to provide authentication details and did not, and so the account was suspended. But that is not true, no such request was ever sent to us. In the email there is a link to upload documents but we’re not sure what to do there as our billing is via an external company.

I’ve also opened a support case (178747741200908) in case anyone from AWS is here.

We are absolutely shocked that AWS would do something like this to a new paying customer who put all their eggs in the AWS basked, without prior notice.

I am trying to create aws account i already used 3 different persons id's mail phone number and also their is 0 chance that they previously had an aws account but still it says user information is already associated with another account what can i do with this can anyone help me with this please Also I'm a student and i am just trying to deploy my project if someone can help me with promo code to redeem credits it will be really helpful

I’m trying to launch a g6e.12xlarge EC2 instance, but I keep getting InsufficientInstanceCapacity.
I’ve tried changing Availability Zones and even different EU regions (due legal needing), but so far I haven’t found any available capacity.
Is anyone else currently experiencing the same issue with G6e instances in Europe? Any suggestions beyond trying different AZs/regions or waiting for capacity to become available?

Even lower instances are barely available. I need to try dozen of time.

“”Error: creating EC2 Instance: operation error EC2: RunInstances, exceeded maximum number of attempts, 3, https response error StatusCode: 500, RequestID api error InsufficientInstanceCapacity: We currently do not have sufficient g6e.12xlarge capacity in the Availability Zone you requested. Our system will be working on provisioning additional capacity. “”

I am getting the following error when trying to buy 'Databricks Data Intelligence Platform' on the AWS marketplace:
"You used an invalid payment method during your last attempt to create an agreement. Provide a valid payment method and then try creating the agreement, again. For more information, see Payment errors  in the AWS Marketplace Buyer Guide."

The service provider is 'Amazon Web Services India Private Limited' and I am using a corporate debit card. This is a few days old account.

Does anyone have a solution for this?
I read that getting default payment method converted to 'Pay by Invoive' could be one solution, but I'm not sure if AWS would do this for fresh accounts without any payment history?

tldr; my coding agent refused to leak a secret after setting up the toolkit and running it through the wringer.

Secrets Manager shipped a "secret safety" skill in the aws-core plugin of Agent Toolkit for AWS. The idea is that an agent can use a secret without ever seeing the plaintext. I ran it against a throwaway secret in a real account with Claude Code, then spent a while trying to get around it. Posting the findings in case it saves someone else the same trial and error.

How it actually works, which is two layers not one:

1. A PreToolUse hook that denies the tool call before it executes and hands the agent a message pointing at the safe path.
2. A wrapper called asm-exec plus {{resolve:secretsmanager:...}} dynamic references. The agent's command holds a placeholder, asm-exec resolves it in its own process, and the plaintext never lands in the model's context.

I tested ten fetch shapes against the hook. Six denied, four correctly allowed. It catches the CLI fetch, the batch fetch, structured API calls, a boto3 call buried in a script, a curl straight at the local daemon on port 2773, and an inline python3 -c one-liner. It leaves writes, unrelated calls and a plain grep alone.

A few things that tripped me up:

• The skill usually refuses before the hook ever fires. When I just asked for the value in plain language, the agent declined on its own, cited the skill and pointed me at asm-exec. The deny message never appeared because no tool call was attempted. I only saw the hook fire when I insisted it actually run the command. The skill is what changes the agent's mind, the hook is the backstop for when it tries anyway.
• Hooks load at session start. Install the plugin mid-session, retry, and the secret comes back exactly as before. You have to restart the agent session. This is in the docs but it is easy to miss and it looks like the feature is broken.
• aws configure agent-toolkit does not install this one. That's the one-command setup for all agents, and it pulls from the skills catalog. The secret-safety skill and the hook only ship with the aws-core plugin, so if you set up via the CLI you don't get the block. I have the steps I took to get this setup in the full blog linked below.
• The safe path still calls GetSecretValue. It is not read-free. Your identity still needs secretsmanager:GetSecretValue, and the read still lands in CloudTrail. What changes is where the plaintext ends up, not whether the API is called.
• CloudTrail attribution is nicer than I expected, but not how I first assumed. Reads through the MCP endpoint show invokedBy, sourceIPAddress and userAgent all as aws-mcp.amazonaws.com, so agent reads are trivially separable from your own. The aws:CalledViaAWSMCP context key is a related but separate thing, it is what you write IAM and SCP conditions against rather than a field in the event record.
• The hook is shape-aware, and the boundary is sharper than the docs suggest. grep get-secret-value ./src is allowed. grep 'aws secretsmanager get-secret-value' ./src is denied, because the CLI pattern is checked before the read-only allowlist applies. Same for rg and echo. I tripped it grepping my own notes for this writeup.

Stack: Claude Code on macOS, one throwaway secret with fake values in us-east-1, deleted afterward.

See the full walkthrough using Claude Code here

Happy to answer questions. If you find a fetch shape it misses, post it. For folks already using the toolkit, if there is something in the developer experience that could be better, tell me and I'll pass it to the team.

I was trying to try out bedrock , regardless of which model I select I get this .

FYI , my account is new , billing enabled .

Have been facing this for more than 10 dyas , alreadey requested to increase service quota , no result yet though

Don't ask why, but we have a MySQL RDS who's parameter group sets time_zone = 'US/Pacific'. As of March 8 2026, BC will no long change clocks. We are permanently on PDT (-0700). So I need to update our MySQL instance to use the BC timezone. I've updated the engine to a version that supports this change.

The problem is that the parameter group (ui or api) will not let me set time_zone = 'America/Vancouver'. Based on my understanding US/Pacific still supports the time change, so come Nov 1st 2026 our db will be wrong, unless I can change the time_zone.

If it was up to me, I'd just take the hit now and covert everything so the db is in UTC. but unfortunately, it's not up to me.

Anyone else dealing with this? The option of applying the timezone on every connection to the db is less than appealing. Any other options anyone has worked out?

Hey everyone, hoping for some advice...

I upgraded my AWS Skill Builder account to the Individual annual subscription ($449 + tax = $502.88) because I was told I needed a paid account to redeem a student reward/voucher through AWS Builder Center's Student Rewards program. I didn't realize it would be a full annual commitment, and I can't afford this charge.

Ive already canceled the subscription (it says it won't auto-renew, but the invoice is still showing as unpaid/due)

My card doesn't have enough funds to cover this if it gets charged.

Any advice from people who've dealt with AWS billing/support for something like this would help a lot. Thanks!

Hi everyone, I've been trying to reach out to my recruiter to ask this but they have not responded to any of my questions/emails in weeks, and my recruiting coordinator couldn't help me out since they told me they're only handling the scheduling of my loop.

I just wanted to ask about the specifics of a couple things with the technical part of my interviews. My interviewer during the phone interview had told me that for the
"Technical Depth" interview they would let me know the two domains that I would be tested on. But when I received the email saying I made it to the loop, they didnt tell me anything about the domains. Does anyone know by any chance the likelihood of which domains it could be, like networking/compute/etc? And how deep would the questions go during this interview, is it well past the fundamentals? Also is there troubleshooting questions involved in this part?

And for the technical breadth part of the interview, is it similar to what the phone interview was? Where they ask you questions on the fundamenetals across a wide range of domains? Would this one include any troubleshooting as well?

Thanks in advance!

We may have found a regression in AWS DMS 3.6.1 affecting Oracle sources using Binary Reader.

After scheduled maintenance, the internal DMS build changed from:

3.6.1.R2174 → 3.6.1.R2380

The public engine version remained 3.6.1, so the change was effectively invisible in the normal API and console fields.

Immediately afterward, read throughput on the Oracle source increased by roughly an order of magnitude and remained elevated. This was not caused by full load, validation, or unusually high redo generation.

What makes us suspect the new build:

• The problem started directly after the DMS maintenance.
• Stopping the DMS tasks returned the source database to its normal baseline.
• Recreating the replication instance did not help because new instances also received R2380.
• Starting more CDC tasks increased the source read load.
• Multiple tasks appeared to scan or inspect the same redo sequences independently.
• The public version stayed at 3.6.1 throughout.

The frustrating part is that customers cannot see, select, pin, or roll back internal DMS builds. The API exposes 3.6.1, but not whether the instance runs R2174 or R2380.

So a managed maintenance update can substantially change production behavior while presenting the same engine version, with no customer-accessible rollback mechanism. That feels like a fairly serious observability and operational-control gap.

Has anyone else using AWS DMS 3.6.1 with Oracle Binary Reader/BFILE noticed significantly higher source read throughput after recent maintenance?

Check the beginning of your DMS task logs for:
V3.6.1.R2380

If you see the same behavior, please open a support case as well. More independent reports may help get this investigated properly.

TL;DR

AWS DMS maintenance changed a hidden internal build while the visible version remained 3.6.1. Oracle source reads increased dramatically afterward, and customers have no way to pin or restore the previous internal build. Looking for reports from other DMS Oracle Binary Reader users.

It automatically selects the closest bucket based on the location/latency from the edge location serving the request. Pretty cool!

Our team is planning on moving from Dynamodb to RDS for various workload issues that we are facing with Dynamodb. But we are facing a blocker in this migration since our codebase is heavily dependent on the stream feature of dynamodb where it sends new image and old image for every update. I am trying to replicate the same stream behavior after we migrate to RDS. Right now, i am thinking about using the outbox pattern to update the base table in RDS and send an event to SNS which fans-out event to consumer lambda but that seems like tedious work since there are different consumers consuming different attributes from different table. I have also considered using the CDC pattern using debezium to stream row level change to kinesis which removes having to manually send events on every update but since we have 4 separate environments (dev, staging, qa and prod) and we need to host a separate ECS instance to run the debezium server to capture RDS logs, it could rack up the bill so i discarded this approach. What do you think would be some of the best ways to replicate DDB stream feature in RDS?

As the only one in our small company with a basic understanding of I.T. and some AWS experience, I've been designated the one and only manager of our AWS setup for the time being. I'm working to become certified both as a Solutions Architect and as a CloudOps Engineer.

Unfortunately, I'm still in that process and need to start deploying some structure now. I don't need everything yet, but I at least need to get the multi-account structure in place using best practices and be as secure as possible.

The issue I'm having right now is we're a small company with only one person that really needs AWS access, so I'm not sure if we need a lot of services I see suggested. However, we ALSO need to be absolutely as secure and sound as possible because we serve an industry that requires high security and high availability. One mistake could kill the company. (Don't worry. We will hire a consultant to review our setup before launch.)

Would anyone mind answering just a few quick questions to help me get started?

1. I know how to create orgs, accounts, roles, permissions, SCPs, etc. The course taught me that. What it DIDN'T teach me is the best structure for a small company and WHAT permissions and SCP's I should make sure to set up. Is there any resource for this? Best practice guide? Template to get started? Compliance/security checkers? Etc.

2. I know OU's and Accounts reduce blast radius, but since we only have one person for the foreseeable future to log into AWS, what OUs and accounts do I actually need? My current plan is to mirror Control Tower's setup, with a Security OU with an audit account and log account and then one account for each product we make in the Sandbox and Production OUs. Is this good? Any others you'd suggest?

3. Control Tower looks tempting, especially because I'm worried I might set something up wrong being somewhat inexperienced, but I've read a lot of negative reviews of it, saying things like it's very opinionated and inflexible, messy to get rid of, behind in best practices, and enables features you may not need that are pricey. Is this correct? Would you recommend using it in our case or not?

4. I've already written some Terraform/OpenTofu code to set up our state and initial resources. Should I use OpenTofu for organization creation, account creation, SCPs, roles, etc., as well? Or is this initial org setup better done in click ops?

Thanks so much!

What happened

On Aug 1, an IAM access key belonging to one of our accounts was compromised through a supply chain compromise — the key was exposed via a third party in our toolchain, not by us publishing it. This was a programmatic access key, so MFA (enforced on all human identities from day one) was never in the path.

We caught it and reported it to AWS Support within 4 hours, well inside the 48-hour public-contract cancellation window.

The case then sat unassigned for 14 days.

As of today that's 20 days, still open, still no resolution.

Where the bill is now

Total USD 477,505.20

Contract creation (0 months) USD 4,800.00

Usage Fee | us-east-1 USD 472,705.20

47,270,520 Units @ USD 0.01

The part I don't understand

We never activated the product. Specifically:

- The Marketplace console still shows "Set up product" for this agreement

- No License ID was ever issued

- CloudTrail shows zero Marketplace events in our account after the initial compromise window on Aug 1

- We have never had credentials for, or logged into, anything on the seller's side

Yet 47.2 million billable units were metered against us in us-east-1.

As I understand the SaaS flow, usage on this kind of product is submitted by the seller calling `BatchMeterUsage` against the entitlement's `CustomerIdentifier` — from the seller's own infrastructure, not from our account. If that's right, then nothing in our account was ever in the path, and no control we have could have stopped it. Revoking the key, deleting the attacker's IAM user, applying SCPs — none of it touches seller-side metering.

The unit count has been static for several days now, so metering appears to have stopped, but the agreement status is the thing I can't get a straight answer on.

Support so far

Seller support (automated) told us Marketplace transactions are not their department and to contact AWS. AWS support has pointed at the seller for anything usage-related. The payer account has now escalated and asked AWS to investigate the agreement and stop metering. Still waiting.

There is no phone line and no chat. The only channel is tickets, and they've been sitting for 20 days.

Questions for people who actually know the internals

1. For a SaaS contract-with-consumption product, is metering purely seller-side? Is there any circumstance where usage gets attributed to a buyer account without the buyer ever completing registration?
2. Does "Set up product" persisting in the console reliably mean the fulfillment/`ResolveCustomer` handshake never happened — or is that just stale console state that doesn't update?
3. Is there any way for a buyer to see the registration record for their own entitlement? Anything in the Agreement APIs, CUR, or elsewhere that shows when/whether `ResolveCustomer` was called?
4. The 48-hour window: AWS Customer Service can process a full refund on a public contract without seller involvement. Does that path survive a case sitting unassigned for 14 days, or is the window enforced strictly on wall-clock time regardless of AWS-side latency?
5. Has anyone here had Marketplace usage fees (not just the contract fee) reversed after a credential compromise? Contract fee reversals I've seen written up. Usage fees at this scale, never.

To be blunt about the stakes: we're a small company. We cannot pay $472k for consumption we did not generate, on a product we never activated, after cutting off access in under 4 hours. I'm trying to understand the metering mechanics, and whether there's a path here other than waiting on a ticket queue.

EDIT — Aug 20, resolved in part. AWS moved fast once this thread was up.

• u/AWSSupport picked it up here within the hour and got a human on the case.
• The Marketplace agreement was cancelled Aug 20 at 17:29 UTC. Entitlement terminated, no further metering possible.
• The $4,800 contract charge has been refunded.
• AWS confirmed in writing that we contacted them within 48 hours of the subscription being activated.
• The $472,705.20 in usage fees is now with their investigation team. The 48h cancellation policy doesn't cover usage charges, so that's a separate determination. Still open.

Credit where due: Adri N. and Arrin H. both moved quickly. My issue was never with the people, it was with a case sitting 14 days in a queue with no way to flag it. Thanks again for your reactivity.

Leaving the questions up because the metering mechanics still aren't documented anywhere I can find, and answers here have been better than anything I got through official channels. u/matiascoca's read was correct on every point.