A map of Ironman events - https://www.tricutlets.com
Readit NewsHad this bite me for my small-scale personal AWS setup. Have an AWS account I run some personal sites on, a Mastodon instance, etc. Got some Billing Alarms I setup that my bill went from normally $100 to $180. Got a $75 charge for USE2-ExtendedSupport:Yr1-Yr2:MySQL5.7 I mean I'm very used to Amazon's ridiculous fee structure but even this one caught me for a loop.
To be fair to AWS, they announced the deprecation of MySQL 5.7 in January 2021, and many emails warned of this change throughout 2024.
Twilio has been complicit in this problem for years, and up until very recently put 0 effort behind tooling to allow customers to block it off from the top.
Instead the world toiled away on what is surely several hundred engineer lifetimes of hours building the same fraud guard solutions in front of Twilio.
Wonderful piece of propaganda that Twilio can put out to pretend to be a thought leader in the space while turning a blind eye to the tens of thousands of dollars of fraud passing over their wires on the daily.
Couldn't agree more. Twilio has been profiting from these scammers for years. We had several calls with our account manager and "fraud expert", and the answer was always the same - migrate to Twilio Authy. The problem is that with Twilio Authy you are basically paying the same amount, it's just that the cut or "protection fee" is not going directly to scammers, but to Twilio.
The last time we talked to them, they bragged about how good their algorithm to detect fraud is and that we should take advantage of it by onboarding to Authy. I asked them why they just don't offer it to all customers, since their platform is enabling scammers. And the manager said, I'm paraphrasing here, "well, we are for profit company".
Huge problem we see at my current company, Stytch (https://stytch.com/). Toll fraud/traffic pumping can result in huge costs, mid thousands to millions per year.
One thing that surprised me a lot to learn, and is covered in the article, is that the primary bad actor is the telecom provider! I had no idea that the telecoms were sharing revenue with hackers that found unprotected SMS channels and exploited them. A really wild thing.
We have a bunch of built in protection against SMS toll fraud for our OTP product as well as more in-depth fingerprinting tools if your app ever runs into this problem. When you get that first surprise bill from Twilio, give us a shout and we can help!
Happened to us as well a while back. We tracked originating IPs to the same telco that was sending SMS to their own numbers through our platform. I couldn't believe it.
Does GitHub provide uptime stats? Seems very unreliable recently.
https://www.githubstatus.com/history seems to show incidents in the last 3 months:
* March - 20 incidents
* April - 12 incidents
* May - 4 incidents (so far)
steelaz commented on Billion-record stolen Chinese database for sale on breach forum theregister.com/2022/07/0... · Posted by u/ellen364
same here, but we still have IAM Users for service accounts. E.g. some customers have on premise infra that needs to talk to our services of infrastructure.
Do you know a way where RBAC can be used for the above?
For us, we're using long lived credentials in this space using IAM Users but with very tightly controlled authorisations.
"IAM Roles Anywhere" was announced just a couple of weeks ago. It might be applicable to your case.
https://aws.amazon.com/about-aws/whats-new/2022/07/aws-ident...
steelaz commented on Billion-record stolen Chinese database for sale on breach forum theregister.com/2022/07/0... · Posted by u/ellen364
Doesn't the client still need to know a long-lived secret (or a long-lived refresh token) in order to generate the ephemeral credentials?
We got rid of all IAM users used by applications and moved to role-based access. Nowhere in the application do you need to enter AWS credentials. AWS SDK will attempt to discover short-lived credentials for you and will assume the role specified at the infrastructure layer, e.g. in a task definition.
Not from the company but we do something similar with opentelemetry. It’s true, because you pay for the total allocation of CPU/memory on Fargate, so you can add a sidecar container into that total allocation with a small deduction from the amount left available to the app itself.
E.g.
Before: 512MB for task, 512MB available for the application
After: 512MB for task, 412MB available for the application, 100MB available for sidecar
Yes, but even in your example, that's 20% of resources going to the sidecar. Not to mention sizing correctly multiple containers in a single task gets complicated.
This is cool product, but but I don't undersatand this statement:
"Importantly, Akita did not impact processing loss or extra costs inside AWS, a main concern at our company stage."
Author specifically talks about AWS Fargate and links to Akita docs where it says in AWS Fargate setup, Akita agent should run as a side car in each container you deploy. How can that not bring significant amount of extra compute cost?
This makes budgeting & forecasting difficult to impossible for a lot of teams, and creates wrong incentives. It is better to have a per user pricing, and then allow them to use as much as they want.