Networking FAQs
This page covers common and critical questions related to CloudRaya Networking Services, including VPCs, Subnets, Access Control Lists (ACLs), Public IPs, Load Balancers, VPN, and SSH Keys, with a focus on real-world architecture, production risks, and failure scenarios.
It is designed to help developers, operators, and platform owners design secure networks, avoid accidental exposure, and troubleshoot connectivity issues across CloudRaya environments.
Architecture & Design Decisions
Q: Why shouldn’t I assign a Public IP to every VM?
A:
Assigning Public IPs to all VMs:
- Exposes internal services and databases directly to the internet
- Increases security risk and scanning traffic
- Makes ACL rules harder to maintain
A safer pattern is to expose only a Load Balancer or one access VM and keep all backend services on private IPs.
Q: Should I use one VPC or multiple VPCs for my environments?
A:
For production and team-based workflows, use separate VPCs per environment. This prevents accidental access between development, staging, and production and allows stricter ACL policies for sensitive workloads.
Access, Isolation & Security
Q: What is the difference between a subnet and an ACL in CloudRaya?
A:
A subnet defines an IP range and groups resources together.
An ACL controls which traffic is allowed in and out of that subnet.
ACL rules apply to all resources in the subnet, not to individual VMs.
Q: Can I restrict network access per VM instead of per subnet?
A:
No. CloudRaya applies network controls at the subnet level using ACLs. If you need different access rules, place resources into different subnets.
Q: What is the most common way to accidentally expose a private service?
A:
Assigning a Public IP or adding an overly permissive ACL rule (such as allowing 0.0.0.0/0 on wide port ranges) to a subnet that contains private services like databases or internal APIs.
Connectivity & Operations
Q: How should I provide secure administrative access to my VMs?
A:
Use VPN access into your VPC and connect to VMs using their private IPs. Avoid opening SSH or RDP ports to the internet.
Q: What happens if I release a Public IP?
A:
The Public IP is detached and returned to the pool. Any service or DNS record pointing to it will stop working. The same IP is not guaranteed to be reusable later.
Q: Can I move a Public IP between VMs or Load Balancers?
A:
Yes. You can retain and reassign a Public IP to another supported resource within the same Cloud Zone. This is useful for maintenance or resource replacement without changing DNS records.
Q: Why can’t my application reach another service inside the same VPC?
A:
The most common causes are:
- Both services are in different subnets with restrictive ACL rules
- Required ports are not allowed in the subnet ACL
- Traffic is being blocked at the Load Balancer instead of passed through
Always verify subnet ACL rules first.
Load Balancing & Traffic Flow
Q: When should I use a Load Balancer instead of a Public IP on a VM?
A:
Use a Load Balancer when you need:
- High availability across multiple VMs
- Rolling deployments without downtime
- A single stable public endpoint for multiple backends
A Public IP on a VM is suitable only for single-instance or low-risk workloads.
Q: What happens if one backend VM goes down behind a Load Balancer?
A:
Traffic is automatically routed to healthy backend VMs. The failed VM will stop receiving traffic until it becomes healthy again or is removed from the pool.
Q: How do Load Balancer algorithms affect my application?
A:
Different algorithms (such as Round Robin or Least Connections) change how traffic is distributed. For example, stateful applications may require session persistence or consistent routing behavior.
Failure Scenarios & “Gotchas”
Q: What is the fastest way to break internal connectivity across multiple services?
A:
Editing an ACL rule on a subnet that contains multiple workloads. Because ACLs apply to all resources in a subnet, one misconfiguration can block traffic for several services at once.
Q: Why did my deployment suddenly fail after rotating SSH keys?
A:
If your automation or CI/CD pipelines rely on an old SSH key, rotating or deleting it will prevent access to VMs. You must update all systems that use that key.
Q: Can my VPN access stop working even if my VMs are running?
A:
Yes. VPN connectivity depends on:
- Active VPN configuration
- Correct routing to subnets
- ACL rules allowing VPN traffic
A change in any of these can block access to private resources.
Billing & Limits
Q: What networking resources continue to incur charges even if my VMs are stopped?
A:
Charges may continue to apply for additional Public IP addresses that are still allocated to your account, even if they are not currently attached to a running VM or service.
Services such as Load Balancers and VPN do not incur charges by themselves. However, if a Public IP is assigned to a Load Balancer or retained separately, that Public IP may still be billed.
Governance & Audit
Q: How can I find out who changed my network configuration?
A:
All networking actions (VPC creation, ACL changes, Public IP assignment, Load Balancer updates, VPN changes) are recorded in the User Action Log, where you can filter by resource type and status.
Best Practices
Q: What is the safest default network design for production workloads?
A:
A common production-safe pattern is:
- A dedicated VPC per environment (Production, Staging, Development)
- Multiple subnets per VPC to separate web, application, and database layers
- A Load Balancer with a Public IP for internet-facing traffic
- Private IPs only for backend and database workloads
- VPN access for administration instead of public management ports
This design limits blast radius, reduces attack surface, and simplifies access control.
Still Have Questions?
If you can’t find what you’re looking for, you can consult our CloudRaya AI Assistant through the live chat for quick guidance.
For more complex network designs or incident reviews, our support team can help you design a secure networking architecture tailored to your workload.
📩 Contact Support: support@wowrack.co.id