Networking Overview

DanubeData provides comprehensive networking features to secure and optimize connectivity for your cloud resources. This guide covers networking concepts, features, and best practices.

Overview

DanubeData networking includes:

  • Public Networking: Internet-accessible resources with public IP addresses
  • Private Networking: Secure communication between resources
  • Firewalls: Fine-grained access control and security
  • Load Balancers (coming soon): Distribute traffic across multiple instances
  • DNS Management: Manage DNS records for your resources

Network Architecture

Public Network

All resources receive public IP addresses by default:

  • IPv4: Public IPv4 address for internet access
  • IPv6: IPv6 address for modern connectivity
  • Bandwidth: Generous bandwidth allocation per instance
  • Global Accessibility: Resources accessible from anywhere

Internal (Team) Network

Resources in the same team share a Kubernetes namespace and can communicate internally without traversing the public internet:

  • Shared namespace: every team has a private namespace; all of your VPS instances, databases, caches, and queues live inside it
  • Internal DNS: short hostnames like redis-mycache resolve from any VPS in the team
  • Free internal traffic: east-west traffic between resources in the same team does not count against VPS bandwidth
  • Cluster-level enforcement: firewall rules apply to internal traffic too — see Firewalls
  • Cross-team connectivity: use Network Peering to connect two of your own teams (e.g. staging ↔ production)

Private Networks (beta)

Beyond the team's shared namespace, you can also create dedicated VXLAN-backed L2 segments with your own CIDR blocks (RFC1918) and attach VPS instances to them as additional NICs — no reboot required. Each network is fully isolated from the public internet and from other tenants. See Private Networks for the full guide.

IP Addressing

Public IP Addresses

Each resource receives:

IPv4:

  • Unique public IPv4 address
  • Static assignment
  • Included at no additional cost
  • Accessible from internet

IPv6:

  • /128 IPv6 address
  • Static assignment
  • Modern protocol support
  • Included at no additional cost

Internal Cluster Addresses

For internal team communication:

  • Each resource has a cluster-internal address from the 10.x.x.x range
  • Persistent across the resource's lifecycle
  • Used for VPS-to-database, VPS-to-cache, and VPS-to-VPS traffic in the same team
  • Not routable on the public internet
  • For databases, caches, and queues, prefer the internal DNS hostname over the IP — IPs may change after a node reschedule

Network Features

Bandwidth Allocation

Every VPS adds 20 TB/month of included outbound (egress) traffic to your team's pooled quota:

  • Pooled: included egress is shared across all VPS instances in the team
  • Overage: €1.00/TB for traffic beyond the pooled quota
  • Monitoring: Track usage in dashboard
  • No Internal Charges: private-network traffic is free and never counts against the quota

Network Performance

  • Latency: < 1ms within same datacenter
  • Throughput: Up to 1 Gbps
  • DDoS Protection: Built-in protection against attacks

Connecting Resources

Within the Same Team

Resources that belong to the same team share a Kubernetes namespace and can communicate via:

  1. Internal DNS (recommended): use short hostnames like db-orders or redis-cache from any VPS in the team
  2. Internal IP: use the cluster 10.x.x.x address shown on the Networking page
  3. Public network: using the public IP — works, but counts against bandwidth and is unnecessary for same-team traffic

Benefits of internal traffic:

  • Free bandwidth (does not count against VPS allowance)
  • Lower latency (no public-internet hop)
  • Not exposed to the public internet
  • Firewall still applies — restrict with rules that reference other instances directly

Across Two of Your Own Teams

Use Network Peering to connect two teams you own (e.g. staging ↔ production). Once peered, resources in either namespace can reach each other over the cluster network.

Across Different Data Centers

Resources in different datacenters communicate over the public internet:

  • Higher latency (50–200 ms typical)
  • Bandwidth charges apply
  • Consider a VPN if you need encrypted transport beyond TLS

Exposing Managed Services to the Internet

Managed databases, caches, and queues are private by default — reachable only from resources inside your team's network. To connect from outside (your laptop, an external application, an IoT device), enable public access (external DNS) on the instance:

  • The instance gets a public hostname you can connect to from anywhere
  • Its firewall opens automatically the moment you enable public access — there's no separate rule to add — and closes again as soon as you turn it back off
  • Queues additionally speak MQTT, MQTTS, STOMP, and STOMPS once external DNS is on, each on its own dedicated port — see Connecting via MQTT & STOMP

Lock external access down to trusted networks with an inbound firewall rule.

Firewalls

Control network access with firewall rules:

  • Inbound Rules: Control incoming traffic
  • Outbound Rules: Control outgoing traffic
  • Protocol Support: TCP, UDP, ICMP
  • Port Ranges: Specific ports or ranges
  • Source/Destination: IP addresses or CIDR blocks

Learn More: Firewalls Documentation

Load Balancers (coming soon)

Load balancers will distribute traffic across multiple instances:

  • HTTP/HTTPS: Layer 7 load balancing
  • TCP: Layer 4 load balancing
  • SSL Termination: Handle TLS at load balancer
  • Health Checks: Automatic unhealthy instance removal
  • Sticky Sessions: Session affinity support

DNS Management

Manage DNS records for your resources:

  • A Records: IPv4 address mapping
  • AAAA Records: IPv6 address mapping
  • CNAME Records: Domain aliasing
  • MX Records: Mail server configuration
  • TXT Records: Verification and SPF records

Access DNS management via Networking > DNS.

Security Best Practices

Network Segmentation

  • Use private networks for internal communication
  • Isolate different applications or environments
  • Limit public exposure to necessary services only
  • Use firewalls for fine-grained control

Access Control

  • Restrict SSH access to specific IP addresses
  • Use firewalls for all publicly accessible resources
  • Implement least privilege principle
  • Regularly review and update firewall rules

Monitoring

  • Monitor bandwidth usage
  • Track unusual traffic patterns
  • Set up alerts for suspicious activity
  • Review firewall logs regularly

Cost Optimization

Bandwidth Management

  • Use private networks for internal traffic (free)
  • Monitor bandwidth usage regularly
  • Optimize data transfer patterns
  • Cache static content
  • Compress data when possible

Network Design

  • Co-locate resources in same datacenter when possible
  • Use private networks to reduce bandwidth costs
  • Implement caching strategies
  • Consider CDN for static content

Troubleshooting

Connectivity Issues

Cannot connect to resource:

  1. Check firewall rules allow your IP
  2. Verify resource is running
  3. Test with different network/IP
  4. Check DNS resolution
  5. Verify credentials

High latency:

  1. Check geographic distance
  2. Run traceroute to identify bottleneck
  3. Verify network congestion
  4. Consider using closer datacenter
  5. Use private network if same datacenter

Bandwidth exceeded:

  1. Review bandwidth usage in dashboard
  2. Identify high-bandwidth resources
  3. Optimize data transfer
  4. Consider upgrading instances
  5. Use private network more effectively