Hacker News new | past | comments | ask | show | jobs | submit login

It's likely using an IAM role with no permissions other than writing logs to CloudWatch.



OK, so they're effectively reselling Lambda, and creating a new Lambda account for each Twilio customer under the hood?


> they're effectively reselling Lambda

Another take on this is that they're creating value for customers by shifting the reliability requirements from the customers themselves to AWS / lambda

... which I think is brilliant.


I hacked together a quick demo using Ruby, Sinatra, and Heroku with Twilio this last weekend and the whole time I was thinking "Heroku makes this easy, but having to host a server makes this harder to debug".

I feel like this new feature will make it super easy to work with Twilio. It's almost a no brainer.


Or you can keep the Ruby stack and just use ngrok in dev. :-)


Trust me, I love Ruby and ngrok works well, but I think a serverless setup is a lot simpler (at least in my mind). I was actually using Twilio to test a Ruby library of mine and set up a text service for product registrations for a CRM. It works freakishly well.

But despite all that, I feel like setting everything up in one place would be a lot simpler.

Now if Twilio had a way to deploy serverless functions via git... that would be a clincher.


It could all be under the same AWS account, and all using the same IAM role. It's just that the role doesn't have access to anything. It can write logs to its own function-specific log group and read from them potentially.

Also, a hell of a lot of work went into this feature. You can try setting this infrastructure up yourself if you think it will save you money. You already know they're using Lambda!


My comment wasn't intended as an attack. I was just curious about their approach to sandboxing, as it's my area of expertise.

Sometimes systems that are secure with two parties become horribly insecure when you add a third. I don't know a lot about IAM but generally I'd be very cautious about using standard access control mechanisms to implement sandboxing while running the code "in your account", as often you find resources are made available to "the whole account" with no further access control settings, because the system designers didn't imagine customers running true third-party code.

That said Amazon has some pretty thorough access control features and I'm sure Twilio has looked into it and figured out something reasonable.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: