Properly handle SecurityGroups in DefaultVPC environments about autospotting HOT 13 CLOSED

FWIW, in the CLI, they say this: http://docs.aws.amazon.com/cli/latest/reference/autoscaling/create-launch-configuration.html, for creating security groups on Launch Configs. Which is likely why reading them matches the behavior you describe:

One or more security groups with which to associate the instances.
If your instances are launched in EC2-Classic, you can either specify security group names or the security group IDs. For more information about security groups for EC2-Classic, see Amazon EC2 Security Groups in the Amazon Elastic Compute Cloud User Guide .
If your instances are launched into a VPC, specify security group IDs. For more information, see Security Groups for Your VPC in the Amazon Virtual Private Cloud User Guide .

from autospotting.

I found a way to reproduce this problem:

It is not happening on resources created manually in the DefaultVPC, which was how I tried to reproduce it first, but it happens when launching a CloudFormation stack created for EC2 Classic.

from autospotting.

Could you describe the problem some more, it is not very clear to me what's the problem is, or what it affects? Maybe we could set standards on how to open issues: version, description, expected, etc

from autospotting.

Good point.

The problem happens on Default VPC environments when launching CloudFormation stacks created for EC2 Classic. These stacks would reference the security groups by name instead of their ID.

The application fails to launch any spot instances because of the way the security groups are being passed when creating the spot request, because the list of groups is ambiguous and the groups can be given by either name or ID, which both come from the same field of the launch configuration, and we have no way to distinguish them yet. The spot request we need to create can have two fields, one for group IDs and another for names, and I think we just use the one for IDs and that can't be used to provide them by name.

As a solution I was thinking to query the groups, search them by both ID and name and always use their IDs. This requires an additional IAM permission to query the groups, and I am not sure it would work on EC2 classic.

A simpler way may be to match them against the 'sg-*' glob and assume they are given by IDs in case of a match and pass them as names otherwise.

from autospotting.

Okay, thank you for the precisions, it makes more sense. Maybe the labels of this issue could be updated to add 'cloudformation' (could also be a good idea to 'terraform' or 'installers') and remove the one requiring information?

from autospotting.

It's not a problem with the AutoSpotting installers, but with the way the AutoScaling group was initially created.

This impacts AutoScaling groups created in DefaultVPC by stacks that were written initially for EC2 Classic, where security groups were referenced by name instead of by ID in the launch configuration.

Essentially, AutoSpotting assumes that the security groups referenced by name would work out of the box, but the spot request API calls fail since on DefaultVPC they are expected to be referenced by ID, like it is the case on normal VPCs.

We would need to do a conversion from SG name to SG ID when building the spot launch request for DefaultVPC environments.

from autospotting.

My team found, to further complicate the above, that in accounts w/ just EC2 Classic (and not DefaultVPC) the id's come back as Ids - but the code is attempting to submit the ids as SecurityGroups, not SecurityGroupIds, and thus, errors out with an error saying SecurityGroup not found. Do we have a full list of what the scenarios are between VPC, DefaultVPC, Classic?

from autospotting.

Per these examples, http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-request-examples.html - they are always using SecurityGroupId for non-VPC, using the ids passed in, so the fix you reference above may actually be sufficient. Can you explain more the scenario in which SecurityGroups get names and names-only in non-VPC (or DefaultVPC mode) if that doesn't work?

from autospotting.

@ahaverbuch In my experience with EC2 Classic, there you can also reference security groups by name, not just by ID, since the names are unique per Classic region. In a few Classic accounts I've seen so far in the wild I just saw stacks which used names, so that's why the code was written like this.

Once VPC was introduced, AWS gradually switched to IDs, because the names may be duplicated between VPCs, you can have the same name in multiple VPCs but the IDs will always be different.
I think the current documentation is geared towards VPC since Classic is disabled for new accounts for a few years now, but there are still lots of people running in Classic mode in some regions.

The problem is the launch configuration makes no difference, but the spot request expects them separated, so we need a bit of logic to determine where to put them.

One way may be to try to search the groups by name them to determine their ID using API calls and always use the ID when requesting the spot instances.

Another way may be to check if they contain the "sg-" prefix, and if they do handle them as IDs, otherwise as names, hoping that few people will name them like that. This would need to be documented as a known limitation but I guess few people would be impacted by this so it may be simple and effective enough.

from autospotting.

@cristim Got it. In my experience w/ Classic regions, it always comes back from Launch Config and uses IDs (though these have been from Lauch Configs created via UI or API, not via CloudFormation, maybe that's different). So you must be right that you can get both and the code should probably handle either in one way or the other.

from autospotting.

The above PR: https://github.com/cristim/autospotting/pull/100 covers the scenarios I was talking about for non-VPC (at least unless you are mixed id and names)

from autospotting.

I've just noticed this issue again with mixed IDs:

2017/08/14 07:50:30 autoscaling.go:608: Failed to create spot instance request for myAutoScalingGroup InvalidGroup.NotFound: The security group 'mySG' does not exist in VPC 'vpc-6018bf05' 

The stack was launched in Default VPC based on a CloudFormation stack having groups given by name, but the spot request API expects them by ID.

We will need to implement some logic to determine the ID for groups given by name.

from autospotting.

We should document this as a known issue somewhere, providing a workaround, until it is properly fixed.

from autospotting.