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".
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.
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.
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.
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?
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.
Hello, this is Jean from Akita. You're right that running Akita as a sidecar does incurs extra compute. Whether or not this incurs extra cost on Fargate depends on whether it's necessary to switch to a larger instance. In zMatch's case, the answer is no. In general, it depends on how much traffic you're sending through Akita.
Something to point out is that Akita passively watches traffic and doesn't sit in the path of traffic, so there's no impact on latency, unless the task is at 100% CPU utilization.
We run very similar scaffolding to host different workloads, except we run it on ECS, so you could complicate reference diagram even further.
In reality, when we had to add Wordpress to our workloads, there was nothing special we had to do except for introducing EFS. All our workloads before that didn't require keeping state on a file level.
And just like that we had a scalable/HA Wordpress setup with pretty decent performance.
AWS has Aurora Serverless (https://aws.amazon.com/rds/aurora/serverless/) for that purpose with MySQL and Postgres compatible engines. But I haven't heard anyone using it for side projects yet.
Note that you can either run Aurora Serverless constantly (at a cost of about $43 a month) or have ~30 second startup times if the instance has timed out (~15 minutes).
They also have RDS Proxy (https://aws.amazon.com/rds/proxy/) that lets you pool connections from tons of lambda instances in order not to overwhelm your DB when scaling up.
