When building websites and web applications with Amazon Web Services (AWS), you design the configuration by combining Amazon EC2, Amazon RDS, Amazon S3, Amazon CloudFront, Application Load Balancer, and other components. However, simply applying typical configuration examples may not be suitable for your company. The appropriate configuration will vary depending on the target audience, access scale, impact of downtime, and security requirements.
For example, for static websites, a configuration centered around Amazon S3 and Amazon CloudFront is a viable option. On the other hand, web applications and e-commerce sites require a design that includes application servers, databases, load balancing, monitoring, and backups. For internal systems, connectivity with existing networks and authentication/access control also need to be considered.
The first thing you need to decide is "what you're going to build." The services you use and the design considerations will differ depending on whether you're creating a static site like a company profile or landing page, or a web application with membership features. For internal systems or e-commerce sites, the design scope includes connection destinations, authentication, availability, backup, and monitoring.
For static websites, the basic configuration involves placing files on Amazon S3 and delivering them via Amazon CloudFront. While this allows you to publish without owning your own server, it's not suitable for user management, administration panels, or database processing.
If you need features such as membership functionality or an administration panel, you'll need to combine Amazon EC2, Application Load Balancer, Amazon RDS, etc. Because you're separating the layers for receiving access, running the application, and storing data, the scope of considerations is broader than for a static site.
If the system is intended for internal use, the connection to the existing network and access control should be designed first. If it's integrating with an on-premises environment, network design including AWS Site-to-Site VPN and AWS Direct Connect is also necessary.
The example configurations are not final versions, but rather for comparison. Do not judge solely based on the names of the services used; instead, check what purpose, scale, and operational requirements the configuration is based on.
Multiple services are combined depending on the application. Understanding the roles of the main services shown in the configuration diagram will allow you to grasp the purpose of each configuration.
Category | Main AWS services | role |
network | Amazon Virtual Private Cloud (Amazon VPC), subnets, internet gateways | Create a network environment on AWS and separate the areas for external access from those for internal use. |
Compute | Amazon EC2, AWS Lambda, Amazon Elastic Container Service (Amazon ECS) | It is used as the execution platform for web servers and applications. |
Database | Amazon RDS, Amazon Aurora, Amazon DynamoDB | Stores and manages data used by the application. |
storage | Amazon S3 | Saves files such as images, HTML, logs, and backup data. |
Content distribution | Amazon CloudFront | Deliver web content quickly and reduce the load on the origin server. |
Load balancing and scaling | Elastic Load Balancing, Amazon EC2 Auto Scaling | The system distributes access across multiple servers and adjusts resources according to the load. |
Security | AWS Identity and Access Management (IAM), AWS WAF, AWS Shield | Responsible for access control, protection against unauthorized access, and protection of web applications. |
Monitoring/operation | Amazon CloudWatch, AWS CloudTrail, AWS Backup | Used for monitoring operating status, recording operation logs, and backup management. |
接 続 | AWS Site-to-Site VPN, AWS Direct Connect | Connecting internal networks and on-premises environments to AWS. |
The combination of services required will vary depending on the scope of publication, data handling, impact of downtime, and operational structure. Static sites should consider Amazon S3 and Amazon CloudFront, web applications should consider Amazon EC2, Application Load Balancer, and Amazon RDS, and internal systems should consider configurations including AWS Site-to-Site VPN and AWS Direct Connect.
Configuration patterns vary depending on the target audience and operational requirements. Here, we categorize them into static sites, small-scale websites, web applications, internal systems, e-commerce sites, serverless architectures, and high-availability configurations. In actual design, adjustments should be made based on access scale, data handled, impact of downtime, and operational structure.
For websites that primarily use HTML, CSS, images, and JavaScript, such as company profiles, service introduction pages, landing pages, and campaign pages, we combine Amazon S3 and Amazon CloudFront.
By placing static files in Amazon S3 and delivering them with Amazon CloudFront, you can publish content without having your own web server. If you need to add some features such as contact forms, you can also consider combining this with AWS Lambda, Amazon API Gateway, or external form services.
This approach is suitable for websites with relatively infrequent updates and limited dynamic processing. However, if member login, an administration panel, or database integration is required, it should be designed as a web application.
For small-scale websites or testing environments, a simple configuration centered around Amazon EC2 is often feasible. This involves deploying web servers and a CMS on Amazon EC2, and combining them with Amazon RDS as needed.
For WordPress sites or small information websites, a good starting point is a configuration using Amazon EC2 and Amazon RDS. It's easy to understand because it's similar to managing existing servers.
However, concentrating processing on Amazon EC2 alone increases the scope of impact in the event of a failure. For continuous operation in a production environment, the design should include backup, monitoring, security patching, and scalability.
In web applications with features such as membership, administration panels, search functions, and reservation functions, layers are separated according to their roles. Generally, access is received by an Application Load Balancer, the application runs on Amazon EC2 or Amazon Elastic Container Service (Amazon ECS), and data is managed on Amazon RDS or Amazon Aurora.
Separating the application server and database helps isolate the impact of load and failures. If increased access is anticipated, combine this with Amazon EC2 Auto Scaling to adjust resources according to processing volume.
In this configuration, not only service deployment but also authentication, access control, logging, and data protection are considered in the design. When handling user information or business data, AWS WAF, AWS Identity and Access Management (IAM), Amazon CloudWatch, and AWS Backup should also be considered from the initial stages.
For internal portals, application workflows, business management systems, and core peripheral systems, the design prioritizes connection paths and access control over internet exposure.
For example, one configuration involves deploying application servers and databases within Amazon Virtual Private Cloud (Amazon VPC) and connecting to them from the company network using AWS Site-to-Site VPN or AWS Direct Connect. For user authentication and permission management, integration with existing identity infrastructure should be considered in addition to IAM.
Even for internal use, simplifying monitoring and backups will lead to problems after deployment. For systems that could disrupt business operations, fault detection, recovery procedures, log management, and data protection must be designed in advance. When integrating with on-premises environments, network, security, and migration methods must be addressed separately.
E-commerce sites handle product information, inventory, orders, payments, and customer information, so they are designed with robust availability and security features. Based on a web application architecture, load balancing, redundancy, monitoring, and backups are incorporated.
Generally, access is distributed using an Application Load Balancer, and multiple application servers are deployed. For databases, Amazon RDS or Amazon Aurora are used, and Multi-AZ configurations and backups are considered. Amazon S3 or Amazon CloudFront are used in combination for delivering image and product data.
Even a short outage can impact sales and customer service for e-commerce sites. We design our systems to handle everything from traffic congestion and payment integration to personal data protection and unauthorized access prevention, and we implement monitoring and recovery systems using AWS WAF, Amazon CloudWatch, AWS CloudTrail, and AWS Backup.
Serverless configurations combine services such as AWS Lambda, Amazon API Gateway, Amazon DynamoDB, and Amazon S3. They are used for event processing, APIs, batch processing, and lightweight web applications, without requiring server management.
For processes with fluctuating access numbers or functions that don't require constant server operation, this is a viable option. Since you're only charged for the amount of processing performed, costs can be kept down depending on your usage patterns.
On the other hand, it may not be suitable for simply migrating existing applications. Serverless-specific constraints such as processing time, number of concurrent executions, database connections, log management, and permission design should be checked in advance.
To minimize the risk of downtime in a production environment, a design that reduces single points of failure is necessary. This involves using multiple Availability Zones and combining them with Elastic Load Balancing, Amazon EC2 Auto Scaling, Amazon RDS Multi-AZ configurations, and Amazon Aurora.
By deploying multiple web servers and application servers, processing can continue even if one fails. Databases are also made redundant, and backup and recovery procedures are established. Operating status is monitored using Amazon CloudWatch, and operation logs are tracked using AWS CloudTrail.
While high-availability configurations are effective for stable operation, they also increase costs and the burden of design and operation. It's not necessary to choose the maximum configuration from the start in every environment. The required availability level should be determined based on the impact of downtime, recovery goals, number of users, and the importance of the data being handled.
The configuration pattern should be chosen according to the intended use and risk. More features don't always mean better, and excessive design increases costs and operational burden. On the other hand, operating with a minimal configuration in an environment where downtime would have a significant impact increases the risk during failures.
Configuration example | Suitable cases | Cases where it is not suitable |
Static website configuration | Websites primarily consisting of static content, such as company profiles, landing pages, service introduction pages, and campaign sites. | Sites requiring member functions, administration panels, search functions, and database processing. |
Small-scale website configuration | Small-scale information sites, testing environments, and limited CMS sites. | Production environments where high traffic is expected, and services where downtime would have a significant impact. |
Web Application Configuration | System that uses application processing and databases, such as member sites, reservation systems, administration panels, and business applications. | For simple static websites and applications where server management should be avoided as much as possible. |
Internal System Configuration | Internal portal, application workflow, business management system, and system that integrates with on-premises environments. | A typical website intended for public access, or a simple website intended for short-term use. |
EC site structure | Websites that handle product, inventory, order, payment, and customer information; services whose downtime would have a significant impact on sales. | Small-scale information listing sites, sites without payment or membership management systems. |
Serverless configuration | APIs, event processing, batch processing, processes with high access fluctuations, lightweight web applications | A system that assumes simple migration of existing server applications, long-term processing, and always-on connectivity. |
Production configuration prioritizing high availability | For production environments where business interruptions and revenue losses must be avoided, systems requiring high availability, monitoring, and recovery capabilities are essential. | Testing environment, small-scale internal use, system with minimal impact during downtime. |
Applying a high-availability configuration to a static company website will unnecessarily increase costs and operational burden. Conversely, operating an e-commerce site that directly impacts sales or internal systems that could lead to business disruption with a minimal configuration will result in a greater impact when a failure occurs.
When choosing a configuration, the criteria should be based not on the number of services, but on the scale of access, the data being handled, the impact of downtime, and the company's internal operational structure.
When choosing a configuration, consider not only the functional requirements but also the cost, availability, security, and operational structure. While increasing the number of services may seem robust, it also increases costs and management complexity. An unnecessarily complex configuration makes not only daily operations but also troubleshooting more difficult.
The first thing to consider is "how much downtime is acceptable?" The required availability differs between a testing environment or a small-scale site and a production environment that directly impacts sales and business operations.
For small websites, a simple configuration centered around Amazon EC2 or Amazon RDS is a viable option. On the other hand, for e-commerce sites or core internal systems, the design should include redundancy using multiple Availability Zones, database backups, monitoring, and failure recovery procedures.
Security requirements vary depending on the scope of public access and the data being handled. For websites exposed to the internet, consider AWS WAF, security groups, and access control using AWS Identity and Access Management (IAM). For internal systems, in addition to whether or not they are publicly accessible, the connection to the internal network, authentication, operation logs, and data protection should also be considered.
As you increase availability and security, the number of services and design elements you'll need will increase. Don't judge solely on monthly costs; choose a configuration that can be realistically managed, including monitoring, backup, operational procedures, and incident response.
Who will operate the system after it's built is also a prerequisite for selecting the configuration. AWS allows for flexible configuration changes, but if you add services without clear operational rules, permission management, monitoring, backup, and cost management will become complex.
If your company lacks expertise in AWS operations, it might be better to start with a manageable configuration rather than building a complex one from the beginning. This involves verifying whether you can manage the entire setup, including monitoring, backup, and security settings.
On the other hand, if increased access or additional features are anticipated in the future, the system should be designed with future expansion in mind. Separating the network, database, and application layers leaves room for load balancing and redundancy to be added later.
When integrating with existing systems, post-migration operations must also be considered. Organizing details such as connectivity with on-premises environments, integration with the ID infrastructure, data migration, and rollback procedures in case of failures will minimize rework after implementation.
Optimizing only during the initial setup will result in a configuration that is vulnerable to changes after deployment. The design should meet current requirements, remain manageable, and leave room for future changes.
While example configurations can serve as a starting point, simply listing the services shown in the diagram is insufficient. Costs, operational burden, and security risks will vary depending on the configuration and usage. When deciding on the configuration, be sure to check for potential problems that may arise after deployment.
Even when using the same service, costs vary depending on the configuration and usage. For Amazon EC2, instance type, uptime, and storage capacity affect the cost. For Amazon RDS and Amazon Aurora, you should also check the instance size, Multi-AZ configuration, backup retention period, and data transfer volume.
As the configuration becomes more complex, the number of operational items also increases. Combining load balancers, multiple availability zones, Amazon EC2 Auto Scaling, AWS WAF, monitoring, and backups enhances availability and resilience. On the other hand, it also expands the scope of configuration verification, incident response, log review, and cost management.
When reviewing costs, we don't rely solely on monthly estimates. We consider factors such as increased access, increased backup storage volume, and the workload during incident response. The configuration diagram is a tool for understanding the overall picture; actual costs and operational realities are determined by the configuration values and usage.
If you design only the part of the application that runs first, vulnerabilities will remain after deployment. Problems such as lack of logging, undefined recovery procedures, and excessively broad permissions will only increase the amount of work required to fix them later.
In configurations using databases, you should define the backup frequency, retention period, and restoration procedure. In environments where downtime has a significant impact, such as e-commerce sites or internal systems, simply having backups is insufficient. The design should include how far back you can restore the system and how much time is acceptable for recovery.
For monitoring, we will use tools such as Amazon CloudWatch to monitor CPU usage, memory, disk space, response time, errors, and logs. For security, we will include AWS Identity and Access Management (IAM) permission management, security groups, AWS WAF, and operation logs from AWS CloudTrail in our design.
In a production environment, a working configuration is not enough. The design must also include features such as the ability to detect anomalies, recover from them, and manage permissions.
The points to check differ between new system construction and migration from an existing environment. When connecting to on-premises environments, internal networks, existing databases, authentication infrastructure, and external services, it is risky to simply use general configuration examples.
For internal systems, we will verify connectivity using AWS Site-to-Site VPN and AWS Direct Connect, IP address design, name resolution, authentication integration, and communication path control. For core peripheral systems and business systems, the design scope will also include data integration with the existing environment, nightly batch processing, external APIs, and the handover of operational monitoring.
If migration is involved, the switching procedure and rollback method should also be defined. If it is unclear when to revert to the old environment, how to handle data differences, and who will make the decisions when problems occur after the migration, troubleshooting will be delayed.
When considering a migration, we look not only at the new AWS environment but also at its connections to existing environments. Organizing connection destinations and migration conditions beforehand can minimize rework and operational confusion after the migration is complete.
Looking at configuration examples can help you organize the general direction. However, in production environments and business systems, relying solely on configuration diagrams can lead to overlooking aspects of availability, security, operation, and cost. In particular, in the following cases, you should confirm the design policy at an early stage.
Referring to example configurations allows your company to clarify its own direction. On the other hand, for configurations involving production environments, internal systems, migration from existing environments, and security requirements, confirming the design policy at an early stage will help minimize rework.
AWS configuration examples vary depending on the use case, such as static sites, small websites, web applications, internal systems, e-commerce sites, and serverless configurations. The combination of services required will also change depending on the scope of publication, access scale, impact of downtime, data handled, and operational structure.
For small-scale testing environments, starting with a simple configuration might be a good option. On the other hand, for production environments or systems directly related to business operations, designing with redundancy, monitoring, backup, and recovery procedures in mind is essential. When migrating from existing systems, connecting to internal networks, and requiring specific security features, simply applying general configuration examples carries the risk of overlooking costs, operational burden, and fault tolerance.
The example configurations are not final versions, but rather materials for comparison and consideration. Configurations that do not suit your company's intended use, downtime risks, and operational structure will lead to increased costs and operational burdens.
