Private gateway
Start with a private network and a virtual router. Use SNAT for outbound access and floating IPs only for VMs that need public ingress.
For initial deployments and internal services View this topologyRUK-COM / VIRTUAL PRIVATE CLOUD
Private cloud networking shaped around your workload. Define subnets, routing and access so your web, application and data tiers work together with clear boundaries—with Ruk-Com expertise.
NETWORK EXPLORER / SIMULATION
Explore gateway connectivity, three separate subnets or policies within one subnet. Switch traffic flows to see the router and security groups at work.
Web → Router → App SG :8443 → App
App → Router → DB SG :5432 → Database
Initial diagram: three private subnets · no public endpoint on DB
START WITH YOUR WORKLOAD
Start with a private network and a virtual router. Use SNAT for outbound access and floating IPs only for VMs that need public ingress.
For initial deployments and internal services View this topologyGive each tier its own subnet. The router connects the networks; security groups define which sources may reach each port.
For multi-tier systems and distinct ownership View this topologyPlace VMs in one network and apply policies by role. Same-subnet connections travel directly while still being filtered at VM ports.
For systems that benefit from a simpler layout View this topologyBUILD THE NETWORK YOU NEED
Plan CIDRs, allocation pools, gateways, DHCP and DNS around your systems, with non-overlapping IP ranges.
Route between IP-managed networks at Layer 3 and plan Internet egress through SNAT.
Associate a public IP with a VM’s private IP and deliberately choose which endpoints to expose.
Allow connections by source, protocol and port at VM ports. Review all groups attached to each port.
Design networking alongside VMs, compute and storage around the same workload.
Work with Ruk-Com on topology and access-matrix reviews, within agreed permissions and service scope.
SECURITY AT THE VM PORT
The router connects networks. Security groups determine permitted connections. This example uses role-based, stateful custom SGs.
| Source | Destination | Protocol / port | Result |
|---|---|---|---|
| Internet | Web |
TCP 443
|
Allow HTTPS |
| Web SG | App |
TCP 8443
|
Allow Web → App |
| App SG | Database |
TCP 5432
|
Allow App → DB |
| App | Internet |
TCP 443
|
Allow egress through SNAT |
| Web SG | Database |
TCP 5432
|
Blocked: no matching allow rule |
Review every attached SG The documented default SG allows all traffic. This restrictive example replaces any allow-all group with custom SGs: allow rules across attached groups are cumulative.
Returns belong to an established connection This stateful example permits returns for allowed connections. Verify the actual stateful setting and define required egress, such as DNS, for your workload.
VPC + CLOUD IAAS
Plan VM growth with a clear picture of each subnet, dependency and public entry point. Start with Cloud IaaS, then shape the VPC around your workload.
FROM DIAGRAM TO DEPLOYMENT
List VMs, existing CIDRs and required connections.
Choose a topology and public entry points.
Build an access matrix; review routes and SGs together.
Test allowed, blocked and return traffic, then agree support scope.
A FEW GOOD QUESTIONS
A VPC provides logical network isolation in shared cloud infrastructure. It does not automatically provide dedicated physical hardware. Discuss specific resource-isolation requirements with our team.
No. Use a private network with a router, separate subnets by tier, or one subnet with role-based SGs. Choose based on system size, operations and access requirements.
In this example the DB has no public endpoint. The app uses its private IP, with SG rules permitting only the required source and port.
Share your IP ranges, routes and connectivity requirements for assessment. The team will review compatibility and service scope for your project.
LET’S DESIGN YOUR NETWORK
Share your workload, IP ranges and access requirements to plan the topology and service scope together.