3 ms·

In my opinion, the most annoying thing about AWS networking - and some other services - is that they often use IDs and do not show labels which forces me to rem

by cygned 8y ago

In my opinion, the most annoying thing about AWS networking - and some other services - is that they often use IDs and do not show labels which forces me to remember them partly, go back and forth or have multiple windows open. The AWS console is not the best UX piece on the web, but this part is especially error prone.

bmurphy1976 8y ago
Having to reference security groups by id instead of name in cloudformation stacks, terraform, and a variety of other places is one of the most infuriating things. Makes everything much more difficult to configure and maintain because the IDs are so opaque and unique. Somebody has to do the grunt work of looking them and and copy/pasting them or writing scripts to propagate configuration forward. What a waste of time and effort.
- chrisacky 8y ago
  I agree, it's frustrating. However, considering you can share security groups, and even share VPC as a resource to different AWS accounts, and that "names" are non-unique, how would you solve the problem of allowing people to select a non-unique resource and know which one they actually mean. It's a pain, sure, but there's no better solution... explicitness creates certainty in this case..
  - bmurphy1976 8y ago
    You would use the arns. Those are unique but predictable.
- scrollaway 8y ago
  In terraform you should never be using IDs directly unless it's in a variable or, preferably, a data source. The reference should look like aws_something.mything.id.
- mvanbaak 8y ago
  Since you mention cloudformation here my tips to make it easier: - tag all groups so its easier to remember - use Export in outputs so you can use ImportValue in other templates - use only cloudformation, no edit/create/add actions in the console Now the ID thing is 0 problems as you never have to worry about them anymore Same goes for terraform or any other InfrastructureAsCode
iheartpotatoes 8y ago
Agreed. I wish they would use the NAMES that I gave everything instead of the cryptic IDs. On the plus side, I'm improving my memory?

by cygned 8y ago

bmurphy1976 8y ago

Having to reference security groups by id instead of name in cloudformation stacks, terraform, and a variety of other places is one of the most infuriating things. Makes everything much more difficult to configure and maintain because the IDs are so opaque and unique. Somebody has to do the grunt work of looking them and and copy/pasting them or writing scripts to propagate configuration forward. What a waste of time and effort.

chrisacky 8y ago
I agree, it's frustrating. However, considering you can share security groups, and even share VPC as a resource to different AWS accounts, and that "names" are non-unique, how would you solve the problem of allowing people to select a non-unique resource and know which one they actually mean. It's a pain, sure, but there's no better solution... explicitness creates certainty in this case..
- bmurphy1976 8y ago
  You would use the arns. Those are unique but predictable.
scrollaway 8y ago
In terraform you should never be using IDs directly unless it's in a variable or, preferably, a data source. The reference should look like aws_something.mything.id.
mvanbaak 8y ago
Since you mention cloudformation here my tips to make it easier: - tag all groups so its easier to remember - use Export in outputs so you can use ImportValue in other templates - use only cloudformation, no edit/create/add actions in the console Now the ID thing is 0 problems as you never have to worry about them anymore Same goes for terraform or any other InfrastructureAsCode

iheartpotatoes 8y ago

Agreed. I wish they would use the NAMES that I gave everything instead of the cryptic IDs. On the plus side, I'm improving my memory?