Why this matters
An open port is only a problem when something can reach it. On AWS, that usually means a security group rule that allows 0.0.0.0/0 or ::/0, plus a public IP, a route to an internet gateway, an internet-facing load balancer, or a managed endpoint with public access turned on. An EC2 instance with SSH open to the world is the classic case, but the same risk shows up on an RDS database marked publicly accessible, an OpenSearch domain with a public endpoint, or a Lambda function URL with no auth.
Security groups are stateful. If you allow inbound TCP 22 from anywhere, the return traffic is allowed automatically. That is convenient, and it is why a single bad rule is enough to expose a host. Network ACLs sit at the subnet level and are stateless, so they are a coarse second layer, not a substitute for tight security group rules.
Public endpoints are broader than ports. An internet-facing Application Load Balancer, an API Gateway stage with no authorizer, an EKS public cluster endpoint and a public RDS endpoint all accept traffic from the internet by design or by accident. The job is to keep the endpoints you need, close the rest, and put a controlled path in front of the ones that remain.
Before you start
You need a full list before you change a rule. Use a read-only role and collect security groups, elastic IPs, load balancers, RDS and Redshift public settings, OpenSearch domains, API Gateway endpoint types, Lambda function URLs and EKS endpoint settings. Tag each item with an owner and an application name. Without that, you will close a port that a partner or an old batch job still uses.
Decide what public means for each service. A marketing site on 443 should be public. SSH, RDP, database ports and search ports should not be. Write the allowed path down: for example, users to CloudFront to an internal ALB, or staff to a Client VPN to a private subnet. If you cannot draw the path, you are not ready to close the port.
Pick a window and a rollback. Security group changes apply fast, so a bad rule can break logins in seconds. Keep the old rule set in a change ticket. Test in a staging VPC first when the service has one. Tell the support desk what users may see during the change.
Check your tools. AWS Config, Security Hub, Trusted Advisor and Reachability Analyzer help, but none of them knows your application. Confirm that VPC Flow Logs are on for the VPCs you will touch, and that you can run a scan from outside the VPC.
How to do it
Work from the outside in. Start with the endpoints the internet can see, then the resources behind them, then the admin paths your team uses. Change one layer at a time and test the user path after each change. That order keeps you from closing a port that a load balancer health check depends on.
Use security group references instead of CIDR blocks wherever you can. If an ALB needs to reach an EC2 target on 8080, allow the ALB security group as the source, not the VPC CIDR. If a database needs traffic from an application, allow the application security group on the database port. This keeps the rule correct when IP ranges change.
- List every public entry point. Export security groups, elastic IPs, internet-facing load balancers, API Gateway endpoint types, Lambda function URLs, EKS endpoint settings and managed services with a public access option. Add the owner and the expected users for each one.
- Remove wide inbound rules. In EC2, open Security Groups, select the group, and edit inbound rules. Delete rules with 0.0.0.0/0 or ::/0 on admin, database and search ports. Replace them with a security group ID, a VPN CIDR or a bastion subnet range.
- Take public IPs off servers. Move instances that do not need direct internet access to a private subnet. Set Auto-assign public IPv4 to false on the subnet, release unused elastic IPs, and use a NAT gateway for outbound updates.
- Restrict load balancers and API endpoints. Set the load balancer scheme to internal when only CloudFront or a VPC client needs it. On API Gateway, use a private endpoint with an interface VPC endpoint, or add an authorizer and AWS WAF to the public stage. On Lambda, set the function URL auth type to AWS_IAM.
- Close public database and search access. Set Publicly accessible to No on RDS and Redshift. Put OpenSearch domains in a VPC. Check that the application subnet can still reach the database on the correct port.
- Tighten cluster endpoints. On EKS, set cluster endpoint access to Private, or keep public access and list the CIDRs that may connect. Review public endpoints on other managed clusters the same way.
- Replace open admin ports. Use AWS Systems Manager Session Manager or EC2 Instance Connect Endpoint for shell access, and AWS Client VPN for network access. Close SSH and RDP to the internet after the replacement path works.
- Recheck the path. Run the application flow: login, upload, webhook, report. Then scan from outside the VPC and confirm the closed ports refuse connections.
How to check it worked
Test from the internet, not from a laptop inside the VPC. Use nmap, curl or telnet against the public DNS name or IP. A closed port should time out or refuse the connection; an open port should answer. Check IPv4 and IPv6 separately, because a rule for 0.0.0.0/0 does not cover ::/0.
Use Reachability Analyzer to trace a path from an internet gateway to a network interface. It shows whether the security group and NACL allow the traffic. AWS Config rules such as restricted-ssh and restricted-common-ports show noncompliance, and Security Hub rolls those findings into one place. Trusted Advisor has a security groups check for rules that allow broad access.
Read VPC Flow Logs for rejected traffic after the change. Some rejects are normal, but a burst from your own application means you closed a port it still needs. Check load balancer target health and database connection metrics. A target group with zero healthy hosts is a clear sign that a security group rule is too tight.
Walk the user path with a real account. Sign in, upload a file, run a report, trigger a webhook. Then check again the next day, because autoscaling groups, CloudFormation stacks and manual fixes can put a wide rule back.
Mistakes to avoid
The temporary rule is the most common failure. Someone opens 0.0.0.0/0 on 22 for a debug session and forgets to remove it. Use a time-limited change, or better, use Session Manager so there is no inbound rule to forget. If you must open a port, add a ticket and a calendar reminder.
Another mistake is closing a port without replacing the access path. A database moved to a private subnet needs the application in the same VPC or a peered VPC, and outbound internet from a private subnet needs a NAT gateway. A private EKS endpoint needs a VPN or a bastion host for kubectl. Plan the replacement before the cutover.
Do not treat a network ACL as the main control. NACLs are stateless, so you must allow return traffic on ephemeral ports. A tight NACL with a loose security group still leaves the port open inside the subnet. Fix the security group first, then use the NACL for a coarse deny list if you need one. Watch for IPv6 and default security groups. Also check snapshots and AMIs shared publicly.
If you want an outside read before a customer security review, Cloudverg's Cloud security review is a fixed price $6,500 engagement that checks public exposure across up to five accounts. It is one option among others, and it pairs well with the cleanup work above.
Frequently asked questions
How do I find open ports on AWS?
Start with security groups that allow 0.0.0.0/0 or ::/0, then map each group to a public IP, an internet-facing load balancer, or a managed endpoint. Check API Gateway endpoint types, Lambda function URLs, RDS public access, OpenSearch network settings and EKS endpoint access. Confirm the result with a scan from outside the VPC, because a rule only matters when a route exists.
Are open ports dangerous if the EC2 instance has no public IP?
Not directly from the internet, because there is no route to the instance. The risk returns if someone adds an internet-facing load balancer, a public IP, a VPN, a peering connection or a public endpoint in front of it. Keep the rule narrow so a future route does not turn an old rule into an exposure.
Should I close port 443 on a public load balancer?
No, if the load balancer serves a public website or API. Keep 443 open and restrict what can reach it with AWS WAF, an authorizer, or a CloudFront distribution. Close 80 or send it to 443, and keep admin paths on a private endpoint.