AWS Security: Encryption to DDoS Protection

Introduction

30 Second Summary

Cada vez que usas tu tarjeta de crédito en internet o envías un mensaje privado, hay capas invisibles de seguridad protegiéndote. En el mundo de la nube, esas capas no se configuran solas.

En este proyecto, recorrerás los 14 servicios de seguridad más importantes de AWS para el examen SAA-C03. Combinarás práctica real en la consola con comprensión profunda de cifrado, gestión de claves, protección de red y detección de amenazas.

What You'll Build

Un laboratorio de seguridad completo en AWS donde habilitarás y configurarás los servicios de seguridad gratuitos mientras estudias los patrones de arquitectura que evalúa el examen SAA-C03.

By the end of this project, you'll have:

• Parámetros configurados en SSM Parameter Store con jerarquía y SecureString cifrado con KMS.
• GuardDuty, Inspector y Macie habilitados y analizando tu cuenta en busca de amenazas, vulnerabilidades y datos sensibles.
• Un certificado público solicitado en ACM y notas de estudio documentando los patrones de arquitectura de seguridad clave para el SAA-C03.
• Secret Mission: crear una alarma automática con EventBridge que notifique vía SNS cuando GuardDuty detecte un hallazgo de severidad alta.

Are there any prerequisites?

Solo necesitas una cuenta de AWS activa con acceso a la consola web. Todo el proyecto se realiza desde el navegador sin herramientas adicionales.

Los servicios hands-on usan trials gratuitos (GuardDuty 30 días, Inspector 15 días, Macie 30 días) y SSM Parameter Store Standard que es gratis siempre. El costo máximo es $0-$1 si decides crear una Customer Managed Key en KMS.

Understand Encryption Fundamentals

Every time you send data to a cloud service or store it there, encryption determines who can read it. Without encryption, anyone who intercepts data in transit or accesses stored files could see them in plain text.

In this step, you will learn the three fundamental types of encryption that AWS uses. You will also create an S3 bucket to see server-side encryption in action.

In this step, get ready to:

• Learn the three types of encryption: in-flight, server-side at rest, and client-side.
• Understand who manages the encryption key in each SSE variant (SSE-S3, SSE-KMS, SSE-C).
• Create an S3 bucket and verify that default encryption is enabled.

Understand the three types of encryption

AWS protects data in three distinct ways depending on when and where encryption happens. Each type solves a different problem.

• Encryption in flight (SSL/TLS) protects data while it travels between your browser and the server. HTTPS is HTTP with SSL/TLS layered on top. This prevents man-in-the-middle attacks where someone intercepts data mid-transmission.
• Server-side encryption at rest (SSE) protects data after the server receives it and stores it on disk. The server encrypts before writing and decrypts before sending back to you. AWS manages this process.
• Client-side encryption (CSE) means you encrypt data before sending it to AWS. The server never sees the unencrypted version. You are responsible for encrypting and decrypting on your side.

What is the difference between these three?

Think of it this way: encryption in flight protects data on the road. Server-side encryption protects data in the warehouse. Client-side encryption means you lock the box before handing it to the courier.

For the SAA-C03 exam, the key question is always: who manages the encryption key?

Map the SSE variants for the SAA-C03

Server-side encryption in S3 comes in multiple flavors. The difference between them is who provides and controls the encryption key.

• SSE-S3: AWS manages both the key and the encryption process. Uses AES-256 by default. You have no visibility into the individual keys.
• SSE-KMS: AWS manages the key inside KMS, but you control who can access it via key policies. You can audit key usage in CloudTrail.
• SSE-C: You provide the encryption key with every request. AWS performs the encryption and decryption but never stores your key.
• CSE (client-side): You encrypt locally before uploading. AWS stores only ciphertext. You decrypt locally after downloading.

How do I choose the right option on the SAA-C03?

If the exam question says the company needs full control over the key lifecycle and audit trail, the answer is SSE-KMS. If the company must supply its own keys and AWS must never store them, the answer is SSE-C. If simplicity is the priority with no key management overhead, the answer is SSE-S3.

Verify default encryption in S3

Since January 5, 2023, every new S3 bucket has SSE-S3 encryption enabled by default. Every object you upload is automatically encrypted at rest with AES-256 at no additional cost. Let's see this in action by creating a bucket and uploading a test file.

• In the AWS Management Console, type S3 in the search bar at the top and select S3 from the results.
• Click Create bucket.
• In the Bucket name field, enter seguridad-lab- followed by your name (for example, seguridad-lab-maria). Bucket names must be globally unique.
• Leave the AWS Region set to your default region.
• Scroll down to the Default encryption section. Confirm that Encryption type is set to Server-side encryption with Amazon S3 managed keys (SSE-S3).
• Leave all other settings as defaults and click Create bucket at the bottom.

Why is SSE-S3 already selected?

Amazon S3 applies SSE-S3 as the base level of encryption for every bucket automatically. You cannot disable encryption for new object uploads. This is a free, always-on protection layer.

Now upload a test file to confirm encryption is applied to individual objects.

• Click on your new bucket name (seguridad-lab- followed by your name) to open it.
• Click Upload.
• Click Add files and select any small text file from your computer (a .txt file with a few words is perfect).
• Click Upload to upload the file.
• Once the upload completes, click Close.

Now verify the encryption on your uploaded object.

• Click on the name of the file you just uploaded to open its details.
• Scroll down to the Server-side encryption settings section.
• Confirm that it shows Server-side encryption as enabled, with encryption type Amazon S3 managed keys (SSE-S3).

What does this confirm?

Your object was automatically encrypted after S3 received it. The encryption key is managed entirely by AWS, rotated regularly, and uses AES-256. You did not have to configure anything for this to happen.

Don't see the encryption section?

Make sure you clicked on the object name (not the checkbox). The object overview page shows properties including encryption settings when you scroll down.

If you see a different encryption type listed, your account may have a custom default encryption policy set by an administrator.

Help me find the encryption settings for my S3 object.

You now have a clear mental model of how AWS handles encryption. Next up, you will dive into AWS KMS to understand how encryption keys are managed, the different key types, and how key policies control access.

Explore AWS KMS Key Management

In the previous step, you confirmed that S3 encrypts objects automatically using SSE-S3. But who manages the encryption keys behind the scenes? That question leads us to AWS KMS.

AWS Key Management Service is the central hub where encryption keys are created, stored, and controlled across your AWS account. In this step, you will explore the three types of KMS keys and understand their differences, key policies, and multi-region architecture patterns for the SAA-C03 exam.

In this step, get ready to:

• Explore the three types of KMS keys and their differences.
• Understand Key Policies and multi-region keys.
• Learn multi-region encryption patterns for DynamoDB Global Tables and Aurora Global Database.

Navigate to KMS and identify key types

Every time an AWS service encrypts data on your behalf, it uses a KMS key. These keys come in three flavors, and the SAA-C03 exam frequently asks you to pick the right one for a scenario.

• In the AWS Management Console, type KMS in the search bar at the top.
• Click Key Management Service in the results to open the KMS console.
• In the left sidebar, click AWS managed keys.
• Observe the keys listed. You may see entries like aws/ebs, aws/s3, aws/rds, or aws/ssm.
• In the left sidebar, click Customer managed keys to see that section (it will likely be empty if you have never created your own keys).

What are the three types of KMS keys?

AWS Owned Keys are completely free and invisible in your account. AWS uses them internally to protect services. They never appear in your KMS console.

AWS Managed Keys (with aliases like aws/ebs or aws/s3) are free to store, rotate automatically every year, and are visible in your console. However, you cannot control their key policy or share them across accounts.

Customer Managed Keys (CMK) cost $1/month per key. You control the key policy, configure rotation (from 90 days to 2,560 days), and can share them across accounts. This is the only type that allows cross-account sharing.

SAA-C03 exam pattern

When an exam question asks about cross-account encryption or custom access control on keys, the answer is always Customer Managed Keys. AWS Managed Keys cannot be shared between accounts.

Understand Key Policies and multi-region keys

Every KMS key has a Key Policy that controls who can use and administer it. This works similarly to an S3 bucket policy but applies to a specific encryption key.

• Click on any AWS managed key in the list (for example, aws/ebs or aws/s3).
• Click the Key policy tab to see the JSON policy document attached to this key.
• Observe the policy structure. Notice how it defines which principals can perform actions like kms:Encrypt, kms:Decrypt, and kms:DescribeKey.

What are the two types of Key Policies?

The Default Key Policy allows the entire account (root user) full access to the key. It works together with IAM policies to determine who can actually use the key.

A Custom Key Policy defines specific users or roles as Key Administrators (who can manage the key) and Key Users (who can use it for encryption and decryption). You would use custom policies on Customer Managed Keys for fine-grained access control.

Now let's look at a powerful feature for multi-region architectures.

What are multi-region KMS keys?

A multi-region key is a primary key that gets replicated to other AWS regions. Each replica shares the same Key ID (prefixed with mrk-), which means data encrypted in one region can be decrypted in another without re-encryption.

Each replica is managed independently in its own region. Multi-region keys are not truly global. They are separate copies that happen to share the same cryptographic material.

The SAA-C03 exam tests this concept in questions about minimizing latency for decryption in multi-region architectures.

Learn multi-region encryption patterns for DynamoDB and Aurora

Multi-region keys unlock powerful architecture patterns. Two of the most important ones for the SAA-C03 involve DynamoDB Global Tables and Aurora Global Database.

How do DynamoDB Global Tables use multi-region KMS keys?

Imagine you encrypt data client-side with a multi-region key in Region A. DynamoDB replicates the encrypted table data to Region B automatically through Global Tables.

In Region B, your application can decrypt the data using the local replica of the same key (same mrk- ID). Without multi-region keys, you would need to call back to Region A for decryption, adding latency. Or you would need to decrypt in Region A and re-encrypt with a different key for Region B.

How does Aurora Global Database benefit from multi-region KMS keys?

The pattern is the same. An Aurora Global Database replicates data to read replicas in other regions. If the data is encrypted with a multi-region KMS key, the read replica in the secondary region can decrypt using its local key replica.

This eliminates cross-region decryption calls and reduces read latency for globally distributed applications.

SAA-C03 question pattern

When an exam question asks how to minimize decryption latency in a multi-region architecture, the answer points to multi-region KMS keys. Look for phrases like "encrypt in one region, decrypt in another" or "reduce cross-region latency for encrypted data."

You now have a solid mental model of KMS key types, policies, and multi-region patterns. Next up, you will explore how encryption works with S3 replication and encrypted AMI sharing between accounts.

Learn S3 Replication and Encrypted AMI Sharing

You now understand KMS key types and policies. The next question is: what happens when encrypted data needs to move between regions or accounts?

In this step, you will explore how S3 replication works with encrypted objects and learn the process for sharing encrypted AMIs between AWS accounts. These are common SAA-C03 exam scenarios that test whether you understand encryption boundaries.

In this step, get ready to:

• Navigate to S3 replication rules and observe the KMS encryption options.
• Learn how encrypted AMIs can be shared between AWS accounts.
• Understand encrypted snapshot rules for cross-region copies.

Explore S3 replication with encryption

When you replicate an S3 bucket to another region, the encryption type of each object determines whether replication works automatically or needs extra configuration.

• In the AWS console, navigate to S3.
• Click on your bucket seguridad-lab-your-name.
• Click the Management tab.
• Scroll down to the Replication rules section.

You will see that no replication rules exist yet. If you were to create one, you would find an option labeled Replicate objects encrypted with AWS KMS in the encryption settings of the rule.

How does encryption affect S3 replication?

Objects encrypted with SSE-S3 replicate automatically with no extra configuration. Objects encrypted with SSE-KMS can also be replicated, but you must specify the destination KMS key in the replication rule.

Objects encrypted with SSE-C (customer-provided keys) cannot be replicated automatically. The IAM role used for replication needs kms:Decrypt permission on the source key and kms:Encrypt permission on the destination key.

SAA-C03 exam pattern

If an exam question asks about replicating encrypted objects across regions, remember: SSE-S3 and SSE-KMS work. SSE-C does not replicate automatically. The replication role needs KMS permissions on both the source and destination keys.

Understand encrypted AMI sharing between accounts

A common SAA-C03 scenario involves sharing an encrypted AMI from one AWS account to another. The encryption key type determines whether this is possible.

Here is the full process for sharing an encrypted AMI from Account A to Account B:

• The AMI in Account A must be encrypted with a Customer Managed Key. AWS Managed Keys cannot be shared between accounts.
• Account A modifies the Key Policy of the Customer Managed Key to grant Account B the following permissions: kms:DescribeKey, kms:ReEncrypt*, kms:CreateGrant, and kms:Decrypt.
• Account A shares the AMI with Account B using modify-image-attribute.
• Account B can now launch an instance from the shared AMI. Optionally, Account B can re-encrypt the AMI with its own KMS key.

Why can't you share an AMI encrypted with an AWS Managed Key?

AWS Managed Keys (like aws/ebs) have a fixed key policy that you cannot modify. Since cross-account sharing requires adding permissions to the key policy, only Customer Managed Keys work for this use case.

SAA-C03 exam pattern

If an exam question says "share an encrypted AMI between accounts," the answer always involves a Customer Managed Key. If the question mentions an AWS Managed Key, the correct answer is that sharing is not possible without re-encrypting with a Customer Managed Key first.

Learn encrypted snapshot cross-region rules

EBS snapshots follow specific encryption rules when copied across regions. These rules appear frequently in SAA-C03 questions about disaster recovery and migration.

• Snapshots of encrypted EBS volumes are automatically encrypted.
• If you copy an unencrypted snapshot, you can choose to encrypt it during the copy process.
• If you copy an encrypted snapshot to another region, you must specify a KMS key in the destination region. KMS keys are regional.

How do you move an encrypted EBS volume to another region?

The process has three steps. First, create a snapshot of the encrypted volume. Second, copy the snapshot to the destination region specifying a KMS key in that region. Third, create a new volume from the copied snapshot in the destination region.

This pattern is the standard answer for any SAA question about migrating encrypted EBS data across regions.

You now understand how encryption interacts with data movement in AWS. Next up, you will get hands-on with SSM Parameter Store to practice storing and organizing configuration data securely.

Configure SSM Parameter Store

Applications need configuration data like database endpoints, port numbers, and credentials. Hardcoding these values makes updates painful and risky.

In this step, you will create parameters in SSM Parameter Store using a hierarchical naming convention. You will also encrypt a sensitive value with SecureString and learn how the Advanced tier adds policy features.

In this step, get ready to:

• Create four parameters organized by environment hierarchy.
• Encrypt a password with SecureString and verify its decryption.
• Understand Advanced tier parameter policies for the SAA-C03.

Create parameters with hierarchy

Parameter Store supports hierarchical paths that work like folders. This lets you organize parameters by application, environment, and purpose.

• In the AWS console search bar, type Systems Manager and select it from the results.
• In the left navigation pane, scroll down and click Parameter Store.
• Click Create parameter.

You will create the first parameter for your production database host.

• In the Name field, enter /app/produccion/db/host.
• Leave Tier set to Standard.
• For Type, select String.
• In the Value field, enter midb.cluster-xyz.us-east-1.rds.amazonaws.com.
• Click Create parameter.

You should see a green success banner confirming the parameter was created.

Now create the second parameter for the production database port.

• Click Create parameter again.
• In the Name field, enter /app/produccion/db/puerto.
• Leave Tier as Standard and Type as String.
• In the Value field, enter 3306.
• Click Create parameter.

Next, create a SecureString parameter for the production database password.

• Click Create parameter.
• In the Name field, enter /app/produccion/db/password.
• Leave Tier as Standard.
• For Type, select SecureString.
• Leave the KMS Key ID as the default alias/aws/ssm (the AWS managed key for Systems Manager).
• In the Value field, enter MiPasswordSeguro123!.
• Click Create parameter.

What is SecureString?

When you select SecureString, Parameter Store uses KMS to encrypt the value before storing it. The alias/aws/ssm key is the AWS managed key for Systems Manager, which has no additional storage cost.

Only the value is encrypted. The parameter name and description remain in plaintext.

Finally, create the development database host parameter.

• Click Create parameter.
• In the Name field, enter /app/desarrollo/db/host.
• Leave Tier as Standard and Type as String.
• In the Value field, enter devdb.cluster-abc.us-east-1.rds.amazonaws.com.
• Click Create parameter.

You should now see all four parameters listed in the Parameter Store dashboard.

Why use hierarchical names?

The hierarchy (/app/produccion/... vs /app/desarrollo/...) lets you organize parameters by environment. You can use IAM policies to restrict access by path. For example, a developer could only read parameters under /app/desarrollo/*.

Don't see all four parameters?

Make sure you clicked Create parameter (not just filled in the form) for each one. If a parameter shows an error, check that the name starts with a forward slash (/).

help me find my SSM parameters in the console

Retrieve parameters and understand SecureString

Now verify that your SecureString parameter is properly encrypted by viewing it in the console.

• In the parameter list, click the name /app/produccion/db/password.
• On the parameter detail page, observe that the Value field shows ****** (masked).
• Click Show to reveal the decrypted value.

You should see MiPasswordSeguro123! displayed in plaintext after clicking Show.

When to use SecureString vs String?

Use SecureString for sensitive data like passwords, API keys, and license codes. Use String for non-sensitive configuration like hostnames, ports, and feature flags.

For the SAA-C03: Parameter Store is ideal for configuration data and lightweight secrets. If you need automatic rotation of credentials, use AWS Secrets Manager instead.

Understand Advanced tier parameter policies

The parameters you created use the Standard tier, which is free. The Advanced tier adds parameter policies at $0.05 per parameter per month.

What are parameter policies?

Parameter policies are only available in the Advanced tier. There are three types:

• Expiration: Automatically deletes the parameter on a specific date.
• ExpirationNotification: Sends an EventBridge notification a set number of days before expiration.
• NoChangeNotification: Notifies if the parameter has not been modified in X days. This is useful for enforcing credential rotation.

Standard vs Advanced tier for the SAA-C03

Standard tier: free, up to 10,000 parameters per Region, 4 KB max value size, no parameter policies.

Advanced tier: $0.05 per parameter per month, up to 100,000 parameters, 8 KB max value size, supports parameter policies and cross-account sharing.

Your parameters are ready. Next up, you will explore AWS Secrets Manager to understand when to use it instead of Parameter Store for credentials that require automatic rotation.

Understand AWS Secrets Manager

In the previous step, you stored configuration values and a password in SSM Parameter Store. Parameter Store is great for application configuration, but what happens when your database credentials need to change every 30 days automatically?

AWS Secrets Manager solves exactly this problem. It stores credentials and rotates them automatically using Lambda functions. In this step, you will explore the Secrets Manager console and understand when to choose it over Parameter Store for the SAA-C03 exam.

In this step, get ready to:

• Navigate to Secrets Manager and understand its workflow.
• Learn how multi-region secret replication works.
• Practice an integrated SAA-C03 scenario question.

Explore Secrets Manager and its workflow

Both Secrets Manager and Parameter Store SecureString can hold encrypted values. The SAA-C03 frequently tests whether you know which one to pick in a given scenario.

• In the AWS Management Console search bar, type Secrets Manager and select the service.
• Observe the landing page. You will see options to store secrets for databases (RDS, Redshift, DocumentDB), other services, or custom key-value pairs.

Secrets Manager vs Parameter Store SecureString

Secrets Manager offers automatic credential rotation using integrated Lambda functions for RDS, Redshift, and DocumentDB. It costs $0.40 per secret per month and supports native multi-region replication.

Parameter Store SecureString has no built-in automatic rotation. The Standard tier is free and simpler to use.

SAA decision rule: if the question mentions "automatic rotation" the answer is Secrets Manager. If it mentions "application configuration" the answer is Parameter Store.

Here is the complete flow of how Secrets Manager works at runtime:

• You store a secret (database credentials, API key, or any sensitive value).
• Secrets Manager encrypts it with KMS.
• Your application calls the GetSecretValue API.
• Secrets Manager decrypts and returns the value.
• Optionally, every X days a Lambda function rotates the secret automatically.

Why we are not creating a secret

Each secret costs $0.40 per month from the moment you create it. Since this step focuses on understanding the concepts for the SAA-C03, navigating the console interface is enough to learn the service without incurring costs.

Understand multi-region secrets

For disaster recovery scenarios, Secrets Manager can replicate a secret to multiple AWS regions. This is a common SAA-C03 topic.

• Each replica is a read-only copy that stays synchronized with the primary secret.
• When you rotate the primary secret, the rotation propagates automatically to all replicas.
• Your application in the secondary region reads the local replica without cross-region latency.
• You can promote a replica to a standalone secret if the secondary region needs full independence.
• Each replica is billed as a separate secret ($0.40/month).

When would I use multi-region secrets?

The primary use case is disaster recovery. If your primary region goes down, your application in the secondary region can still access credentials locally. Without multi-region secrets, your secondary app would fail because it cannot reach the primary region to fetch the secret.

Practice an integrated SAA-C03 scenario

Let's put everything together with a realistic exam scenario. This is the type of question that combines multiple services.

SAA scenario: multi-region app with automatic rotation

Scenario: "A multi-region application needs database credentials with automatic rotation and minimal access latency."

Correct answer: Secrets Manager with multi-region secrets and automatic rotation enabled.

Parameter Store does not have native rotation. KMS manages encryption keys, not credentials. Secrets Manager is the only service that combines automatic rotation with multi-region replication in one solution.

• Review the logic: the question says "automatic rotation" which eliminates Parameter Store. It says "minimal latency" in multiple regions which points to multi-region replication. Only Secrets Manager satisfies both requirements.

Why not just KMS?

KMS manages encryption keys. Secrets Manager manages credentials (usernames, passwords, API keys). They work together because Secrets Manager uses KMS to encrypt your secrets, but KMS alone cannot store or rotate a database password.

You now understand how Secrets Manager handles credential rotation and multi-region replication. Next up, you will explore AWS Certificate Manager (ACM) and learn how to enable HTTPS on load balancers and API endpoints for free.

Request an ACM Certificate

Your application stores its secrets securely, but the data traveling between your users and your servers is just as vulnerable.

AWS Certificate Manager (ACM) provides free public SSL/TLS certificates that encrypt traffic in flight. In this step, you'll request a certificate and learn how ACM integrates with load balancers and API Gateway for the SAA-C03 exam.

In this step, get ready to:

• Request a public certificate in ACM with DNS validation.
• Understand certificate renewal and import differences.
• Learn how ACM integrates with ALB and API Gateway.

Request a public certificate

ACM lets you provision SSL/TLS certificates at no additional cost when you use them with integrated AWS services like ALB, CloudFront, or API Gateway.

• In the AWS Console search bar, type Certificate Manager and select the service.
• Click Request a certificate.
• Select Request a public certificate.
• Click Next.

• In the Fully qualified domain name field, type ejemplo.tudominio.com (or your own domain if you have one).
• In the Validation method section, select DNS validation – recommended.
• In the Key algorithm section, leave the default RSA 2048 selected.
• Click Request.

The console returns to your certificate list. Your new certificate shows a status of Pending validation.

Why is it pending?

ACM needs to verify that you own or control the domain before issuing the certificate. With DNS validation, you would add a CNAME record that ACM provides to your domain's DNS configuration. Since we used an example domain, the certificate will remain in this state.

DNS validation is recommended because it enables automatic certificate renewal. Email validation requires manual action each time the certificate is about to expire.

What does a public ACM certificate cost?

Public certificates are free when used with integrated AWS services (ALB, CloudFront, API Gateway). You cannot install them directly on an EC2 instance. If you need a certificate on EC2, you must use a third-party certificate or ACM Private CA.

SAA-C03 exam pattern

If an exam question says "free SSL certificate for ALB or CloudFront," the answer is always ACM public certificate. If it says "SSL on EC2 directly," ACM public certificates do not work there.

Understand certificate renewal and imports

ACM also supports importing certificates from third-party providers like Let's Encrypt or DigiCert. The renewal behavior differs significantly depending on how the certificate was provisioned.

• Certificates provisioned by ACM: ACM handles renewal automatically 45 days before expiration. No manual intervention needed.
• Imported certificates: ACM does NOT renew these automatically. You must monitor expiration dates and re-import a new certificate manually before it expires.

What domain types does ACM support?

ACM supports single domains (ejemplo.com), multiple domains using Subject Alternative Names (SAN), and wildcard certificates (*.ejemplo.com). A wildcard protects all subdomains at one level but does NOT protect the bare domain itself.

SAA-C03 renewal question

If an exam question mentions "certificate about to expire" and asks how to automate renewal, check whether the certificate was provisioned by ACM (automatic) or imported (manual). Imported certificates require EventBridge + Lambda to monitor expiration and trigger re-import.

Learn how ACM integrates with ALB and API Gateway

ACM certificates become useful when you attach them to the services that handle your traffic. The two most common integrations for the SAA-C03 are Application Load Balancers and API Gateway.

Integration with ALB

• When you create an HTTPS listener on an ALB, you select the ACM certificate from a dropdown.
• The ALB terminates the SSL/TLS connection (this is called SSL termination or SSL offloading).
• Traffic between the ALB and your EC2 instances can travel over HTTP (within the VPC) or HTTPS (for end-to-end encryption).

Integration with API Gateway

• For custom domain names in API Gateway, you need an ACM certificate.
• Edge-optimized endpoint: the certificate MUST be in us-east-1 (because edge-optimized uses CloudFront under the hood).
• Regional endpoint: the certificate MUST be in the same region as the API.

How do I enable HTTPS on an ALB?

The full pattern is: request a public certificate in ACM, then associate it with an HTTPS listener on your ALB. The ALB handles the TLS handshake so your backend instances don't have to manage certificates themselves.

Region rule for CloudFront

Any ACM certificate used with CloudFront must also be in us-east-1. This is the same requirement as edge-optimized API Gateway because both use CloudFront distributions.

You now understand how ACM provides free certificates and where they fit in an AWS architecture. Next up, you'll explore AWS WAF and learn how to protect your web applications from common attacks.

Explore AWS WAF and DDoS Protection

Ya dominas el cifrado y la gestión de secretos en AWS. Ahora es momento de proteger tus aplicaciones web contra ataques externos.

En este paso vas a explorar tres capas de defensa que AWS ofrece: WAF para filtrar tráfico malicioso a nivel de aplicación, Shield para protección contra DDoS, y Firewall Manager para gestionar políticas de seguridad en múltiples cuentas.

In this step, get ready to:

• Explorar los componentes de AWS WAF y sus tipos de reglas.
• Comparar Shield Standard (gratis) con Shield Advanced.
• Diseñar una arquitectura DDoS-resiliente con las mejores prácticas de AWS.

Explorar AWS WAF en la consola

AWS WAF es un firewall de aplicaciones web que protege contra exploits comunes como SQL injection y cross-site scripting (XSS). Se asocia directamente a recursos como CloudFront, Application Load Balancer, API Gateway, AppSync y Cognito.

• En la consola de AWS, busca WAF en la barra de búsqueda superior.
• Haz clic en WAF & Shield para abrir el servicio.
• Explora el menú lateral izquierdo. Observa las secciones: Web ACLs, IP sets, Regex pattern sets, y Rule groups.

What are WAF's main components?

WAF se organiza en cuatro componentes principales que trabajan juntos:

• Web ACL: el contenedor principal de reglas. Se asocia a un recurso específico (ALB, CloudFront, etc.).
• Rules: condiciones que evalúan cada request y ejecutan una acción (Allow, Block, Count, CAPTCHA).
• Rule Groups: conjuntos reutilizables de reglas. Pueden ser propias o AWS Managed Rules pre-configuradas.
• Managed Rules: reglas mantenidas por AWS o partners (ej: Core Rule Set, SQL Database, Known Bad Inputs).

Why doesn't WAF work with NLB or EC2 directly?

WAF opera en Layer 7 (HTTP/HTTPS), por lo que solo puede inspeccionar tráfico de aplicación. Un Network Load Balancer opera en Layer 4 (TCP/UDP) y EC2 recibe tráfico en cualquier capa. WAF necesita un recurso que procese HTTP para funcionar.

WAF tiene un costo de aproximadamente $5.00/mes por Web ACL más $1.00/mes por managed rule group, por lo que en este paso solo explorarás la interfaz sin crear recursos.

Entender la solución de IP fija con WAF y los tipos de reglas

Un problema frecuente en el examen SAA-C03 combina WAF con la necesidad de una IP fija. ALB no tiene IP fija, pero WAF solo funciona con ALB (no con NLB).

How do you get a fixed IP with WAF?

La solución es usar AWS Global Accelerator delante del ALB. Global Accelerator proporciona 2 IPs estáticas (Anycast).

El flujo queda: Cliente → Global Accelerator (IP fija) → ALB (con WAF) → EC2. Cuando el examen dice "necesito WAF + IP fija", la respuesta es Global Accelerator + ALB + WAF.

WAF soporta varios tipos de reglas que cubren distintos vectores de ataque:

• IP Set Rules: bloquear o permitir hasta 10,000 IPs por set.
• Rate-based Rules: bloquear IPs que excedan X requests en 5 minutos (protección contra brute force).
• Geo-match Rules: bloquear o permitir tráfico por país de origen.
• SQL Injection / XSS: AWS Managed Rules que detectan patrones de inyección en requests.
• Size Constraints: bloquear requests con body o headers que superen un tamaño definido.
• Regex Pattern: reglas basadas en expresiones regulares para detectar patrones personalizados.

Truco SAA para WAF + NLB

Si el examen pregunta "¿cómo usar WAF con NLB?", la respuesta es que no es posible directamente. Las alternativas son: poner un ALB detrás del NLB, o usar CloudFront delante del NLB (CloudFront sí soporta WAF).

Comparar Shield, Firewall Manager y la arquitectura anti-DDoS

Además de WAF, AWS ofrece protección dedicada contra ataques DDoS con Shield, y gestión centralizada de políticas con Firewall Manager.

• En el menú lateral de WAF & Shield, haz clic en AWS Shield para ver la página de información.
• Observa que Shield Standard ya está activo en tu cuenta sin necesidad de configuración.

What is the difference between Shield Standard and Shield Advanced?

Shield Standard es gratuito y automático para todos los clientes de AWS. Protege contra ataques DDoS L3/L4 comunes (SYN floods, UDP reflection). Siempre está activo en CloudFront, Route 53, ELB y Global Accelerator.

Shield Advanced cuesta $3,000/mes con compromiso de 1 año. Incluye protección avanzada L3/L4/L7, acceso 24/7 al Shield Response Team (SRT), DDoS cost protection (AWS reembolsa costos de escalado causados por DDoS), y WAF sin costo adicional para recursos protegidos.

Para el SAA: Shield Standard es suficiente para la mayoría de casos. Shield Advanced es para empresas con alta exposición a DDoS y recursos críticos.

Para organizaciones con múltiples cuentas AWS, Firewall Manager permite gestionar políticas de seguridad de forma centralizada.

What is AWS Firewall Manager?

Firewall Manager gestiona políticas de WAF, Shield Advanced, Security Groups VPC, Network Firewall y Route 53 Resolver DNS Firewall en múltiples cuentas usando AWS Organizations. Cuando creas una política, se aplica automáticamente a todas las cuentas (incluso las nuevas).

Cuesta $100/mes por política por región. Para el SAA: "¿Cómo aplicar reglas WAF en todas las cuentas de una organización automáticamente?" → AWS Firewall Manager.

Ahora vamos a conectar todo en una arquitectura DDoS-resiliente completa.

How do you build a DDoS-resilient architecture?

La arquitectura de defensa en capas (de afuera hacia adentro) es:

• Edge: CloudFront absorbe tráfico en edge locations + Shield Standard automático.
• DNS: Route 53 es resistente a DDoS por diseño (distribuido globalmente).
• WAF: en CloudFront o ALB para filtrar L7 (rate limiting, geo-blocking).
• Infraestructura: Auto Scaling Groups para absorber picos. Elastic Load Balancing para distribuir.
• Red: Security Groups + NACLs para filtrar tráfico en la VPC.

Regla de oro: minimiza la superficie de ataque. No expongas EC2 directamente a internet si puedes usar ALB o CloudFront delante.

Patrón SAA de costo mínimo

"Proteger una aplicación web contra DDoS con costo mínimo" → CloudFront + WAF + ALB + Auto Scaling + Shield Standard. Todo esto es gratuito o bajo costo excepto WAF (~$5/mes).

Ya tienes un panorama completo de las capas de protección de red en AWS. En el siguiente paso vas a habilitar los servicios de detección de amenazas: GuardDuty, Inspector y Macie.

Enable Amazon GuardDuty

Hasta ahora has aprendido a proteger tu infraestructura con cifrado, gestión de claves, firewalls y protección DDoS. Pero proteger no es suficiente. También necesitas detectar cuándo alguien intenta atacar tu cuenta.

Amazon GuardDuty es el servicio de detección inteligente de amenazas de AWS. Analiza continuamente tus logs y tráfico de red buscando actividad maliciosa. En este paso, lo habilitarás y explorarás los hallazgos de seguridad que genera.

In this step, get ready to:

• Habilitar GuardDuty con el trial gratuito de 30 días.
• Generar y analizar sample findings de seguridad.
• Entender la integración con EventBridge para respuesta automatizada.

Habilitar GuardDuty (30 días gratis)

GuardDuty empieza a monitorear tu cuenta en cuanto lo activas. Analiza tres fuentes de datos de forma automática sin que tengas que configurar nada adicional.

• En la barra de búsqueda de la consola de AWS, escribe GuardDuty y selecciona el servicio.
• Selecciona la opción Amazon GuardDuty - All features.
• Haz clic en Get started.
• En la página de bienvenida, revisa los términos del servicio y haz clic en Enable GuardDuty.

Deberías ver el dashboard de GuardDuty con un mensaje confirmando que el servicio está activo. El trial de 30 días es completamente gratuito en la región actual.

What does GuardDuty analyze?

GuardDuty usa tres fuentes de datos fundacionales sin que tengas que habilitarlas manualmente:

• CloudTrail Management Events: quién hizo qué en tu cuenta (llamadas API).
• VPC Flow Logs: tráfico de red de tus instancias.
• DNS Logs: consultas DNS sospechosas desde tus recursos.

No necesitas habilitar VPC Flow Logs manualmente. GuardDuty usa una fuente de datos independiente e interna de AWS.

GuardDuty ya está habilitado?

Si ves un mensaje indicando que GuardDuty ya está activo, es posible que lo hayas habilitado anteriormente. Puedes continuar con el siguiente substep directamente.

Si ves un error de permisos, verifica que tu usuario IAM tenga la política AmazonGuardDutyFullAccess asociada.

help me troubleshoot why I can't enable GuardDuty in my AWS account

Generar y analizar sample findings

GuardDuty detecta amenazas reales con el tiempo, pero para entender cómo se ven los hallazgos puedes generar ejemplos inmediatamente. Los sample findings simulan diferentes tipos de amenazas con datos de ejemplo.

• En el panel de navegación izquierdo de GuardDuty, haz clic en Settings.
• En la sección Sample findings, haz clic en Generate sample findings.
• Regresa al panel de navegación izquierdo y haz clic en Findings.

Deberías ver una lista de hallazgos de ejemplo. Cada título tiene el prefijo [SAMPLE] para indicar que son datos simulados.

• Haz clic en cualquier finding de tipo EC2 (por ejemplo, uno que mencione comunicación con IP maliciosa o bitcoin mining).
• Observa el panel de detalle que se abre con la información: Severity, Resource afectado, Action y Actor (IP, usuario).
• Ahora haz clic en un finding de tipo IAM (credenciales usadas desde ubicación inusual o API calls anómalos).
• Finalmente, revisa un finding de tipo S3 (bucket policy cambiada a pública o acceso desde IP sospechosa).

How do severity levels work?

Cada finding tiene un nivel de severidad numérico que se agrupa en tres categorías principales:

• High (7.0 a 8.9): el recurso está comprometido y se está usando activamente para fines no autorizados. Requiere remediación inmediata.
• Medium (4.0 a 6.9): actividad sospechosa que se desvía del comportamiento normal. Investiga pronto.
• Low (1.0 a 3.9): actividad intentada pero que no logró comprometer el recurso. Por ejemplo, port scans o intentos fallidos de acceso.

Para el SAA-C03: GuardDuty detecta amenazas pero NO bloquea tráfico. Para actuar sobre un finding, necesitas integrarlo con EventBridge.

Integración con EventBridge para respuesta automatizada

GuardDuty por sí solo no bloquea amenazas ni toma acciones correctivas. Su poder real viene cuando lo conectas con Amazon EventBridge para automatizar respuestas a los findings.

• Regresa a la lista de Findings y observa que cada finding tiene un recurso afectado, una severidad y detalles del actor.
• Imagina este flujo de automatización: GuardDuty detecta un finding de severidad HIGH. EventBridge captura el evento. Una acción se dispara automáticamente (notificación SNS, función Lambda, o Step Functions).

What automation patterns does this enable?

GuardDuty envía todos sus findings a EventBridge automáticamente. Los patrones más comunes de automatización son:

• Finding HIGH detectado. EventBridge lo envía a SNS. Tu equipo recibe un email de alerta.
• IP sospechosa detectada. EventBridge activa una función Lambda. Lambda actualiza WAF para bloquear esa IP.
• Credenciales IAM comprometidas. EventBridge activa Lambda. Lambda desactiva las access keys automáticamente.

Para el SAA-C03, la pregunta clave es: cómo automatizar la respuesta a una amenaza detectada por GuardDuty? La respuesta siempre es EventBridge + Lambda o SNS.

Why is GuardDuty different from a firewall?

WAF y Shield protegen bloqueando tráfico malicioso antes de que llegue a tu aplicación. GuardDuty hace lo opuesto: observa lo que ya está pasando y te alerta cuando algo es sospechoso.

Piensa en WAF como la cerradura de la puerta y GuardDuty como la cámara de seguridad que graba todo lo que ocurre adentro.

Recuerda para el examen

GuardDuty = detección de amenazas y comportamiento malicioso. Inspector = vulnerabilidades en software (CVEs). Macie = datos sensibles en S3 (PII). No los confundas en el SAA-C03.

GuardDuty está activo y analizando tu cuenta. En el siguiente paso, habilitarás Inspector y Macie para completar la tríada de detección de AWS.

Enable Amazon Inspector and Macie

In the previous step, you enabled GuardDuty and explored how it detects active threats in your AWS account using CloudTrail, VPC Flow Logs, and DNS queries. That covers one angle of security detection.

Now you'll activate two more detection services that complete the picture. Amazon Inspector scans your workloads for known software vulnerabilities (CVEs), while Amazon Macie discovers sensitive data hiding inside your S3 buckets.

In this step, get ready to:

• Enable Amazon Inspector to scan EC2, ECR, and Lambda for vulnerabilities.
• Enable Amazon Macie to analyze your S3 buckets for sensitive data.
• Compare GuardDuty, Inspector, and Macie to know when to use each one.

Enable Amazon Inspector (15-day free trial)

Amazon Inspector is a vulnerability management service that continuously scans your workloads for known software vulnerabilities. Unlike GuardDuty (which detects active threats), Inspector answers the question: do my servers have unpatched CVEs?

• In the AWS console search bar, type Inspector and select Amazon Inspector.
• Click Get Started.
• Click Activate Amazon Inspector.

After activation, Inspector immediately begins discovering your workloads and scanning them for vulnerabilities.

What does Inspector scan?

When you activate Inspector for a standalone account, all scan types are enabled by default:

• EC2 instances: scans for package vulnerabilities and network reachability using the SSM Agent (no additional agent needed).
• ECR container images: scans container images in your registry for vulnerable dependencies.
• Lambda functions: scans function code and dependencies for known vulnerabilities.

Inspector uses the SSM Agent on EC2 instances, so you do not need to install anything extra. It automatically re-scans when changes occur (new packages, patches, or newly published CVEs).

• Observe the Inspector dashboard. If you have no EC2 instances, ECR images, or Lambda functions running, the dashboard will show zero scanned resources. That is expected.

SAA-C03 tip: Inspector vs GuardDuty

If an exam question mentions "scan for vulnerabilities" or "find unpatched CVEs on EC2," the answer is Amazon Inspector. If the question mentions "detect malicious activity" or "unusual API calls," the answer is GuardDuty.

Not seeing the Get Started page?

If you see a dashboard instead of the Get Started page, Inspector may already be enabled in your account for this region. Check the Account management page in the left navigation to confirm scan types are active.

help me figure out why Inspector is not showing the activation page

Enable Amazon Macie (30-day free trial)

Amazon Macie uses machine learning and pattern matching to discover sensitive data stored in your S3 buckets. It can find PII like names, emails, credit card numbers, passport numbers, and even AWS credentials accidentally stored in objects.

• In the AWS console search bar, type Macie and select Amazon Macie.
• Click Get started.
• Click Enable Macie.

Macie immediately begins inventorying your S3 buckets and monitoring them for security and access control issues.

What happens after enabling Macie?

Macie generates an inventory of all your S3 general purpose buckets in the current region. It evaluates each bucket for security posture (public access, encryption settings) and assigns a sensitivity score.

Macie looks for sensitive data types including PII (names, emails, credit card numbers, passport numbers), AWS credentials, and financial data. It uses both machine learning and pattern matching to identify these.

• Click S3 buckets in the left navigation panel.
• Observe your bucket inventory. You should see your seguridad-lab- bucket listed with its security details (encryption, public access status).

Macie sees your test bucket

Your seguridad-lab- bucket from Step 1 will appear in Macie's inventory. Since it contains a test text file, Macie will analyze it for sensitive data patterns during its automated discovery process.

Bucket list appears empty?

Macie takes a few minutes to populate the S3 bucket inventory after initial activation. Wait 2-3 minutes and refresh the page. If the list remains empty, confirm you are in the same region where you created your S3 bucket.

help me troubleshoot why Macie is not showing my S3 buckets

Compare the three detection services

You now have three detection services running in your account. Each answers a fundamentally different security question. Understanding when to use each one is critical for the SAA-C03 exam.

• GuardDuty: Detects active threats and malicious behavior. "Is someone attacking my account right now?" Sources: CloudTrail Management Events, VPC Flow Logs, DNS Logs.
• Inspector: Detects software vulnerabilities. "Do my servers have unpatched CVEs?" Sources: SSM Agent on EC2, ECR container images, Lambda function code.
• Macie: Detects sensitive data in S3. "Do I have PII or credentials exposed in my buckets?" Source: S3 object content.

How do these services work together?

All three services generate findings in a common JSON format compatible with AWS Security Hub. This means you can aggregate findings from GuardDuty, Inspector, and Macie into a single dashboard for centralized security visibility.

You can also route any of their findings through EventBridge to trigger automated responses (Lambda functions, SNS notifications, or Step Functions workflows).

SAA-C03 quick decision rule

When you see these keywords in an exam question, map directly to the correct service:

• "Sensitive data in S3" or "PII exposed" = Amazon Macie.
• "Vulnerabilities" or "unpatched CVEs" = Amazon Inspector.
• "Malicious activity" or "unusual behavior" or "threats" = Amazon GuardDuty.

Secret mission

Automatizar Alertas de Seguridad con EventBridge

GuardDuty detecta amenazas, pero ¿de qué sirve si nadie se entera a tiempo? En esta misión secreta, vas a crear un sistema de alertas automáticas que te notifique por email cuando GuardDuty detecte un hallazgo de severidad alta.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. Most of the services you activated have free trials that will start charging once the trial ends.

Cost warning

GuardDuty (30-day trial), Inspector (15-day trial), and Macie (30-day trial) will begin charging once their free trials expire. If you do not plan to continue using these services, suspend or disable them before the trial period ends to avoid unexpected charges.

Resources you used:

• SSM Parameter Store parameters (Standard tier, always free).
• Amazon GuardDuty (30-day free trial).
• Amazon Inspector (15-day free trial).
• Amazon Macie (30-day free trial).
• ACM certificate (free while in Pending validation state).
• S3 bucket seguridad-lab-[nombre] with one test file.
• SNS topic alertas-seguridad (Secret Mission).
• EventBridge rule for GuardDuty alerts (Secret Mission).

Keep everything running

No action needed. Choose this if you are still actively studying for the SAA-C03 and want to keep exploring GuardDuty findings and Inspector results.

• GuardDuty, Inspector, and Macie will continue running on their free trials.
• Set a calendar reminder to disable these services BEFORE the trial ends (Inspector has the shortest trial at 15 days).
• SSM Parameter Store Standard parameters remain free indefinitely.
• The ACM certificate in Pending validation state costs nothing.

Pause - I'll come back to this later

Shut down the detection services to stop any potential charges, but keep your parameters and other free resources intact.

• Suspend GuardDuty: Go to GuardDuty in the console, select Settings in the navigation pane, then choose Suspend GuardDuty and confirm.
• Suspend Macie: Go to Macie in the console, select Settings in the navigation pane, then in the Suspend Macie section choose Suspend Macie. Enter Suspend when prompted and confirm.
• Deactivate Inspector: Go to Inspector in the console, select General settings in the navigation pane, then choose Deactivate Inspector. Enter deactivate when prompted and confirm.
• SSM parameters, the S3 bucket, the ACM certificate, the SNS topic, and the EventBridge rule all remain at no cost.

Delete - I don't want to use this again

Remove all project resources completely. Follow each step below to delete everything you created.

• Disable GuardDuty: Go to GuardDuty in the console, select Settings in the navigation pane, then choose Disable GuardDuty and confirm your action.
• Disable Macie: Go to Macie in the console, select Settings in the navigation pane, then in the Disable Macie section choose Disable Macie. Enter Disable when prompted and confirm.
• Deactivate Inspector: Go to Inspector in the console, select General settings in the navigation pane, then choose Deactivate Inspector. Enter deactivate when prompted and confirm.
• Delete SSM Parameters: Go to Systems Manager > Parameter Store. Select all four parameters (/app/produccion/db/host, /app/produccion/db/puerto, /app/produccion/db/password, /app/desarrollo/db/host), then choose Delete and confirm.
• Delete the S3 bucket: Go to S3, select your seguridad-lab-[nombre] bucket. Choose Empty to remove all objects first. Then select the bucket again and choose Delete.
• Delete the ACM certificate: Go to Certificate Manager, select the certificate you requested, then choose Delete and confirm.
• Delete the SNS topic: Go to SNS > Topics, select alertas-seguridad, then choose Delete and confirm.
• Delete the EventBridge rule: Go to EventBridge > Rules, select your GuardDuty alert rule, then choose Delete and confirm.

Nice Work!

Nice Work!

Has completado la Guía Maestra de Seguridad en AWS. Ahora tienes experiencia real con los servicios de seguridad más importantes y un mapa mental claro de los patrones que evalúa el examen SAA-C03.

Lo que aprendiste:

• Configurar SSM Parameter Store con jerarquía y SecureString, y entender cuándo usar Secrets Manager para rotación automática de credenciales.
• Habilitar y explorar los tres servicios de detección de AWS: GuardDuty para amenazas activas, Inspector para vulnerabilidades, y Macie para datos sensibles en S3.
• Dominar los patrones de arquitectura de seguridad para el SAA-C03: tipos de cifrado, KMS, WAF, Shield, y las mejores prácticas de protección DDoS.
• Crear un sistema de alertas automáticas con EventBridge y SNS que notifica cuando GuardDuty detecta hallazgos de alta severidad.

¿Listo para ponerte a prueba?