{"slug":"networking-overview","title":"Networking Overview","description":"DanubeData provides comprehensive networking features to secure and optimize connectivity for your cloud resources. This guide covers networking concepts, features, and best practices.","section":"Features","url":"https://docs.danubedata.ro/networking-overview","markdown_url":"https://docs.danubedata.ro/networking-overview.md","breadcrumbs":[{"title":"Features","slug":null},{"title":"Networking","slug":"networking-overview"}],"headings":[{"level":1,"title":"Networking Overview","id":"networking-overview"},{"level":2,"title":"Overview","id":"overview"},{"level":2,"title":"Network Architecture","id":"network-architecture"},{"level":3,"title":"Public Network","id":"public-network"},{"level":3,"title":"Internal (Team) Network","id":"internal-team-network"},{"level":3,"title":"Private Networks (beta)","id":"private-networks-beta"},{"level":2,"title":"IP Addressing","id":"ip-addressing"},{"level":3,"title":"Public IP Addresses","id":"public-ip-addresses"},{"level":3,"title":"Internal Cluster Addresses","id":"internal-cluster-addresses"},{"level":2,"title":"Network Features","id":"network-features"},{"level":3,"title":"Bandwidth Allocation","id":"bandwidth-allocation"},{"level":3,"title":"Network Performance","id":"network-performance"},{"level":2,"title":"Connecting Resources","id":"connecting-resources"},{"level":3,"title":"Within the Same Team","id":"within-the-same-team"},{"level":3,"title":"Across Two of Your Own Teams","id":"across-two-of-your-own-teams"},{"level":3,"title":"Across Different Data Centers","id":"across-different-data-centers"},{"level":3,"title":"Exposing Managed Services to the Internet","id":"exposing-managed-services-to-the-internet"},{"level":2,"title":"Firewalls","id":"firewalls"},{"level":2,"title":"Load Balancers (coming soon)","id":"load-balancers-coming-soon"},{"level":2,"title":"DNS Management","id":"dns-management"},{"level":2,"title":"Security Best Practices","id":"security-best-practices"},{"level":3,"title":"Network Segmentation","id":"network-segmentation"},{"level":3,"title":"Access Control","id":"access-control"},{"level":3,"title":"Monitoring","id":"monitoring"},{"level":2,"title":"Cost Optimization","id":"cost-optimization"},{"level":3,"title":"Bandwidth Management","id":"bandwidth-management"},{"level":3,"title":"Network Design","id":"network-design"},{"level":2,"title":"Troubleshooting","id":"troubleshooting"},{"level":3,"title":"Connectivity Issues","id":"connectivity-issues"},{"level":2,"title":"Related Documentation","id":"related-documentation"}],"format":"markdown","word_count":1180,"content":"# Networking Overview\n\nDanubeData provides comprehensive networking features to secure and optimize connectivity for your cloud resources. This guide covers networking concepts, features, and best practices.\n\n## Overview\n\nDanubeData networking includes:\n\n- **Public Networking**: Internet-accessible resources with public IP addresses\n- **Private Networking**: Secure communication between resources\n- **Firewalls**: Fine-grained access control and security\n- **Load Balancers** (coming soon): Distribute traffic across multiple instances\n- **DNS Management**: Manage DNS records for your resources\n\n## Network Architecture\n\n### Public Network\n\nAll resources receive public IP addresses by default:\n\n- **IPv4**: Public IPv4 address for internet access\n- **IPv6**: IPv6 address for modern connectivity\n- **Bandwidth**: Generous bandwidth allocation per instance\n- **Global Accessibility**: Resources accessible from anywhere\n\n### Internal (Team) Network\n\nResources in the same team share a Kubernetes namespace and can communicate internally without traversing the public internet:\n\n- **Shared namespace**: every team has a private namespace; all of your VPS instances, databases, caches, and queues live inside it\n- **Internal DNS**: short hostnames like `redis-mycache` resolve from any VPS in the team\n- **Free internal traffic**: east-west traffic between resources in the same team does not count against VPS bandwidth\n- **Cluster-level enforcement**: firewall rules apply to internal traffic too — see [Firewalls](https://docs.danubedata.ro/networking-firewalls)\n- **Cross-team connectivity**: use [Network Peering](https://docs.danubedata.ro/networking-peering) to connect two of your own teams (e.g. staging ↔ production)\n\n### Private Networks (beta)\n\nBeyond 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](https://docs.danubedata.ro/networking-private) for the full guide.\n\n## IP Addressing\n\n### Public IP Addresses\n\nEach resource receives:\n\n**IPv4**:\n- Unique public IPv4 address\n- Static assignment\n- Included at no additional cost\n- Accessible from internet\n\n**IPv6**:\n- /128 IPv6 address\n- Static assignment\n- Modern protocol support\n- Included at no additional cost\n\n### Internal Cluster Addresses\n\nFor internal team communication:\n\n- Each resource has a cluster-internal address from the `10.x.x.x` range\n- Persistent across the resource's lifecycle\n- Used for VPS-to-database, VPS-to-cache, and VPS-to-VPS traffic in the same team\n- Not routable on the public internet\n- For databases, caches, and queues, prefer the internal DNS hostname over the IP — IPs may change after a node reschedule\n\n## Network Features\n\n### Bandwidth Allocation\n\nEvery VPS adds **20 TB/month** of included outbound (egress) traffic to your team's pooled quota:\n\n- **Pooled**: included egress is shared across all VPS instances in the team\n- **Overage**: €1.00/TB for traffic beyond the pooled quota\n- **Monitoring**: Track usage in dashboard\n- **No Internal Charges**: private-network traffic is free and never counts against the quota\n\n### Network Performance\n\n- **Latency**: < 1ms within same datacenter\n- **Throughput**: Up to 1 Gbps\n- **DDoS Protection**: Built-in protection against attacks\n\n## Connecting Resources\n\n### Within the Same Team\n\nResources that belong to the same team share a Kubernetes namespace and can communicate via:\n\n1. **Internal DNS** (recommended): use short hostnames like `db-orders` or `redis-cache` from any VPS in the team\n2. **Internal IP**: use the cluster `10.x.x.x` address shown on the [Networking page](https://docs.danubedata.ro/networking-overview)\n3. **Public network**: using the public IP — works, but counts against bandwidth and is unnecessary for same-team traffic\n\n**Benefits of internal traffic**:\n- Free bandwidth (does not count against VPS allowance)\n- Lower latency (no public-internet hop)\n- Not exposed to the public internet\n- Firewall still applies — restrict with rules that reference other instances directly\n\n### Across Two of Your Own Teams\n\nUse [Network Peering](https://docs.danubedata.ro/networking-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.\n\n### Across Different Data Centers\n\nResources in different datacenters communicate over the public internet:\n\n- Higher latency (50–200 ms typical)\n- Bandwidth charges apply\n- Consider a VPN if you need encrypted transport beyond TLS\n\n### Exposing Managed Services to the Internet\n\nManaged 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:\n\n- The instance gets a public hostname you can connect to from anywhere\n- 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\n- **Queues** additionally speak MQTT, MQTTS, STOMP, and STOMPS once external DNS is on, each on its own dedicated port — see [Connecting via MQTT & STOMP](https://docs.danubedata.ro/queue-mqtt-stomp)\n\nLock external access down to trusted networks with an inbound [firewall rule](https://docs.danubedata.ro/networking-firewalls).\n\n## Firewalls\n\nControl network access with firewall rules:\n\n- **Inbound Rules**: Control incoming traffic\n- **Outbound Rules**: Control outgoing traffic\n- **Protocol Support**: TCP, UDP, ICMP\n- **Port Ranges**: Specific ports or ranges\n- **Source/Destination**: IP addresses or CIDR blocks\n\n**Learn More**: [Firewalls Documentation](https://docs.danubedata.ro/networking-firewalls)\n\n## Load Balancers (coming soon)\n\nLoad balancers will distribute traffic across multiple instances:\n\n- **HTTP/HTTPS**: Layer 7 load balancing\n- **TCP**: Layer 4 load balancing\n- **SSL Termination**: Handle TLS at load balancer\n- **Health Checks**: Automatic unhealthy instance removal\n- **Sticky Sessions**: Session affinity support\n\n\n## DNS Management\n\nManage DNS records for your resources:\n\n- **A Records**: IPv4 address mapping\n- **AAAA Records**: IPv6 address mapping\n- **CNAME Records**: Domain aliasing\n- **MX Records**: Mail server configuration\n- **TXT Records**: Verification and SPF records\n\nAccess DNS management via **Networking** > **DNS**.\n\n## Security Best Practices\n\n### Network Segmentation\n\n- Use private networks for internal communication\n- Isolate different applications or environments\n- Limit public exposure to necessary services only\n- Use firewalls for fine-grained control\n\n### Access Control\n\n- Restrict SSH access to specific IP addresses\n- Use firewalls for all publicly accessible resources\n- Implement least privilege principle\n- Regularly review and update firewall rules\n\n### Monitoring\n\n- Monitor bandwidth usage\n- Track unusual traffic patterns\n- Set up alerts for suspicious activity\n- Review firewall logs regularly\n\n## Cost Optimization\n\n### Bandwidth Management\n\n- Use private networks for internal traffic (free)\n- Monitor bandwidth usage regularly\n- Optimize data transfer patterns\n- Cache static content\n- Compress data when possible\n\n### Network Design\n\n- Co-locate resources in same datacenter when possible\n- Use private networks to reduce bandwidth costs\n- Implement caching strategies\n- Consider CDN for static content\n\n## Troubleshooting\n\n### Connectivity Issues\n\n**Cannot connect to resource**:\n\n1. Check firewall rules allow your IP\n2. Verify resource is running\n3. Test with different network/IP\n4. Check DNS resolution\n5. Verify credentials\n\n**High latency**:\n\n1. Check geographic distance\n2. Run traceroute to identify bottleneck\n3. Verify network congestion\n4. Consider using closer datacenter\n5. Use private network if same datacenter\n\n**Bandwidth exceeded**:\n\n1. Review bandwidth usage in dashboard\n2. Identify high-bandwidth resources\n3. Optimize data transfer\n4. Consider upgrading instances\n5. Use private network more effectively\n\n## Related Documentation\n\n- [Firewalls](https://docs.danubedata.ro/networking-firewalls)\n- [Network Peering](https://docs.danubedata.ro/networking-peering)\n- [Private Networks](https://docs.danubedata.ro/networking-private)\n- [Platform Security](https://docs.danubedata.ro/platform-security)\n- [VPS Overview](https://docs.danubedata.ro/vps-overview)\n\n","prev":{"title":"Monitoring","slug":"cache-monitoring","url":"https://docs.danubedata.ro/cache-monitoring","markdown_url":"https://docs.danubedata.ro/cache-monitoring.md","json_url":"https://docs.danubedata.ro/cache-monitoring.json"},"next":{"title":"Firewalls","slug":"networking-firewalls","url":"https://docs.danubedata.ro/networking-firewalls","markdown_url":"https://docs.danubedata.ro/networking-firewalls.md","json_url":"https://docs.danubedata.ro/networking-firewalls.json"},"index_url":"https://docs.danubedata.ro/index.json"}