Multi-Platform Server Maintenance Differences: Console, Security Groups, and Image Ecosystems

When maintaining servers across multiple cloud platforms, issues often stem not from technical limitations, but from the assumption that “operations here are the same as there.” Each platform’s console structure, security group model, and default images differ significantly; applying experience blindly leads to pitfalls.

This article does not evaluate platform superiority or inferiority, but focuses on the differences that must be verified per platform during managed operations.

Dimensions to Verify

Security Groups: The Most Common Pitfall

Different platforms have several common differences in security groups:

• Different Default Policies: Some deny all inbound traffic by default, while others allow certain common ports.
• Different Rule Priority Models: Some use priority numbers, while others follow a “Deny Takes Precedence” logic.
• Different Binding Methods: Bound to instances vs. bound to network interfaces (ENIs).

# Do not only troubleshoot on the machine; verify the console security group simultaneously.
# Server-side (System Firewall)
firewall-cmd --list-all

# External Verification (from another machine)
nc -zv Server_Public_IP Port
# Timeout = Blocked (could be security group or system firewall)

When troubleshooting port connectivity issues, always verify the security group separately. It exists outside the server, so no command executed inside the machine can detect it.

Image Ecosystem and Default Configurations

Different platforms’ public images may have different pre-installed software and default configurations, leading to environmental discrepancies:

# Verify item by item before deployment (do not assume it matches previous machines)
cat /etc/os-release
php -v; php -m | tr 'n' ' '
mysql --version
ss -lntp                 # Check which ports are listening by default
cat /etc/ssh/sshd_config | grep -E 'PermitRootLogin|PasswordAuthentication'

Practical Advice for Multi-Platform Maintenance

1. Establish a Per-Platform Verification Checklist

When taking over a new server (regardless of platform):
□ Console security group rules (Inbound/Outbound)
□ System firewall status
□ Location of VNC / Rescue Mode access
□ Snapshot policies and costs
□ Default SSH configuration (Can root log in?)
□ Default listening ports (Any unnecessary services?)
□ Monitoring alert configuration location
□ Ticket entry point and response levels

2. Do Not Copy Configurations Across Platforms

# When migrating/creating new instances, compare rather than copy
diff <(php -m | sort) /tmp/old_php_modules.txt
diff /etc/nginx/conf.d/old.conf /etc/nginx/conf.d/new.conf

“Copying from another machine” carries higher risks in multi-platform scenarios—different underlying images mean identical configurations may yield different results.

3. Document Platform-Specific Operation Paths

Platform-Specific Records (Example Structure):
- Security Groups: Console → Network & Security → Security Groups
- VNC Access: Console → Instances → Remote Connection
- Snapshots: Console → Storage & Snapshots
- Tickets: Console → Top Right Corner → Submit Ticket

This information is rarely used daily, but lacking it during emergencies puts you at a severe disadvantage.

Decision Tree

Taking Over a New Platform Server
├─ First, locate the "last resort" (VNC/Rescue)
├─ Then, verify network boundaries
│  ├─ Console Security Groups (Outside the server, must be checked separately)
│  └─ System Firewall
├─ Verify environmental differences (Do not assume consistency with other platforms)
│  ├─ OS version, pre-installed software, default ports
│  └─ Default SSH configuration
├─ Verify recoverability
│  └─ How to create snapshots and configure backups
└─ Document operation paths for this platform (Useful in emergencies)

Scenario Walkthrough: Same Configuration, But Ports Fail After Switching Platforms

Phenomenon: An environment running smoothly on Cloud Platform A fails to expose its service ports after being moved to Cloud Platform B with the exact same configuration. The configuration was double-checked and found identical.

1. First, confirm if the program is running → Process is active, port is listening,
   indicating the issue is not with the service itself.
2. Access from the server itself → Returns normally.
   If local access works but external access fails, the scope immediately narrows to the network layer.
3. Troubleshoot layer by layer → Host firewall rules are correct.
4. Realize there is a layer outside the server → Cloud platform access control is an independent layer,
   invisible from within the machine; verification must happen in the console.
5. Confirm the new platform’s default policy differs → Platform B allows only a few ports by default,
   requiring manual rule addition in the console.
6. Verify after allowing access, and note this difference → Treat it as a new variable when switching platforms.

# Fixed order, platform-agnostic
# 1. Is it listening?
ss -lntp | grep Port

# 2. Local access (Most valuable test)
curl -sS -o /dev/null -w '%{http_code}n' http://127.0.0.1:Port

# 3. System Firewall
firewall-cmd --list-all 2>/dev/null | head -20
iptables -L -n | grep Port

# 4. Cloud Platform Security Group — Cannot be queried on the server; must check the console

Root Cause: Different cloud platforms have different default allow policies.
A habit formed on one platform (“modifying host-side settings is sufficient”) does not hold on another.

Two Key Takeaways:

• In troubleshooting link issues, “Local OK, External Fail” points directly to the solution.
  It immediately rules out service issues and focuses attention on control policies.
• Host firewalls and cloud security groups are two independent layers; the latter is invisible inside the server.
  If everything looks normal inside the server but connectivity still fails, go straight to the console.

Comparison of Dimensions to Verify Across Three Platforms

The first row represents the most frequent source of problems.
System firewalls and cloud platform security groups are two independent control layers.
Habits formed on Platform A (“only modifying the system firewall is enough”) may not apply to Platform B,
producing identical symptoms: local access works, external access fails, and the missing layer is often overlooked.

# Fixed order for troubleshooting "Local OK, External Fail" (Platform-agnostic)
# 1. Is the service listening?
ss -lntp | grep Port

# 2. Is local access possible? (The dividing line)
curl -sS -o /dev/null -w '%{http_code}n' http://127.0.0.1:Port

# 3. System Firewall
firewall-cmd --list-ports 2>/dev/null
iptables -L -n | grep Port

# 4. Cloud Platform Security Group — This layer can only be confirmed in the console; CLI cannot see it

Step 4 is the key difference in cross-platform troubleshooting: Security group status is invisible inside the server.
Therefore, after verifying the first three steps inside the server with no anomalies,
do not continue searching on the machine; go directly to the console to verify security group rules.

Three Practical Suggestions for Co-existing Platforms

1. Maintain your own configuration checklist: Do not rely on any platform’s UI; record which ports are actually open in each environment.
2. Standardize the sequence for port changes: Add new, verify, then remove old. Follow this sequence across all platforms.
3. Do not assume consistent platform behavior: When switching platforms, treat security groups and images as new variables and re-verify them.

8 Common Pitfalls

1. Applying experience from other platforms: Security group models may be completely different.
2. Troubleshooting port issues only on the machine: Security groups cannot be queried there.
3. Adding security group rules but not binding them to instances: Rules take no effect.
4. Assuming default configurations are consistent: SSH, firewalls, and pre-installed software may vary.
5. Using unverified marketplace images: Prefer public images.
6. Not knowing where VNC is: Searching for it only when locked out.
7. Not confirming snapshot policies: Discovering no snapshots exist when recovery is needed.
8. Copying configurations across platforms: Different underlying images may lead to different results.

Real Customer Feedback (From Cloud Marketplace Reviews and Inquiries)

The following excerpts are taken from real buyer reviews and inquiries for similar maintenance services on Alibaba Cloud, Tencent Cloud, and Huawei Cloud marketplaces (Service providers include our store and peers; provided solely for reference based on real feedback, not fictitious tickets):

28***05 2021-06-06 5.0 Secure & Reliable | Comprehensive After-sales | Skilled Technical Staff (User did not fill in comment content) 10***31 2021-06-06 5.0 On-time Delivery | Affordable Price | Skilled Technical Staff (User did not fill in comment content) 10***31 2021-06-05 5.0 Affordable Price | Secure & Reliable | Comprehensive After-sales Useful. Helped me handle several abnormal processes.

10***44 2026-09-09 5.0 Comprehensive Features | User-Friendly Product | Clean Interface Useful. Supports the latest WordPress 7.1 system.

1****1 Rating: 5.0 Points 2020-06-18 11:51 Many thanks! He****She Society Rating: 5.0 Points 2020-04-21 15:04 The boss is great! Configuration was fast! No interruptions in between! Excellent!