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. [LAB] Create a billing alert to avoid surprise bills
  7. Infrastructure Security
    VPC networks
  8. Default VPCs
  9. [DEMO] Creating VPCs and Subnets
  10. How many VPCs should you use?
  11. [DEMO] Subnet, Route Table, and Gateway Configurations
  12. [LAB] [Challenge] Create a VPC with public and private subnets
  13. [DEMO] Security Groups (SGs)
  14. Security Groups Best Practices
  15. [DEMO] Network Access Control Lists (NACLs)
  16. [Cheat Sheet] SGs vs. NACLs
  17. [LAB] [Challenge] Configure security groups and NACLs to specific requirements
  18. Elastic Load Balancers
  19. [DEMO] AWS WAF
  20. [LAB] [Challenge] Deploy AWS WAF ACL for Application Load Balancer
  21. [DEMO] AWS Network Firewall - Part 1
  22. [DEMO] AWS Network Firewall - Part 2
  23. AWS Shield for DDoS Protection
  24. AWS Firewall Manager
  25. Identity and Access Management (IAM)
    Key Concepts of IAM in AWS
  26. [DEMO] Getting started with IAM in AWS
  27. [DEMO] Creating our first admin user
  28. Assigning permissions with policies
  29. IAM Roles
  30. [DEMO] Creating a role for EC2 instances to access S3 buckets
  31. End-User Management with Amazon Cognito
  32. Data Protection
    Data protection in the cloud
  33. EBS Data Protection and Encryption
  34. Amazon RDS Data Protection and Encryption
  35. Key Management with AWS KMS
  36. [DEMO] Creating a Symmetric Encryption KMS Key
  37. Amazon S3 Bucket Protection
    Understanding Bucket Ownership
  38. Managing Access to Buckets
  39. [Cheat Sheet] S3 Bucket Policies vs. ACLs vs. IAM Policies
  40. [LAB] [Challenge] Create an IAM role for secure access to S3 based on a scenario
  41. Using Signed URLs
  42. Encrypting S3 Data
  43. [DEMO] Enable S3 Object Versioning
  44. Amazon S3 Protection Summary
  45. Logging and Monitoring
    AWS Log Types and Auditing Options
  46. [DEMO] Enable S3 Server Access Logs
  47. AWS CloudTrail
  48. Amazon CloudWatch
  49. [DEMO] CloudTrail Security Automation with CloudWatch Logs and SNS
  50. Proper Logging and Monitoring
  51. [DEMO] Must-have AWS monitoring and alerting with SSK
  52. Wrap-up and Key Takeaways
    What now?
Lesson 4 of 52
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.

Conclusion

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!

Responses

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.