This is the first in what I hope will be a series of posts on using out Amazon Web Service (AWS) in the wild. I’m writing it for anyone who finds themselves in a similar situation to me, i.e. relatively new to AWS but with significant technical exposure to other on-premise and cloud provider automation.
I’ve been given a great opportunity recently to join a startup that are embarking on their AWS journey, therefore much of the content of these posts is inspired by the challenges I’ve hit, where answers to the questions I’m asking doesn’t seem widely available.
Identity and Access Management (IAM)
I’m not going to attempt to explain IAM in detail here, there’s plenty of (dry) material available from AWS themselves and some incredibly accessible training over at https://acloud.guru.
AWS IAM naming conventions
I like naming conventions, however I don’t like the arguments that naming things cause, naming is hard, as Martin Fowler and friends remind us . To solve this, setting a convention early on when embarking on any sizeable infrastructure work, cloud or on-premise gives everyone a pattern to follow from that point. I have found starting with the following in AWS for IAM makes sense.
|User (person)||(PascalCase) |
FirstName then Surname
|User (application)||(PascalCase) |
'App' followed by the internal application name
|Optionally add a verb to the application user name if multiple, more granular user accounts can be used, e.g. AppPricingAPIWrite.|
A noun (or AWS service name) describing the area of access followed by a collective noun describing the level of user access.
|Where possible I ensure the first noun matches the language used within AWS, i.e. account-administrators, not system-administrators.|
The trusted entity (AWS service or other AWS account name) followed by the application name, followed by a summary of the combined policies access
|An instance can only be associated to 1 role.
1 role can be attached to a maximum of 10 policies.
Maximum of 64 characters.
I haven't tested these conventions with roles used to permission users using the Web Identity or SAML providers.
Organisation name (or account name) followed by AWS service name (optionally followed by target service name for e.g. with replication) followed by summary of access level actions
|The organisation name (or account name) should ideally match that used when defining your resource tagging.|
A few notes
- I purposefully use kebab-case for policies as it makes it immediately obvious they are are not built-in AWS policies.
- I use kebab-case for groups and roles to be consistent with policies.
- I use PascalCase for names as using non-alphanumeric characters has burnt me in the Windows world and it still hurts.
- I don’t use any special characters in any names (excluding a hyphen) as again I feel it unecessary.