Skip to content
FibaCloud

NETWORKING / VPC

Connect application layers with a network plan you can explain.

Define the connections your web, application and data components actually need. A VPC plan makes private addressing, traffic direction and access boundaries explicit. Treat internet-facing services separately from components intended only for your application.

FibaCloud platformVPC
Separating application and data traffic
Workload first
Clear connections between layersAccess based on an actual requirementAn addressing plan that allows for growth

01 / Overview

A private network is an opportunity to make every connection deliberate.

The VPC approach organises network relationships between cloud resources. An application server may need to reach a database without that database being accessible from the entire internet. Design the relationship through addressing, routing and security rules together.

Private IP addresses do not by themselves provide encryption or complete security. Application authentication, operating-system security and network permissions remain separate layers. Verify regional, connectivity and routing options against the current service scope before making them dependencies of the architecture.

01

Clear connections between layers

Document which service needs to reach which destination. Distinguish application and data connections from unnecessary public exposure.

02

Access based on an actual requirement

Do not equate membership of a network with permission to use every resource. Define access by service, source and purpose.

03

An addressing plan that allows for growth

Consider future services and networks that may need to connect. Identifying overlaps early reduces avoidable migration work later.

02 / Architecture

Separating application and data traffic

Illustrative network: application and data connections are planned separately after the user entry point. Private addressing does not replace permissions or encryption.

Selection guide
Architecture explained
  1. User entry
  2. Application layer
  3. Private address space
  4. Data layer
Illustrative network: application and data connections are planned separately after the user entry point. Private addressing does not replace permissions or encryption.

03 / Selection guide

Clarify the network with four questions.

Clarify the network with four questions.
ConsiderHow to decideWhy it matters
IP address spaceChoose a plan that does not overlap existing or future connected networks.Overlapping private ranges can create routing and access problems.
Traffic directionDefine incoming, outgoing and service-to-service connections separately.Opening an inbound port may not cover every dependency an application needs.
Name resolution and routesDefine how services find a destination and the path they use to reach it.Connectivity and correct name resolution must work together.
Access and observationPlan permission rules and a way to investigate failed connections.Private networks can still contain unintended access or broken dependencies.

04 / Use cases

Architectures that benefit from a deliberate VPC plan.

01 / VPC

Web, application and database layers

Show the user entry point, application communication and data connections separately. Define the access each layer really requires.

02 / VPC

Development and production

Make an explicit decision about communication between environments. Plan controls that prevent test processes from accidentally connecting to live data.

03 / VPC

Multiple services

Organise service addressing and name resolution. Keep the connection changes required by a new service understandable.

05 / From planning to operation

From an address plan to verified connections.

  1. Map dependencies

    List sources, destinations, ports and connection purposes. Treat administrative access separately from application traffic.

  2. Choose addresses and routes

    Check overlaps and supported connectivity options. Identify the effect of network changes on DNS and application configuration.

  3. Apply access rules

    Allow the required connections and restrict unnecessary access. Review firewall and application permissions together.

  4. Test both allowed and denied paths

    Verify connections that should work and those that should not. Record recovery steps for access problems after a network change.

Questions

A clearer path to your next decision.

Talk to our team
Does a VPC cover every security requirement?

No. Network organisation works alongside authentication, firewall rules, operating-system updates and application security. Private addressing alone is not a security guarantee.

Does a private IP encrypt traffic?

Addressing and encryption are different concerns. Plan suitable transport encryption and application authentication for sensitive data.

Can a VPC connect to another network?

Verify regional, connectivity and routing options against the current service scope. Do not assume peering or VPN capabilities without confirming support.

Should every service inside the VPC reach every other service?

No. Defining only the necessary connections creates a clearer operating model. Assess source and destination permissions, ports and the purpose of access separately.

Go deeper with practical guides.

Connect product decisions with installation, configuration and operating knowledge.

Explore technical tutorials

Technical references

These references explain the technical concepts discussed on this page. Available configurations and service scope are defined by FibaCloud product and order information.

FIBACLOUD / VPC

Start with your project. Build on the right resources.

Tell us about your application, expected usage and operating requirements. Let’s bring the resource choices together.

Your privacy matters

We use cookies to provide our services and for analytics and marketing. To find out more about our use of cookies, please see our Privacy Policy and Cookie and Tracking Notice. By continuing to browse our website, you agree to our use of cookies.
Settings