IPv4 and IPv6: reduce costs while keeping users connected

A company runs ten cloud servers, each with a public IPv4 address. While reviewing its bill, it notices address charges on top of compute, storage and traffic. Could it switch the servers to IPv6 and remove those IPv4 addresses? Would its website still work for visitors on IPv4-only networks? What about payment, email and backup integrations?

In this hypothetical example, savings depend on architecture. You can adopt IPv6 and reduce public IPv4 usage while keeping users connected, provided the design covers incoming connections, communication with the application and outbound access to external services.

What changes between IPv4 and IPv6?

IP provides addressing for network interfaces and forwards packets between networks. IPv4 and IPv6 are versions of that protocol. IPv4 uses 32-bit addresses, such as 192.0.2.10. IPv6 expands addressing to 128 bits, such as 2001:db8::10, as defined in the IETF IPv6 specification. Both examples are reserved for documentation.

The larger address space accommodates many more devices and networks. It allows infrastructure to grow with less dependence on sharing IPv4 addresses. That does not mean every device should be reachable from the internet: routing and access rules remain separate decisions.

IPv4 local networks commonly use private addresses. A router performing NAT translates those addresses for external connections; with CGNAT, sharing also takes place in the provider's network. NAT does not replace a firewall policy. With IPv6, you must still decide who can initiate connections and which services are exposed.

An IPv4-only device cannot communicate directly with an IPv6-only server. You need both address families at the service or an intermediary that can receive a connection over one family and connect over the other.

Why adopt IPv6 when IPv4 still works?

IPv6 prepares applications for networks that already use it and supports growth with less dependence on individually billed public IPv4 addresses. It can also simplify parts of addressing in environments designed for it.

Adoption must include the application. Libraries, monitoring, VPNs, IP allowlists and administration tools need to handle IPv6. Actual connectivity depends on the provider and available routes; enabling IPv6 alone does not guarantee lower latency, higher speed or better security.

For many environments, the first step is to run IPv4 and IPv6 together, measure the results and gradually reduce IPv4 dependence.

Where IPv6 can reduce costs

Public IPv4 addresses are an easily identified expense. The Amazon VPC pricing page, checked on November 2, 2026, lists a standard rate of US$0.005 per public IPv4 address per hour, whether in use or idle. Exceptions and benefits need to be checked for each account.

Using 730 hours as a monthly reference:

Billed public IPv4 addresses	Calculation	Reference monthly cost
1	1 × 730 × US$0.005	US$3.65
10	10 × 730 × US$0.005	US$36.50
50	50 × 730 × US$0.005	US$182.50

These figures cover addresses alone, before any applicable benefits and taxes. They are neither the environment's total cost nor a rate shared by all providers.

If the company replaces ten public IPv4 addresses with a shared entry layer using two billed IPv4 addresses, that line item falls by US$29.20 per month. This is an arithmetic scenario: actual address counts depend on the service, availability zones and resilience requirements.

To decide whether it pays off, subtract additional proxy or load balancer charges, processing, transfer and operations from that reduction. Migration also has an initial cost. If the new layer costs more than the removed addresses, the monthly bill can increase.

Removing a machine's public IPv4 address does not automatically eliminate NAT Gateway expenses. Outbound access to IPv4 destinations may still require translation and incur charges. Compare the actual traffic paths before and after the change.

Three ways to keep users connected

1. Dual stack: offer IPv4 and IPv6 together

A dual-stack deployment accepts both address families. DNS publishes an A record for IPv4 and an AAAA record for IPv6; IPv6 DNS support is defined in RFC 3596.

Compatible clients can use mechanisms such as Happy Eyeballs, which coordinates connection attempts to reduce delays when one path has problems. It improves the experience but cannot repair a broken route or create connectivity where none exists.

Dual stack is often a useful adoption stage. Because it retains IPv4, it does not by itself produce public address savings.

2. A dual-stack entry layer with IPv6 origin servers

For websites and APIs, an alternative is to keep IPv4 and IPv6 at the layer receiving connections and use IPv6 to reach application servers:

1. User access: visitors connect to the domain normally over IPv4 or IPv6.
2. Dual-stack entry: a proxy or load balancer accepts the connection using either address family.
3. IPv6 origin: the intermediary establishes a new IPv6 connection to the application server, which may no longer need public IPv4.

One entry layer can serve multiple applications, subject to architecture and capacity.

Before choosing a CDN, proxy or load balancer, confirm IPv6 support for the connection to the origin. Accepting IPv6 visitors does not prove that a product can reach an IPv6-only origin. Check ports, TLS, WebSocket, upload limits, health checks and client IP handling. Accept forwarded headers only from trusted proxies.

The entry layer needs availability appropriate to the business. A single proxy can turn a small saving into a single point of failure. Restrict direct origin access to preserve controls enforced at the entry layer.

3. Keep IPv4 where dependencies still require it

Some services, protocols or integrations may require IPv4. Keep a compatible path while that dependency exists. This may mean retaining dual stack in part of the environment or concentrating IPv4 connectivity in specific components.

Situation	Path to evaluate
Public website with clients on different networks	Dual-stack entry layer
Multiple web applications with IPv6-compatible origins	Shared entry layer with IPv6 origin connections
Integration requiring a fixed IPv4 egress address	Controlled IPv4 egress with cost and availability planning
TCP or UDP service outside the web proxy's scope	Protocol-specific solution or retained IPv4

An HTTP proxy does not automatically solve email, VPN, gaming or every other protocol.

What if an IPv6 server needs to access an IPv4 API?

This is an outbound problem, separate from visitors reaching the website. NAT64 allows IPv6 clients to initiate communication with IPv4 servers through translation. DNS64 can synthesize AAAA records from A records to enable that path.

The pair requires suitable infrastructure and configuration. Applications using literal IPv4 addresses, protocols embedding addresses in payloads and egress IP requirements need specific evaluation. Translation and traffic charges may apply.

NAT64/DNS64 does not automatically let an IPv4 visitor reach an IPv6 origin. For that direction, plan a compatible entry layer such as the proxy described above.

How to adopt IPv6 without disrupting operations

Start with an inventory: who accesses the application, which services does it call and how does the team administer servers? Include payments, webhooks, email, package repositories, backups, VPNs and monitoring.

Then introduce the change gradually:

1. Enable and validate infrastructure IPv6. Check addresses, routes, cloud rules, host firewalls and the interfaces where applications listen.
2. Check security for both address families. Avoid applying restrictions only to IPv4. Preserve ICMPv6 messages required for networking, following the IETF recommendations for ICMPv6 filtering.
3. Test before publishing AAAA. A DNS record only announces an address; it does not configure networking, TLS or the application.
4. Validate access and integrations. Test login, uploads, payments and webhooks on IPv4-only, IPv6 and dual-stack networks, including mobile devices.
5. Monitor by address family. Compare errors, response times and availability. Check IP handling in logs, alerts and access lists.
6. Prepare rollback. Plan DNS TTLs and retain the previous path during observation. DNS changes do not immediately remove cached records.
7. Remove IPv4 only where it is dispensable. Confirm inbound access, outbound access, administration and recovery before releasing billed addresses.

Commands for an initial check

Replace example.com with a domain you administer:

dig +short A example.com
dig +short AAAA example.com
curl -4 --connect-timeout 10 -I https://example.com
curl -6 --connect-timeout 10 -I https://example.com

The first two commands query DNS. The others attempt an HTTP HEAD request over the specified address family. The curl -6 test requires IPv6 connectivity on the source machine and network. A local failure alone does not prove a server fault. Some services do not accept HEAD; test a suitable endpoint instead.

These commands provide an initial check rather than complete production validation. If a proxy is involved, test the path to it and its connection to the origin separately.

Frequently asked questions

Can I run a public website on an IPv6-only server?

Yes, provided users without IPv6 have a compatible entry layer that can reach that origin. A domain pointing only to an IPv6 origin does not directly serve IPv4-only networks.

Is adding an AAAA record enough?

No. The advertised address needs working routing, appropriate firewall rules and an available service. Publish the record after validating those conditions.

Is IPv6 always cheaper?

No. Savings depend on provider charges, the IPv4 addresses you can remove and the layers needed to keep the service running. Traffic, compute and operations still have costs.

Should I disable IPv4 now?

Let tests and dependencies determine that decision. You can enable IPv6 first and keep IPv4 where it remains necessary without migrating every component at once.

Applying this to your environment

When comparing servers, include public IPs, incoming traffic and outbound integration access in the same calculation. The Fidalgo VPS and cloud comparison tool helps you start with CPU and memory; network costs need to complete that analysis.

If your company wants to adopt IPv6 or review IPv4 expenses, Fidalgo can help map dependencies, design connectivity and validate the migration. Talk to us about your environment.