Skip to content

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 and 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 10 Gbit/s uplink
  • 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 and 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, and external clients can connect right away: its default firewall allows the service port from any address
  • Turning public access back off closes the public endpoints again
  • Queues additionally speak MQTT, MQTTS, STOMP, and STOMPS once external DNS is on, each on its own dedicated port — see Connecting via MQTT & STOMP

To limit public access to trusted addresses, edit the instance's firewall: its inbound rules also apply to the public endpoints. See Restricting public access.

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