Naming resources

[marsavar]

Hi DevX!

Opening this discussion following an unintended behaviour I discovered after I introduced GuFastlyKinesisLogRoleExperimental, an IAM role that lets Fastly write to a Kinesis stream specified by the consumer of the construct.

In order for Fastly to write to a Kinesis stream, a policy needs to be attached to the role. The policy I have created has a fixed name, meaning that attempting to cloudform two GuFastlyKinesisLogRoleExperimental results in a naming conflict.

Several approaches can be taken to address the issue:

@akash1810 suggested the following options

1. Remove the explicit name, in favour of auto-generated name
2. Do not create a separate IAM Policy, instead create an inline policy on the IAM Role
3. Move to singletons
4. Add the id to the name

@nicl suggested checking if the policy exists and use it instead of creating a new one with a different name (this, I think, is the same as point 3 above)

@philmcmahon suggested prepending a variable to the id so that it is unique, as done in the Lambda construct. (same as point 4 above)

I also suggested passing the name of the policy as a prop to the role construct (if so, should it be a mandatory prop, or optional?)

Another idea that was floated is to use an inline policy instead of a managed policy. However, according to the AWS documentation, "If a policy could apply to more than one entity, it’s better to use a managed policy." Our use case involves newing up two separate roles, each responsible for writing to a separate Kinesis stream, so it seems that a managed policy is probably better.

There are pros and cons to each method, and I hope the below summarises them:

Remove the explicit name, in favour of auto-generated name

Pros: easier for consumers, as they won't have to come up with a new name
Cons: less discoverable in the AWS console?

Do not create a separate IAM Policy, instead create an inline policy on the IAM Role

Pros: fewer constructs = less maintenance burden, also no need to name the policy
Cons: discouraged by the AWS documentation if the inline policy applies to more than one entity

Move to singletons

Pros: reusing existing resources instead of creating two or more that do essentially the same thing
Cons: more complexity?

Add the id to the name

Pros: unique identifiers
Cons: ???

Passing the name of the policy as a prop to the role construct

Pros: more fine grained naming control
Cons: duplication of policies that do the same thing, but have different names. Breaking backward compatibility if introduced as a mandatory prop.

I would like for us to reach a consensus before I raise a PR to address the specific issue at hand, and eventually making the decision into a precedent (crystallising it into a style guide doc, as suggested by @akash1810), so that future contributors to GuCDK will apply the same rationale when introducing new constructs/patterns to the library.