AWS policy descriptors are certainly robust enough to handle something like this. These frameworks are built for hackathon type projects where you are just using a personal AWS account and you don't care about fiddling with permissions. Try getting access to an Administrator user/role at a big company.
To back up my first point, the framework owner could easily instruct users to set up a temporary user/role that creates the initial function roles/policies as one-time setup. Then a user/role with only the service-level permissions (Lambda etc.) could manage all the actual resources.
The devs who build these frameworks want them to be super simple to use, otherwise they won't retain users!
AWS policy descriptors actually aren't, that I've seen anyway (I'd invite you to provide a counter example though; I'd -love- to see it, because it's something I'd definitely use). In IAM, you have an action, and a resource. I can create a user that has access to CreateRole and CreatePolicy, but I can't limit what kind of policy that user can create. There's no way to say "This person can only create a policy that involves the dynamodb:, lambda: actions, and no others", for instance. They either have access to create any policy, or they can't create any.
And to your first point, it's not just being super simple though; fundamentally you have to have that admin access to be able to deploy initially.
After that, sure, provided you make no changes to the policies, the framework could theoretically diff the policies with just the iam:Get* actions applied, ensure they're the same, and deploy without touching it. But you get into weird situations where you decide "oh, this function now needs access to Dynamo, so let me modify the policy for the role the lambda is executing under", and now you have to have admin credentials again. Any new resources in AWS you want access to require you to have the iam:PutRolePolicy action, which, given you already created it and attached it, is again equivalent to admin rights, and the ability to do anything.
No way you're getting 15 ms on a TLS connection over the internet. I've set up similar pings with API Gateway and API Gateway -> Lambda, and it seems with the APIGW the TLS connection is the most expensive part. On an established connection I've seen 10 ms overhead which is not great but worth the value in some cases.
Is your 'Bare EC2' over SSL? I've used Apex Ping as well (btw it runs on Lambda), and it seems they open a new connection on each ping.
Getting 15 ms latency on a brand new TLS connection is nearly impossible over the internet. If you actually check the latency breakdown on your Ping, you'll see the TLS handshake is dominating the API Gateway -> EC2 request.
I'm all for this type of analysis, but too often it isn't apples to apples.
Apple doesn't want everyone to switch to lightning. They are banking that bluetooth will eventually be the 90% even 99% standard among consumers. I tend to agree.
The case provides 24 hours of battery life. If you're in a situation where your case has no battery life at all and your airpods have no battery life at all, they take 15 minutes to charge.
The AirPods are bluetooth. I think that has been a point of confusion. Also, 5 hrs may not seem like much but 24 hours w/ the case is a lot more than comparable bluetooth earbuds. And I really love the idea of a battery case: extend battery life, no connector on headphones, keeping them in the case may make it harder to lose them.
Thanks for clarifying the point about the bluetooth - this definitely got buried for me. The case is a good stopgap for improving battery life, but I still think they need to last 10 hours on a single charge to be really useful. For instance, 5 hours won't be enough for a plane trip if you include the time it takes to get to the airport/arrive at your destination. If they can just last a little bit longer, I'd be more on board with the change.
WWW-Authenticate is a requirement of HTTP itself, not Basic Auth. Returning 401 without this header (which API Gateway does) violates RFC 7235. It is the means by which HTTP negotiates an authentication protocol; without it, there is no way for authentication to proceed except by guessing.
And plenty need to serve non-UTF8 data, such as images, or documents with a content encoding (like the GP was trying to). Sure, "JSON toys" is a bit hyperbolic, but "HTTP service that can transfer media" describes some double-digit percentage of all web services. API Gateway may fully support many use cases, but in my mind it's a toy until it supports this major one.
(Note that it's not like API Gateway claims up front "JSON only!" or some such. Outbound binary data just silently gets garbled and the only mention of this limitation is buried in various threads on the forums.)
