Don't forget to create account on our site to get access to more material made only for free registered user.  

AWS Developer Certification : Associate Level AWS Sysops Administrator Certification : Assciate Level   AWS Solution Architect Certification : Associate Level  AWS Solution Architect Certification : Associate Level

1.    You can modify the rules for a security group at any time; the new rules are automatically applied to all instances that are associated with the security group (no need to re-start instances). When we decide whether to allow traffic to reach an instance, we evaluate all the rules from all the security groups that are associated with the instance.

2.    If you have requirements that aren't met by security groups, you can maintain your own firewall on any of your instances in addition to using security groups.

3.    You can't specify a security group that you created for a VPC when you launch an instance in EC2-Classic.

4.    After you launch an instance in EC2-Classic, you can't change its security groups. However, you can add rules to or remove rules from a security group, and those changes are automatically applied to all instances that are associated with the security group.

5.    If you're using EC2-VPC, you must use security groups created specifically for your VPC. When you launch an instance in a VPC, you must specify a security group for that VPC. You can't specify a security group that you created for EC2-Classic when you launch an instance in a VPC.

6.    After you launch an instance in a VPC, you can change its security groups. Security groups are associated with network interfaces. Changing an instance's security group’s changes the security groups associated with the primary network interface (eth0).

7.    You can also change the security groups associated with any other network interface. 

8.    You can change the rules of a security group, and those changes are automatically applied to all instances that are associated with the security group.

9.    In EC2-VPC, you can associate a network interface with up to 5 security groups and add up to 50 rules to a security group.

10. When you specify a security group for a non-default VPC to the CLI or the API actions, you must use the security group ID and not the security group name to identify the security group.

11. Security groups for EC2-VPC have additional capabilities that aren't supported by security groups for EC2-Classic.

12. The rules of a security group control the inbound traffic that's allowed to reach the instances that are associated with the security group and the outbound traffic that's allowed to leave them.

13. By default, security groups allow all outbound traffic.

14. Security group rules are always permissive; you can't create rules that deny access.

15. You can add and remove rules at any time. You can't change the outbound rules for EC2-Classic. If you're using the Amazon EC2 console, you can modify existing rules, and you can copy the rules from an existing security group to a new security group.

16. Security groups are state-ful — if you send a request from your instance, the response traffic for that request is allowed to flow in regardless of inbound security group rules. For VPC security groups, this also means that responses to allowed inbound traffic are allowed to flow out, regardless of outbound rules.

17. If your instance (host A) initiates traffic to host B and uses a protocol other than TCP, UDP, or ICMP, your instance’s firewall only tracks the IP address and protocol number for the purpose of allowing response traffic from host B. If host B initiates traffic to your instance in a separate request within 600 seconds of the original request or response, your instance accepts it regardless of inbound security group rules, because it’s regarded as response traffic. For VPC security groups, you can control this by modifying your security group’s outbound rules to permit only certain types of outbound traffic. Alternatively, you can use a network ACL for your subnet — network ACLs are stateless and therefore do not automatically allow response traffic

18. An individual IP address, in CIDR notation. Be sure to use the /32 prefix after the IP address; if you use the /0 prefix after the IP address, this opens the port to everyone. For example, specify the IP address 203.0.113.1 as 203.0.113.1/32.

19. When you specify a security group as the source or destination for a rule, the rule affects all instances associated with the security group. Incoming traffic is allowed based on the private IP addresses of the instances that are associated with the source security group (and not the public IP or Elastic IP addresses). 

20. If your security group rule references a security group in a peer VPC, and the referenced security group or VPC peering connection is deleted, the rule is marked as stale. 

21. If there is more than one rule for a specific port, we apply the most permissive rule. For example, if you have a rule that allows access to TCP port 22 (SSH) from IP address 203.0.113.1 and another rule that allows access to TCP port 22 from everyone, everyone has access to TCP port 22.

22. When you associate multiple security groups with an instance, the rules from each security group are effectively aggregated to create one set of rules. We use this set of rules to determine whether to allow access.

23. Because you can assign multiple security groups to an instance, an instance can have hundreds of rules that apply. This might cause problems when you access the instance. Therefore, we recommend that you condense your rules as much as possible.

24. Your security groups use connection tracking to track information about traffic to and from the instance. Rules are applied based on the connection state of the traffic to determine if the traffic is allowed or denied. 

25. This allows security groups to be stateful — responses to inbound traffic are allowed to flow out of the instance regardless of outbound security group rules, and vice versa. For example, if you initiate an ICMP ping command to your instance from your home computer, and your inbound security group rules allow ICMP traffic, information about the connection (including the port information) is tracked. Response traffic from the instance for the ping command is not tracked as new request, but rather as an established connection and is allowed to flow out of the instance, even if your outbound security group rules restrict outbound ICMP traffic.

26. Not all flows of traffic are tracked. If a security group rule permits TCP or UDP flows for all traffic/ip (0.0.0.0/0) and there is a corresponding rule in the other direction that permits the response traffic, then that flow of traffic is not tracked. The response traffic is therefore allowed to flow based on the inbound or outbound rule that permits the response traffic, and not on tracking information.

27. An existing flow of traffic that is tracked may not be interrupted when you remove the security group rule that enables that flow. Instead, the flow is interrupted when it's stopped by you or the other host for at least a few minutes (or up to 5 days for established TCP connections). For UDP, this may require terminating actions on the remote side of the flow. An untracked flow of traffic is immediately interrupted if the rule that enables the flow is removed or modified. For example, if you remove a rule that allows all inbound SSH traffic (0.0.0.0/0) to the instance, then your existing SSH connections to the instance are immediately dropped.

28. If you want to ensure that traffic is immediately interrupted when you remove a security group rule, you can use a network ACL for your subnet — network ACLs are stateless and therefore do not automatically allow response traffic. 

29. Your AWS account automatically has a default security group per region for EC2-Classic. When you create a VPC, we automatically create a default security group for the VPC. If you don't specify a different security group when you launch an instance, the instance is automatically associated with the appropriate default security group.

30. A default security group is named default, and it has an ID assigned by AWS. The following are the initial settings for each default security group:

·         Allow inbound traffic only from other instances associated with the default security group

·         Allow all outbound traffic from the instance

31. The default security group specifies itself as a source security group in its inbound rules. This is what allows instances associated with the default security group to communicate with other instances associated with the default security group.

32. You can change the rules for a default security group. For example, you can add an inbound rule to allow SSH connections so that specific hosts can manage the instance.

33. You can't delete a default security group. 

34. After you launch an instance in EC2-Classic, you can't change its security groups. After you launch an instance in a VPC, you can change its security groups

35. When you add a rule to a security group, the new rule is automatically applied to any instances associated with the security group.

36. When you delete a rule from a security group, the change is automatically applied to any instances associated with the security group.

37. You can't delete a security group that is associated with an instance. You can't delete the default security group. You can't delete a security group that is referenced by a rule in another security group. If your security group is referenced by one of its own rules, you must delete the rule before you can delete the security group.