Should Users be able to change Security Groups on a running AWS Instance?

34 views
Skip to first unread message

Jay Farschman

unread,
Apr 20, 2016, 12:34:33 PM4/20/16
to scalr-discuss
As I roll out my latest version of the Scalr CE to my AWS end-users, the most common problem I'm having with them is around security groups.  They don't think about what ports need to be open, because the "Security" tab doesn't seem that important when they are building a Farm Role.  Then after they spin up the VM/instance, they try to add "Security Groups" to the Farm Role, but this does not add them to the running instance.

Should this work?

I am forced to tell user:

  1. If you haven't invested much time in the instance, build it again
  2. If you've invest too much time, contact me in chat and I'll add the rules for you.
I have 150+ users and they all want to work quickly.  Thanks.

Marc O'Brien

unread,
Apr 20, 2016, 4:56:39 PM4/20/16
to scalr-discuss
Hi Jay,

Your users can not change the Security Groups associated with a server that has already been launched.  They can edit rules in an existing Security Group, but can not change the Security Group assignment without terminating and re-launching.

Reference Documentation:

https://scalr-wiki.atlassian.net/wiki/display/docs/Security+Groups%2C+Security+Rules+and+Running+Instances

https://scalr-wiki.atlassian.net/wiki/display/docs/Editing+a+Running+Farm

Let us know if you have any questions from here.

Many thanks,
Wm. Marc O'Brien
Scalr Technical Support

Jay Farschman

unread,
Apr 21, 2016, 10:21:52 AM4/21/16
to scalr-...@googlegroups.com
Thanks Marc,

I'd have to say that's the most inconvenient thing I've found in Scalr.  It's seems difficult to explain to user that Farm-Roles are just meta-data describing a desired state and that meta-data is only applied at the startup.

I may end up making some sort of short video explaining this concept.

I should have found those links in the documentation. In fact, I think I did, but my users are coming from an OpenStack environment where they just self-serviced their own firewall rules while the instances were up and running.  It's a paradigm shift.

--
You received this message because you are subscribed to a topic in the Google Groups "scalr-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scalr-discuss/CF_op7uYaVI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scalr-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

Marc O'Brien

unread,
Apr 21, 2016, 1:54:09 PM4/21/16
to scalr-discuss
Hi Jay,

I completely understand the frustration and inconvenience.  I am touching base with Dev internally to determine if there was a design or technical limitation that lead to this, or if there is perhaps a better way for us to enable hot-swap security groups.  I will follow up here once I have better information for you.

Marc O'Brien

unread,
Apr 22, 2016, 5:56:27 PM4/22/16
to scalr-...@googlegroups.com
Hi Jay,

I wanted to follow up on this after gaining some insight from Dev.  We do understand that it can be frustrating to users who are used to a certain functionality and have a different experience when using Scalr.  Due to the multi-cloud nature of Scalr, in some cases full feature parity does not lend to a consistent experience when using multiple clouds.  Having said that, we are always striving to hear the voice of our customers and provide solutions that enrich your experience with Scalr.  We will be sure to assess this report and consider how we could improve this behavior in the future.  Let me know if you have any questions.


Many thanks,
Wm. Marc O'Brien
Scalr Technical Support

Reply all
Reply to author
Forward
0 new messages