RUK-COM / VIRTUAL PRIVATE CLOUD

Connect your systems.
Define every path.

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.

Logical isolation Access per VM Expert-led design
YOUR NETWORK. YOUR RULES. Simulation
Private network: Internet through a router to a web endpoint; application and database stay private. PRIVATE NETWORK · 10.20.10.0/24 INTERNET VIRTUAL ROUTER Floating IP / NAT WEB SG · TCP 443 APP SG · TCP 8443 DATABASE SG · TCP 5432
Only Web is exposed · App and DB use private IPs

NETWORK EXPLORER / SIMULATION

See traffic flow. Understand access policies.

Explore gateway connectivity, three separate subnets or policies within one subnet. Switch traffic flows to see the router and security groups at work.

Three subnets · the router connects tiers; SGs filter VM ports
Simulation · example IPs Request · initiating connection
Internet → Virtual Router (DNAT) SG allows HTTPS → Web :443

Web → Router → App SG :8443 → App
App → Router → DB SG :5432 → Database

Initial diagram: three private subnets · no public endpoint on DB

Request Response Security group boundary

START WITH YOUR WORKLOAD

Choose boundaries that fit your workload.

01

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 topology
02

Separate Web / App / DB

Give 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 topology
03

One subnet, separate access with SGs

Place 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 topology

BUILD THE NETWORK YOU NEED

From addressing to access control.

Private networks & subnets

Plan CIDRs, allocation pools, gateways, DHCP and DNS around your systems, with non-overlapping IP ranges.

Virtual routers & NAT

Route between IP-managed networks at Layer 3 and plan Internet egress through SNAT.

Floating IPs

Associate a public IP with a VM’s private IP and deliberately choose which endpoints to expose.

Security groups

Allow connections by source, protocol and port at VM ports. Review all groups attached to each port.

Built around Cloud IaaS

Design networking alongside VMs, compute and storage around the same workload.

Expert planning and review

Work with Ruk-Com on topology and access-matrix reviews, within agreed permissions and service scope.

SECURITY AT THE VM PORT

A route is only half the story.

The router connects networks. Security groups determine permitted connections. This example uses role-based, stateful custom SGs.

Example access matrix · not the service default
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

The right compute.
A network designed with it.

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.

Compute / Virtual machines Web · App · Database
VPC / Network architecture Subnet · Router · Security Group
Ruk-Com / Your support team Plan · Review · Coordinate

FROM DIAGRAM TO DEPLOYMENT

Plan it before you connect it.

01

Map the workload

List VMs, existing CIDRs and required connections.

02

Set the boundaries

Choose a topology and public entry points.

03

Define access

Build an access matrix; review routes and SGs together.

04

Test and hand over

Test allowed, blocked and return traffic, then agree support scope.

A FEW GOOD QUESTIONS

Before you build your VPC.

Does a VPC mean dedicated physical hardware?

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.

Does every system need three subnets?

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.

Does the database need a public IP?

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.

How should existing systems or branches connect?

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

Bring your architecture.
Let’s connect the details.

Share your workload, IP ranges and access requirements to plan the topology and service scope together.