Free cloud for a static IP: AWS vs Google Cloud for algo trading

“Free VM” and “free static IP” are not the same product. That distinction matters to an API trader because the broker identifies the public source address of an order—not the price label attached to the virtual machine.

AWS and Google Cloud can both run a small dual-stack gateway. Both can also produce a surprise bill when an external IPv4 is assumed to be included with compute. A better design separates research from the network identity: run pandas, notebooks and backtests where compute is convenient, then use a small, controlled gateway only for the broker calls that require a whitelisted address.

This page explains the current public pricing, a two-tier architecture, IPv4 and IPv6 trade-offs, and the extra approval needed before family members share one static IP.

Pricing and broker rules change. The figures below were checked on 12 August 2026 against first-party provider and regulatory sources. Recheck the linked pricing page before provisioning.

Short answer

What AWS charges for a public static IPv4

AWS changed public IPv4 pricing on 1 February 2024. The current Amazon VPC pricing page lists $0.005 per public IPv4 address-hour for both in-use and idle addresses. AWS’s own example calculates one address running for 30 days as:

1 address × 24 hours × 30 days × $0.005 = $3.60

Using 730 hours for an average month gives about $3.65 per month, before EC2, storage, snapshots, data transfer, taxes or any managed network service. An Elastic IP is “static,” but attachment to a running instance does not remove this public IPv4 charge. The EC2 documentation is direct: AWS charges for all public IPv4 addresses, including addresses associated with running instances.

That makes public IPv4 an add-on to the VM rather than a free property of the VM. An advertised EC2 free allowance or promotional credit can reduce compute cost, but it should not be used to claim the address has no price. Credits can cover a bill temporarily; they do not change the underlying SKU.

AWS VPC can be dual-stack, and AWS states there is no additional charge to use IPv6 in VPC. IPv6 addresses are publicly routable, so security groups, network ACLs and routing must be configured deliberately. “No IPv6 address fee” does not mean free EC2 or free traffic.

How Google Cloud can save compute cost—and where it does not

Google Cloud’s Free Tier currently includes one non-preemptible e2-micro VM worth of monthly hours in us-west1, us-central1 or us-east1, plus limited disk and outbound data. The exact allowance and eligible regions are on the Google Cloud Free Program page.

The address is a separate line item. Google Cloud VPC network pricing lists:

• External static or ephemeral IPv4 on a standard VM: $0.005/hour.
• External IPv4 on a Spot VM: $0.0025/hour.
• Reserved static IPv4 that is not assigned: $0.01/hour.
• External IPv6 assigned to a VM: no address charge.
• Static regional IPv6: currently listed as no charge while that offering remains in its documented state.

Google defines a static external IPv4 as “in use” while associated with a VM even if that VM is stopped. Stopping a VM can reduce compute usage, but it does not stop the static IPv4 meter. Dissociating it changes the address to the more expensive unused reservation state; deleting the reservation releases the stable address you wanted to whitelist.

Therefore, the realistic low-cost Google design is not “free static IPv4.” It is free-tier-eligible compute plus a separately billed IPv4, or an IPv6-only design when every required broker endpoint accepts IPv6. At 730 hours, the standard-VM IPv4 is about $3.65/month, subject to currency conversion and tax.

Google Cloud supports dual-stack VMs. Its IPv6 configuration documentation describes an interface with IPv4 and a /96 IPv6 range. A dual-stack interface can have one external IPv4 and one external IPv6. This is useful during the industry’s transition: prefer IPv6 for compatible broker routes, retain IPv4 only where compatibility requires it, and measure the actual bill.

A two-tier architecture that stays small

The most useful optimization is architectural, not a hunt for a magical free IP.

Tier 1: research and decision-making

Run the expensive or bursty work on your laptop, a workstation, Google Colab, or managed batch compute:

• Download and cache permitted market data.
• Build OHLCV bars and compute technical indicators.
• Train models and run backtests.
• Apply position sizing, maximum-loss, freshness and market-session checks.
• Create a signed or authenticated order intent with a unique idempotency key.

This tier does not need the broker-approved egress address for ordinary analytics. It can scale up for a backtest and scale down afterward. The new ServLoci indicator notebooks demonstrate this split with 50 indicators, broker candle normalization and de-duplicated alerts.

Tier 2: network identity and order dispatch

Keep a small, patched and monitored gateway responsible for a narrow surface:

• Accept an authenticated order intent from Tier 1.
• Recheck quantity, symbol, freshness, exposure and idempotency.
• Send only place, modify and cancel calls through the broker-approved static address.
• Record the broker request ID, response, fill updates and failure state.
• Reject arbitrary destinations and non-order paths.

This tier usually needs little CPU. It needs predictable identity, secure secrets, daily session handling, logs, a heartbeat and a recovery plan. ServLoci is designed to be this stable broker-facing network lane, while your analysis continues on the compute you already own.

Laptop / Colab / research compute
  market data → 50 indicators → signal → risk gate → order intent
                                                   |
                                                   v
Small dual-stack gateway / ServLoci
  authenticate → deduplicate → final risk gate → broker order API
                                      IPv6 when accepted; IPv4 when required

The boundary also reduces data transfer through the gateway. Live ticks, historical bars and large option-chain downloads can stay direct unless a broker explicitly restricts those reads. Order messages are small; accidental full-feed proxying is not.

Why dual-stack can help a trader

Dual-stack does not improve a strategy’s expected return. It improves compatibility and operational control.

• IPv6 path: a large address space, no external-address fee on Google Cloud under current pricing, and no additional VPC IPv6 charge on AWS. It is valuable when a broker accepts and validates IPv6.
• IPv4 path: widest compatibility with legacy broker dashboards, APIs and third-party dependencies, but a scarce address with an explicit cloud price.
• Failover: a broker may allow a primary and secondary static IP. Whether those addresses can be IPv4, IPv6 or a mix is broker-specific.
• Verification: test the actual egress family seen by the broker-facing hostname. A dual-stack client can choose IPv4 or IPv6 based on DNS, routing and library behavior.

Do not expose a SOCKS or HTTP proxy to the public internet without strong authentication and destination restrictions. A globally routable IPv6 address still needs an ingress firewall; the absence of NAT is not a security policy.

Trading with family: approval comes before sharing

The exchange implementation standard says a static IP is generally mapped to one client at a time, with an exception for eligible family sharing after a written, registered-email or 2FA-validated request to the broker. See the NSE implementation standards and the underlying SEBI retail-algo circular.

The broker still controls the operational workflow. For example, FYERS documents a common static-IP request for family members covering a spouse, dependent parents and dependent children, subject to a signed declaration, relationship proof and KYC verification.

A safe family design keeps identities separate even when an address is approved for sharing:

• Separate broker accounts, API apps, access tokens and audit logs.
• Separate strategy limits and maximum loss for each client ID.
• An explicit mapping from order intent to the approved account.
• Broker confirmation retained with the infrastructure record.
• No pooling of credentials or silent order copying between accounts.

If the broker has not approved the relationship and address, provision separate egress identities. “Same household” is not enough evidence by itself.

Challenges that remain after obtaining a static IP

A stable address solves one requirement. It does not solve the whole trading system.

Daily authentication and 2FA

Many Indian broker access tokens are intentionally short-lived. Automating around 2FA in a way the broker does not permit can break terms or security. Follow the current official login flow and treat tokens as secrets.

Broker-specific schemas

Symbols, instrument IDs, candle timestamps, order types and product codes differ. Normalize market data into one internal shape, but keep the broker order adapter explicit. Avoid a “universal” payload that silently drops broker-specific constraints.

Duplicate and ambiguous orders

A client timeout does not prove the broker rejected an order. Query by a correlation or client-order ID before retrying. Persist intent, request, response and order updates so a process restart cannot repeat an order blindly.

Small-VM limits

A tiny VM is suitable for routing and light validation, not necessarily pandas, browser automation, a notebook server, a database, several WebSocket feeds and model inference at once. Memory pressure and CPU throttling can appear exactly when markets are busy. Keep Tier 2 narrow.

Cost drift

Snapshots, disks, logs, NAT gateways, load balancers, DNS, cross-region traffic and idle reserved addresses can cost more than the VM. Create a billing budget and alert on the first small amount rather than waiting for month end.

A practical decision checklist

1. Ask the broker which IP family its current API order allowlist accepts.
2. Confirm whether the address is client-level or app/API-key-level.
3. For family use, complete the broker’s declaration and KYC workflow first.
4. Calculate compute, IPv4 address, disk, egress, tax and backup—not just VM price.
5. Use dual-stack when it improves compatibility, but verify which path each hostname actually uses.
6. Keep data and indicator computation in Tier 1; keep Tier 2 small and restricted.
7. Test a read-only endpoint, then paper/dry-run, then the smallest permitted live order.
8. Record every signal, risk decision, idempotency key and broker response.
9. Configure billing and no-heartbeat alerts.
10. Recheck provider pricing and broker policy before every infrastructure migration.

Bottom line

AWS and Google Cloud both charge about $0.005 per hour for a continuously attached standard public IPv4 under their current published pricing. Google Cloud can still make the compute portion inexpensive through its eligible e2-micro Free Tier, while both clouds offer useful IPv6 economics. Neither turns a 24×7 static IPv4 into a permanently free resource.

For most individual traders, the clean design is two-tier: analysis on existing or elastic compute, then a small dual-stack order gateway with a broker-approved identity. For a family, use that same architecture only after the broker approves the shared address and each account remains separately authenticated, risk-limited and audited.

Open the 24-part notebook course or get a ServLoci static IP.