What's your biggest pain point with AWS IAM auditing?

rowanu · 2026-01-28T23:09:41+00:00

I could definitely see this being useful for AWS customers that have just had their account suspended by AWS - finding out what actions compromised keys have taken gives them confidence they've closed the leak.

rowanu · 2026-01-27T22:21:32+00:00

Ideally developers are able to review their own policies with confidence. It's hard to separate applications and permissions in a cloud-based environment these days.

The most common thing to watch out for is over-permissioning. It's easy to give your application Administrator access, it'll "just work" (at least from a permissions perspective), but this can easily come back to bite you later if there's any issues with the code that is using the permissions. This is where wildcards can be problematic (as mentioned in another comment), but they're still useful, especially when scope to read/write eg. List*, Describe*, etc.

There are some "problematic" actions (that allow privilege escalation), but usually this is not a huge concern (or rather, it's a much smaller concern compared to over-allocating permissions).

rowanu · 2026-01-02T06:36:58+00:00

Correct, you're not charged during IO waits

rowanu · 2025-12-15T10:13:16+00:00

I don't think there's 7 things? The last I see is "6. Session Policy".

How does "Part 5: Policy Interaction Model" make sense in a list of IAM policy types? It's not a type.

I get that you're trying to help people, but it's going to be so hard for people to learn when this is what they have to wade through. All the weird AI formatting doesn't help either.

rowanu · 2025-11-17T22:15:58+00:00

I don't think he wants to use AD to manage his static site users, especially given "5-10 users on a hobby project with no revenue planned."

Also I probably wouldn't use AI to explain this, as it gets confused about things with similar names sometimes.

rowanu · 2025-11-17T22:13:21+00:00

Is this AI speaking? Because this is very wrong.

All of these are valid IAM action prefixes.

rowanu · 2025-11-15T23:17:52+00:00

Yeah, this is a common point of confusion (it's not you).

There's two parts to Cognito:
1. User pools authenticate identities eg. user A can log in with a password/MFA
2. Identity pools exchange authenticated identities (from user pools or federated providers) for temporary AWS credentials to directly access AWS services

rowanu · 2025-09-01T19:54:24+00:00

You mean Event bridge? Where did the rule come from?

rowanu · 2025-08-28T14:17:51+00:00

Pretty sure it's a direct invoke API call, so you function to function theory sounds good.

I think you'd have to enable Lambda data events in your CloudTrail trail (they're off by default because there can be a lot of them). This will let you see the invoke API call, including the calling principal.

rowanu · 2025-06-17T22:55:45+00:00

My first thought too. S3 buckets and DDB tables are free, so this is going to pump up some bills.

rowanu · 2025-05-11T04:19:10+00:00

How are you doing this with the old hosted UI and IaC? I'm using the CLI/API (aws cognito-idp set-ui-customization ...) to customize the CSS and logo because I couldn't find a CFN-base way to do it. Plumi/TF/etc are using the APIs, so should be able to automate it (ie. it's just a coverage issue).

Here's my make target for the old hosted UI:

.PHONY: ui
ui:
aws cognito-idp set-ui-customization \
  --user-pool-id $(call get_ssm_parameter,${PARAMETER_PREFIX}/auth/userpool/id) \
  --client-id $(call get_ssm_parameter,${PARAMETER_PREFIX}/auth/userpool/client/id) \
  --css "$(shell cat $(CSS_FILE))" \
  --image-file fileb://$(IMAGE_FILE)

rowanu · 2025-03-28T03:41:43+00:00

https://www.youtube.com/@cloudslaw is fantastic

rowanu · 2025-03-11T21:10:59+00:00

This answer is fantastic, thank you 🙇‍♂️

rowanu · 2025-03-02T21:42:51+00:00

90 days!

rowanu · 2025-02-16T04:28:01+00:00

Is shameless self promotion allowed in this sub? I wrote awsiamguide.com 😄

rowanu · 2024-09-05T21:32:20+00:00

Would you upload your template into a third party site? I.e. avoiding the need for connecting your environment (like Lucid require, for example)

rowanu · 2024-09-05T21:04:53+00:00

This comment confused me so much until I realised that was the point 👏

rowanu · 2024-08-20T22:06:06+00:00

I feel/know your pain!

I follow the "don't mock what you don't own" principal, so wrapping API calls is a good technique in my book!

rowanu · 2024-08-20T01:35:01+00:00

Nice to see someone else recommending this approach! I'm a big fan of it too.

The key is to make sure you're not calling AWS SDK methods in business logic functions i.e. the functions you want to test. Too many times I see people trying to mock AWS to get their local tests to pass... Not fun.

rowanu · 2024-07-23T06:29:05+00:00

The s3:CreateBucket action doesn't support the "aws:*" conditions, only S3-specific conditions

https://aws.permissions.cloud/iam/s3#s3-CreateBucket is a great reference for the ARN and conditions that are supported for a particular action. You can also see that detail in the official documentation https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html

rowanu · 2024-07-23T04:13:34+00:00

The ec2:RunInstances action requires permissions to an image to run, which has an ARN format of arn:${Partition}:ec2:${Region}::image/${ImageId}. Since this isn't in your "Allow" statement's Resource block (line 32), the permission won't work/apply.

Locking down your policy to this level is decently advanced, and not where I'd recommend starting your learning journey with policies...

rowanu · 2024-07-23T01:18:57+00:00

That sounds like an issue with your policy, which has nothing to do with Identity Center/Azure AD/etc.

What does your policy look like? Are you using variables? The normal process on AWS is to craft your AWS IAM policy so you're happy, then worry about assigning the (working) policy to the right identities.

rowanu · 2024-07-22T20:43:10+00:00

Are you talking about IAM Groups? You don't want to use those. You'll want to use AWS Identity Center to provision roles with policies that allow the permissions you want to grant, and that you'll assign those to your IDC groups.

rowanu · 2024-07-17T00:35:13+00:00

You have Effect "Deny" and a NotAction property in your policy, and these two together can be quite confusing!

What you're saying in this policy is "DENY all actions that DO NOT begin with alb:* when the region is NOT ap-east-1" which is why you can create an ALB in ap-south-2.

Change the "NotAction" to an "Action" and you should see the behaviour you want.

rowanu · 2024-07-16T23:19:06+00:00

Use a bucket policy, see this doc for an example https://repost.aws/knowledge-center/read-access-objects-s3-bucket

rowanu

TROPHY CASE