NAT Gateway on Huawei Cloud: A Practical SNAT and DNAT Guide

Every cloud deployment eventually runs into the same design question: which of my resources should be reachable from the internet, and which should stay hidden? Give every server a public IP and you get simplicity — plus a much bigger attack surface and a bigger bill. Hide everything and your private servers cannot even download a security patch. The NAT gateway is the middle path that most production networks end up using, and once you understand its two halves — SNAT and DNAT — the design decisions get a lot easier.

What a NAT gateway actually does

At its core, a NAT gateway sits between your virtual private cloud and the internet and translates addresses back and forth. Your servers keep their private IP addresses, which are never exposed. When traffic needs to cross to the public internet, the gateway rewrites the source or destination address (and usually the port) so the conversation works, then translates the replies back on the way in. Nothing on the internet ever sees your real private topology — it only ever sees the gateway’s public addresses.

Compared with attaching a public EIP to every single server, a gateway concentrates your public footprint into one managed place. Fewer public IPs to track, fewer firewall rules scattered across instances, and one clear chokepoint where you can observe what is going in and out.

SNAT: letting private resources reach out

SNAT (source NAT) handles the outbound direction. A server in a private subnet wants to pull OS updates, download a container image, or call a third-party API — but it has no public IP of its own. With an SNAT rule in place, the gateway rewrites the server’s private source address to one of the gateway’s public EIPs before sending the packet out. The reply comes back to the EIP, the gateway translates it back to the private address, and the server never knows the difference.

This is the pattern behind almost every private-subnet design you will see: application servers and databases live in private subnets with no public IPs at all, and a single SNAT configuration gives all of them controlled outbound access. It is simpler to manage than a fleet of EIPs, and it means your servers cannot be probed directly from the internet no matter what.

A practical tip: decide early whether your SNAT rules apply per-subnet or per-server. Subnet-level rules are easier to maintain — anything you drop into that subnet automatically gets outbound access. Server-level rules give you tighter control for special cases, like a host whose outbound traffic must come from one fixed, allowlisted source IP. Most teams end up with subnet-level rules as the default and carve out exceptions where they matter.

DNAT: letting the outside world reach in — selectively

DNAT (destination NAT) is the inbound mirror image. Sometimes you do want external traffic to reach a private resource: an HTTPS request to your web tier, or an administrative SSH session to a bastion host. A DNAT rule maps a public IP and port on the gateway to a private IP and port inside your VPC. An incoming connection to the gateway’s EIP on port 443 gets forwarded to your internal server or load balancer on port 443.

The key word is selectively. DNAT is port forwarding with intent: you open exactly the ports you need and nothing more. A common mistake is mapping broad port ranges just in case — that quietly recreates the exposed-server problem the private subnet was supposed to solve. Map 443 for your web service, use a non-standard port for admin SSH if you must expose it at all, and leave everything else closed.

A typical layout that works

If you are sketching your first VPC with a NAT gateway, this layout covers most web-application needs:

• One public subnet holding the NAT gateway (with its EIPs) and your public load balancer.
• One or more private subnets holding application servers, with an SNAT rule giving them outbound access.
• Databases in their own private subnets, often with no SNAT at all — they only need to talk to the application tier, never to the internet.
• DNAT rules only for the specific services that genuinely need inbound internet traffic.

This gives you defense in depth almost for free: even if someone compromises a web server, the database tier has no path to or from the internet to exploit.

Planning your public IPs

The gateway’s public face is one or more elastic IPs. A few things worth thinking about up front:

• Spread gateways across availability zones when high availability matters, so a zonal issue does not take your outbound traffic with it.
• If external partners allowlist your source IPs, keep the EIP set small and stable. Every extra EIP is another address they have to add, and SNAT source IPs changing unexpectedly is a classic integration headache.
• Remember that public IPs and their bandwidth are billed resources. A NAT gateway does not make bandwidth free; it just concentrates it.

Monitoring and troubleshooting

When a server cannot reach the internet, the NAT gateway is one of several suspects. A quick checklist that saves time:

1. Is the SNAT rule actually covering this server’s subnet (or the server itself)?
2. Is the gateway’s public IP healthy and is there available bandwidth?
3. Do the VPC route tables send the subnet’s default route to the NAT gateway?
4. Are security groups and network ACLs allowing the outbound traffic and the return path?

In my experience the route table is the culprit more often than the gateway itself — a subnet that was supposed to be private accidentally keeping a direct internet route, or a brand-new subnet missing the NAT route entirely. When inbound DNAT is not working, check the port mapping first, then the security group on the target server: the forwarded traffic still has to pass the server’s own firewall rules.

What a NAT gateway is not

Two misconceptions are worth clearing up. First, a NAT gateway is not a firewall. It translates addresses; it does not inspect traffic or block attacks. Pair it with security groups, network ACLs, and where appropriate a web application firewall. Second, NAT is not encryption. Traffic crossing the internet still needs TLS where confidentiality matters — NAT hides your topology, it does not protect your data in transit.

Wrapping up

For most teams, the NAT gateway decision tree is short: put workloads that do not need inbound internet in private subnets, give them outbound access with SNAT, expose only specific services with DNAT port mappings, and keep your public IP footprint small and stable. It is one of those services that is easy to set up in an afternoon and quietly pays for itself every day after — fewer public IPs to manage, a smaller attack surface, and a network layout that stays understandable as you grow.