|Did this page help you? Yes | No | Tell us about it...|
When you deploy any type of application, you typically need to do the following:
Set up a computer to run your application.
Secure your application and resources.
Set up your network for users to access your application.
Scale your application.
Monitor your application and resources.
Ensure that your application is fault-tolerant.
This guide introduces you to several key AWS services and components that help address these basic needs. In this guide, you will learn more about what these key services are, why they are important in deploying a web application, and how to use them.
To help you learn about the key AWS services, we’ll review an example architecture of a web application hosted on AWS, and we’ll walk through the process of deploying DotNetNuke. (DotNetNuke is an open-source content management system.) You can adapt this sample to your specific needs if you want. By the end of this walkthrough, you should be able to do the following:
Sign up for AWS.
Launch, connect, secure, and deploy DotNetNuke to a computer in the cloud.
Create a custom template of a computer containing the hardware, software, and configuration you need.
Set up a load balancer to distribute traffic across multiple computers in the cloud.
Scale your fleet of computers in the cloud.
Monitor the health of your application and computers.
Clean up your AWS resources.
For a deeper understanding of AWS best practices and the various options that AWS provides, we recommend that you read Web Application Hosting: Best Practices at AWS Cloud Computing Whitepapers.
If you are looking for a quicker and easier way to deploy your web applications, you can use AWS Elastic Beanstalk. AWS Elastic Beanstalk handles the deployment details of capacity provisioning, load balancing, auto scaling, and application health monitoring using several of the services discussed in this document. To learn how to get started with AWS Elastic Beanstalk in the AWS Free Usage Tier, go to Deploy a Sample Web Application in the Free Usage Tier in the Getting Started with AWS Free Usage Tier.
If this guide is not exactly what you are looking for, you may want to check out the following documents:
Getting Started with AWS — Provides information about Amazon Web Services, with helpful links for learning more.
Getting Started with AWS Free Usage Tier — Provides information about how to get started with the free usage tier.
Hosting Websites on Amazon S3 in the Amazon Simple Storage Service Developer Guide — Provides a walkthrough in just a few steps of a static website deployment that does not require running an application.
Getting Started with AWS CloudFormation in the AWS CloudFormation User Guide — Helps you quickly get started using an AWS CloudFormation WordPress blog sample template without needing to figure out the order in which AWS services need to be provisioned or worry about the subtleties of how to make those dependencies work.
Getting Started with AWS Web Application Hosting for Microsoft Windows — Provides a more in-depth walkthrough that uses more services, such as Amazon Simple Storage Service (Amazon S3), Amazon CloudFront, Amazon Relational Database Service (Amazon RDS), and Amazon Route 53.
Amazon Elastic Compute Cloud Microsoft Windows Guide — Provides information that helps you get started using Amazon EC2 instances that run the Microsoft Windows Server operating system.
If you are responsible for running a web application, you face a variety of infrastructure and architecture issues for which AWS can give you easy, seamless, and cost-effective solutions. This section provides a list of Amazon Web Services and components, and it explains the value they add in meeting the challenges you'll face in this example solution. We break this down in to the following sections: computing resources, security, monitoring, networking, and fault-tolerance.
When you deploy an on-premises solution, you need to buy a computer with an operating system, software, and hardware that match your needs. When you deploy your solution on Amazon Web Services, you select an Amazon Machine Image (AMI) and then use it to deploy a virtual server known as an Amazon Elastic Compute Cloud (EC2) instance. An AMI is a template that contains a software configuration (e.g., operating system, application server, and applications). For example, an AMI might contain all the software to act as a web server (e.g., Windows Server, IIS, and your website). A large selection of public AMIs is available from Amazon and the Amazon EC2 community. You can find an AMI that most closely matches your needs and then customize it. You can save this customized configuration to another AMI, which you can use to launch new Amazon EC2 instances whenever you need them.
Storage can be an integral part of an Amazon EC2 instance, or it can be an independent component whose lifetime is managed separately from the lifetime of the instance. There are AMIs for each storage strategy, and you will need to decide which type you want to use. When you launch your Amazon EC2 instances, you can store your root device data on Amazon Elastic Block Store (Amazon EBS) or the local instance store. Amazon Elastic Block Store (Amazon EBS) is a durable, block-level storage volume that you can attach to a single Amazon EC2 running instance. Amazon EBS volumes behave like raw, unformatted, external block devices you can attach. They persist independently from the running life of an Amazon EC2 instance. Alternatively, the local instance store is a temporary storage volume and persists only during the life of the instance. You might use Amazon EBS-backed instances for web or database servers that keep state locally and require the data to be available even if the associated instance crashes. You might use Amazon instance-store backed instances to manage traffic on large web sites where each instance is a clone. This is an inexpensive way to launch instances where data is not stored to the root device. To summarize the two key differences between these AMIs:
You can stop and restart an Amazon EBS-backed instance, but you can only run or terminate an Amazon EC2 instance store-backed instance.
By default, any data on the instance store is lost if the instance fails or terminates. Data on Amazon EBS-backed instances is stored on an Amazon EBS volume, so no data is lost if the instance is terminated.
For more information about the differences between instance store-backed and Amazon EBS-backed instances, go to Basics of Amazon EBS-Backed AMIs and Instances in the Amazon Elastic Compute Cloud User Guide.
Typically, after you buy a new computer you need to create a new password to access it. In AWS, a key pair is used to connect to your instance. After you connect to your instance, you'll change your password just as you would on your local computer. You'll use this password to sign in to your instance each time.
When you deploy your application, you’ll want to secure your system. For an on-premises deployment, you would normally specify the ports and the protocols in which users can access your application. In AWS, you do the same thing. AWS has security groups that act like inbound network firewalls so you can decide who can connect to your Amazon EC2 instance over which ports.
You may find that your application traffic varies during the day. For example, from 9 a.m. to 5 p.m., you may experience peak traffic; for the rest of the day, traffic may be much slower. As traffic levels change, it would be useful to continually adjust the number of computers running your application to changes in traffic. Auto Scaling can automatically launch and terminate instances on your behalf according to the policies that you set. If you have defined a baseline AMI, Auto Scaling launches new instances with the exact same configuration. Auto Scaling can also send you notifications when it adds or removes instances.
You need to stay aware of the current performance and state of your resources. If your resources are not in the appropriate state, can’t handle the traffic load, or are sitting idle, you need to be alerted so you can take appropriate action. Amazon CloudWatch monitors AWS cloud resources and the applications you run on AWS. You can collect and track metrics, analyze the data, and react immediately to keep your applications and business running smoothly. You can use information from Amazon CloudWatch to take action on the policies that you set using Auto Scaling. For example, you can create an alarm to notify you if your CPU utilization exceeds 95%. If the threshold is exceeded, Amazon CloudWatch sends an alarm, and Auto Scaling takes action according to the policy that you set. In this example, Auto Scaling can launch a new instance to handle the increased load. Similarly, you could set an alarm that notifies you if your CPU utilization falls below a certain threshold. In that case, Auto Scaling could terminate an instance, saving you money.
You can monitor the status of your instances by viewing status checks and scheduled events for your instances. Automated status checks performed by Amazon EC2 detect whether specific issues are affecting your instances. The status check information, together with the data provided by Amazon CloudWatch, gives you detailed operational visibility into each of your instances.
You can also see the status of specific events scheduled for your instances. Scheduled events provide information about upcoming activities, such as rebooting or terminating an instance, that are planned for your instances, along with the scheduled start and end times of each event. To learn more about instance status, go to Monitoring the Status of Your Instances in the Amazon Elastic Compute Cloud User Guide.
If you require multiple computers to host your web application, you need to balance the traffic across those computers. Elastic Load Balancing provides this service in the same way that an on-premises load balancer does. You can associate a load balancer with an Auto Scaling group. As instances are launched and terminated, the load balancer automatically directs traffic to the running instances. Elastic Load Balancing also performs health checks on each instance. If an instance is not responding, the load balancer can automatically redirect traffic to the healthy instances.
AWS assigns a URL to your AWS resources, such as your Elastic Load Balancer and your Amazon EC2 instances; however, you may want a URL that is more specific and easy to remember, such as www.example.com. To do so, you need to purchase a domain name from a domain registrar. After you purchase your domain name, you can use Amazon Route 53 to map your domain name to your AWS deployment.
You may want to provision a private, isolated network. You can use Amazon Virtual Private Cloud (Amazon VPC) to provision a private, isolated section of the Amazon Web Services (AWS) cloud where you can launch AWS resources in a virtual network that you define. For example, if you are hosting a multitier web application, you may want to customize the network configuration so that your web servers are public facing and your database and application servers are in a private-facing subnet with no Internet access. The application servers and databases can’t be directly accessed from the Internet, but they can still access the Internet over a NAT instance so they can, for example, download patches.
You can control access between the servers and subnets by using inbound and outbound packet filtering provided by network access control lists and security groups. Some other cases where you may want to use Amazon VPC include:
Hosting scalable web applications in the AWS cloud that are connected to your data center
Extending your corporate network into the cloud
For information on how to get started using Amazon VPC, go to Get Started with Amazon VPC in the Amazon Virtual Private Cloud Getting Started Guide.
To make your web application fault-tolerant, you need to consider deploying your computers in different physical locations. It can be expensive to maintain hardware in different physical locations for an on-premises solution. AWS offers resources in different Availability Zones and regions. Availability Zones are analogous to data centers. You can have multiple instances running in different Availability Zones so that if one Availability Zone becomes unavailable (e.g., due to a natural disaster), then all traffic would be routed to another Availability Zone. There are multiple Availability Zones in each region.
It’s even more advantageous to spread your instances across Regions. If a region, including all of its Availability Zones, becomes completely unavailable, your traffic is routed to another region.
The following table summarizes the key challenges to developing a simple web application and the AWS services that address these challenges.
|Challenge||Amazon Web Services||Benefit|
Need computers to run your application.
Amazon Elastic Compute Cloud (EC2)
Amazon EC2 runs the web server and application servers.
|Incoming traffic needs to be evenly distributed across computers to maximize performance.|
Elastic Load Balancing
Elastic Load Balancing supports health checks on hosts, distribution of traffic to Amazon EC2 instances across multiple Availability Zones, and dynamic addition and removal of Amazon EC2 hosts from the load-balancing rotation.
|Servers need to be provisioned to handle peak capacity, but the unused cycles are wasted at other times.|
Auto Scaling creates capacity groups of servers that can grow or shrink on demand.
|Servers need to be monitored for performance and state|
Amazon CloudWatch reports metrics data for Amazon EC2 instances, and the metrics it gathers are used by Auto Scaling.
Applications may require persistent storage.
Amazon Elastic Block Store (Amazon EBS)
Amazon EBS provides a persistent file system for web and application servers.
The following table summarizes additional challenges to developing a simple web application and the AWS components that address these challenges.
Need a secure mechanism to connect to the computer.
Amazon Key Pair
A key pair is a security credential similar to a password, which you use to securely connect to your instance after the instance running.
Need to provide security to protect application servers from outside malicious users.
Amazon Security Group
An Amazon Security Group gives you control over the protocols, ports, and source IP address ranges that are allowed to reach your Amazon EC2 instances.
Need to design with failover in mind.
Availability Zones are distinct locations engineered to be insulated from failures in other Availability Zones. Each Availability Zone provides inexpensive, low-latency network connectivity to other Availability Zones in the same region.
The following diagram shows an example architecture that uses the AWS resources mentioned in the previous section.
As an example, we’ll walk through a deployment of a simple web application. If you’re doing something else, you can adapt this example architecture to your specific situation. In this diagram, Amazon EC2 instances in a security group run the application and web server. The Amazon EC2 Security Group acts as an exterior firewall for the Amazon EC2 instances. An Auto Scaling group maintains a fleet of Amazon EC2 instances that can be automatically added or removed in order to handle the presented load. This Auto Scaling group spans two Availability Zones to protect against potential failures in either Availability Zone. To ensure that traffic is distributed evenly among the Amazon EC2 instances, an Elastic Load Balancer is associated with the Auto Scaling group. If the Auto Scaling group launches or terminates instances to respond to load changes, the Elastic Load Balancer automatically adjusts accordingly.
For a step-by-step walkthrough of how to build out this architecture, see Getting Started. This walkthrough will teach you how to do the following:
Sign up for AWS.
Launch, connect, and deploy DotNetDuke to an Amazon EC2 instance.
Create a Custom AMI.
Set up an Elastic Load Balancer to distribute traffic across your Amazon EC2 instances.
Scale your fleet of instances automatically using Auto Scaling.
Monitor your AWS resources using Amazon CloudWatch.
Clean up your AWS resources.