It is difficult to provide a comprehensive list of use cases for Amazon. Since the AWS infrastructure is so vast and versatile, then it sometime seems like there's almost nothing you can't do.

Nevertheless we want to cover some of the more common scenarios. The first and perhaps most obvious use case for AWS is for developing new applications utilizing AWS services. You can take advantage of all the benefits of the platform, and you can pick and choose the most relevant services without considering historical or legacy factors. New applications can be designed to scale in and out seamlessly according to application load, using service-oriented architecture, SOA principles. Resilience against inevitable failures that will happen sooner or later can be part of the architecture from the start. Many applications developed today, not just websites, follow the n-tier web application architecture model to at least some degree. Internal enterprise applications that are only accessed within a corporate network often follow this architecture pattern as do mobile applications that are typically more likely than not to access web application backends residing on cloud platforms like AWS. As we've seen, it is easy to get started with AWS services. Therefore the new application can be developed rapidly and you can go to market without waiting for IT infrastructure to be provisioned something that often takes weeks if not months in the traditional on-premises world. Additionally all of these benefits can be enjoyed alongside AWS generally lower costs. If you have existing applications hosted locally, on-premises, another effective AWS use case is to back up the data from those applications to the AWS cloud regularly. This provides the benefits of low cost, long-term storage as well as the confidence that your data is stored offsite in case a disaster within your on-premises data centers should occur. There are many tools specifically created for this in addition to support from traditional backup software vendors to include AWS as a target location for the backup. The low price for long-term archival on AWS makes the low costs and maintenance burden very attractive when compared with tape backup and archival.

Going beyond just backing up the data in AWS, you can also set up a disaster recovery, DR strategy, using AWS as a fallback for your production application infrastructure. This can range from having AWS as a cold site with manual configuration to bring your applications back online in the event of a disaster in your on-premises infrastructure all the way to an active-active or hot DR strategy where AWS plays a role in the production load at all times. Of course there are many possibilities in between these two extremes whose adoption should be determined by a solid risk assessment and business impact analysis, BIA. Cost will always be an important factor to keep in mind when deciding on the preferred DR strategy. If it is important to reach an international audience with your application, AWS provides a global footprint of AWS regions in addition to many edge locations for storing content close to the end user. As we saw earlier in the course, physical proximity still matters on the internet and AWS can help improve your application response time by utilizing these edge locations. This is especially important for applications that require large files to be transferred such as video and software downloads. By designing or updating your applications to take advantage of AWS services such as CloudFront, AWS content delivery network, most if not all of your application files will be cached physically close to the end user to reduce the amount of time it takes for your video to start playing or your software download to complete. You can even use AWS as a CDN if your application is already running on-premises. So there's no need to use only AWS services when designing your application. You can pick and choose. Any kind of computationally intensive task may be a good fit for AWS, especially if the task is only performed intermittently as opposed to all the time.

You're only charged for the resources that you use. So after the task is completed, at least some of the associated costs disappear. Crucially it's important to note that if the duration of your compute-intensive task scales linearly to the number of your dedicated virtual machines, 100 hours on 10 virtual machines will normally cost roughly the same as 1 hour on 1000 virtual machines.

This opens up great potential to speed up research and analytics time without increasing the cost, something that would have been difficult to do with physical servers in a local data center. These are just a few of the many possible use cases for AWS. In future courses, we'll go into a lot more detail to understand how to achieve these results in practice. We've covered a lot of ground in this technical introductory course. As you will have noticed, we've kept the discussion at a very high level and this was necessary to ensure we touched on the key concepts and the full range of AWS products and services.

Hopefully it has helped your understanding of AWS and inspired you to want to learn more and delve into more detail. Most importantly we hope that you're eager to start using AWS and cloud services for your applications. Before talking about your next steps, let us review our learning objectives. You should now be able to: explain what the AWS product categories are, explain what the six main ways of accessing AWS services are, explain the key concepts of AWS regions and availability zones and how they relate to each other, explain what an AWS account is, explain the basic concept of the AWS shared responsibility model, and explain what some of the key use cases for AWS are. If you aren't yet completely comfortable with any of these elements, we recommend that you go back for a review before moving on to other courses. When you're confident about the content in this course, we would recommend that you move on to the next detail level within the core infrastructure services and security.

Specifically the following five courses would be good next steps: AWS compute fundamentals, AWS 120, AWS storage fundamentals, AWS 140, AWS networking fundamentals, AWS 160, AWS database fundamentals, AWS 180 and AWS security fundamentals, AWS 190. Once you complete these, you will have finished the AWS technical foundation track, and can proceed to the intermediate courses covering individual AWS services in much more detail.

 

Lectures:

• AWS Introduction
• Accessing AWS Services
• AWS Regions and Availability Zones
• AWS Account
• Using AWS Tools