Why Security Infrastructure Must Be Redesigned During Cloud Migration

Why Cloud Security Architecture Must Differ from On-Premises

Cloud migration has become a necessity rather than an option for enterprises. To achieve cost efficiency, flexible scalability, and rapid service deployment, many organizations are moving their core systems to public or private clouds.
However, real-world projects frequently encounter unexpected problems.

"We moved the application to the cloud — but can we keep the same security architecture we had before?"

Web Application Firewalls (WAF), IPS, IDS, SSL Visibility solutions, and DDoS protection appliances that worked flawlessly on-premises often fail to behave as expected in the cloud. This isn't simply because the equipment is different — it's because the cloud's network architecture is fundamentally different from that of on-premises environments. 

In the Cloud, the Network Structure Itself Changes

In on-premises environments, it's common to physically place firewalls, IPS, and WAF devices inline along the network path so that traffic passes through them in a specific order.

In the cloud, however, most services are built on VPCs (Virtual Private Clouds).
All servers and security appliances operate within a virtual network, and physical L2 connections or bridge-based device linking are not possible. As a result, the Transparent-mode security configurations commonly used in traditional data centers are difficult to replicate as-is.

In other words, moving to the cloud isn't just about lifting security appliances onto virtual machines (VMs) — it requires redesigning the traffic path itself from the ground up. 

5 Security Constraints Most Commonly Encountered During Cloud Migration

1. Security appliances cannot be placed wherever you want
On-premises, devices can be directly interconnected to freely control traffic flow.
In the cloud, however, all communication relies on virtual switches and routing policies, so security appliances also function as just another routing hop.

This makes it difficult to apply traditional inline architectures as-is, and creates constraints for Deep Packet Inspection (DPI) and coordination between multiple security appliances.

2. SNAT can cause loss of the original IP address
In the cloud, SNAT (Source NAT) is often used to properly route response traffic.
The problem is that this process can change the original client IP address.

Losing the original IP causes several issues:

• Difficulty tracing the actual attacker's location
• Reduced accuracy of session-based security policies
• Limitations in log analysis and forensics
• Decreased security visibility

Even if the security appliance functions normally, the information available for analysis changes.

3. SSL/TLS decryption is also harder to control as desired
Today, the vast majority of traffic is HTTPS-based encrypted communication.
Analyzing it requires SSL/TLS decryption, but the SSL Termination feature of a cloud's default Load Balancer often decrypts the entire traffic path uniformly.

In actual operations, however, selective SSL decryption is frequently needed, such as:

• Decrypting only specific services
• Excluding sections containing personal information
• Decrypting only at specific security appliances

This kind of fine-grained control becomes even more critical in environments with high personal-data protection requirements, such as financial institutions and public agencies.
4. Routing-based design is required instead of redirect-based methods
On-premises environments offer various ways to steer traffic, such as L2 Redirect, GRE tunnels, and Policy-Based Routing (PBR).

Cloud environments, by contrast, mostly operate based on static routing tables.
This means flexible configurations like "route only certain traffic through the IPS" are not easy to achieve, and the entire security architecture must be designed around routing from the outset.

5. High Availability (HA) is not optional — it's mandatory
In the cloud, if a single security appliance fails, the entire service can be affected.
To prevent this, the following must be designed together:

• Active-Standby configuration
• Load Balancer
• Health Check
• Failover

However, this introduces new challenges in the form of increased operational complexity and cost.

 

The Solution Isn't a "Security Appliance" — It's "Traffic Design"

To address these challenges, the role of cloud-native L4/L7 switches (ADCs) has become increasingly important.
While a cloud's default Load Balancer focuses on server load balancing (SLB), real-world security environments require capabilities such as:

• Service Chaining
• Conditional SSL decryption
• Traffic branching by security appliance
• Separation of WEB/Non-WEB traffic
• Mirroring-based detection
• Inline security processing
• Automatic failover in the event of a failure

Only with the ability to flexibly route and control traffic toward the desired security appliances can organizations achieve on-premises-level security policies in the cloud.

 

In the Cloud Era, "Architecture" Matters More Than "Products"

Cloud migration is not simply the task of moving servers — it is the process of redesigning security architecture from the ground up.
Even security products that have been proven reliable on-premises may not behave the same way in the cloud, making it essential to design with the differences in network structure in mind.

Cloud security is evolving toward designs centered on the traffic path. Only by appropriately combining technologies such as selective SSL decryption, service chaining, mirroring-based detection, and High Availability (HA) can organizations preserve the flexibility of the cloud while achieving security levels that meet or exceed those of on-premises environments.

Ultimately, the key to a successful cloud migration lies not in simply deploying security products to the cloud, but in designing a security architecture optimized for the cloud environment.