Compute and protect together
Comprehensively evaluate instance load, normal traffic, and attack risks to avoid focusing only on defense quotas and ignoring the computing and bandwidth requirements of the business itself.
TITANIUM CLOUDCarrying services on the cloud
Titanium Cloud
Carrying services on the cloud
DDoS-protected connection
Combine cloud computing resources with DDoS protection to plan hosting solutions for online businesses facing network attacks.
Titanium CloudResource architecture
- 01access layerUser connection·Business traffic
- 02protective layerDDoS detection · Traffic cleaning
- 03Computing layerCloud instances · Business applications
It is suitable for businesses that require cloud deployment and have clear protection requirements for network attack risks.
PRODUCT OVERVIEW
What is titanium cloud (DDoS-protected cloud)?
- cloud computing
- DDoS protection
- business continuity
Titanium Cloud takes DDoS-protected cloud as its product direction and integrates cloud computing and network attack protection into the same business plan. When selecting, evaluate normal business traffic and attack risks at the same time, and match computing resources, network bandwidth, and protection strategies.
What to evaluate
Titanium Cloud is designed for businesses that need to plan cloud computing and network protection at the same time. The focus of selection is to allow normal users to still complete key operations under abnormal traffic: ingress acceptance, cleaning and forwarding, origin server capacity and application strategies must be evaluated together. A single defense peak cannot explain the complete business carrying capacity.
Establish a line of defense against cyberattacks
Combining the detection and cleaning capabilities of DDoS-protected networks to handle DDoS traffic. The protection scope, trigger conditions and over-limit policy are subject to the actual plan.
Evaluate access according to application protocol
Distinguish the ports and protocols used by websites, games and interface services, check the support range before accessing, and take into account normal connection and protection requirements.
INSIDE THE ARCHITECTURE
From anomaly detection to business recovery, understand DDoS-protected links step by step
Splitting the DDoS-protected cloud into four links: entrance, detection and cleaning, trusted return to origin, and business processing can help locate where the fault occurred.
- 01
Business entrance
Confirm the access address, protocol and port range, and distinguish between normal business peaks and abnormal traffic baselines.
- 02
Test cleaning
Combining traffic rate, packet rate and behavioral characteristics to identify anomalies, trigger filtering or traffic diversion according to the agreed mechanism.
- 03
Trusted return to origin
The cleaned request is delivered to the business instance through the return-to-origin link, and is subject to origin server access control and identity verification.
- 04
Application processing and recovery
The business instance handles the request; after a switch or exception, the connection, interface and data dependency are verified, and the success rate of key operations is reviewed.
First distinguish between bandwidth, packet rate and connection indicators
Normal bandwidth describes legitimate business transmission requirements, while Gbps of attack traffic describes the amount of bits per second. The two have different purposes. PPS measures packet processing pressure, CPS measures new connections per second, and QPS measures requests per second. The same bandwidth may be accompanied by different packet rates and connection pressures. Long connections also depend on the number of concurrent connections. Capacity assessments should indicate measurement locations, time windows, and statistical directions.
Cleaning trigger and black hole recovery are two different things
Cleaning aims to filter out anomalies and continue to deliver legitimate traffic; blackholes may make all traffic to the target address temporarily unreachable. Before accessing, you should confirm the detection conditions, cleaning triggering method, connection impact during towing, and the processing mechanism after exceeding the protection boundary. The recovery plan needs to cover attack weakening determination, removal conditions, and business retesting. The disappearance of alarms cannot be regarded as recovery completion.
Bring the origin server into the protection scope
Proxy-based protection requires checking the complete path from the ingress to the origin server, including return-to-origin bandwidth, routing, certificates, and trusted source ranges. The origin server should only open necessary business entrances, check historical resolution, and test whether the domain name and management address are exposed. The back-to-origin whitelist solves the accessibility of legal forwarding. Access restrictions and authentication jointly reduce the risk of bypassing the entrance. Normal business must be verified after rule changes.
The above is a general protection architecture and selection method. The data sources are used to illustrate technical concepts and are not WAF.PRO's capability commitments. The access mode, agreement scope, protection specifications and recovery terms of Titanium Cloud should be based on the actual solution.
PERFORMANCE & CAPACITY
Use metrics to locate the bottleneck
Assessments should see both network entry and application results. Use normal business samples to establish a baseline, and then verify capacity and failure recovery during approved test windows.
| Metric | Application impact | How to assess |
|---|---|---|
| Normal business bandwidth | Download, upload, and return-to-origin peaks determine daily experience. | Record the service peak value by direction and confirm the forwarding capacity after cleaning. |
| Attack traffic Gbps | It reflects bandwidth pressure and cannot be converted into business throughput commitment. | Confirm the protection objects, continuous conditions and over-limit processing range. |
| Packet rate PPS | When small packets are dense, packet processing may reach a bottleneck before bandwidth. | Also observe packet rate, packet loss and network device pressure. |
| CPS and concurrent connections | New connections and existing connections consume processing and state resources respectively. | Record handshake success rate, active connections, number of reconnections and timeout. |
| QPS and interface time consumption | The same number of requests may also result in different computational and database loads. | Distinguish the interface type and check the tail delay, error rate and service success rate. |
Metrics and terminology
- Gbps vs. PPS
- Gbps represents the data rate of one billion bits per second; PPS represents the number of packets per second, reflecting different processing pressures.
- CPS and concurrent connections
- CPS is the number of new connections per second; concurrent connections is the number of connections that are still active at the same time, and the two are not interchangeable.
- QPS
- The number of requests per second needs to be understood in conjunction with interface complexity, identity verification, and backend resource consumption.
- black hole processing
- Discarding the traffic of the target address under certain conditions may also make normal access unreachable; the conditions for release and recovery must be clear.
BEFORE YOU CHOOSE
Define requirements before choosing resources
Bring these four types of information to make the selection discussion more concrete.
- business resources
- CPU, memory, disk, normal business bandwidth and access peaks.
- Protection amount
- Basic and elastic defense, billing methods, over-limit processing and black hole recovery strategies.
- Access and protocols
- Required TCP/UDP protocols, port ranges, connection persistence and access control.
- Application layer protection
- Whether requirements such as CC, WAF and WebSocket are supported and whether additional products are required.
APPLICATION SCENARIOS
Workloads to start with
Games and interactive services
Evaluate port protocols and network attack protection solutions for continuous connection, login and business communication requirements.
Publicly oriented website
Plan hosting resources for websites that encounter network layer attacks, and SCDN and WAF can be separately evaluated for application layer protection.
Online platform and interface
In response to activity peaks and attack risks, normal business bearing, access policies and protection capacity are planned at the same time.
DEPLOYMENT PLAYBOOK
Arrange access based on key transactions
First identify the operations that must remain available, and then decide what responsibilities the portal, application, and data layers will each have.
- 01
Sort out dependencies
List the domain name, port, certificate, callback source and data dependency, and select acceptance operations such as login, query or submission.
- 02
Verify compatibility
Confirm the support range, timeout, session persistence and real client address delivery methods of TCP, UDP, long connections and WebSocket.
- 03
Access in batches
Migrate low-risk entrances first, check parsing, return-to-source access control, and logs, then expand the business scope and retain the rollback steps.
- 04
Exercise recovery
Verify connection re-establishment, client backoff retries and backlog processing, and continuously check key interfaces and data consistency during the recovery phase.
Deployment trade-offs
Continuously cleaned links and on-demand pulling have different paths and switching costs; the access method should be determined based on the business requirements for delay, connection continuity and recovery time.
OPERATE WITH CONFIDENCE
From launch to ongoing operations
Let alerts reflect user impact
Place business metrics such as network traffic, connection failures, interface errors, and orders on the same timeline. Personnel on duty need to know the affected entrance, business scope and start time, and first determine whether key operations can still be completed before dealing with cleaning strategy or capacity issues.
Application layer protection requires understanding the business
DDoS also involves application layer resource exhaustion. CC usually describes page or interface-oriented request abuse, and WAF focuses on HTTP request inspection and rule control. For high-cost interfaces such as login and search, strategies should be formulated based on identity, speed, and resource budget to avoid judging risks based solely on bandwidth.
Leave a channel for normal traffic
Active traffic, partner callbacks, and shared exit users may exhibit high request densities. Before the strategy goes online, representative clients should be verified, and false blocking samples and rule versions should be recorded; necessary releases should be limited to objects and scope to avoid broad whitelists that weaken the protection of other entrances.
Continue to observe the origin server after recovery
When the network recovers, client reconnection and delayed tasks may arrive at the same time. The recovery status of the connection pool, queue, database and cache should be observed, the backlog should be digested according to business priority, and the differences between the three time points of protection triggering, business interruption and recovery should be reviewed.
CHOICES & TRADE-OFFS
Compare product advantages under real conditions
When your business is
More content downloads or resource distribution
First check the legal traffic capacity and caching policy.
Attack protection credits cannot replace the bandwidth required for daily downloads.
When your business is
Dense interfaces and high single calculation cost
Also plan request management and backend resource isolation.
When the network traffic is not heavy, the application may also be exhausted first.
When your business is
Games, push messaging, or ongoing conversations
List protocol compatibility and reconnection behavior as key points for acceptance.
The accessibility of the page is not enough to prove that the long connection business is running normally.
Three judgments that are easily overlooked
Misconception: higher defense Gbps means a faster website
Speed also depends on legitimate traffic bandwidth, origin routing, compute resources and application processing.
Misconception: DDoS protection removes the need for WAF
Network cleaning, application layer request management and vulnerability protection have different responsibilities and should be combined according to business.
Misconception: more scrubbed traffic means the service is down
The success rate of legitimate users should be checked at the same time. Filtering records alone cannot indicate that the business has been interrupted.
QUESTIONS & ANSWERS
Questions before you choose
How to choose between Titanium Cloud and ordinary cloud servers?+
Ordinary cloud servers focus on daily computing; Titanium Cloud also focuses on network attack protection. If the business has clear DDoS risks, DDoS-protected solutions should be evaluated based on attack history, bandwidth peaks, and business protocols.
Does Titanium Cloud automatically include WAF and CC protection?+
DDoS can involve the network layer and application layer, CC is usually an application layer attack, and WAF is oriented towards web request and application security. The “DDoS-protected” name alone cannot tell whether full CC and WAF capabilities are included. Please confirm the specific plan; the Standard of each SCDN line on this site and above includes WAF, and access can be evaluated separately.
What happens if the defense limit is exceeded?+
Different solutions may involve elastic defense, additional billing, current limiting or black hole processing. Before purchasing, please confirm the trigger rules, notification methods, recovery conditions and fees, and formulate a response plan based on business needs.
The origin server address has been hidden, do I still need to restrict access?+
Needed. Addresses may be exposed from history or other services, trusted back-to-origin access scopes should be established, and administrative portals should be protected.
How can I tell whether the problem is in protection or the application?+
Compare the three time lines of entry, return to origin and application; connection failure, origin server timeout and application error should be located separately.
The business bandwidth is very small. Can the connection indicator be ignored?+
No. Frequent connection establishment and a large number of persistent connections will cause different resource pressures, and CPS, concurrent connections and timeouts should be evaluated separately.
YOUR NEXT STEP
Plan your Titanium Cloud deployment
Provide business type, access area, peak load, data size and recovery objectives, and work with technical consultants to evaluate configuration, network and delivery solutions.