AWS EC2 Networking Explained: Private IP, Public IP, Elastic IP, and Security Groups

When you launch an Amazon EC2 instance, AWS creates more than just a virtual server. It connects that server to a network, assigns a private IP address, and lets you configure how the instance communicates with other resources and the internet.

But this raises several questions. Why does an EC2 instance have a private IP address? Why does it sometimes have a public IP address as well? What happens to its address when you stop the instance? And how do Security Groups protect it?

In this article, we'll answer these questions from the beginning, using one consistent example to explain how EC2 networking works.

You don't need an AWS account or any prior deployment experience to follow along. A basic understanding of VPCs and subnets is helpful, but we'll review those concepts first.

1. What Is Amazon EC2, and Why Does It Need Networking?

Amazon Elastic Compute Cloud (EC2) is an AWS service that provides virtual servers, called instances.

You can use an EC2 instance to run:

• A Next.js or React-based web application.

• A Node.js or Python backend API.

• A background processing service.

• A self-managed database.

• Other applications that require a server.

Imagine you deploy a Next.js application on EC2.

The server is running, and your application is listening on a port.

But how will a visitor reach it?

How will the server connect to another server or download software updates?

The answer is networking.

Just like your laptop needs a network connection to communicate with other devices, an EC2 instance requires network configuration to exchange data.

Where does EC2 fit inside a VPC?

Remember these three concepts:

VPC: The overall virtual network.

Subnet: A smaller IP address range inside the VPC.

EC2 instance: A virtual server launched into that network.

For example, imagine we have:

The web server belongs to the public subnet, while the API server belongs to the private subnet.

Both servers are inside the same VPC.

That means they can potentially communicate using private IP addresses, provided their routing and security rules allow it.

An important distinction: simply placing an instance in a subnet does not guarantee internet connectivity. The subnet's routes, the instance's addressing, and its security settings all matter.

2. How Does an EC2 Instance Get an IP Address?

Let's look at our public subnet:

10.0.1.0/24

A /24 contains 256 IPv4 addresses.

Its complete range is:

10.0.1.0 to 10.0.1.255

AWS reserves five addresses in each IPv4 subnet, leaving 251 assignable addresses in this example.

The assignable range is:

10.0.1.4 to 10.0.1.254

When you launch an EC2 instance into this subnet, AWS assigns it a private IPv4 address from the available subnet addresses.

For example:

10.0.1.10

The address may be chosen automatically by AWS, or you can request a specific available private IP address.

Why does AWS assign the address from the subnet?

Because the subnet defines which IP addresses belong to that network.

Imagine a company building divided into different departments.

Each department has a specific room-number range.

If a new employee joins Department A, they receive a room from Department A's range, not from another department.

Similarly, an instance launched into 10.0.1.0/24 receives its primary private IPv4 address from that subnet.

It cannot simply select 10.0.2.20 as its primary address while attached to 10.0.1.0/24, because that address belongs to a different subnet.

3. What Is a Private IP Address in AWS EC2?

A private IPv4 address is used for communication within private networks.

In our example, the web server has:

10.0.1.10

And the backend server has:

10.0.2.20

Suppose the web server needs data from the backend API.

It can send a request to:

http://10.0.2.20:3000

Here:

• 10.0.2.20 identifies the backend server's network address.

• 3000 is the destination TCP port where the example API is listening.

Because both instances are inside the same VPC, traffic can follow the VPC's local route without traversing the public internet.

The connection still depends on suitable Security Group rules, any applicable Network ACLs, and the API actually listening for connections.

Why use private IP addresses?

Private addressing provides several benefits.

Internal communication: Services can communicate within a private network without requiring a public IPv4 address on every instance.

Reduced exposure: An instance that has only a private IPv4 address is not directly reachable over the public IPv4 internet.

Network organization: We can group applications into different subnets while preserving controlled communication between them.

Efficient public address usage: Internal resources do not need individual public IPv4 addresses merely to talk to other resources inside their VPC.

Does the private IP change when EC2 restarts?

Usually, no.

The primary private IPv4 address remains associated with the instance's primary network interface when the instance is rebooted or stopped and started.

For example:

Before stopping:

10.0.1.10

After starting:

10.0.1.10

The address is generally released when the instance is terminated and its primary network interface is deleted.

This is different from how automatically assigned public IPv4 addresses behave.

4. What Is a Public IP Address in AWS EC2?

A public IPv4 address is a globally routable address that can be used for internet communication.

Suppose our Next.js web server needs to receive traffic from visitors outside AWS.

The EC2 instance might have:

• Private IP: 10.0.1.10

• Public IP: 203.0.113.10

The public IP shown here is a documentation-only example address, not an actual address allocated by AWS.

Visitors would reach the server using its real public address or a domain name that resolves to its public endpoint.

Why does one EC2 instance have two IP addresses?

Because the addresses have different purposes.

The private IP identifies the instance within its VPC network.

The public IP provides an externally reachable IPv4 address when the routing and security configuration permits access.

Think of an office building.

An employee may have an internal extension number used by colleagues. The company also has an external telephone number customers can call.

Both identify ways to reach the same employee, but they serve different communication contexts.

An EC2 instance can work similarly:

These are not two completely separate servers.

They represent network addressing associated with the same EC2 instance.

Does the public IP exist inside the operating system?

Here's an important detail.

For a standard EC2 public IPv4 configuration, the Internet Gateway provides a one-to-one network address translation between the instance's private address and its public address.

That means the instance's operating system normally sees its private IPv4 address on its network interface, rather than the associated public IPv4 address.

This often surprises developers who inspect an EC2 instance's network interfaces and only find a 10.x.x.x address.

The public IPv4 mapping is handled by AWS networking.

See Amazon EC2 instance IP addressing.

5. Does Every EC2 Instance Automatically Receive a Public IP?

No.

This depends on the subnet's public IPv4 auto-assignment setting and the instance's launch configuration.

For example:

Default VPC: Instances launched in default subnets generally receive public IPv4 addresses automatically, unless configured otherwise.

Custom VPC: New nondefault subnets normally have automatic public IPv4 assignment disabled.

You can enable or disable automatic public IPv4 assignment where supported.

But remember:

A public IP address alone does not guarantee internet access.

For direct public IPv4 communication, you generally need:

1. A public IPv4 address or Elastic IP associated with the instance.

2. An Internet Gateway attached to the VPC.

3. A subnet route table with the appropriate route to the Internet Gateway.

4. Security rules allowing the required traffic.

5. An application that is actually running and listening on the correct network interface and port.

If any required component is missing, connectivity may fail.

Example: A public IP but no internet connection

Imagine an EC2 instance has a public IP, but its subnet route table contains only:

There is no route to an Internet Gateway.

Even though the instance has a public IPv4 address, it does not have the required direct internet route.

This illustrates why IP addressing and routing must be understood together.

6. What Happens to the Public IP When EC2 Stops?

This is one of the most practical EC2 networking concepts.

Suppose you launch an instance and AWS assigns:

203.0.113.10

You use that public address to connect to your application.

Later, you stop the instance.

For a normally auto-assigned public IPv4 address, AWS releases that address back to its pool.

When you start the instance again, AWS generally assigns a new public IPv4 address.

For example:

These public addresses are illustrative.

There are networking configurations involving multiple interfaces or secondary addresses where automatic reassignment behaves differently. For a basic single-interface instance, a stop/start should be treated as potentially changing the automatically assigned public IP.

What about rebooting?

Rebooting an EC2 instance is different from stopping and starting it.

A normal EC2 reboot generally preserves the current automatically assigned public IPv4 address.

Why does this matter for a website?

Imagine you configured your domain's DNS A record to point directly to your instance's public IPv4 address.

After a stop/start operation, that address changes.

Your DNS record may still point to the old address, causing your website to become unreachable.

This is one reason AWS provides Elastic IP addresses.

7. What Is an Elastic IP Address?

An Elastic IP (EIP) is a static public IPv4 address allocated to your AWS account.

Unlike a normal automatically assigned public IPv4 address, an Elastic IP remains allocated to your account until you explicitly release it.

Suppose you allocate an Elastic IP:

203.0.113.40

Again, this is an illustrative documentation address.

You associate it with your EC2 instance.

Now your instance has:

• Private IPv4: 10.0.1.10

• Elastic IP: 203.0.113.40

When the instance is stopped and started, the Elastic IP remains associated with the instance.

How is an Elastic IP different from a normal public IP?

Why is an Elastic IP useful?

Consider a simple website hosted on one EC2 instance.

Your domain is:

example.com

Your DNS A record points to an Elastic IP:

203.0.113.40

The Elastic IP is associated with your EC2 instance.

If you stop and start the instance, the address remains the same.

This prevents the specific problem of a changing EC2 public IPv4 address invalidating your DNS record.

However, an Elastic IP does not prevent application downtime while an instance is stopped, and it is not a complete high-availability solution.

Can we move an Elastic IP to another EC2 instance?

Yes.

Imagine your original EC2 instance becomes unusable.

You create a replacement instance.

An Elastic IP can be reassociated with the replacement resource, subject to AWS's association and network constraints.

The public address remains the same, while the underlying resource changes.

This is useful, but active connections may be interrupted during reassociation.

Does an Elastic IP cost money?

Yes.

AWS charges for public IPv4 addresses, including:

• Public IPv4 addresses associated with running EC2 instances.

• Elastic IP addresses associated with resources.

• Elastic IP addresses allocated to your account but not associated with resources.

Actual billing depends on AWS pricing, usage, and applicable credits or benefits.

An important beginner lesson is that an unassociated Elastic IP can still generate charges.

See AWS Elastic IP documentation and Amazon VPC pricing.

Should every EC2 instance use an Elastic IP?

No.

Elastic IPs are useful when a stable public IPv4 address is required.

But many applications do not need public IPs on individual instances.

For example, a production web application may use an internet-facing Application Load Balancer and place its EC2 application servers in private subnets.

Clients connect to the load balancer's DNS endpoint rather than to individual EC2 public addresses.

The decision depends on your architecture, not simply on whether the instance runs a website.

8. What Is an Elastic Network Interface (ENI)?

Until now, we've discussed IP addresses as if they belong directly to the EC2 server.

Technically, there is another important networking component involved.

It's called an Elastic Network Interface, or ENI.

An ENI is a logical virtual network card in an AWS VPC.

Think about a physical computer.

Your laptop has a Wi-Fi adapter or Ethernet interface that connects it to a network.

An EC2 instance also needs a network interface.

AWS provides this through an ENI.

How do EC2, ENI, subnet, and IP address relate?

Consider:

• VPC: 10.0.0.0/16

• Subnet: 10.0.1.0/24

• EC2 instance: Web Server

• Primary ENI private IPv4: 10.0.1.10

The relationships are:

VPC → Subnet → ENI → EC2

The network interface belongs to a subnet and is attached to an instance.

The interface carries networking attributes such as:

• Primary private IPv4 address.

• Optional secondary private IPv4 addresses.

• Optional IPv6 addresses.

• Security Group associations.

• MAC address.

• Public IPv4 or Elastic IP association information.

This explains why an EC2 instance's networking is closely tied to its ENI.

Primary vs. secondary network interfaces

Every EC2 instance has a primary network interface.

Its primary interface cannot normally be detached while the instance exists.

Supported instance types can also have additional network interfaces.

Additional interfaces can be useful when an instance needs multiple network connections or different networking configurations.

For beginners, the key point is:

An ENI represents the networking attachment and associated settings; it is not another EC2 server.

Why is understanding ENI important?

Because Security Groups are associated with network interfaces, and private IP addresses are assigned to those interfaces.

It also explains why private addresses normally remain stable across EC2 stop/start operations: the primary network interface and its addressing persist.

See AWS Elastic Network Interfaces.

9. What Is a Security Group in AWS?

An EC2 instance can have correct IP addresses and routes, but we still need to decide which connections are allowed.

That is the purpose of a Security Group.

A Security Group acts as a stateful virtual firewall for supported AWS resources and their network interfaces.

It controls permitted inbound and outbound network traffic.

Imagine your EC2 instance is an office building.

The IP address identifies where the building is.

The route table determines how visitors can travel to it.

The Security Group is like a security checkpoint that decides which types of connections may enter or leave.

Inbound vs. outbound traffic

Inbound traffic is traffic arriving at the protected resource.

Examples:

• A visitor opening your website.

• An administrator connecting using SSH.

• Another server calling your API.

Outbound traffic is traffic leaving the protected resource.

Examples:

• Your server downloading application dependencies.

• Your backend making an external API request.

• Your EC2 instance initiating a connection to another server.

A Security Group has separate rules for inbound and outbound traffic.

10. Understanding Security Group Rules

A Security Group rule describes the type of network communication allowed.

For inbound rules, the important fields are:

• Protocol.

• Port or port range.

• Source address or source Security Group.

For outbound rules, you configure the destination instead of the source.

Example: Security Group for a web server

Suppose your EC2 instance hosts a Next.js application behind Nginx.

You might configure:

What does each rule mean?

Port 80: Allows inbound HTTP connections from IPv4 addresses.

Port 443: Allows inbound HTTPS connections from IPv4 addresses.

Port 22: Allows SSH administration from a specific trusted public IPv4 address.

If HTTPS is your preferred protocol, port 80 may only be used to redirect clients to HTTPS.

What does 0.0.0.0/0 mean?

It means every IPv4 address.

A rule allowing TCP 443 from 0.0.0.0/0 makes the HTTPS port eligible to receive traffic from any IPv4 source that can reach the instance.

It does not guarantee the application is reachable, because routing and other controls must also permit the connection.

What does /32 mean?

A /32 represents one specific IPv4 address.

Suppose your administrator's public address is represented as:

198.51.100.25

Then:

198.51.100.25/32

matches only that one IPv4 address.

This is an illustrative documentation address.

For administrative ports such as SSH, limiting access to trusted source addresses is much safer than allowing unrestricted access from every address.

For many workloads, AWS Systems Manager Session Manager or EC2 Instance Connect Endpoint can provide administrative access without exposing SSH to the public internet.

11. What Do Ports 22, 80, 443, and 3000 Mean?

Beginners often confuse an IP address with a port.

They solve different problems.

An IP address identifies the network endpoint.

A port identifies a communication endpoint used by a process or service on that host.

For example:

10.0.2.20:3000

Here:

• 10.0.2.20 is the destination IP.

• 3000 is the destination port.

Common TCP ports include:

Applications are not required to use only these conventional ports.

Example: Next.js behind Nginx

Suppose your Next.js application listens locally on port 3000.

Nginx receives public HTTPS traffic on port 443 and forwards requests to the local application.

Conceptually:

Visitor → HTTPS port 443 → Nginx → Local port 3000 → Next.js

In this configuration, you generally don't need to expose port 3000 to the public internet.

Your Security Group can allow inbound HTTPS on 443 while leaving 3000 closed to external connections.

This reduces unnecessary exposure of internal application ports.

12. Why Are Security Groups Called Stateful?

AWS Security Groups are stateful.

This means they track permitted connections and automatically allow associated response traffic.

Let's understand with an example.

Suppose an EC2 instance makes an outbound HTTPS request to an external API.

The request uses TCP port 443 at the destination.

If the outbound connection is allowed and succeeds through the network, the corresponding response traffic can return without requiring a separate inbound Security Group rule for that response.

Similarly, if a web visitor is allowed to connect to your EC2 instance on port 443, the instance can send the response without needing a separate outbound rule specifically for that response.

This is why stateful firewalls are convenient.

Do Security Groups support deny rules?

No.

Security Groups use allow rules.

If a traffic flow does not match an applicable allow rule, it is not permitted.

If multiple Security Groups are associated with a network interface, AWS evaluates their combined allow rules.

What are the default Security Group rules?

There is an important difference between the VPC's default Security Group and a newly created custom Security Group.

A newly created custom Security Group normally starts with:

• No inbound rules.

• An outbound rule allowing all traffic.

The default Security Group automatically created with a VPC normally includes an inbound rule allowing traffic from other resources using that same Security Group, along with outbound allow-all rules.

These defaults can be changed.

For clarity and security, using purpose-specific custom Security Groups is usually preferable to relying on the VPC's default group.

See Security Group rules in Amazon VPC.

13. How Can Two EC2 Instances Communicate Privately?

Let's return to our application.

We have two EC2 instances:

Both belong to the VPC:

10.0.0.0/16

The web server makes a request to:

http://10.0.2.20:3000

How do we allow this communication securely?

Option 1: Allow a specific private IP

The API server's Security Group could allow:

This permits the example web server address to connect to the API on TCP port 3000.

But what happens if we add more web servers?

We might need to update the allowed source IP addresses.

Option 2: Reference another Security Group

A more flexible approach is to use Security Group references.

Suppose:

• Web Server Security Group: web-sg

• API Server Security Group: api-sg

The API Security Group can allow inbound TCP 3000 from web-sg.

Now resources associated with the referenced web Security Group can connect to the API on the specified port, assuming routes and other controls permit the traffic.

This is useful when instances are replaced or scaled.

You don't need to maintain an individual list of every web server's private IP address.

Important: Referencing a Security Group does not automatically copy its rules or allow every port. The configured protocol, port, and direction still apply.

14. Putting It Together: How a Website Request Reaches EC2

Let's consider a simplified full-stack application.

The infrastructure contains:

• VPC: 10.0.0.0/16

• Public subnet: 10.0.1.0/24

• Private subnet: 10.0.2.0/24

• Next.js web server: 10.0.1.10

• Node.js API server: 10.0.2.20

The web server has a public IPv4 endpoint.

The API server has only a private IPv4 address.

Scenario A: A user opens the website

A visitor opens:

https://example.com

The domain resolves to the website's public endpoint.

The request reaches AWS networking through the Internet Gateway.

The public IPv4 destination is translated to the instance's corresponding private IPv4 address.

The web server's Security Group checks whether the HTTPS connection is allowed.

If routing, Security Groups, Network ACLs, and the application configuration all permit it, the request reaches the web server.

Nginx may then forward the request to the Next.js application running locally.

Scenario B: Next.js requests data from the API

The Next.js server needs application data.

It makes a server-side request to the backend:

http://10.0.2.20:3000

Since the two instances belong to the same VPC, the connection uses private VPC routing.

The API server's Security Group permits connections from the web server's Security Group on port 3000.

The API processes the request and returns the response.

This internal request does not need to travel through the public internet.

Note that the request must genuinely originate server-side. A user's browser cannot directly access an ordinary private 10.x.x.x VPC address from the public internet.

Scenario C: The private API calls an external service

Suppose the Node.js API needs to call a public payment or notification service.

The instance has no public IPv4 address.

It may use an outbound route through a public NAT Gateway.

Conceptually:

Private API → NAT Gateway → Internet Gateway → External Service

The NAT Gateway provides outbound connectivity and the return path for the response.

It does not expose the private API server for arbitrary incoming connections.

These three scenarios illustrate different networking purposes:

• Public IP and Internet Gateway for public-facing access.

• Private IP and local routing for internal server communication.

• NAT Gateway for permitted outbound internet access from private instances.

15. Troubleshooting: Why Can't I Access My EC2 Application?

Imagine your EC2 instance is running, but your website does not open.

A common beginner mistake is assuming the problem must be the EC2 instance itself.

In reality, several networking layers can cause the same symptom.

A systematic approach is more useful than randomly changing Security Group rules.

Problem 1: The EC2 instance has no public IP

Symptom: You cannot access the instance directly using a public IPv4 endpoint.

Possible reason: The instance was launched without a public IPv4 address or Elastic IP.

What to understand: A private IPv4 address is not directly reachable over the public internet.

Possible approaches: Use a suitable public endpoint, load balancer, or private administrative access mechanism depending on the architecture.

Problem 2: The instance has a public IP, but no Internet Gateway route

Symptom: The instance has a public address, but external connectivity fails.

Possible reason: The subnet has no default IPv4 route to an attached Internet Gateway.

What to understand: Address assignment and routing are separate concerns.

Problem 3: Security Group does not allow HTTPS

Symptom: A website is running but cannot be reached over HTTPS.

Possible reason: TCP port 443 is not permitted from the intended client sources.

What to understand: Having a public IP and an internet route does not override Security Group restrictions.

Problem 4: The application is listening only on localhost

Symptom: An application responds internally but is unreachable from another server or through its external network address.

Possible reason: The service is bound to 127.0.0.1 rather than an interface reachable by the intended client.

What to understand: Firewall permissions do not automatically make a locally bound application externally accessible.

For example, a Node.js application bound to localhost can still be reached by a local Nginx reverse proxy, but not directly from another EC2 instance through the server's private IP.

Problem 5: A domain points to an old public IP

Symptom: The EC2 instance is reachable using its new public IPv4 address, but the domain no longer works.

Possible reason: The instance's automatically assigned public IPv4 address changed after a stop/start operation.

What to understand: DNS configuration must point to the current endpoint. A static Elastic IP or load-balancer DNS endpoint can avoid certain address-change problems.

Problem 6: Two private EC2 instances cannot communicate

Symptom: The web server cannot connect to the backend API.

Possible reasons:

• The backend Security Group does not allow the required connection.

• The web server's outbound permissions are too restrictive.

• Network ACLs block the traffic or return path.

• Routing has been customized incorrectly.

• The backend application is not listening on the correct address or port.

What to understand: Being in the same VPC makes local routing possible, but it does not automatically permit every connection.

A useful troubleshooting order

When debugging a connection, ask:

1. Address: Am I connecting to the correct private or public IP?

2. Route: Is there a valid network path to the destination?

3. Security: Do Security Groups and Network ACLs permit the traffic?

4. Service: Is the application running and listening on the intended port?

5. DNS: If using a domain, does it resolve to the correct endpoint?

This process helps narrow down the problem without introducing unnecessary security risks.

16. Common EC2 Networking Mistakes

Assuming a public IP makes an instance secure or accessible

A public IP is an address, not a security policy or a complete connectivity configuration.

Opening every port to 0.0.0.0/0

Allowing unrestricted inbound traffic on unnecessary ports increases exposure.

Only allow required protocols and ports from appropriate sources.

Exposing backend development ports publicly

A Next.js or Node.js application listening on port 3000 does not necessarily need that port open to everyone.

A reverse proxy or private application architecture can provide a better separation.

Using a changing public IPv4 address in DNS without planning for changes

Normal automatically assigned public IPv4 addresses are not permanently allocated to the account.

If a stable endpoint is needed, evaluate an Elastic IP or a managed load-balancing solution.

Giving every server an Elastic IP

Not every EC2 instance needs direct public IPv4 connectivity.

Internal services can communicate privately, and public IPv4 addresses can introduce additional cost and exposure.

Confusing Security Groups with route tables

Route tables determine traffic paths.

Security Groups determine permitted traffic.

Both are essential, but they solve different problems.

Assuming private IP addresses never change

The primary private IPv4 address normally persists across stop/start operations, but it is not a permanent identifier for the application if the underlying instance and interface are deleted and recreated.

Stable service discovery and architecture are still important.

17. Frequently Asked Questions

What is the difference between a private IP and a public IP in EC2?

A private IPv4 address is used for communication within private networks. A public IPv4 address enables internet communication when routing and security settings permit it.

Can an EC2 instance have only a private IP?

Yes.

Private instances commonly run backend services, internal applications, and other workloads that do not need direct public IPv4 connectivity.

Can two EC2 instances communicate without public IP addresses?

Yes.

Instances inside the same VPC can communicate using private addresses, subject to routing and security permissions.

Does an Elastic IP replace the private IP?

No.

An Elastic IP provides a static public IPv4 address associated with a private IPv4 address on a network interface.

The instance still uses private addressing within its VPC.

Does a public IP change after rebooting EC2?

A normal EC2 reboot generally preserves the auto-assigned public IPv4 address.

Stopping and starting the instance normally causes the automatically assigned public IPv4 address to be released and replaced.

Can one Security Group be used by multiple EC2 instances?

Yes.

A Security Group can be associated with multiple supported resources in the same VPC.

Multiple Security Groups can also be associated with a network interface, subject to AWS limits.

Are Security Groups free?

AWS does not charge separately for ordinary Security Group usage.

The EC2 instances, public IPv4 addresses, network data transfer, and other resources used by your architecture may still generate charges.

What is the difference between a Security Group and a Network ACL?

A Security Group is a stateful firewall associated with resource network interfaces.

A Network ACL is a stateless traffic control mechanism associated with a subnet.

Security Groups are generally the primary network access control mechanism for EC2 applications.

Does an Elastic IP guarantee that my website stays online?

No.

An Elastic IP keeps the public IPv4 address stable, but it does not make an unhealthy or stopped instance available.

High availability requires additional architectural decisions, such as redundancy, health checks, and load balancing.

Conclusion

EC2 networking is easier to understand when we separate the responsibilities of each component.

A private IP address enables communication within the VPC.

A public IP address provides an internet-facing IPv4 identity when suitable routes and security settings exist.

An Elastic IP address provides a static public IPv4 address that can remain allocated to your AWS account.

An Elastic Network Interface connects the EC2 instance to its subnet and carries its network addressing and Security Group associations.

A Security Group controls which connections are permitted to and from the instance.

These components work together, but none replaces the others.

The most useful habit is to think about every connection as a combination of destination address, network route, security permission, and an application listening on the correct port.

Once those four pieces make sense, many common EC2 networking problems become easier to understand and troubleshoot.

References

• Amazon EC2 networking overview - AWS Documentation

• Amazon EC2 IP addressing

• Elastic IP addresses - AWS

• Elastic Network Interfaces - AWS

• Security Group rules - Amazon VPC

• Internet Gateways - Amazon VPC

• Amazon VPC pricing