I have an OpWorks stack setup with layers and instances.
On one of the layers I decided I needed a new security attached to it. I attached the group but it is not being applied to the EC2 instance.
Is there a command anywhere to perform the applying of the security group changes?
You've probably figured this out by now, but if anyone else stumbles over the same problem - you need to rebuild the EC2 instances in order for them to pick up the new security group assignment.
Changes within already assigned security groups are applied immediately, but security groups themselves get assigned to instances upon launch only.
Related
the title says almost everything, but just to make it clear, I DON'T want to
(1) use the console, OR
(2) use the CLI,
I want to add a SG dynamically using nodejs. I am shocked that there is not an obvious answer to this in the AWS documentation, but, if there is, I certainly can't find it!
You do this through modifyNetworkInterfaceAttribute which takes Groups parameter:
Changes the security groups for the network interface. The new set of groups you specify replaces the current set. You must specify at least one group, even if it's just the default security group in the VPC. You must specify the ID of the security group, not the name.
So you have to get NetworkInterfaceId of your instance (an instance can have multiple interfaces) first. You can do that using describeInstances. Once you have the NetworkInterfaceId you modify their SGs using modifyNetworkInterfaceAttribute.
How is it possible to cancel replacing instances in instance group without website going offline? We have a managed instance group of compute engine instances, we start replace operation with maximum unavailable instances set to 0, if new instance for some reason doesn't become healthy there is an option to remove instance. However it removes all instances making website to go down until a new instance is created. Is it supposed to happen?
This seems to be expected behavior. Please have a look at rolling update in order to update your instance. Striving for 0 downtime could be achievable. To make your servers more responsive and less disruptive, you may consider the following two strategies:
Max surge. This will create instances above the target size in order to speed up the update process.
Opportunistic update. “An opportunistic update is only applied when new instances are created by the managed instance group”
I'm creating EC2 machines in AWS using JClouds. The machines are created without any issues but they are put into a default security group created by JClouds. A typical default security group by JClouds will have the "jclouds#" prefix like here:
jclouds#euweawlt-c96-j40788-26
Since we have predefined security groups I want to use them instead.
According the link JClouds AWS guide this should be possible through a simple line of code:
template.getOptions().as(EC2TemplateOptions.class).securityGroups(group1, group2);
So I've added it to my code as well:
computeTemplate.getOptions().as(EC2TemplateOptions.class).securityGroups(securityGroup);
...where securityGroup is the name of our predefined security group.
The same documentation page states that this should be enough:
"With respect to the security group, jclouds creates a security group for you, with rules corresponding to the inboundPorts() option (defaults to open port 22), unless you use the option EC2TemplateOptions.securityGroups()."
The end result is that the EC2 machine is added to the security group specified by the above code AND the default "jcloud#..." security group as well. Hence JClouds does create a default security group after all.
I really want to get rid of that since we already have a security group, it is not removed when the machine is terminated and there have been exceptions thrown by the JClouds API due the security group not being available after creation, whatever that means.
Any pointers are welcome.
Looking at the code, it looks like you're right and jclouds will always create that security group by default. I think there is no current workaround for that and I'd suggest you report that as an issue in the jclouds JIRA.
I think the fix should be as easy as moving the highlighted lines into the previous else clause, but let's better open the issue so it can be properly tracked
I'm trying to install Priam on our Cassandra cluster for backup purposes.
Following the installation directions (https://github.com/Netflix/Priam/wiki/Setup) I see that an autoscaling group is necessary to deploy Priam. Is it still possible to use Priam even if our servers are not a part of an auto scaling group?
Unless you want to modify the code, the answer is No.
I posted another reply about the Priam/Netflix conventions for instance names, Auto-scaling group names and security group names here. I thought the benefits of being able to use Priam outweighed the minor hassle of changing some instance names, security group names, and setting up auto-scaling groups.
I'm new to AWS and RDS. I've combed through help files and other stackflow questions, but can't seem to find out if i'm doing something wrong.
When I go to my RDS Instance, I see
Security Groups:default( active )
I click default, and it takes me to the SG page, where I create new groups.
However, any rules I put in those new groups don't work, only the rules I put in the default group works. In some of the documentation, I see the screenshots and the beside the Security Groups on the instance page, it doesn't list default, but a user created group.
So is there some way to make all the new groups active or a way to change which group has precedence on that Instance page? Or am I going to have to put all my rules in the default group?
I had the same problem trying to modify security group right from the top-level view of instances. [The Postgres RDS setup has it backwards, having me create the instance and then telling me I have to do the security group thing, saying only "see startup guide" and providing a broken link to that. :)]
Anyway, I finally figured out I had to select the running instance and then under instance actions select "Modify" and then there is a nice friendly widget for changing the security group.
Update:
You can now change a RDS security group, see user115813's answer a few pixels under my original answer.
Please feel free to validate his answer instead of mine.