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. [DEMO] Security Groups (SGs)
  15. Security Groups Best Practices
  16. [DEMO] Network Access Control Lists (NACLs)
  17. [Cheat Sheet] SGs vs. NACLs
  18. [LAB] [Challenge] Configure security groups and NACLs to specific requirements
  19. Elastic Load Balancers
  20. [DEMO] AWS WAF
  21. [LAB] [Challenge] Deploy AWS WAF ACL for Application Load Balancer
  22. [DEMO] AWS Network Firewall - Part 1
  23. [DEMO] AWS Network Firewall - Part 2
  24. AWS Shield for DDoS Protection
  25. AWS Firewall Manager
  26. Identity and Access Management (IAM)
    Key Concepts of IAM in AWS
  27. [DEMO] Getting started with IAM in AWS
  28. [DEMO] Creating our first admin user
  29. Assigning permissions with policies
  30. [Cheat Sheet] Anatomy of an AWS IAM Policy
  31. [DEMO] Using Identity Center AWS SSO
  32. IAM Roles
  33. [DEMO] Creating a role for EC2 instances to access S3 buckets
  34. End-User Management with Amazon Cognito
  35. Data Protection
    Data protection in the cloud
  36. EBS Data Protection and Encryption
  37. Amazon RDS Data Protection and Encryption
  38. Key Management with AWS KMS
  39. [DEMO] Creating a Symmetric Encryption KMS Key
  40. Amazon S3 Bucket Protection
    Understanding Bucket Ownership
  41. Managing Access to Buckets
  42. [Cheat Sheet] S3 Bucket Policies vs. ACLs vs. IAM Policies
  43. [LAB] [Challenge] Create an IAM role for secure access to S3 based on a scenario
  44. Using Signed URLs
  45. Encrypting S3 Data
  46. [DEMO] Enable S3 Object Versioning
  47. [Cheat Sheet] Amazon S3 Protection Summary
  48. [Cheat Sheet] Create a least privilege S3 bucket policy
  49. Logging, Monitoring, and Incident Response
    AWS Log Types and Auditing Options
  50. [DEMO] Enable S3 Server Access Logs
  51. AWS CloudTrail
  52. Amazon CloudWatch
  53. [DEMO] CloudTrail Security Automation with CloudWatch Logs and SNS
  54. [DEMO] Amazon VPC Flow Logs
  55. Proper Logging and Monitoring
  56. Amazon GuardDuty
  57. [LAB] [DEMO] Enable Threat Detection with GuardDuty
  58. [DEMO] Amazon EventBridge
  59. AWS Config
  60. AWS Systems Manager
  61. [DEMO] AWS Config Automated Remediation with SSM
  62. Amazon Detective
  63. [LAB] [DEMO] Amazon Inspector
  64. [DEMO] Amazon Macie
  65. [DEMO] AWS Security Hub
  66. [DEMO] Must-have AWS monitoring and alerting with SSK
  67. Multi-Account Security
    [DEMO] AWS Organizations
  68. [DEMO] AWS SCPs and Management Policies
  69. AWS Control Tower
  70. Wrap-up and Key Takeaways
    What now?
Lesson 3 of 70
In Progress

Security concerns with our architecture

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!)

In the prior lesson, we looked at this typical cloud architecture by explaining the purpose of each component.

An architecture like this is often referred to as a multi-tier architecture because the services are separated into multiple different layers, or tiers. For example, when we have a presentation tier, a logic tier, and a data tier, we can call that a three-tier architecture.

When we are dealing with an architecture like this, we need to think about the security implications. We shouldn’t just launch these resources and call it a day as soon as it works. We have to map out potential attack vectors and we have to think like an attacker in order to also implement defenses.

In this lesson, we’re going to walk through this architecture like a security professional who is looking to implement defenses.

For example, with this architecture alone, I can think of at least 5 categories we would need to focus on as an organization to properly secure this deployment:

  1. Networking Security
  2. Data Protection
  3. IAM
  4. Logging & Monitoring
  5. Business Continuity

Networking Security

One of the primary concerns is that, since this an architecture for a web application, we will be accepting user requests through a website.

Those requests will travel into our VPC, into our subnets, into our web servers and app servers, and those servers will be communicating with our database.

This, alone, creates all sorts of potential attack vectors. We could be dealing with:

  • Injection attacks like XSS, SQL injections, OS Command injections, etc…
  • Denial of Service attacks
  • Access control issues that allow privilege escalation
  • Information and data leaks
  • and much more…

For those reasons, we need to consider network security by implementing:

  • DDoS defenses
  • Network segmentation through proper configuration of subnets
  • Traffic control with Network Access Control Lists (NACLs) and Security Groups
  • And so on…

Once we have all of this in place, we can also add firewalls, such as the AWS Web Application Firewall, or WAF, and a Content Distribution Network, or CDN.

This multi-layered approach will help reduce the amount of malicious traffic reaching our VPC in the first place, but even for those attacks that do make it through, we can make it extremely difficult for them to go beyond and cause any damage.

Data Protection

In addition to network security, we need to be thinking about data protection.

Data protection involves all aspects of securing our data, which includes data stored in Amazon S3, in EC2 instances, and in our databases.

EC2 instances use what’s called Elastic Block Store, or EBS, which can be directly attached to an instance. These can be high-performance SSD-based or even HDD-based, and they can store data that’s directly used by our web servers or application servers.

That means they can be storing sensitive data that should be encrypted at rest.

The same holds true for data stored in Amazon S3 — while Amazon takes care of physical security, which we’ll talk about in the “Shared Responsibility” lesson soon — we may still need to encrypt data stored on S3 for regulatory compliance reasons.

We will also need to encrypt data in transit, which is data moving across networks, and/or data in use.

All of this encryption requires keys, so we also need a proper and secure way of creating and managing private keys.


Even if we have top-notch network and data security practices in place, if we’re not properly taking care of our AWS accounts and users, a malicious actor can easily hijack our accounts and resources.

For example, if we don’t follow the principle of least privileges and a user account gets compromised, an attacker could do a serious amount of damage even with accounts that are supposed to be low-level accounts.

The same is true for resources launched in AWS. If we don’t give least privileges to our EC2 instances or other resources, and if an attacker gains access to one of our instances, they could easily escalate privileges and laterally move through our VPC and subnets.

To properly secure our AWS users, accounts, and resources, we need to learn about:

  • Policies
  • Roles
  • User account and credentials best practices
  • End user management
  • and more…

Logging, Monitoring, and Auditing

Once our security controls are in place, we need to have a way of keeping eyes on whether they are being effective or not, and whether anyone is attacking our infrastructure or has successfully breached our defenses.

The way to do that is with logging, monitoring, and auditing.

This requires learning how to properly log from multiple different sources, depending on the services we’re using. It also requires learning how to ingest those logs to turn them into useful and actionable data, how to monitor key metrics, and how to create and set up alerts in order to get notified.

Business Continuity

Finally, we need to consider business continuity.

Business continuity refers to taking proactive steps to ensure that our most important operations can continue functioning during an attack or during some sort of other disruption.

Certain types of attacks, like Distributed Denial of Service, or DDoS attacks, are designed to try and take down operations to cause harm to the business.

Or, it doesn’t even have to be a malicious disruption. AWS, while a very stable cloud platform, does have outages from time to time. How well your environment sustains those outages depends on the type of outage, but also on how you’ve set up your environment.

That’s why business continuity is an important part of your security strategy, and we’ll explore how we can use:

  • Load balancers
  • Auto Scaling
  • Availability Zones
  • Backups
  • Versioning

…in order to increase our resiliency to potential disruptions.

Useful Benchmarks and Frameworks

By the way, there exist multiple benchmarks or frameworks we can use to help us secure our cloud environments.

One of those benchmarks is from the Center for Internet Security, or CIS. These documents are freely available for download from their website, and here’s just one example of one for AWS Three-Tier Web recommendations.

If we scroll down to the Table of Contents, we can see a section dedicated to Recommendations.

Many of these recommendations align directly with what we just talked about. They have multiple recommendations for:

  1. Data protection
  2. Identity and Access Management
  3. Business continuity
  4. Event monitoring and response
  5. Audit and logging
  6. Networking

If you click on any of those recommendations, you will see a brief description and explanation, as well as how to audit your environment to verify compliance.


In this lesson, we walked through a practical scenario of how we can start to look at cloud architectures from a security perspective.

Now, let’s move on to the next lesson where we’ll take a closer look at how AWS works.


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.

  1. I really love the way you are teaching. Best thing about this Course Module is that you are explaining in Video as well as in Blog method (Section of below video) which help me to revise again and again easily.

    Thanks again 🙂