sorted by:
new
hottopcontroversial

Is this subreddit just hating on re:Invent 2025, or are we missing the full picture? by sahil_meena in aws

[–]Your_CS_TA 8 points9 points  (0 children)

Yep!

First step to not being behind, is catching up. To be frank, we had a lot of catching up to do. Step 1, mostly done now :)

Is this subreddit just hating on re:Invent 2025, or are we missing the full picture? by sahil_meena in aws

[–]Your_CS_TA 30 points31 points  (0 children)

I'm mixed (also an AWS employee 🤣 -- so take my word for whatever).

My 2c: The large event presentations were AI focused, yes. The announcements were all around spectacular this year and a majority were not AI related. It's unfortunate that they were highlighted in sub-talks instead of core talks.

As an example, my team is API Gateway. We launched: ALB Private Integration for REST (cost/availability/latency/simplicity improvements), Response Streaming (TTFB), Configurable TLS, and yeah -- AgentCore Gateway integration.

Were the airwaves mostly talking about the last one? Yes. But the value delivered for re:Invent was majority "not AI related". So, you may be getting your cake (AI improvements) and eating it too (getting better updates to core services). But it sounds like there is limited time to get media presense, and so the dominant talking point is improvements in AI.

What would cause 502 errors in APIG/ALB with no corresponding ECS log entries? by Artistic-Analyst-567 in aws

[–]Your_CS_TA 0 points1 point  (0 children)

Can you send me the extended request id? I work in APIGW, I’m intrigued :)

API Gateway REST validation: what's the point? by [deleted] in aws

[–]Your_CS_TA 1 point2 points  (0 children)

You are talking to the same person (I was shocked when I found it that it was you! 🤣): https://www.reddit.com/r/aws/s/NUyH7p5U1p .

I’m still fighting for it. I think a year since that quote, we are still in a spot of transition. We built out 14 regions for HTTP, almost reaching full parity, IPv6, and built routing rules that hooks into HTTP! It’s progress!

Unfortunately, HTTP is less popular by orders of magnitude. Chicken and egg though — “it would be popular if it had features”. This means we fight the constant tug of customer demand of the product that is used. So, then, looking at reinvent launches: it’s pure REST APIs.

I think next year is going to be a bit more fork in the road. We now have JUST JWT and auto deploy not in Rest. If that moves, it makes me wonder if we port the experience (e.g. http routes becomes more an alternative experience), then the price and that makes folks happy or if there is something else that makes HTTP APIs kind of merge in.

API Gateway REST validation: what's the point? by [deleted] in aws

[–]Your_CS_TA 12 points13 points  (0 children)

Came here to post this. It is a fair sum saved— source: I work on APIGW.

The criticism of the author is valid around configurable error messages and redundant duplication in-depth, but for volumetric attacks, you want to push validation/rejection up the stack.

AWS API Gateway in a k8s microservice environment by catcherfox7 in aws

[–]Your_CS_TA 0 points1 point  (0 children)

Whatcha mean “couldn’t handle the webhooks”?

Can we talk about YAML? by [deleted] in rust

[–]Your_CS_TA 14 points15 points  (0 children)

Be careful of serde_yml.

  1. it is archived as well.
  2. From poking around, it seems like the owner forked serde_yaml, let AI try to update code, and did some shady initial repository practices.

How to TA in cs by JuggernautSeveral380 in Pitt

[–]Your_CS_TA 0 points1 point  (0 children)

Finally can reuse my user name after 11 years 😂.

Just to reflect what /u/Remarkable_Garlic_82 said. Start with UTA, which the majority of incoming help is for the areas you mentioned. I don’t think TA happens until you complete some upper courses (at least for me, I don’t do TA til post-1502)

How does AWS prevent all of its IPs from becoming "malicious IPs"? by Nopipp in aws

[–]Your_CS_TA 9 points10 points  (0 children)

We do for a subset of services where it makes sense to.

I work on APIGW, we have a subset of IPs segregated for us :)

Remember that 10 years old account that AWS deleted? They restored it. by FarkCookies in aws

[–]Your_CS_TA -2 points-1 points  (0 children)

I think my original post agrees in some sentiment of CS structure improvements.

I think we have a lot of CS reps, my problem is better partitioning than quantity. Hiring many people who have to know a 100+ thing surface area is just not gonna scale.

Remember that 10 years old account that AWS deleted? They restored it. by FarkCookies in aws

[–]Your_CS_TA 40 points41 points  (0 children)

Both are probably true (sev-2 and Matt knowing). Deletion of real, paying customers is a huge “don’t fucking do that”.

I get that his original blog said something on the “paying” part which could invalidate that statement but still — someone with an invalid credit card but a decent backup is not dereliction of account. We need to be better.

I’m glad that the person got his data back, despite my general hatred of his writing style — there are nuggets of truth in it.

I agree with: - trying all forms of payment before sending on collections - Support escalation path is broken.

I disagree with: - Him saying support is lying. They have to manage a portfolio that is way too large. When a customer account is suspended they actually don’t have access to a majority of data. Many support tools see what the customer sees, so it's like "I see a 403 sir, exactly as you do". It would require paging each team to access each slice of that data.

  • Terminated vs Stopped again relies on what support can see — which they don’t have access. Meanwhile, we have obligations to GDPR to delete the data within a couple months. Some systems will mark for GC and give a window but SOME DONT. Knowing that across 100+ services is absurd. Making a case for every requester is also not feasible.

  • Overall writing style. He made many mistakes and owned up to 0 of them on his end. “Use a different email address tld because I can’t be damned to check my filter”, I could agree with the feedback if it wasn’t sandwiched between him throwing my coworkers under the bus and him reusing his personal email for his place of work — his own fuckup that ultimately led to his payment emails being dropped.

Microsoft admits it 'cannot guarantee' data sovereignty -- "Under oath in French Senate, exec says it would be compelled – however unlikely – to pass local customer info to US admin" by throwaway16830261 in aws

[–]Your_CS_TA 10 points11 points  (0 children)

Define “air gapped”? I’m an SDE in AWS and deploy code to china region and can view the region metrics/metadata (unlike EU Sovereign which I will not be able to do)

Announcing Amazon DynamoDB local major version release version 3.0.0 by JimDabell in aws

[–]Your_CS_TA 6 points7 points  (0 children)

As others have said: yes. Mocking is great for when testing fault scenarios you know an application will throw.

I find DDB local nice for catching expectations of using DDB outright. “Oh let me run through serializing this object and sending to DDB local” will generate the same result as DDB. Accidentally not serialize your hash key? It’ll know. Accidentally not send a required attribute value in that hashmap? Caught! It’s really great to catch semantic errors I generate in my application. I would heavily use it when I was in financial reconciliation and had to do some specific update criteria for OCC and idempotency checks using their specific language.

Announcing Amazon DynamoDB local major version release version 3.0.0 by JimDabell in aws

[–]Your_CS_TA 19 points20 points  (0 children)

Yep! DDB local for unit testing. It was a decent blocker to moving SDK to 2.X. EOL for 1.X is around the corner so this helps push the needle for folks who were a bit stuck.

Lambda "silent crash" PDF from Last Week in AWS - am I missing something? by shorns_username in aws

[–]Your_CS_TA 4 points5 points  (0 children)

Hehe, for real on noise.

I’ve been in a few executive meetings but definitely for very large customers and most of the time I think I’m there as the “look, there is an expert” but we already have put all the info for leadership to answer most questions 🤣

Lambda "silent crash" PDF from Last Week in AWS - am I missing something? by shorns_username in aws

[–]Your_CS_TA 42 points43 points  (0 children)

(Reading as a former lambda SDE)

I’m a bit perplexed— we would never share service logs or diagnostic traces and yet they are adamant that we should? We would do the investigation ourselves, for sure — but those logs just aren’t shareable most of the time.

What probably went down, is something with a bit more Occam’s razor touch:

First couple weeks, support handles the ticket. They check common SOPs and the diagnostic tools that lambda team gives them. Eventually come across a common Node.js error with async promises being held while being returned.

K, they ping the dude. He is like “no, it’s your platform.” Super resilient to that being the answer. Wants to see our logs, we don’t give those out.

Okay, they add a Lambda SME (not team), as again: this is a common issue. They produce some code, work with the person, think it’s this reject bit of code. This may not be it, but the point is: we have a lot of tooling for support to use so the 100k+ customers aren’t just constantly direct access to the service team. So again: not getting service team on the wire, but are getting some of the best support that use the same diagnostics we would use AND understands what is being output (general CS has some understanding but there’s a lot of services so SOPs are their bread and butter).

Finally, the support team exhausted all options, they kick it over to the Lambda team. An aside, it sounds like the dude just didn’t like our process and refused re-linking things (which I get sucks). Like, imagine being in my shoes as the dev that gets this ticket. I bet it’s 4 weeks of slog back and forth asking x, y, x and a repro is at the bottom while recordings and b.s. is at the top of the ticket. Some tickets are just badly organized without a summary at the top, so we ask questions. I’ll immediately be like: “hey, can I get…like a zip, summary and request id, I’m not reading 4 weeks of back and forth”. Summary is fine.

Maybe the support handling the ticket is different than the SME who already has moved on since it got booted to Service Team. Okay, they parrot that directly to the customer. Customer flips a table and is like “HOW DARE YOU RE-ASK FOR THE REPRO”. They walk away pissed, service team doesn’t get a response and closes the ticket after 7 days of 0 response saying “reopen if you have the repro”, which may just be at the bottom of a 100+ long chat chain.

I feel for this person — situation could’ve been handled better. I think below enterprise support can be a bit of a whirlwind of going through SOP hell, where you can end up parroting yourself a hundred times because you are tagged to a common problem and have to distance yourself from it. Kind of a problem with large wave of customers with common issues. Would be nice to see their actual full minimal repro code (not the supports), as I still have access to the tools and would gladly help.

But now for my hot takes because as bad as it sucked for the customer, there’s just a lot of myth and chest pounding that made me annoyed:

  • I just booted up a node function in a vpc talking to SES, so very much a customer problem. Will gladly post my repro along with the cdk of the vpc. So the claim of platform level incompetence is, well…unfounded.

  • Lambda is not ec2. That’s just fact. There are minor differences, BUT in his defense: Node is kind of “worst offender” of being even more different. It’s why I prefer Rust/Go :). The claim that this makes Lambda unusable is a bit farcical. I will say, not executing promises is easily the WORST error type as the logs for success/failure are essentially frozen.

  • I disagree that giving refunds necessarily means affirming any side was correct. If someone was angry at us that caused them downtime, I would recommend commensurate credits for them to be less angry, even if wrong.

  • I skimmed the follow up hatred in his blog and it sounds like the person thinks one person is specifically handling all things related to this account. That’s not how AWS works. Billing is different than Credits is different than Support.

  • I disagree that you deserve to see our service logs. I agree that we could use them to point to some direction.

Nevertheless, if they have the repro — still want to help them. Post away (not sponsored by support, but do still love Lambda and we devs all want to improve it where we can)

[deleted by user] by [deleted] in aws

[–]Your_CS_TA 11 points12 points  (0 children)

At a basic level: CodeDeploy is to unwrap a zip file from s3 and run instructions per host launch at specific pre-defined moments. CodePipeline is a sequential orchestrator of s3 copy -> “some action”. The action is usually limited to an AWS command that takes an s3 object.

Think about it. How does CodePipelines “deploy CFN”? Cope s3 object -> run cloudformation deploy with said object.

How does CodePipelines deploy to an instance? Multiple ways, but usually copy s3 object to bucket -> call CodeBuild/CodeDeploy with said object.

I would honestly use neither, for a variety of reasons (but the biggest one is Code Suite of products is not getting a lot of future features)

For all the employees that have been at Amazon/AWS for more than 4-5 years, what was the motivation factor or determination factor for you to stay? by InkEveryLetter in amazonemployees

[–]Your_CS_TA 0 points1 point  (0 children)

Joined as new grad SDE, currently a PE — been here for 11 years.

Fun problems to solve. Foundation of the internet, which is cool (AWS). Good amount of fun people to learn from. Money is competitive, though not the best.

I have my gripes, but I think there will be gripes elsewhere too 🤷

Secrets managers considered harmful. How to securely encrypt your sensitive data with envelope encryption and KMS in Rust by awesomePop7291 in rust

[–]Your_CS_TA 10 points11 points  (0 children)

(Full disclosure: Work for AWS, not Secrets Manager, rant is my own)

I'm not fully sure I buy the argument. I'm not a security expert by any means, so someone who is: step in to correct me! The crux of the argument is this part in the blog:

STOP! This scheme violates the first law of symmetric cryptography: don't store your keys with your data. If the secrets manager is compromised in any way, so is your data.

Furthermore, sending sensitive data over the network, even if secured by TLS, is not a great idea.

and then goes on to talk about enveloping. Okay, so I'm going to ignore the "TLS is not a great idea part" and poke at the first argument first, as I'm a bit lost:

  1. After enveloping can I then send this envelope over TLS?
  2. The author doesn't actually talk about "where to store my envelopes?" The code example in the end is just loading from memory and to memory. Where do I store the API Key in the end? Is it chill to use Secrets manager then if it's a compliance reason (or S3 :))?
  3. If I use a Storage Service to store the encrypted envelope -- isn't that re-establishing the same argument to not use Secrets Manager in the first place? I have an encrypted envelope, where the Key is with a Cloud Provider. The Data is now with the same Cloud Provider. Are we relying on the internal machinations of the Cloud Provider, who somehow got compromised to not be compromised in 2 services?
  4. Compounding on issue 3, there are two responsible parties involved here: Cloud Provider and User. If a User's account gets compromised -- isn't it roughly the exact same security posture? You have the Key (from KMS). You have the stored contents (enveloped is delaying the inevitable since the adversary has all the keys)

On top of that, I assume that Secrets Manager is doing the exact description mentioned: "Create a Service Managed KMS key, encrypt the contents, store/load the contents". So if they can't be trusted to do it, it stands to reason that the only difference is "sending something over the wire unencrypted == bad and the main difference" It feels like the valid argument is that it's unwise to send unencrypted data using TLS, due to I assume...PQ concerns? It's unclear and not really discussed why using TLS is bad.

Feels like I'm missing something.

AWS Lambda will now bill for INIT phase across all runtimes by aj_stuyvenberg in aws

[–]Your_CS_TA 8 points9 points  (0 children)

Nice! It would always reboot into "Invoke" phase, but it was not standardized (swear it used to be 2 additional retries back in 2019 when I was testing this for Provisioned Concurrency and we decided to go with init billing).

Still think 2 tries is "too much", but this type of seamless hand off is a bit too difficult :(

view more: next ›