My friend Matt Zeitlin was recently bemoaning a terrible UX in AWS — controlling permissions for an outside contributor.

(By the way, Zeitlin has built this very cool website for group chess lessons, if you ever need an idea for a group activity — https://rookly.com/)

In Zeitlin’s words:

It would be great if I could quickly give Flank access to run a specific Lambda without full Lamba access. If I knew that they couldn’t accidentally touch something unrelated, that would give me peace of mind. I know it’s possible, it’s just not easy.

Starting from the Lambda

There are two ways to approach this problem. The first is to go to the Lambda itself and configure permissions from there.

The table of Lambdas is useless

When Matt goes to the Lambda page, he wants to quickly expose one Lambda to one user. Because he’s thinking in terms of user permissions, he might even be searching for that Lambda in terms of existing permissions. Where is the Lambda that I exposed to John last week...?

Instead, he’s confronted with this page. He can’t do what he wants from here…

... so he selects a row, and clicks "Actions". But his action is not one of The Actions!

Comparison: Dropbox

Now compare this with Dropbox.

In Dropbox, the permissions of each row are displayed on the table. And each row has a […] button that reveals a myriad of possible actions (including Sharing)

If you do click on a row, a variety of new options appear up top. The most common actions are buttons that are one click away. (”Download” is more information than simply “Actions”)

The Lambda drilldown is missing "actions"

Back to AWS — when he drills down into a Lambda, the main call to action is another “Actions” button, but it doesn’t contain the action that he needs!

The REAL action is two levels deep

So, instead, he has to go two levels deep, to find a Permissions tab

As a quick aside, the “Function Overview” still takes up 75% of the screen at this point, even though it’s clearly not relevant to permissioning.

"Permissions" != IAM

This is where things get fun. On this tab, the call to action is an “Add Permissions” button. Guess what? These permissions have nothing to do with IAM permissions.

If you have an existing IAM permission on this specific Lambda, you might expect it to show up here. It does not. If you create a permission here, you might expect it to show up in IAM. It does not.

Starting from IAM

The second route is to start in IAM, with the user, and to give him/her permissions on a specific Lambda.

The User table is equally useless

The user table faces the same problem as the Lambda table. You just can't do very much from this level.

"Add permissions" is a... child... of "Add permissions"?

When Matt does drill down on a user, he’s presented with a confusing dropdown. What’s the difference between “Add Permissions” and “Create Inline Policy”? 🤷

Assuming he does know the difference, he can finally reach the Create Policy tool.

If you squint...

But midway through this flow, there is one thing on the page that HE MUST DO. And how is that displayed? It’s hidden as a small link in the middle of the page, outside of the normal flow of action. Very easy to miss.

Open a new tab, search, drill down, then copy + paste

Assuming he does find that button, he then has to go find the Lambda ARN and copy + paste it back into this bizarre two-way input.

Extreme Lambda Makeover

As they say, a problem well-defined is a solution half-defined. So, there isn’t much work left…

Change #1: Dropbox style table

First, bring permissions (actions and information) up to the list-level, like Dropbox

Change #2: Side panel for editing table

Then, bring out a side panel that allows Matt to choose what permissions he wants, followed by who gets those permissions. We could even reuse the “pick permission” and “pick user” components from IAM.

Looking better!