Amazon Web Services (AWS) offers a variety of services, including Amazon EC2, AWS Lambda, Amazon ECS, Amazon S3, and Amazon RDS. However, simply comparing service names and features is not enough to determine which configuration best suits your company's requirements.
When making a selection, you should consider "what you want to achieve," "how much of the operation will be handled in-house," and "how you anticipate future expansion and costs." You need to consider not only the features of each service, but also the operational burden, management scope, and cost structure that will arise after selection.
This article explains the criteria for choosing AWS services, how to select them based on your purpose, and how to differentiate between services, which can often be confusing. Rather than simply listing services, we will organize perspectives for considering the appropriate AWS configuration based on your company's objectives, requirements, and operational structure.
AWS configurations should be based on requirements, not service names. Even for the same web application, the required configuration differs between testing and production environments. By clarifying "purpose," "operational burden," "cost," and "scalability/availability" before selection, you can avoid excessive configurations and rework after deployment.
The first thing to confirm is your objective with AWS. The necessary services will differ depending on whether you're publishing a website, building a business system, storing and analyzing data, or using AI for data generation.
For static websites, a configuration combining Amazon S3 and Amazon CloudFront is a strong option. For web applications with membership management and payment functions, a combination of Amazon EC2, Amazon ECS, AWS Lambda, and Amazon RDS is used.
The items I would like to check are as follows:
The clearer your objectives, the better you can distinguish between necessary and unnecessary services.
The more flexible a service is, the wider the scope of management you'll need to handle in-house. Amazon EC2 allows you to control the OS and middleware, but you'll also be responsible for patching, security settings, monitoring, and backups.
To minimize operational burden, managed services such as AWS Lambda, Amazon RDS, and AWS Fargate are good options. However, permission management, monitoring design, backup policies, and cost management are the responsibility of the user.
The key is to clearly define what you will manage in-house and what you will entrust to AWS. If you are unclear about this, the management burden will increase after the system goes live.
AWS costs cannot be judged solely by the service price. You need to consider server usage fees, storage capacity, data transfer volume, log retention, backups, monitoring, and even the time spent by operations staff.
Amazon EC2 charges are incurred as long as the instance is running. Since there are fixed operating costs even during off-peak hours, it's important to check that your configuration isn't excessive for your usage.
On the other hand, the costs of AWS Lambda and AWS Fargate vary depending on usage. Because costs can exceed expectations due to the number of executions, execution time, retries, and large volumes of external access, it's crucial to set up AWS Budgets and usage monitoring from the outset.
When comparing services, what you should look at is not "which service is the cheapest," but "whether the cost structure suits your company's usage, access fluctuations, and operational structure."
We anticipate not only the current usage scale but also future increases in the number of users and data volume. For web services with significant access fluctuations, business systems where downtime has a major impact, and analytical platforms handling large amounts of data, we design with scalability and availability in mind.
To prepare for increased traffic, combine Amazon EC2 Auto Scaling and Elastic Load Balancing. For databases, compare Amazon RDS, Amazon Aurora, Amazon DynamoDB, etc., depending on availability and performance requirements.
On the other hand, a high-availability configuration is not always necessary for testing environments or small-scale internal tools. Consider the impact of downtime, future increases in usage, and the time required for recovery, and then determine the configuration based on the necessary level of availability.
The AWS services you should choose will depend on your purpose. Even for the same purpose of "running a system," the necessary configurations will differ depending on whether you're publishing a website, migrating business systems, building a data analysis platform, or utilizing generative AI.
Here, we will organize the services to consider and the criteria for selection, categorized by typical use cases.
Websites and web applications differ in their structure depending on whether they are primarily static content or include application functionality.
For static corporate websites, campaign sites, and media sites, a configuration combining Amazon S3 and Amazon CloudFront is a strong option. Because it allows for delivery without the need for servers, the configuration can be simplified.
For web applications that include features such as login, member management, payment processing, and an administration panel, you need to choose the application's execution platform.
When building a new system, we first consider a configuration that minimizes operational burden. For always-on web applications, Amazon ECS/AWS Fargate are good candidates, while AWS Lambda is suitable for short-term event processing. If compatibility with existing environments or OS-level control is required, we consider Amazon EC2.
In a production environment, the design encompasses not only the execution platform but also monitoring, backup, security, and scalability.
Business systems are designed based on criteria such as compatibility with the existing environment, the impact of business disruption, and the company's internal operational structure.
If you're migrating without significantly changing your on-premises configuration, Amazon EC2 is a good option. Its flexible configuration, including the OS and middleware, allows for a migration that closely resembles your existing system. However, you'll be responsible for OS management, security patching, monitoring, and backups.
If you are considering building a new system or a phased modernization, a configuration that combines Amazon ECS, AWS Fargate, and AWS Lambda to reduce operational burden is also an option.
Business systems are designed with the following elements as a set:
We combine Amazon RDS, Amazon VPC, AWS Identity and Access Management (IAM), Amazon CloudWatch, AWS Backup, and other services, and determine the configuration based on the level of impact on business operations.
When it comes to data storage, first consider the type of data you want to store and how you want to access it. For storing images, videos, logs, backup files, documents, etc., Amazon S3 is a typical choice.
If you're using it as disk space for Amazon EC2, consider Amazon EBS; if you're sharing the same file area from multiple servers, consider Amazon EFS.
The main differences in their usage are as follows:
Simply stating "storing data" isn't enough to determine the right service. You need to organize and select a service based on which service will access the data, in what format, and how frequently.
Database selection involves checking compatibility with existing systems, data structure, performance requirements, and access patterns. The choice will vary depending on whether you are migrating an existing RDB as is, improving performance and availability, or needing to handle high-volume access.
If you're using relational databases such as MySQL, PostgreSQL, Microsoft SQL Server, or Oracle Database, Amazon RDS is a good option. Its configuration is similar to existing RDBs, making migration and operation easier, and it also reduces operational burdens such as backups and patching.
If you want higher performance and availability, as well as reduced database operation burden, consider Amazon Aurora. It maintains compatibility with MySQL and PostgreSQL, while making it easy to entrust automatic storage expansion and replication management to AWS.
For handling high-volume access and flexible data structures, Amazon DynamoDB is a good option. It's suitable for session information, IoT data, mobile apps, and frequently accessed application data.
The main differences in their usage are as follows:
Database selection isn't simply a matter of choosing between "RDB or NoSQL." The selection process must take into account compatibility with existing systems, data volume, access frequency, and operational structure.
In data analysis and BI, the criteria include data volume, storage location, analysis frequency, and user skills.
For high-speed analysis of large amounts of structured data, Amazon Redshift is a good option. As a data warehouse (DWH), it can aggregate and analyze sales data, customer data, log data, and more.
If you want to directly analyze data stored in Amazon S3, consider Amazon Athena. It's suitable for log analysis and exploratory analysis on data lakes because it allows you to search using SQL without managing servers.
If you're creating dashboards and visualizing data within your company, Amazon QuickSight is a good option. It's suitable for cross-departmental monitoring of key performance indicators, sales performance, usage data, and more.
The main differences in their usage are as follows:
The analytics platform is designed not as a standalone service, but as a complete workflow encompassing data collection, processing, storage, and visualization.
In generative AI and machine learning, we consider the objectives as being divided into "development of generative AI applications," "construction and operation of machine learning models," and "use of AI in internal business operations."
For chatbots, document search, text generation, and internal knowledge utilization using generative AI, we recommend considering Amazon Bedrock first. It offers multiple platform models and allows you to build generative AI applications on AWS.
If you have the infrastructure to develop, train, and deploy machine learning models in-house, Amazon SageMaker is a good option. It's a service that allows data scientists and machine learning engineers to handle everything from model development to operation.
For internal document search and business support, check out Amazon Q Business, and for development support, check out Amazon Q Developer.
The main differences in their usage are as follows:
For typical business use, you should first consider Amazon Bedrock or Amazon Q Business. If you also need development support, Amazon Q Developer is another option. If you have a system in place to train, tune, and operate models in-house, then you should consider Amazon SageMaker.
In generative AI and machine learning, we don't judge solely on model performance. We determine the configuration by considering everything from managing reference data, designing access permissions, security, and improving accuracy after deployment.
AWS offers services that appear to have similar roles. However, the degree of flexibility, operational burden, and cost variability will vary depending on the service you choose.
Here, we'll organize some common combinations that people often get confused about when making their selection, outlining which requirements to use and what responsibilities to accept after the selection.
Amazon EC2, AWS Lambda, and Amazon ECS are all services for running applications. The differences lie in the scope of server management, the unit of processing, and the operational responsibilities that arise after choosing one of them.
Services | Easy to choose | Acceptance at the time of selection |
AWS Lambda | Short-term event processing, partial API processing, lightweight batch processing | Maximum execution time, retries, number of concurrent executions, and variable usage-based billing. |
Amazon ECS / AWS Fargate | Always-on web applications, business applications, and container-based development. | Container design, task definition, log and monitoring design |
Amazon EC2 | Migration that closely resembles the existing environment, and configurations requiring fine-grained control over the OS and middleware. | OS management, patching, monitoring, backup, security settings |
When building a new system, the first thing to consider is a configuration that minimizes server management. For short-term event processing, AWS Lambda is a good option, while for web applications and business systems that run continuously, Amazon ECS/AWS Fargate are good choices.
If compatibility with existing environments or OS-level control is required, consider Amazon EC2 as an option. However, while Amazon EC2 offers greater flexibility, it also means that your company will be responsible for a wider range of tasks, including OS management, monitoring, and backups.
Amazon S3, Amazon EBS, and Amazon EFS are all services related to data storage. When selecting a service, you should consider not only the type of data to be stored, but also the access method, whether or not data will be shared, and the performance requirements.
The main differences in their usage are as follows:
Amazon S3: For storing large amounts of images, videos, logs, backups, static files, etc.
Amazon EBS: Use this when you want to provide storage space for your OS and databases as disks connected to Amazon EC2.
Amazon EFS: When you need to read and write the same file area from multiple servers.
Amazon S3 is suitable for storing object data and delivering static content. Amazon EBS is used in combination with Amazon EC2 as storage for the OS and databases. Amazon EFS is effective in configurations where multiple Amazon EC2 instances or application servers handle common files.
Simply stating "storing data" isn't enough to determine the right service. You need to organize and select a service based on which service will access the data, in what format, and how frequently.
Amazon RDS, Amazon Aurora, and Amazon DynamoDB are all used for database purposes. When selecting one, you should check compatibility with existing systems, data structure, access patterns, and performance requirements.
The main differences in their usage are as follows:
Amazon RDS: For those who want to run existing MySQL, PostgreSQL, Microsoft SQL Server, Oracle Database, etc. on AWS.
Amazon Aurora: When you want to improve the balance between performance, availability, and operational burden while maintaining RDB compatibility.
Amazon DynamoDB: For situations where access patterns are clear and you want to handle high-volume access and flexible data structures.
If your existing system uses relational databases (RDBs), Amazon RDS is a good option. For large-scale web services or high-critical business systems, consider Amazon Aurora. For session management, IoT data, mobile apps, and frequently accessed application data, Amazon DynamoDB is a suitable choice.
When selecting a database, we don't just decide whether it's an RDB or NoSQL. We also consider compatibility with existing systems, access frequency, data volume, availability, and future scalability.
Amazon CloudWatch, AWS Config, and AWS Systems Manager are all services related to the operation and management of the AWS environment. However, they differ in their roles: monitoring, configuration management, and automation of operational tasks.
The main differences in their usage are as follows:
Amazon CloudWatch: Monitor the operational status, logs, and metrics of your resources and applications.
AWS Config: Manage configuration changes and compliance status of AWS resources.
AWS Systems Manager: Performs server operations, patching, command execution, and task automation.
Amazon CloudWatch is used to monitor the system's status. It allows you to check CPU usage, logs, alarms, and more, helping to detect failures and performance degradation.
AWS Config is a service that records and evaluates the configuration status of AWS resources. You can track the change history of security groups, AWS Identity and Access Management (IAM), Amazon S3 buckets, and more, and check compliance with internal rules and compliance requirements.
AWS Systems Manager is a service for managing and automating operational tasks. It can be used for patch management, command execution, parameter management, and more across multiple Amazon EC2 instances.
To summarize, monitoring is handled by Amazon CloudWatch, configuration management by AWS Config, and the management and automation of operational tasks by AWS Systems Manager. In actual operation, these are not chosen individually, but rather combined according to their roles.
AWS offers flexible configuration options, but choosing services based solely on their individual features can lead to rework after deployment. Cost, operational burden, security, and scalability are particularly important considerations to check in the initial stages.
Here, we'll summarize points that are often overlooked during the selection process.
Amazon EC2 offers a high degree of flexibility and can be used in a way that closely resembles existing server environments. It is a strong option when you want fine-grained control over the OS and middleware.
On the other hand, choosing Amazon EC2 means you'll be responsible for OS management, security patching, middleware updates, monitoring, and backups. While it's easy to start with a small-scale configuration, the management workload increases as the scope of operation expands.
When making your selection, please check the following:
Is it necessary to have fine-grained control over the OS and middleware?
Is it necessary to migrate using a configuration similar to the existing system?
Do you have the infrastructure to continue operating your own servers?
Can these be replaced by AWS Lambda, Amazon ECS, AWS Fargate, etc.?
When building a new system, we first consider a configuration that minimizes operational burden. Then, if compatibility with the existing environment or OS-level control is required, we include Amazon EC2 as an option.
AWS allows you to design configurations by combining multiple services. Even for web applications, this includes not only the execution platform, but also the database, storage, networking, authentication, monitoring, and backup.
Even if you decide on an execution platform such as Amazon EC2 or AWS Lambda beforehand, if the surrounding design is insufficient, additional measures will be required during operation. In particular, database availability, log storage, security groups, AWS Identity and Access Management (IAM) permission design, and backup policies should be decided at an early stage.
The items to check are as follows:
Where to run the application
Where to save the data
How to design external access and internal connectivity
How to design authentication and access control
How to manage monitoring, logging, and backups
To what extent will recovery be possible in the event of a failure?
AWS services should be evaluated within the context of the entire configuration, not individually.
In an AWS environment, security, permission management, and monitoring are designed from the initial stages. Setting these up all at once after deployment expands the scope of configuration changes and increases the amount of verification work required.
In particular, IAM permissions, network settings, logging, encryption, and monitoring alerts are items that should be decided before going into production. By incorporating a minimum level of design during the initial setup phase, the management burden after going live can be reduced.
The points to check are as follows:
Are IAM permissions set to the minimum necessary?
Are the security groups and network access control lists (network ACLs) designed appropriately?
Are you encrypting important data?
Have you configured the necessary monitoring using Amazon CloudWatch or similar tools?
Can I view the operation logs and change history?
Have you organized your backup and recovery procedures?
We design security, permissions, and monitoring simultaneously with service selection. Separating these aspects will lead to significant revisions after deployment.
When selecting a solution, we consider not only the current scale of use but also anticipate future changes and expansions. The number of users, access count, data volume, and functional requirements will change after the system goes live.
Even small web applications require scaling and database performance reviews as the number of users increases. Similarly, internal business systems require improved access control, monitoring, backups, and operational rules as the number of user departments increases.
When looking ahead to the future, please check the following:
Can it handle the increase in the number of users and accesses?
Are the storage location and fees appropriate even if the amount of data increases?
Can it accommodate additional features and integration with other systems?
Can the system be managed even if the number of operations staff increases or decreases?
Can we separate the production environment, testing environment, and development environment?
There's no need to start with a large-scale configuration from the beginning. However, creating a configuration that's easy to modify later allows you to optimize your AWS environment as your business and systems grow.
The selection of AWS services can be divided into areas that can be handled internally and areas that require consultation with experts. For small-scale testing or simple internal tools, you can consider the configuration yourself. On the other hand, for production environments, core systems, customer-facing services, and environments handling personal information, the design needs to include not only service selection but also networking, access control, monitoring, backup, and disaster recovery.
Cases that are easier to handle in-house are those with a limited scope of impact and clear requirements. Small-scale websites, testing environments, short-term PoCs, and internal tools with limited users can be considered while referring to official documentation and configuration examples.
However, even with a small-scale configuration, AWS Identity and Access Management (IAM) permission design, backup, monitoring, and cost management should be addressed in the initial stages. Taking a "we'll think about it later because it's small" approach will only lead to rework after deployment.
You should consult an expert if configuration errors or outages could impact your business. In particular, if you cannot design and review the following internally, the risks of selecting a production environment on your own increase significantly.
Amazon Virtual Private Cloud (Amazon VPC), subnets, routing
IAM's Least Privilege Design
Monitoring items and alerts for the production environment
Backup and recovery procedures
Recovery time and scope of impact during a failure
Monthly fees and future cost increases
The purpose of consulting with experts is not to have them decide on AWS service names. It is to confirm whether the configuration is something you can take responsibility for after it goes live, from the perspectives of design, security, cost, and operational structure.
You don't need to decide on the exact service name before consulting. What you should clarify first is your objectives for using AWS, your existing environment, the expected number of users and data volume, the impact of downtime, security requirements, and your company's operational structure.
Even if all requirements aren't finalized, clarifying current challenges and constraints will make the discussion points clearer during consultations. Selecting AWS services isn't about choosing a service name; it's about determining a configuration that can be continuously operated in accordance with your company's objectives, constraints, and operational structure.
AWS services should be selected based on your company's objectives, system requirements, and operational structure, rather than service name or popularity. The appropriate configuration will vary depending on the purpose, such as websites, business systems, data storage, analysis, and AI generation.
The important thing is to not only check the functionality of each service, but also what responsibilities your company will take on after selecting it. Amazon EC2 offers a high degree of flexibility, but it also expands your responsibilities for OS management and monitoring. AWS Lambda and AWS Fargate can reduce operational burden, but they require design decisions regarding execution time, processing volume, and container operation.
For small-scale testing, it may be possible to conduct it in-house. On the other hand, for production environments, core systems, and environments with high security requirements, the design includes not only service selection but also Amazon Virtual Private Cloud (Amazon VPC), AWS Identity and Access Management (IAM), monitoring, backup, and disaster recovery. Selecting AWS services is not simply a matter of choosing convenient services, but rather determining a configuration that can be continuously operated.
