EC2 instances come with a single interface - eth0. This interface is mapped to your instance's private IP address and cannot be detached from the instance. (Of course, you can take the interface down, but that a function of the operating system, not AWS).
The only case in which you can attach/detach network interfaces is if your instance is running in a Virtual Private Cloud (VPC). Such instances support multiple interfaces.
Since the instance only has a single network interface, the fact that you are able to connect to it - even if it is only via the AWS console - suggests that the interface still exists and is operational (the 'Network Interface' entry in the AWS console entry is only filled in for VPC instances). It is worth noting that the public IP address of an instance will change when an instance is stopped and started (although, a 'reboot' should not affect this). Elastic IPs can be used to provide a 'static' IP address. The public IP address (whether dynamic or 'elastic') is not directly associated with the interface, rather the EC2 network will NAT the public address to the private one.
Since you still have SSH access to the instance, you can confirm the interface is operational by looking at for an eth0 entry in the output of ifconfig. You can also use the ec2-describe-instances command to get the private and public ip addresses of your instance(s).
EC2 instances typically have two causes of blocked packets - either the operating system's firewall (iptables/netfilter in this case) or the EC2 security group. To the extent possible, it is always preferable to block traffic with your security group as it prevents data from ever reaching the instance. Security groups however, are stateless, and most packages are not setup to dynamically modify them, so you will likely use iptables as well.
By default, the EC2 security group drops all ICMP packets (needed for ping) - so unless you specifically enable it, ping will not work. To enable ping from the AWS console (for your security group):
- Create a 'Custom ICMP Rule' for your security group
- Type: Echo Request and Type: Echo Reply (both are required)
- Source: 0.0.0.0/0
You can see your currently configured iptables rules with: iptables -nvL and you can view your security group settings with ec2-describe-group SECURITY_GROUP
Brute force attacks and having your server scanned are, unfortunately, part of what it entails to have a public facing server today. That attacks occur is typically not something to be concerned with, but rather how your server is setup to ensure those attacks do not result in breaches. Usually, manually blocking a single IP address isn't the most effective route, since you will normally find quite an assortment of IPs as the originators of attacks against your server. I would recommend looking into fail2ban if you want a solution based on failed logins (it scans your logs and dynamically adds/removes the necessary firewall rules) or a iptables rule set based on the recent module.
Additionally, it is usually good practice, when working with iptables, to setup a cron job that will flush your iptables rules (iptables -F) after a few minutes, so that you do not accidentally lock yourself out of your server.
In this case, an update to nginx resulted in an invalid configuration, due to the addition of /etc/nginx/conf.d/default.conf. Create an empty file with the same name (instead of deleting the file) to prevent future updates from causing the same problem. While it is probably not something most people do after an update, you can always test your nginx config with service nginx configtest, which will let you know if there are any problems, before you terminate the running nginx process.
If you actually do find yourself with a disable network interface (e.g. because of ifdown eth0), you will not be able to SSH into the instance (or contact it in anyway). The solution for that scenario is to stop the instance, detach the EBS root volume, attach it as an additional volume to a new EC2 instance, fix the problem, reattach the EBS volume to your original instance, and start it back up. It is one of the definite advantages of EBS volumes.
The subnet you are trying to connect to must be in the same availability zone as the instance. When you go to create a VPC, you usually create it with one subnet. Click "edit public subnet" and then select an availability zone. For example I see us-east-1a, us-east-1c, and us-east-1d. By default it is "no preference", which I believe means it will choose one for you.
Alternatively you can add a new subnet to your VPC. You can set an availability zone for a subnet in the same manner as above.
Just to be clear - us-east-1c and us-east-1b are distinctly different availability zones.
Also, see the VPC FAQ
Q. Can I attach a network interface in one AZ to an instance in another AZ?
Network interfaces can only be attached to instances residing in the same AZ.
Q. Can I attach a network interface in one VPC to an instance in another VPC?
Network interfaces can only be attached to instances in the same VPC as the interface.
Best Answer
I think you created a security group, from the main EC2 dashboard, select Network and Security > Network Interfaces > Create network Interface.
make sure you are in the same zone as the instance you whsh to attach it to