Clear connections between layers
Document which service needs to reach which destination. Distinguish application and data connections from unnecessary public exposure.
NETWORKING / VPC
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.
01 / Overview
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.
Document which service needs to reach which destination. Distinguish application and data connections from unnecessary public exposure.
Do not equate membership of a network with permission to use every resource. Define access by service, source and purpose.
Consider future services and networks that may need to connect. Identifying overlaps early reduces avoidable migration work later.
02 / Architecture
Illustrative network: application and data connections are planned separately after the user entry point. Private addressing does not replace permissions or encryption.
Selection guide03 / Selection guide
| Consider | How to decide | Why it matters |
|---|---|---|
| IP address space | Choose a plan that does not overlap existing or future connected networks. | Overlapping private ranges can create routing and access problems. |
| Traffic direction | Define incoming, outgoing and service-to-service connections separately. | Opening an inbound port may not cover every dependency an application needs. |
| Name resolution and routes | Define how services find a destination and the path they use to reach it. | Connectivity and correct name resolution must work together. |
| Access and observation | Plan permission rules and a way to investigate failed connections. | Private networks can still contain unintended access or broken dependencies. |
04 / Use cases
Show the user entry point, application communication and data connections separately. Define the access each layer really requires.
Make an explicit decision about communication between environments. Plan controls that prevent test processes from accidentally connecting to live data.
Organise service addressing and name resolution. Keep the connection changes required by a new service understandable.
05 / From planning to operation
List sources, destinations, ports and connection purposes. Treat administrative access separately from application traffic.
Check overlaps and supported connectivity options. Identify the effect of network changes on DNS and application configuration.
Allow the required connections and restrict unnecessary access. Review firewall and application permissions together.
Verify connections that should work and those that should not. Record recovery steps for access problems after a network change.
No. Network organisation works alongside authentication, firewall rules, operating-system updates and application security. Private addressing alone is not a security guarantee.
Addressing and encryption are different concerns. Plan suitable transport encryption and application authentication for sensitive data.
Verify regional, connectivity and routing options against the current service scope. Do not assume peering or VPN capabilities without confirming support.
No. Defining only the necessary connections creates a clearer operating model. Assess source and destination permissions, ports and the purpose of access separately.
Connect product decisions with installation, configuration and operating knowledge.
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
Tell us about your application, expected usage and operating requirements. Let’s bring the resource choices together.