# Use Cases

This page describes common scenarios where Managed NAT Gateway addresses specific business and technical requirements in IONOS Cloud environments.

## Scenario 1: Securing database servers from direct Internet exposure

### Precondition

Your database cluster operates in a private subnet. The servers must download security patches and send backup data to external storage services; however, security compliance prohibits the cluster from accepting any inbound connections from the Internet.

### Solution

Managed NAT Gateway provides outbound-only Internet connectivity allowing your database servers to initiate connections for updates and backups while remaining unreachable to external attackers. The gateway automatically blocks all unsolicited inbound traffic.

**Typical setup:**

* Host database instances in a private subnet.
* Deploy a Managed NAT Gateway in a public subnet.
* Configure routing to direct `0.0.0.0/0` traffic to the NAT Gateway.
* Define security groups that allow outbound HTTPS for patch downloads.
* Ensure database servers have no assigned public IP addresses.

## Scenario 2: Enable software updates for air-gapped workloads

### Precondition

You run compliance-sensitive workloads in isolated private subnets that must periodically connect to vendor update servers, package repositories, and license validation endpoints, but must remain unexposed to broader internet access.

### Solution

A NAT Gateway provides controlled outbound access on demand. By enabling Internet connectivity only during maintenance windows, you ensure workloads remain isolated from inbound threats while still reaching specific external services. This approach maintains a "gap" during standard operations and only bridges it for required updates.

**Typical setup:**

* Host restricted workloads in a private subnet with no default Internet route.
* Deploy a NAT Gateway to facilitate outbound traffic only when necessary.
* Implement whitelist rules for specific update server domains.
* Apply routing modifications only during scheduled maintenance windows.
* Monitor all outbound connections to maintain a comprehensive audit trail.

## Scenario 3: Multi-tier application with private backend services

### Precondition

You deploy a three-tier web application where frontend servers use public IP addresses. However, the application and database tiers reside in private subnets and must access external APIs for payment processing, email delivery, and third-party integrations without exposing those tiers to the public Internet.

### Solution

A NAT Gateway enables private application servers to request external services securely. This architecture maintains strict security isolation between tiers while facilitating necessary integrations with SaaS providers and cloud services. By routing outbound requests through the gateway, you ensure backend instances remain protected from direct external probes.

**Typical setup:**

* Place load balancers and web servers in a public subnet to handle incoming traffic.
* Isolate application servers in a private subnet that routes outbound traffic through a NAT Gateway.
* Secure database servers in a dedicated private subnet with no direct Internet path.
* Route all private subnet traffic destined for the Internet through the NAT Gateway.
* Apply Network ACLs and Security Groups to restrict and audit inter-tier communication.

## Scenario 4: Container workloads pulling images from registries

### Precondition

You operate Kubernetes clusters or container hosts in private subnets that must pull container images from Docker Hub, private registries, and vendor repositories during deployments and auto-scaling events, but must not be directly reachable from the internet.

### Solution

A NAT Gateway provides reliable outbound connectivity for image pulls. This architecture eliminates the need for public IP addresses on worker nodes, thereby reducing the attack surface. Nodes securely reach any required registry while the gateway ensures the internal infrastructure remains protected from external discovery.

**Typical setup:**

* Deploy Kubernetes worker nodes or container hosts within a private subnet.
* Manage all registry-bound traffic through a central NAT Gateway.
* Configure DNS to ensure reliable registry name resolution.
* Implement a caching proxy (optional) to accelerate pulls for frequently used images.
* Restrict outbound connections to trusted registry endpoints using security policies.

## Scenario 5: Development environments accessing cloud services

### Precondition

Development teams use instances in private subnets that must connect to external resources, including GitHub, npm registries, cloud storage APIs, and SaaS development tools. These systems require Internet access for productivity but must not be exposed to the public Internet.

### Solution

A NAT Gateway provides seamless access to required external services while shielding development instances from external scanning and automated attacks. By routing all outbound developer traffic through a single managed point, you simplify the network architecture and ensure that internal systems remain unreachable from the outside.

**Typical setup:**

* Provision a dedicated private subnet for each development team or project.
* Centralize all outbound development traffic through a shared NAT Gateway.
* Establish routing tables for each development subnet to point internet-bound traffic to the gateway.
* Define firewall rules that permit only common development protocols. Example: HTTPS or SSH.
* Enable flow logging to monitor security patterns and accelerate troubleshooting.

## Next steps

* [<mark style="color:blue;">Managed NAT Gateway Overview</mark>](https://docs.ionos.com/cloud/network-services/nat-gateway/overview)
* [<mark style="color:blue;">Configure a NAT Gateway</mark>](https://docs.ionos.com/cloud/network-services/nat-gateway/setup-nat-gateway)
* [<mark style="color:blue;">Cloud API documentation</mark>](https://api.ionos.com/docs/cloud/v6/#tag/NAT-Gateways)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.ionos.com/cloud/network-services/nat-gateway/use-cases.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.