- Amazon Route 53
Serverless architecture, which eliminates the need for server construction and maintenance, allowing developers to focus on application implementation, has become a standard choice in current system development and infrastructure operations thanks to the widespread adoption of cloud services such as Amazon Web Services (AWS).
While there are benefits such as a significant reduction in infrastructure operation burden, cost optimization through fully pay-as-you-go pricing, and automatic scaling, proper architecture design requires a structural understanding of "why these benefits arise" and "how they differ from traditional configurations."
This article will summarize the main advantages and mechanisms of serverless computing, and then explain specific examples of systems where its benefits can be realized and systems where it is not suitable.
Serverless is an execution model that entrusts infrastructure management, such as server provisioning, patching, and scaling, to cloud providers, allowing developers to focus on implementing application code.
Platforms like AWS allow you to build infrastructure-independent architectures by combining various managed services. This section outlines the fundamental concepts and key differences from traditional configurations.
The essence of serverless computing lies not in the "absence of servers," but in the "abstraction of infrastructure management."
Traditional system operations involved a vast amount of infrastructure tasks, such as designing the number of servers, maintaining the OS, and configuring monitoring. With serverless computing, these management tasks are handled by the cloud, allowing users to execute processes immediately simply by deploying source code. This "operational bypass" is the greatest value that serverless computing offers.
The biggest difference lies in the "boundaries of management responsibility."
This difference dramatically reduces the user's burden in the "shared responsibility model" and shifts the unit of resource management from "a single server" to "requests and events."
The reason serverless has become a standard option is to respond to the rapidly changing market environment (shortening time to market).
In modern system development, spending time on infrastructure setup directly translates to lost opportunities. Adopting serverless architecture accelerates the development cycle and enables flexible system scalability through event-driven design. The maturation of ecosystems such as AWS Lambda, Amazon API Gateway, and Amazon DynamoDB is strongly supporting this trend.
Adopting serverless architecture not only improves operational efficiency but also dramatically changes business agility and cost structure. The main benefits can be summarized in the following five points:
The biggest advantage is being freed from so-called "undifferentiated heavy lifting," such as applying OS patches, security updates, and managing hardware capacity.
With services like AWS Lambda, AWS handles the provisioning and maintenance of the execution environment, allowing engineers to focus their resources on implementing the business logic, which is their primary objective.
Many serverless services employ a "pay-as-you-go" model, where charges are based on the number of requests or processing time.
Traditional server configurations have been plagued by the cost of "idle assets" resulting from excessive specifications designed to handle peak demand. Serverless computing eliminates billing for time when code is not running, resulting in high cost efficiency, especially for workloads with significant load fluctuations.
Serverless architecture automatically scales execution resources in real time based on the number of requests and the volume of events.
Even if website traffic suddenly surges, users don't need to add servers or fine-tune auto-scaling thresholds beforehand. This flexible scalability minimizes the risk of lost opportunities.
By skipping the infrastructure construction and capacity design processes, you can shorten the "Time to Market"—the time it takes to instantly turn an idea into reality.
Furthermore, the design philosophy of defining processes at the function level is highly compatible with microservices, allowing for the independent and rapid updating of parts of the system, thus establishing a flexible improvement cycle that responds to business changes.
Many serverless services employ a redundant configuration spanning multiple Availability Zones (AZs) by default. Since high availability is guaranteed on the infrastructure side without users having to perform complex cluster design or failover configurations themselves, the ability to entrust infrastructure-level failure response to AWS is a significant advantage from a stable operation perspective.
The operational efficiency and cost optimization offered by serverless architecture are achieved through "three structures" that differ from traditional server-based architectures.
The source of the benefits of serverless computing lies in the change in the "shared responsibility model" with cloud providers.
In traditional IaaS (such as Amazon EC2), OS maintenance and scaling design were the responsibility of the user. However, with serverless computing, AWS takes full responsibility for the operation of these infrastructure layers. This shift in management boundaries frees users from physical resource constraints, creating a structure that allows them to dedicate all resources to implementing business logic.
Serverless architecture is based on triggering processes based on specific "events."
Examples of triggers: HTTP requests to Amazon API Gateway, file uploads to Amazon S3, scheduled execution via Amazon EventBridge, etc.
In this model, computing resources are completely released when there are no requests and are provisioned instantly only when needed. This "operate only when needed" structure technically ensures automatic scaling and efficient resource utilization.
The basis for cost optimization lies in extremely granular billing metrics tailored to each execution unit.
AWS Lambda charges are determined by the execution time (in milliseconds) of the code and the amount of memory allocated. By shifting from a model where you pay for "server uptime" to a model where you pay for "actual processing volume," it's possible to eliminate the cost of idle time (waiting time). This execution-based billing, combined with an event-driven model, delivers maximum cost performance.
Due to its characteristics, serverless computing has clear strengths and weaknesses when it comes to workloads. It particularly shines in processes with volatile load fluctuations or processes that are triggered by specific actions, such as those listed below.
The backend of a web service accessed by a large number of users is one of the most typical use cases for serverless architecture.
Standard configuration: Amazon API Gateway + AWS Lambda + Amazon DynamoDB
In this configuration, AWS Lambda scales in milliseconds according to the volume of requests, making it extremely resilient to access spikes. Furthermore, costs are virtually zero during low-traffic hours such as late at night, freeing you from the need for meticulous capacity planning (server number estimation) in advance.
Processing tasks that do not require real-time processing, such as log aggregation, image conversion, and data cleansing, are also areas that are highly compatible with serverless architecture.
For example, you can trigger an AWS Lambda function when data is saved to Amazon S3 to automate ETL processing (data extraction, processing, and writing). Since there is no need to keep a server running constantly, you can build an efficient data processing infrastructure that consumes resources only when running, at minimal cost.
Serverless architecture plays a central role in microservices, where multiple services are intricately linked, as well as in building loosely coupled systems.
By designing each process as an independent component centered around Amazon EventBridge, the scalability and maintainability of the entire system are dramatically improved. Combined with AWS Step Functions, complex business processes, including error retry handling and conditional branching, can be securely controlled on the managed service side without increasing the size of the code.
Serverless is not a panacea, and due to its architectural characteristics, its benefits may diminish under certain conditions, or it may even be counterproductive in terms of cost and performance. When considering implementation, the following constraints should be evaluated.
Serverless computing optimizes costs by reducing "resource idle time (waiting time)." Therefore, for workloads with constant traffic 24/365 and high CPU and memory utilization, using Amazon EC2 or Amazon ECS (containers) with reserved instances tends to result in lower total costs.
The advantage of serverless architecture—that it only runs when needed—can translate into higher costs in a continuously running environment, making it necessary to determine the cost-benefit ratio.
Services like AWS Lambda can experience a phenomenon called "cold start," where the execution environment is destroyed if there is no execution for a certain period of time, and an initialization process is triggered the next time it is started.
While this is often acceptable for typical web applications, in systems that require consistently low response times (minimal jitter) in milliseconds, such as financial transactions or real-time control systems, this startup delay can become a critical bottleneck.
The "lift and shift" approach, which involves migrating large existing applications to serverless without modifying the code, is not recommended.
AWS Lambda has technical limitations, such as a runtime limit (maximum 15 minutes) and memory and package size limits. Attempting to migrate without properly splitting the functionality (microservices) will not only violate these limitations but also lead to increased debugging complexity and worsened cold start performance, preventing you from fully enjoying the benefits of serverless computing.
Serverless architecture is a powerful tool for minimizing infrastructure management burdens and increasing business agility. The "run only when you need it, pay only for what you use" model, centered around AWS Lambda, offers unprecedented value in balancing resource efficiency and cost optimization.
However, to unlock its true potential, appropriate selection based on system characteristics is essential. Understanding the trade-offs of serverless, containers (such as Amazon ECS), and IaaS (Amazon EC2), and designing a "right tool for the right job" solution that matches business requirements, is crucial for the success of cloud adoption.