Cloud Server Network Security Journey

Securing a Cloud Server is not a single setting — it is a sequence. This journey walks you through FPT Cloud's network-security tools in the order you should apply them, from understanding your network foundation to locking down traffic, ordering your firewall rules, and handling advanced edge cases. Each stage links to the full how-to guide and ends with a way to confirm you are done.

Who this journey is for

• Cloud operators who provision instances and need to expose services (SSH, RDP, HTTP/HTTPS, databases) without leaving a virtual machine open to the internet.
• Security administrators who own a VPC and want a repeatable order of operations for controlling and auditing inbound and outbound traffic.

You do not need to read every linked page front to back. Use this page as a map: follow the stages in order, then open the linked guide only when you reach the step it supports.

The path at a glance

Think of the journey as a left-to-right flow:

Foundation
  → Security Groups
    → Rule priority
      → Security Group audit
        → Gateway / NAT egress
          → Advanced NIC / HA cases
            → Final verification checklist

1. Understand your foundation — VPC, Subnet, Floating IP, and where Security Groups fit.
2. Build your firewall — create Security Groups and inbound/outbound rules.
3. Order your rules — set priority so the right rule wins.
4. Audit at scale — filter and review Security Groups across the VPC.
5. Control edge traffic — Gateway and NAT Instance for egress.
6. Handle advanced cases — Allow Address Pair (HA) and static IP changes.

Before you start

• An active FPT Cloud account with access to the Networking service group in the portal.
• At least one VPC with a Subnet, and one virtual machine you want to protect.
• The role needed to create and edit Security Groups in your VPC (see your IAM settings).

Stage 1 — Understand your network foundation

Why it matters: Before you open or close a single port, you need to know what you are protecting. FPT Cloud builds on a Virtual Private Cloud (VPC) for internal connectivity, Subnets for segmentation, and Floating IP for external access. Security Groups sit on top of this as a virtual firewall. Knowing this layout tells you where each rule applies.

What you do: Read the networking model and identify your VPC, its Subnets, and how your instances reach the internet (standard gateway vs. the No-gateway model).

→ Networking Overview

You're done when: You can name the VPC and Subnet your target virtual machine lives in, and you know whether traffic leaves through the FCI gateway or a self-managed router.

Stage 2 — Build your firewall with Security Groups

Why it matters: A Security Group is your virtual network firewall. It controls which ports are open on a virtual machine and which internet addresses may reach them. This is the single most important step for keeping a server off the open internet.

What you do:

1. Create a Security Group in the target Subnet.
2. Add inbound rules for only the ports you need (for example, SSH on 22, HTTPS on 443).
3. Scope each rule's Source as tightly as possible — prefer MyIP or a specific IP over All IPv4, especially for sensitive ports like 22 and 3389.
4. Add outbound rules if you need to restrict where the server can connect.
5. Attach the Security Group to your virtual machine (or a CIDR range).

注意

Opening a sensitive port (22, 3389) to All IPv4 exposes the server to the entire internet. The portal shows a high-risk warning when you do this — allow trusted IPs only.

→ Security Group Management

You're done when: Your virtual machine is attached to a Security Group whose inbound rules open only the ports you intend, each scoped to trusted sources.

Stage 3 — Order your rules with priority

Why it matters: When several rules could match the same traffic, order decides the outcome. Priority controls which rule the firewall applies first — a misordered "Deny All" can silently block the access you meant to allow.

What you do: Open Manage priority rule for the Security Group and arrange rules so that specific rules (for example, Allow SSH) sit above broad rules (for example, Deny All). The lower the priority number, the earlier the rule is evaluated; the first match wins and the rest are skipped.

注記

Priority management is available only for certain tenants with special configurations. If you don't see the option, contact support. Changing priority applies in real time and does not cause VM downtime.

→ Manage Priority Rule

You're done when: Your most specific allow rules are evaluated before any broad deny rule, and a quick trace of a sample connection matches the outcome you expect.

Stage 4 — Audit your Security Groups at scale

Why it matters: One VPC can accumulate dozens of Security Groups. To keep your posture clean you need to find them fast — by name, tag, applied instance/IP, status, or firewall type — and spot rules that are too broad or no longer needed.

What you do: Use the Filter on the Security Group screen to narrow the list, for example all Active groups tagged tagging-prod whose name contains prod. Filtering is read-only and is for review only — it never changes a Security Group.

→ Filter Security Group

You're done when: You can list every Security Group applied to your production instances and confirm none expose a sensitive port to All IPv4.

Stage 5 — Control edge and egress traffic

Why it matters: Security Groups guard the virtual machine. The Gateway and NAT Instance govern how a whole Subnet reaches — or is reached from — the internet. Use these to give private instances controlled outbound access without giving them public IPs.

What you do:

• Review and manage routes, NAT, and no-NAT rules per gateway.
• For instances in an isolated network that still need outbound internet, route them through a NAT Instance.

→ Gateway

→ NAT Instance

You're done when: Private instances reach the internet only through the gateway or NAT path you intend, and no instance has an unexpected public route.

Stage 6 — Handle advanced cases

Why it matters: High-availability setups and manual IP changes can quietly break security if traffic bypasses your rules or an instance loses connectivity.

What you do:

• For HA configurations where a virtual IP or MAC moves between instances, configure Allow Address Pair so the extra IP/MAC pair is permitted on the interface.
• After editing a NIC, set the new static IP inside the guest OS — FPT Cloud does not update it automatically.

→ Allow Address Pair

→ Change Network Config

You're done when: Your HA virtual IPs pass traffic as expected and every instance keeps connectivity after a NIC change.

Verify your security posture

Run through this checklist before you consider the journey complete:

• Every internet-facing virtual machine is attached to a Security Group.
• No sensitive port (22, 3389) is open to All IPv4 without justification.
• Inbound rules open only the ports each service needs.
• Rule priority puts specific allow rules ahead of broad deny rules.
• Outbound rules and gateway/NAT paths match your intended egress.
• HA address pairs and static IPs are configured where applicable.

Next steps

• Tag your Security Groups so the filter audit in Stage 4 stays fast as you scale.
• Re-run the verification checklist whenever you add a new internet-facing service.
• Explore the full Networking and Manage Security Group sections for capabilities beyond this core path.