I saw this today and it seemed odd. In one region I have no VPC, but I apparently have a default security group that can't be deleted because "This is a default security group. Default security groups cannot be deleted."
How did this default security group come to exist without a VPC?
At one point there must have been a VPC, which came with this default security group, but I thought if the VPC is deleted the corresponding default security group would be deleted along with it.
All modern AWS accounts are provisioned with a VPC. VPCs can be deleted but the default security group can not.
I believe this dates back to the beginning of the EC2 service (i.e. EC2 Classic). In 2013 and earlier, users were able to create instances on a flat network that was shared with other customers and there was no concept of VPCs. AWS required EC2 instances to be associated with a security group but if none were created/selected by the user, AWS could rely on the default security group being available.
So the reason that we can have a default security group without a VPC is that security groups were actually a concept before VPCs and AWS still keeps this default security group requirement as a side effect of some of those earlier infrastructure requirements.
Ran into this yesterday.
Was using EC2 Classic Resource Finder and came across this resource along with some Security Groups(including the default) and an EIP. Deleted the non-default SG's and released the EIP without issue. Was unable to delete the default SG with the error "The following security groups can't be deleted. They are either default security groups, referenced by other security groups or they are associated with instances or network interfaces".
Ensuring this was not associated with a VPC or any other resources were referencing it, we reached out to support. Support confirmed that this resource will be sunset with EC2 Classic in 2023.
I think that must be it. I remembered deleting a default VPC for security reasons, but the default security group persisted.
Security is one of the key aspects in this term.
It is useful to note that security is always considered a top priority job at AWS. Therefore, Default Security Group cannot be deleted partially because they it is the last line of defense for potentially malicious attack on your Amazon EC2 instances. Amazon relies on Security Groups as virtual firewalls that your instances will be paired-up with exclusively for safety reasons. That is also why default SGs by default block any incoming traffic.
On the hand, protective NACL (Network Access Control Lists) feature is only one aspect of the VPC setup. VPCs are primarily logical networking compartments in your cloud infrastructure and you have absolute freedom to define them in any way you see fit. One use case is that you can have complex routing solutions that define many of the aspects of your cloud infrastructure, and accidentally adding Amazon EC2 instances to a default VPC by your developers can lead to hours of debugging why your resource is not behaving as expected.
In summary, security and the mentioned legacy aspects of the Amazon EC2 Classic instances related to the VPC concept (EC2-Classic and a VPC ) are one of the key reasons why default SGs can not be deleted compared to the default VPCs. Still, if you delete the default VPC, you will not be able to restore it or to provision new Amazon EC2 instances until you create at least one custom VPC in the respective region.
If you delete the default VPC, any running EC2 instances, network interfaces, it will automatically delete the default security group as well.
Can you delete a default VPC for a region?
You can delete a default subnet or default VPC just as you can delete
any other subnet or VPC.
However, if you delete your default subnets or default VPC, you must
explicitly specify a subnet in another VPC in which to launch your
instance, because you can't launch instances into EC2-Classic. If you
do not have another VPC, you must create a nondefault VPC and
nondefault subnet. For more information, see Create a VPC.
Reference: https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html
Related
I currently have a Lambda function that performs a series of task, but one part in particular requires connection to an RDS instance in another AWS account. The function spins up a new EC2 instance at each trigger and uses userdata to perform the series of tasks I have written.
The RDS instance has a security group, and I would need to whitelist the EC2 instance's IP to connect. This is infeasible as I am spinning up a new EC2 instance each time the function is triggered. Is there a way to whitelist all EC2 instance's in a particular AWS account in another AWS account's security group rules?
I am assuming you dont want your traffic to go over the internet.
Updating your security groups to reference peer VPC groups
You can update the inbound or outbound rules for your VPC security groups to reference security groups in the peered VPC. Doing so allows traffic to flow to and from instances that are associated with the referenced security group in the peered VPC.
The peer VPC can be a VPC in your account, or a VPC in another AWS account. To reference a security group in another AWS account, include the account number in Source or Destination field; for example, 123456789012/sg-1a2b3c4d.
This is the most elegant way instead of whitelisting all ec2 instances. Traffic always stays on the global AWS backbone, and never traverses the public internet, which reduces threats, such as common exploits, and DDoS attacks.
You still hold the controls what can be accessed between the accounts via many methods
Security groups
Route Tables
Network ACLs.
When creating an EC2 instance (or some other kind of stuff) on AWS, there appears a default VPC.
Also, as another option, a VPC can be created beforehand and selected during the EC2 instance creation etc..
So, in which use cases should we create a new VPC instead of using the default one?
The AWS Documentation does a pretty good job describing how they create the default VPC.
When we create a default VPC, we do the following to set it up for
you:
Create a VPC with a size /16 IPv4 CIDR block (172.31.0.0/16). This provides up to 65,536 private IPv4 addresses.
Create a size /20 default subnet in each Availability Zone. This provides up to 4,096 addresses per subnet, a few of which are reserved
for our use.
Create an internet gateway and connect it to your default VPC.
Create a main route table for your default VPC with a rule that sends all IPv4 traffic destined for the internet to the internet
gateway.
Create a default security group and associate it with your default VPC.
Create a default network access control list (ACL) and associate it with your default VPC.
Associate the default DHCP options set for your AWS account with your default VPC.
This is great with simple applications and proof of concepts, but not for productions deployments. A DB instance should for example not be publicly available, and should there for be placed in a private subnet, something the default VPC does not have. You would then create some sort of backend instance that would connect to the DB and expose a REST interface to the public.
Another reason may be if you are running multiple environments (DEV, QA, PROD) that are all copies of each other. In this case you would want them to be totally isolated from each other as to not risk a bad deployment in the DEV environment to accidentally affect the PROD environment.
The list can go on with other reasons, and there are probably some that are better than those that I have presented you with today.
If you understand VPC reasonably well, then you should always create your own VPC. This is because you have full control over the structure.
I suspect that the primary reason for providing a Default VPC is so that people can launch an Amazon EC2 instance without having to understand VPCs first.
I don't use the default VPC. I have created another VPC. However, I haven't assigned my other VPC as default. I would like to delete my default VPC and set my other VPC as default.
I read some arguments on the Internet. If I delete the default VPC then I will not be able to create instances. Is this correct?
What will happen if I delete the default VPC in AWS?
AWS has recently announced a feature to self restore the default VPC.
Also its not mandatory to have a default VPC in place for a region. However, at least one is needed if you plan to start EC2 instances in the particular region.
Note: In the past, if the default VPC is deleted, it was required to contact AWS Support to restore it back.
To answer your question, if there are no resources in your default VPC, and you delete it, nothing will happen. Any VPC other than the default will need to be "manually" selected and may not auto-populate for other services - there is no existing way (and no real need) to call another VPC the "default VPC", however.
I have an Aurora cluster in RDS and a Lambda Function.
Both are assigned the same VPC.
Both have the same subnets (us-east-1 a-f)
Both have the same security group assigned
Lambda is assigned a role with AmazonRDSFullAccess, AmazonVPCFullAccess,
AWSLambdaVPCAccessExecutionRole
When I run the lambda instance, I get connection timeout when trying to connect to Aurora. I'm able to access Aurora locally (with access key added to aws configure).
Any ideas what else I can check for why lambda wouldn't have access to the instance? Thank you
Update: The subnets each have the following configuration:
Both have the same security group assigned
It's a common misconception that members of the same security group can communicate with each other by virtue of being members of the same group. This is not the case. Being members of the same group only means they follow the same set of rules.
Members of a security group can only access other members of the group if the group allows access to itself.
Instances associated with a security group can't talk to each other unless you add rules allowing it (exception: the default security group has these rules by default).
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html
Add a rule to this group for "MySQL/Aurora" traffic, but instead of entering an IP address, enter the sg-xxxxxxxx identifier of the security group.
I had a similar problem until I realized the VPC I was using did not have dns resolution enabled for hosts within the VPC.
The enableDnsSupport option needs to be set for the VPC.
See http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html
When a new security group is added, or the existing one is modified, the affects are not visible. For instance, I have a security group called “mdi-sg-redshift” with two rules:
As you can see, these rules allow inbounds from anyone across the globe. When applied to the cluster, they should allow inbounds at those ports. Does NOT work! I have rebooted the cluster to no affect.
Here is the snapshot of my Redshift Cluster:
Here is the snapshot of the port scanner.
The cluster was rebooted several times to no effect.
Also noted that the cluster belongs to the same region as the VPC and the security group. The cluster belongs to the VPC that has the security group applied.
I have seen similar issues on EC2 side, but reboots usually fixed it. Not this time.
Anyone with insights? Thanks!
This sounds mostly a VPC rules issue.
Things I will check:
Do you get the same issue if you create your cluster outside of VPC?
Check Cluster Subnet group. It says default in your screen shot. Which subnet groups is dded to this default subnet group? Make sure your cluster is running in the subnet which is added to default subnet group.
Check VPC security group policy for the Red-shift cluster
Did this set-up ever worked in the past ? OR is it the 1st time you are working on this cluster? If it worked in the past, then what setting with respect to VPC/cluster subnet group/ VPC security groups has changed?
Where are you accessing Redshift from?
If you ar trying to access Redshift from outside VPC then please check the Route Table for an entry of Internet Gateway (to verify if the Redshift cluster is publicly available over internet)
If you are trying to access Redshift from within VPC then there might be some other issue that might be stopping access