Ben Kehoe Profile picture
Soon to be at Siemens | Former vacuum salesman | AWS Serverless Hero | views my own
Dec 27, 2021 8 tweets 2 min read
Living the serverless dream: Christmas Day 2021, when everybody who has bought a Roomba since Black Friday opens them in about a four hour window on Christmas morning, was completely hands off keyboard for us. Literally nothing needed to handle the massive influx of traffic. To give you an idea of what the spike is like, here's a graph from a previous Christmas that we've shared in the past: A graph showing large spike in registrations on Christmas Da
Oct 4, 2021 10 tweets 2 min read
I want to dispel this notion that what happens around `aws sso login` is analogous to storing temporary SigV4 credentials for IAM roles in ~/.aws/credentials. The difference is about refreshing credentials. 1/ `aws sso login` performs *interactive* authentication (via the browser), which results in an OAuth token that lasts for the duration of your login session. It is not a refreshable or repeatable operation—once that token is expired it has to involve you again. 2/
Sep 7, 2021 9 tweets 2 min read
v2.8 of aws-assume-role-lib has been released.
- Better region selection (minor backwards incompatibility)
- Export creds on command line (please don't)
- Simpler PolicyArns syntax
b/c of the breaking change, compatibility version has been incremented. 1/
github.com/benkehoe/aws-a… Previously, the default behavior for the child session region was to take an explicit region from the parent if there was one, otherwise use the normal region config. When using a config profile, this meant the parent session region wasn't carried over. 2/
Apr 3, 2021 4 tweets 1 min read
I recently learned that if you pour those boxy liquid containers like for nut milk with the spout side on top rather than bottom, they pour smoothly, and my life is measurably better for this information It makes perfect sense, with the spout on the lower side, the glug-glug pouring is the air forcing its way in through a spout totally blocked by liquid. With it on the higher side, the air can go over the top of the liquid to the air inside. But this had never occurred to me
Nov 27, 2020 11 tweets 2 min read
I want to talk a bit about what this was like.
tl;dr: it was *long* and inconvenient timing but, as an operations team, not particularly stressful. Questions of “when”, not how or if systems would come back. A lot of waiting and watching—and that’s desirable. Wednesday, there was not much to do. AWS IoT was hit hard by the Kinesis outage, which meant lots of stuff was simply not going to work. And CloudWatch outage meant we couldn’t see what was and wasn’t working cloud-side.
Jun 30, 2020 10 tweets 2 min read
When doing infra as code, you want to plan your deploys around what infra state—that is, resource graphs—you want to achieve, not around what graph manipulation your tooling restricts you to. To that end, here's a maturity model for CloudFormation support for AWS services 1/10 Stage 1: CloudFormation support at launch, for every launch. For cloud-native customers, if it's not in CloudFormation, it doesn't exist. This should be table stakes at this point. But it's not, so let's make it a milestone. 2/10
Mar 8, 2020 10 tweets 2 min read
AWS SSO has a naming problem. It’s going to quickly be the best way to enable access into AWS *using your own Single sign on identity provider for authentication.* Its capability to be an IdP or single sign on provider to other apps is not where its value lies for most people 1/ Today, you need your IdP to understand everything about access into AWS—the mapping of people to accounts and roles, because that information needs to get packaged up in a SAML assertion. Size limits on the SAML assertion make sensible multi-account setups hard. 2/
Jan 26, 2020 8 tweets 2 min read
AWS has been adding a lot of features to use OAuth directly with API Gateway, skipping Cognito Identity Pools and AWS IAM. I think this is regressive. A lot of useful functionality is coming out of it, but we should hope to get that IAM-side instead. For example, using OAuth, you can define allowed scopes on a given route (resource+method). Now you've got attribute-based access control in your app. Great! Except all the excellent tooling around AWS IAM is no longer available to you.
Dec 21, 2019 10 tweets 3 min read
Extra excited about this now. sso:GetRoleCredentials takes account and role name parameters (weird that it's not a role ARN but whatever). This looks to me like the client is in control of what IAM principal the user will become. This is a good thing! ⏬1/9 A great enabling capability for an org is creating single page apps w/ serverless backends, and now with these APIs in JS those apps can use SSO. One of the difficulties with these apps is that there may be many copies of a given app, for dev or just in many different accts 2/9
Jun 14, 2019 6 tweets 2 min read
One of @awscloud's biggest weaknesses is that while product teams strive to create great experiences for their services, AWS users have to use many teams' services and there's very little accountability for the cross-AWS-team experience. AWS is the best in the world at creating autonomous teams. We’re asking AWS to figure out how to scale their customer obsession in a way that cross-team feedback is appropriately prioritized.
Feb 18, 2019 5 tweets 2 min read
Statelessness is not the critical property of #serverless compute, it's ephemerality. Being positively limited in duration means the provider can *transparently* manage the platform, no scheduled (or unscheduled, in Fargate's case) downtime needed. Currently, most serverless compute is time-limited, run in response to fixed-size(-ish) events. But finite-input-limited compute is possible; this is AWS Batch's model.
Jan 24, 2019 6 tweets 2 min read
I am wholly against this mindset. It downplays the operations and maintenance burden assumed by building something yourself. Looking at TCO, it's almost always a better option to accept the 80% fully-managed-service solution than take on all the extra burden of a custom build By building something yourself—and even before that, setting up infrastructure like k8s b/c you're *planning* that you'll want to build things yourself—you're spending resources on technology problems. You should instead by looking for ways to keep focus on business problems