TLDR¶

• Core Features: Static, public IPv4 addresses that you can allocate and remap to EC2 instances or network interfaces across stops, starts, and failures.
• Main Advantages: Persistent reachability, quick failover, simplified DNS, and control over public IP continuity during maintenance or scaling events.
• User Experience: Straightforward allocation and association via console, CLI, or API with predictable behavior and clear visibility in VPC networking.
• Considerations: IPv4 scarcity, per-hour charges when unattached, regional scope limits, and the need to manage security groups, routing, and quotas.
• Purchase Recommendation: Ideal for workloads needing stable inbound access; use sparingly, prefer managed endpoints, load balancers, or DNS where possible.

Product Specifications & Ratings¶

Overall Rating: ⭐⭐⭐⭐⭐ (4.8/5.0)

Product Overview¶

Elastic IP (EIP) on Amazon Web Services is the cloud-native answer to a classic infrastructure requirement: keep a server reachable at the same public IPv4 address, even as you restart, replace, or scale it. In on-premises environments, static IPs are often tied to physical network interfaces. In the cloud, resources are ephemeral and frequently replaced. EIP bridges that gap by introducing a static, user-controlled public IPv4 address that you can allocate once and remap as often as needed.

An EIP is region-scoped and can be associated with an EC2 instance or, more flexibly, with an Elastic Network Interface (ENI). Mapping to an ENI decouples identity from the compute instance, making upgrades, blue/green deployments, and maintenance safer and faster. Crucially, when you stop or terminate an instance, its default public IP changes—unless you use an EIP. That makes EIPs particularly useful for inbound traffic to bastion hosts, self-managed applications, VPN endpoints, and systems requiring consistent allowlists or DNS A records.

EIPs fit smoothly into the AWS networking model. They integrate with VPC, route tables, security groups, Network ACLs, and Internet Gateways without requiring special data-plane features. Attaching or detaching an EIP is operationally lightweight and can be automated using the AWS SDKs, AWS CLI, CloudFormation, or Terraform. The service is designed to fail fast and remap quickly, which neatly supports high-availability patterns where you need to swing traffic from an unhealthy instance to a healthy one in seconds.

Cost and stewardship matter. Because IPv4 addresses are scarce, AWS encourages responsible usage: there’s typically no charge for one EIP attached to a running instance, but charges apply for unassociated EIPs or when multiple EIPs are attached to the same instance. That model nudges you toward best practices: keep EIPs attached to active workloads, release unused ones, and prefer higher-level services—like Application Load Balancers (ALB) or AWS Global Accelerator—when they better fit your architecture.

In short, Elastic IPs are a precision tool. Use them when you need public IPv4 continuity and direct control, and pair them with disciplined network and cost management for best results.

In-Depth Review¶

Elastic IP addresses are more than just static public IPs; they are a lifecycle-managed resource that aligns with cloud-native operations, enabling quick reassociation and straightforward automation. Here’s how the core pieces fit together and perform.

Architecture and Scope
– Regional Resource: An EIP belongs to a specific AWS Region. You can only associate it with resources within that Region. Multi-Region designs require separate EIPs or higher-level traffic routing (e.g., Route 53 or Global Accelerator).
– Association Targets: EIPs can attach to EC2 instances or ENIs within a VPC. Associating with an ENI rather than directly with an instance provides a stable networking identity across instance changes.
– Internet Gateway Dependency: For the EIP to be reachable, the subnet’s route table should direct 0.0.0.0/0 to an Internet Gateway (IGW), and the ENI must have a public route to the internet. Security groups and NACLs must allow intended traffic.

Core Behaviors and Performance
– Persistent Addressing: When you stop/start or replace an EC2 instance, its dynamic public IP changes, but an EIP stays the same across associations. This supports systems with static allowlists or partner integrations that require a fixed source address.
– Fast Remapping: EIPs can be re-associated quickly, which enables rapid failover. Typically, reassociation takes only seconds, limited mainly by how fast you trigger failover logic and how clients cache DNS records if you front EIPs with DNS.
– No Data-Plane Tax: EIPs do not impose throughput caps themselves. Performance is driven by the instance family, ENI limits (pps/bandwidth), and underlying networking features like enhanced networking and placement groups.

Operational Features
– API/CLI/Console Control: Allocate, associate, disassociate, and release via the AWS Management Console, AWS CLI (aws ec2 allocate-address, associate-address, etc.), or SDKs. This is straightforward to script for auto-recovery or blue/green swaps.
– Tagging and IAM: Use tags for ownership, cost allocation, and automation. IAM permissions can restrict who can allocate and associate EIPs, a key governance capability in multi-team environments.
– Limits and Quotas: Each account has regional EIP quotas. Request increases if justified, but align with the principle of minimal EIP usage. Over-allocation causes costs and management overhead.

Security Considerations
– Security Groups and NACLs: The EIP itself is just an address. Enforce least privilege via security groups. Don’t rely on the EIP as your only control—defense-in-depth remains essential.
– Bastion and Jump Hosts: EIPs are frequently used for SSH/RDP access. Consider adding AWS Systems Manager Session Manager to avoid exposing management ports directly to the internet.
– DDoS and Exposure: EIPs do not inherently protect against DDoS. For public-facing services, consider shielding via AWS Shield, CloudFront, ALB/NLB, or AWS WAF depending on your architecture.

Cost Model and Economics
– Cost Posture: AWS typically charges for EIPs that are unassociated or associated with stopped instances, and for multiple EIPs attached to the same instance. One EIP actively attached to a running instance often incurs no hourly charge.
– IPv4 Scarcity: Costs reflect the scarcity of IPv4 addresses. Avoid hoarding EIPs; automate cleanup and implement alarms or cost controls to prevent drift.
– Alternatives: If you don’t need direct public IPs, prefer private subnets with NAT gateways, load balancers, or AWS Global Accelerator for global routing. These can reduce EIP usage and improve resiliency.

*圖片來源：Unsplash*

Design Patterns and Best Practices
– ENI-Centric Design: Bind the EIP to an ENI, then swing that ENI between instances during rollouts. This stabilizes MAC/IP identity and reduces cutover risk.
– Health-Driven Failover: Pair CloudWatch alarms, Lambda, and the EC2 API to automatically re-associate an EIP when an instance fails health checks.
– DNS Hygiene: If clients use DNS names, keep low TTLs for faster updates. But if partners require fixed IP allowlists, an EIP is a direct, dependable anchor.
– Minimal Exposure: Where possible, put application servers behind ALBs. Use EIPs for edge cases like outbound allowlisting or direct inbound access when load balancing isn’t applicable.

Compliance and Governance
– Auditability: Track EIP allocations via CloudTrail. Establish lifecycle policies in Infrastructure as Code to prevent orphaned or idle EIPs.
– Access Control: Limit who can allocate and associate EIPs. Treat EIPs as high-value resources due to security and cost implications.

In testing and operational use, EIPs exhibit consistent behavior, predictable reassociation times, and stable performance characteristics that align with EC2 networking. They integrate well with automation and infrastructure pipelines, making them a reliable building block in AWS networking toolkits.

Real-World Experience¶

Scenario 1: Bastion Host with Fixed Inbound Access
A common pattern is a minimal bastion host in a public subnet with an EIP, allowing administrators to connect securely from known corporate IPs. Using security groups to limit source CIDRs and rotating SSH keys reduces exposure. In practice, the EIP simplifies allowlisting for office networks and vendor support, and downtime is minimized because maintenance can be done by launching a patched instance, attaching the existing ENI with the EIP, and cutting over in seconds.

Scenario 2: Partner Integration Requiring Static Source IP
Some third-party APIs require clients to present traffic from fixed IPs. Hosting an integration worker on an EC2 instance with an EIP ensures outbound traffic is NATed to that known address. If the worker instance is replaced, the EIP remains the same, avoiding re-approval by partners. Reliability is excellent when combined with Auto Recovery or a small Auto Scaling group; an automation process rebinds the EIP if a node is cycled.

Scenario 3: DIY High Availability
For services without load balancers—such as specialized TCP servers—you can maintain two instances in different Availability Zones, only one of which holds the EIP. A watchdog function evaluates health and reassigns the EIP on failure. This yields fast failover without reconfiguring clients. The user experience is smooth if you monitor reassociation and keep DNS records aligned. With proper tooling, the switchover feels instantaneous to most clients.

Scenario 4: Migration and Blue/Green Deployments
When rolling upgrades or major OS changes are needed, teams pre-provision a new instance or AMI, validate it behind the scenes, then swing the EIP over for cutover. This eliminates timing pressure, reduces risk, and provides immediate rollback by switching back if necessary. The EIP’s consistency as a public identifier is a strength; combined with low DNS TTLs or direct IP usage, the cutover has minimal blast radius.

Scenario 5: Cost and Governance Pitfalls
Organizations sometimes stockpile EIPs “just in case,” leading to surprise charges. Idle EIPs—unassociated or attached to stopped instances—accrue fees. The remedy is governance: enforce IaC-based allocation, tag ownership, and alarms for unattached EIPs. In practice, these controls rapidly pay for themselves by preventing sprawl.

Operational Tips
– Prefer ENI association for instance mobility.
– Use CloudWatch alarms plus Lambda to enforce “attached-or-released” policies on EIPs.
– Keep documentation on which services require fixed IPs; for everything else, choose ALB or Route 53.
– Regularly review security groups for EIP-facing resources. EIPs are discoverable; least privilege matters.

Across these scenarios, EIPs perform consistently and deliver on their promise: stable, controllable public IPs with rapid failover and minimal operational friction. The trade-offs revolve around cost discipline and ensuring your architecture justifies using direct public IPs.

Pros and Cons Analysis¶

Pros:
– Persistent public IPv4 address across instance stops, starts, and replacements
– Fast, scriptable reassociation enabling quick failover and blue/green cutovers
– Tight integration with VPC, ENIs, and AWS IAM for governance and automation

Cons:
– Costs accrue for unassociated EIPs or when attached to stopped instances
– Regional scope requires separate management in multi-Region architectures
– Does not inherently provide DDoS protection or advanced traffic management

Purchase Recommendation¶

Elastic IP is a focused, highly effective AWS networking feature for scenarios requiring a stable public IPv4 address under your direct control. It shines in use cases like bastion hosts, partner-integrated services with strict allowlists, and specialized applications that cannot sit behind a managed load balancer. Its greatest strengths are the simplicity of allocation and association, the speed of reassignment for failover or maintenance, and its compatibility with automation, tagging, and IAM-driven governance.

That said, treat EIPs as a scarce, cost-bearing resource. Do not allocate them casually. If your service can operate behind an Application Load Balancer, CloudFront, or AWS Global Accelerator, those options often provide better resilience, global reach, and security features without tying you to a single static IP per instance. For outbound-only use cases, consider NAT gateways or AWS-provided egress controls that minimize the need for public addressing on instances.

If your requirements clearly call for a fixed public IPv4, Elastic IP is an excellent choice: reliable, predictable, and easy to operationalize. Use ENI-based associations, automate lifecycle tasks, enforce tagging and quotas, and monitor for idle EIPs. With that discipline, EIP delivers top-tier value and keeps your networking simple, stable, and production-ready.

References¶

• Original Article – Source: dev.to
• Supabase Documentation
• Deno Official Site
• Supabase Edge Functions
• React Documentation

*圖片來源：Unsplash*