From server ownership to scale
“We should be able to handle early traffic with cloud infrastructure.”
In meetings about upcoming game launches, the word “cloud” comes up more often than ever.
Yet when someone asks, “What exactly is the cloud?” the answers are often vague.
“It is where data is stored.”
“It means renting servers from AWS or Azure.”
These answers are not wrong. But they do not explain the real shift.
Cloud is not simply a storage space or a rented server. It is a concept that changed the way IT services, including games, are operated.
Only a few years ago, the first item on a game launch checklist was often “concurrent user simulation.”
The reason was simple. At the time, game companies had to purchase servers directly or install them in an IDC before launching a service.
The process looked something like this:
Estimate concurrent users, decide how many servers to buy, place the hardware order, install the equipment, and only then begin to finalize marketing and operational plans.
This model is called on-premises, meaning the game company owns and operates the infrastructure itself.
At first glance, this may sound stable. In reality, it created serious business risk.
If a game performed better than expected, the servers could fail under the load. If it performed worse than expected, expensive hardware remained underused. Maintenance costs continued either way. Launch schedules were vulnerable to delays because hardware ordering and installation took time. Global expansion was also slow, since overseas service meant separate infrastructure contracts, logistics, and physical setup in each market.
In short, the model created risk on both sides. Success could overwhelm the system, and weak performance could leave the company with wasted capital.
Cloud emerged as a response to this problem.
Its core idea is simple. Instead of buying infrastructure in advance, companies can use computing resources when needed and release them when they are no longer needed. This is a shift from ownership to usage based operations.
For example, an on-premise model may require a large upfront capital investment to purchase servers. Cloud changes this into an operating expense model, where companies pay based on actual usage. As a result, investment risk becomes more distributed and more manageable.
A useful analogy is electricity. Most people do not install a private power plant at home. They connect to a grid and use only the electricity they need. Cloud applies a similar logic to servers, storage, databases, and networks.
This model entered the mainstream in 2006, when Amazon Web Services introduced services such as EC2 and S3.
People often describe it as “Amazon started renting out spare servers,” but the real background was more strategic than that.
Amazon’s internal teams were repeatedly rebuilding infrastructure, and the company recognized that infrastructure itself could be standardized and offered as a service.
That decision led to services such as EC2 for computing and S3 for storage. From that point on, companies no longer needed to own physical equipment directly. Instead, they could use computing, storage, databases, and network resources over the internet as services.
In other words, cloud did not begin as a business of renting idle resources. It began as a technological innovation aimed at standardizing infrastructure and delivering it as a service.
Cloud became possible because of two major technical changes.
The first was virtualization, which made it possible to divide one physical server into multiple virtual machines. Instead of dedicating one physical asset to one workload, resources could now be shared and allocated more efficiently.
The second was distributed architecture, which made it possible for systems located across multiple data centers to work together as one service.
Together, these changes transformed how infrastructure could be managed.
Virtualization made computing resources more flexible. A useful analogy would be the difference between one company occupying an entire building and multiple teams sharing separate spaces inside the same building. The building is the same, but the resources are used more efficiently.
Later, container technologies such as Docker and Kubernetes made this model even more flexible. Instead of preparing every environment from scratch, companies could replicate and deploy execution environments almost instantly. In practical game operations, this made it easier to scale matchmaking services, lobby systems, and build servers with far greater speed.
Distributed architecture added another layer of flexibility.
Cloud resources are not all located in one place. They are spread across global data centers, often called regions, and connected through network infrastructure.
For game services, this creates immediate operational advantages. Korean players can be served from Seoul, while players in North America can be served from Virginia. If one region experiences disruption, another region can take over. New markets can be opened without waiting for hardware procurement and local installation.
This is also the foundation of auto scaling, one of the most important features of cloud operations. If traffic surges on launch day, server capacity can expand automatically. When the event ends and traffic falls, unnecessary resources can be reduced just as quickly. That improves both service stability and cost efficiency.
In a cloud environment, teams no longer need to wait through the traditional cycle of ordering, shipping, installing, and configuring physical hardware.
Instead, they connect to a cloud service provider such as AWS and provision resources directly through the internet. Servers can be launched, scaled, or terminated in minutes.
This dramatically reduces one of the biggest hidden costs in IT operations, which is time.
That said, cloud only provides an environment in which systems can scale automatically. It does not decide on its own when scaling should happen. That part still needs to be designed by the operations team.
In other words, cloud is not magic. It is a structure that makes automation possible.
So how are cloud services actually provided?
Broadly speaking, there are four major service models as follows:
Once you understand the differences between them, one thing becomes clear.
Cloud is not just about renting servers. It is about deciding how much operational responsibility you want to handle yourself, and how much you want the provider to handle for you.
If we summarize the changes in game business before and after cloud adoption, the difference is significant.
The impact of cloud in games goes far beyond IT convenience.
It became a turning point that changed the operating structure of the game business as a whole.
Cloud is more than a technology for renting servers.
It is a framework that makes game operations more predictable, reduces launch risk, improves global agility, and creates a more flexible cost structure. It allows game services to respond to sudden spikes in concurrency, expand internationally without heavy physical constraints, and operate with greater speed and resilience.
For the game industry, that is the real meaning of cloud. It is not ownership of infrastructure. It is the ability to operate with precision under uncertainty.
In the next article, I will look at why companies such as Supercell can run global services without owning physical servers, and how leading game companies use cloud in practice to support live operations at scale.
※ Disclaimer: This content reflects the author’s personal views and includes only publicly available examples. It does not represent the official position of any company mentioned