Amazon EC2 instances are assigned private IP addresses within the VPC's CIDR range (typically 10.0.0.0/16, 172.16.0.0/12, or 192.168.0.0/16). These addresses are only routable within the VPC and connected networks via VPN or Direct Connect.

Private IPs are reachable between instances in the same VPC by default, but there are important security considerations:

// Example security group rule allowing private IP communication
{
  "IpProtocol": "tcp",
  "FromPort": 22,
  "ToPort": 22,
  "UserIdGroupPairs": [
    {
      "GroupId": "sg-123456",
      "Description": "Allow SSH from same VPC"
    }
  ],
  "IpRanges": [],
  "Ipv6Ranges": [],
  "PrefixListIds": [],
  "ToPort": 22
}

While you can assume 10.x.x.x traffic originates within your VPC, you cannot assume it's always from your instances due to:

• Multiple accounts sharing VPC peering
• ClassicLink configurations
• Transit Gateway attachments

Instead of trusting private IP ranges blindly:

# Example: Verify instance identity using IAM roles
aws ec2 describe-instances \
  --instance-ids i-1234567890abcdef0 \
  --query 'Reservations[].Instances[].PrivateIpAddress' \
  --output text

Implement these additional security measures:

1. Use VPC security groups with least-privilege rules
2. Enable VPC flow logs to monitor traffic
3. Implement instance metadata checks

Here's how to verify instance identity in an application:

import boto3

def verify_instance(ip_address):
    ec2 = boto3.client('ec2')
    response = ec2.describe_instances(
        Filters=[{'Name': 'private-ip-address', 'Values': [ip_address]}]
    )
    if response['Reservations']:
        instance_id = response['Reservations'][0]['Instances'][0]['InstanceId']
        # Check tags or other identifying metadata
        return instance_id
    return None

Always combine network-level security with application-level authentication when designing your architecture.

When you launch an EC2 instance in AWS, it's assigned both a public and private IP address (if configured to do so). The private IP address exists within the VPC's CIDR block range you've defined (typically 10.0.0.0/16, 172.16.0.0/12, or 192.168.0.0/16). These private IPs are only routable within the VPC.

# Example AWS CLI command to view private IPs
aws ec2 describe-instances \
  --query 'Reservations[*].Instances[*].[InstanceId,PrivateIpAddress]' \
  --output table

By default, all instances within the same VPC can communicate with each other using private IPs. However, this doesn't mean they should communicate without proper security measures. The key points about private IP accessibility:

• Instances in the same VPC can reach each other via private IPs
• Cross-VPC communication requires VPC peering or Transit Gateway
• Security Groups and NACLs act as firewalls for this traffic

While private IPs are only accessible within your VPC, you should never assume they're automatically secure. Here's why:

# Example of a potential security risk if you trust all private IPs
# This is BAD practice - don't do this!
if request.remote_ip.startswith('10.'):
    grant_admin_access()  # Dangerous assumption!

Instead, implement proper authentication between services. For example, using IAM roles and instance metadata:

# Better approach using IAM roles
import boto3
from botocore.exceptions import ClientError

def verify_instance_identity(instance_id):
    ec2 = boto3.client('ec2')
    try:
        response = ec2.describe_instances(InstanceIds=[instance_id])
        return len(response['Reservations']) > 0
    except ClientError as e:
        return False

Here are some approaches to secure your instance-to-instance communication:

1. Use Security Groups as your primary firewall:

   # Example security group allowing only specific instances
   aws ec2 authorize-security-group-ingress \
     --group-id sg-903004f8 \
     --protocol tcp \
     --port 22 \
     --source-group sg-6e7af919
   

2. Implement Service-to-Service Authentication using mutual TLS or IAM
3. Use PrivateLink for sensitive services to avoid exposing them even within the VPC
4. Monitor VPC Flow Logs for unusual private IP communication patterns

In some cases, you might want additional isolation:

• Create separate subnets for different tiers (web, app, db)
• Use separate VPCs for different environments (prod, staging)
• Implement VPC endpoints for AWS services to keep traffic within AWS network

# Example VPC endpoint for S3
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-1a2b3c4d \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-11aa22bb