Back to Course

Introduction to AWS Security

0% Complete
0/0 Steps
  1. Introduction

    About the course and authors
  2. AWS cloud architecture
  3. Security concerns with our architecture
  4. Regions and Availability Zones (AZs)
  5. Shared responsibility in the cloud
  6. [Cheat Sheet] AWS Security Services
  7. [LAB] Create a billing alert to avoid surprise bills
  8. Infrastructure Security
    VPC networks
  9. Default VPCs
  10. [DEMO] Creating VPCs and Subnets
  11. How many VPCs should you use?
  12. [DEMO] Subnet, Route Table, and Gateway Configurations
  13. [LAB] [Challenge] Create a VPC with public and private subnets
  14. [LAB] Launching an EC2 instance
  15. [DEMO] Security Groups (SGs)
  16. Security Groups Best Practices
  17. [DEMO] Network Access Control Lists (NACLs)
  18. [Cheat Sheet] SGs vs. NACLs
  19. [LAB] [Challenge] Configure security groups and NACLs to specific requirements
  20. Elastic Load Balancers
  21. [DEMO] AWS WAF
  22. [LAB] [Challenge] Deploy AWS WAF ACL for Application Load Balancer
  23. [DEMO] AWS Network Firewall - Part 1
  24. [DEMO] AWS Network Firewall - Part 2
  25. AWS Shield for DDoS Protection
  26. AWS Firewall Manager
  27. Identity and Access Management (IAM)
    Key Concepts of IAM in AWS
  28. [DEMO] Getting started with IAM in AWS
  29. [DEMO] Creating our first admin user
  30. Assigning permissions with policies
  31. [Cheat Sheet] Anatomy of an AWS IAM Policy
  32. [DEMO] Using Identity Center AWS SSO
  33. IAM Roles
  34. [DEMO] Creating a role for EC2 instances to access S3 buckets
  35. End-User Management with Amazon Cognito
  36. Data Protection
    Data protection in the cloud
  37. EBS Data Protection and Encryption
  38. Amazon RDS Data Protection and Encryption
  39. Key Management with AWS KMS
  40. [Cheat Sheet] Getting Started with AWS KMS
  41. [DEMO] Creating a Symmetric Encryption KMS Key
  42. [Cheat Sheet] Encrypt and Decrypt Data with KMS and Data Keys
  43. [LAB] Encrypt and Decrypt Data with KMS and Data Keys
  44. Amazon S3 Bucket Protection
    Understanding Bucket Ownership
  45. [LAB] Creating Buckets and Uploading Objects in S3
  46. Managing Access to Buckets
  47. [Cheat Sheet] S3 Bucket Policies vs. ACLs vs. IAM Policies
  48. [LAB] [Challenge] Create an IAM role for secure access to S3 based on a scenario
  49. Using Signed URLs
  50. Encrypting S3 Data
  51. [DEMO] Enable S3 Object Versioning
  52. [Cheat Sheet] Amazon S3 Protection Summary
  53. [Cheat Sheet] Create a least privilege S3 bucket policy
  54. Logging, Monitoring, and Incident Response
    AWS Log Types and Auditing Options
  55. [DEMO] Enable S3 Server Access Logs
  56. AWS CloudTrail
  57. Amazon CloudWatch
  58. [DEMO] CloudTrail Security Automation with CloudWatch Logs and SNS
  59. [DEMO] Amazon VPC Flow Logs
  60. Proper Logging and Monitoring
  61. Amazon GuardDuty
  62. [LAB] [DEMO] Enable Threat Detection with GuardDuty
  63. [DEMO] Amazon EventBridge
  64. AWS Config
  65. AWS Systems Manager
  66. [LAB] Secure EC2 Access with SSM Session Manager and KMS
  67. [DEMO] AWS Config Automated Remediation with SSM
  68. Amazon Detective
  69. [LAB] [DEMO] Amazon Inspector
  70. [DEMO] Amazon Macie
  71. [DEMO] AWS Security Hub
  72. [DEMO] Must-have AWS monitoring and alerting with SSK
  73. Multi-Account Security
    [DEMO] AWS Organizations
  74. [DEMO] AWS SCPs and Management Policies
  75. AWS Control Tower
  76. Wrap-up and Key Takeaways
    What now?
Lesson 4 of 76
In Progress

Regions and Availability Zones (AZs)

Christophe December 21, 2022

Access the interactive diagram for this lesson here. (It may ask you to create a free account in order to view. You do not need paid features to view this course’s content so you can ignore that!)

Regions and Zones

One of the key points we haven’t discussed yet is how many of the resources we can deploy in AWS need to be deployed in a specific region.

You see, the cloud is simply someone else’s computers. Those computers are physical pieces of equipment that have to reside somewhere.

That somewhere can, in large part, be decided by the customer — you.

The way you do that is by selecting an AWS Region.

The AWS infrastructure is distributed in locations all around the world. Amazon divides the world into Regions which are physical locations with AWS data centers. In each region, Amazon operates multiple, isolated, and physically separate availability zones. An Availability Zone consists of one or more discrete data centers, with redundant power, networking, and connectivity.

Choosing a region

When you start building your AWS infrastructure, you must select the region in which you will be deploying your resources.

You need to weigh in several parameters in order to choose the right region for you.

Legal and Regulatory Compliance

First of all, legal and regulatory compliance is an important factor that you need to consider. Many compliance frameworks, especially those dealing with the protection of personal data, have data residency requirements.

For example, if you’re processing or storing personal information of EU citizens, you need to comply with GDPR, the European General Data Protection Regulation. GDPR requires that you either keep personal data of EU citizens within the EU, or that you inform the citizen that you are transferring their data outside of the EU and that you implement additional security controls.

All of this means that you may want to choose a region according to data residency requirements.

Performance, Availability, and Cost

Second of all, another important aspect to consider is latency. It makes sense to choose a region with close proximity to the location of your user base to minimize latency.

Cost and service availability are two other factors worth taking into account. Some AWS services are priced differently from one region to another. Also, sometimes, newer services and features are deployed to regions gradually, which means that they may not be available to some of those regions for quite some time.

Availability Zones

As we mentioned a moment ago, each region has Availability Zones, or AZs.

An AZ is one or more data centers with redundant power, networking, and connectivity within that AWS Region.

When using AWS services, sometimes they are automatically deployed across AZs, while other times you have to manually select which AZ to deploy the resource into, and whether you want to deploy the services across multiple AZs or not.

The reason to use more than one AZ is to increase availability, fault tolerance, and scalability of your services.

If we look back to our Cloud Architecture Diagram, we can see that we have subnets deployed into two different AZs. We are then deploying duplicate instances across those AZs, as well as a database replica.

That way, if something happens to one of those AZs, like if there’s a natural disaster, a human error, or even a terrorist attack, it’s unlikely to cause the entire region to go down and instead would hopefully only affect one of those AZs.

If that’s the case, then our application can continue functioning as normal because we still have that secondary AZ.

That makes AZs a very valuable feature for business continuity.


That’s it for now in terms of talking about regions and zones…next, we need to talk about one more key aspect of cloud security: understanding shared responsibility.

Go ahead and complete this lesson, and I’ll see you in the next!


Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.