Episode 18 : Master AWS Security - Encryption, Threat Detection & Compliance | Interactive Format | SAA-C03

Hey everyone, Baloo here. Welcome back to Tech Talk with Baloo, your complete guide to async the AWS Solutions Architect Associate Exam. Today we are tackling episode 18 and we are diving into a topic that touches absolutely everything we have covered so far, that security and encryption. We are going to look at KMS Secrets Manager, Parameter Store, AWS Certificate Manager, Cloud HSM, WAF, Shield, GodDuty, Inspector and Macy. That's a lot, but each plays a critical role in securing AWS architectures. So let me start with the scenario that captures why this all matters. Imagine you're the architect for a health care company. You're storing patient records, payment data and personal, identifiable information or PII data. You see two now asks four questions to you. One, how are you protecting the data at rest? Number two, how are you protecting it in transit? And question three, how are you managing the secrets your application uses like database passwords? And four, how are you protecting against attacks on your web application from the internet? If you don't have great answers to all the four questions about, you have a security problem. And in regulated industries like health care, finance or government, a security problem can mean catastrophic fines, reputational damage or even criminal liability for that matter. So today we're going to give you the answers to all of those questions. We'll cover encryption fundamentals and KMS in depth. We'll then explore how to securely store secrets and configurations using Secrets Manager and Parameter Store. We'll touch on SSL or TLS Certificates with ACM and the difference between KMS and Cloud HSM. Then we'll move to network and application security that's AWS Shield for DDoS protection, WAF for application layer attacks and firewall manager for centralized policy management. Finally, we'll cover the threat detection services that's GodDuty, Inspector and Macy. This episode continues the interactive format from previous episode. So throughout I'll drop in pulse checks where you should pause and think for a minute, trap spotlights for exam traps and memory hooks to lock concepts in. Pay attention to the pauses. They're your active recall opportunities. By the end of this episode, you'll be able to design secure AWS architectures and handle security-focused questions on the SAAA-C03 exam confidently. So let's dive straight in. Section 1. Why security matters in AWS? Before we dive into specific services, let's establish the security mindset. AWS operates on what's called the shared responsibility model. AWS is responsible for security of the cloud, the physical infrastructure, the underlying hardware, the network, the host operating system and the hypervisor. You're responsible for security in the cloud. That's the configuration of your services, your data, your operating systems on EC2, your application code and most importantly, your identity and access management. When you put data in S3, AWS makes sure that disks are physically secure and the storage system is reliable. But it's your job to make sure that the right people have access. The data is encrypted and the bucket isn't publicly accessible. This distinction matters because most security incidents in AWS happens on the customer side of the line and not in AWS. Now within your responsibility, security falls into few key areas. Identity and access management, which we covered in detail in episode 3 with IAM, encryption, both at rest and in transit, which is most of today's episode that we'll cover, network security which we touched on VPC security groups and NACLs episode, application security that's protecting against attacks like SQL injection and finally thread detection that's automatically finding suspicious activity. Today, we are focused on encryption, secrets management and the lead defenses on the top that's WAF, shield, guard duty and friends. Think of these as external security layers that protect against attacks from the outside plus the encryption that protects data where it sits. Onto memory hook. Think of AWS security like a castle. AWS protects the ground and the walls. You protect the door through the IAM services, the safe inside the castle that is the encryption and the moat against attackers using the WAF or the shield. Security is layered and master each layer. Onto section 2, encryption fundamentals. Let's start with the basics. Encryption is the process of taking readable data, what we call plaintext and transforming it into unreadable data called ciphertext using what we call a key. Only someone with the right key can decrypt it back to plaintext. If someone steals the encrypted data without the key, they have just garbage data. There are two main types of encryption you need to understand here. There is symmetric encryption that uses one key. The same key encrypts and decrypts the data. It's fast and efficient, which is why it's used for encrypting larger amounts of data. The downside is who has the key can read your data. So the security depends on protecting that one key very carefully. AWS uses AES256 for symmetric encryption, which is industry standard. A symmetric encryption on the other hand uses two keys, what we call a public key and a private key. They're mathematically related, but you can't derive one from the other. Data encrypted with the public key can only be decrypted with the private key. The public key can be shared freely. The private key, though, must be kept a secret. This is more computationally expensive than the symmetric mechanism, but it solves the key exchange problem. AWS uses RSA and ECC for asymmetric encryption. When AWS services need to encrypt data, they usually use symmetric encryption because of speed. A symmetric is used for specific use cases like digital signatures or scenarios where you need to encrypt outside of AWS. There are also two contexts where encryption matters. First, encryption at rest means that data is encrypted when it's stored on your disk. Think of S3 objects, EBS volumes, RDS databases, DynamoDB tables, and so forth. The data sits in storage encrypted, so even if someone's got physical access to a disk, they couldn't read it. Then you have the encryption in transit, means that the data is encrypted while it's moving across the network. Think of HTTPS, TLS, or SSL. The data is encrypted as it travels from your application to a database or between services, so even if someone intercepted the network traffic, they couldn't read it. The best practice is to use both. Encrypted rest and in transit. Some services do this automatically, but the others require you to configure it. On for a pulse check, a quick question here. If a hacker breaks into an AWS data center and steals a hard drive containing your data, what protects you? Let's pause and think. The answer is encryption at rest. The data on the disk is encrypted, so without the encryption key, the stolen drive contains useless ciphertext. This is one of the primary reasons we encrypt data at rest that is to protect against physical theft even though it's extremely unlikely in AWS data centers. On for a trap spotlight now. A common exam trap is confusing where encryption happens. SSC S3, SSC KMS, SSC, these are the S3 server-side encryption options for data at rest inside S3. HTTPS or TLS, these are for data in transit. So read the question carefully to determine which one is being asked for. On for a memory hook, think of encryption at rest like a safe. Encryption in transit is like an armoured car, both protect your valuables but in different situations. Hope this helps. On to section 3, AWS KMS deep dive. Now let's get into the heart of AWS encryption, KMS, the key management service. KMS is a central service for managing encryption keys in AWS. Whenever you see encrypt with KMS or managed encryption in AWS, KMS is doing the actual work behind the scenes. It integrates with virtually every AWS service that supports encryption. Now there are three main types of KMS keys. The first one is AWS-owned keys. These are owned by AWS and used by AWS services for default encryption. You don't see them, you can't manage them, and they are free. Examples include SSC S3 default encryption for S3, default encryption for SQS, default encryption for DynamoDB. These are great when you just need the default encryption with zero management. Number two, you have the AWS managed keys. These are created and managed by AWS for use within specific services. They appear in your account with naming like AWS/Service name, for example, AWS/Audios or AWS/EBS. You can see them but you can delete or rotate them. These are also free. Next, we have the customer managed keys. These are keys you create, manage, control, and pay for. That's $1 per month per key plus $3 cents per $10,000 api calls. You define the policy, choose when to rotate them and decide who can use them. This is where you have full control. For sensitive data with compliance requirements, you typically use customer managed keys. Customer managed keys can be created in KMS itself, or you can import your own key material from outside of AWS, which is generally useful for compliance scenarios where you must generate keys in your own HSM and bring them into AWS. Now, let's talk about KMS key types from the cryptography perspective. KMS support symmetric and asymmetric keys. Symmetric keys are the default, AS256, is used by AWS services. You never get access to the key material directly. You can only call the KMS api to encrypt or decrypt. KMS does the cryptography on your behalf. asymmetric key comes in RSA or ECC variants. They are used for scenarios where you need encrypt or decrypt operations or for digital signatures that is for signing and verifying. The public key is downloadable, but the private key stays in KMS. Use cases include encrypting data outside of AWS by users who can make KMS API calls or signing data to prove its authenticity. A really important concept here is called key rotation. AWS managed keys rotate automatically every year. Customer managed keys, on the other hand, can be configured for automatic rotation, typically every year, but it's configurable, or you can rotate them on demand. Imported keys can only be rotated manually using aliases. Key rotation is important for security because if a key is somehow compromised, the rotation limits the window of exposure. On for a pulse check? Try this. You have a critical compliance requirement that your encryption keys must rotate every 90 days and the company's security team must control the rotation time precisely. Which type of key means this requirement? The answer is customer managed keys. They support both automatic rotation and on demand rotation as we spoke, giving you control over the timing. AWS managed keys only rotate annually and you generally have no control over it. Imported keys require manual rotation. So customer managed keys with on demand rotation gives you the precise control needed for that 90 day requirement. Now let's talk about KMS key policies. This is how access to keys is controlled. Unlike most AWS resources where I am policies grant permissions, KMS keys always have key policies. Even if an IAM policy allows access, the KMS key policy must also allow it. This is a critical security design. The default KMS key policy gives full access to the root user of the AWS account plus whatever you specify when creating the key. A custom key policy lets you define exactly who can use the key, who can administer the key and crucially, who from the other AWS accounts can access it. Cross account access requires both the source accounts IAM policies and the target keys policy to allow it. A powerful feature here is multi-region keys. Normally a KMS key is tied to a specific region. You can't use a key from US East 1, for example, to decrypt data in EU-West 1. Multi-region keys solve this problem. You create a primary key in one region, then replicate it to other regions. The replicas have the same key ID and material. Data encrypted in one region can be decrypted in another without re-encryption or cross-region API calls. Multi-region keys are perfect for global applications, as you can imagine. Global DynamoDB tables, global Aurora databases, multi-region disaster recovery scenarios, and so forth. So remember the exam loves to test this for global application with client-side encryption scenarios. On for a trap spotlight here. A very common exam trap is that if you want to share an encrypted eBS snapshot with another AWS account, you need to do four things. Number one, encrypt the snapshot with a customer manage key, not an AWS manage key. You can't share AWS manage keys. Two, modify the snapshot permissions to share with the target account. Number three, update the KMS key policy to allow the target account to use the key. Four, in the target account, copy the snapshot and optionally re-encrypt with their own key. If you missed any of these steps, then the sharing fails. So for a memory who care, think of KMS keys like Walt keys. AWS own keys are like Bangs master keys. You never see them. AWS manage keys are like the Bangs safe deposit keys. You see them, but can't change them. Customer manage keys on the other hand are like your own house keys. You control everything, but you pay for the locksmith. Let's go to section four now, Secrets Manager versus Parameter Store. Now let's talk about a comparison that's tested constantly on the exam. Secrets Manager versus Parameter Store. Both services let you store configuration data and secrets. Both can encrypt with KMS. Both can integrate with IAM. So when do you use which? Let us break it down. Let's start with Systems Manager Parameter Store. This is the older, simpler service. It's free for standard parameters. Up to 10,000 parameters per region per account. Each parameter can be up to four KB. You can choose to encrypt with KMS or store plain text. It's great for configuration data like API endpoints, feature flags, or application settings. Parameter Store has a hierarchical structure. You use slashes to create namespaces. So you might have slash my company slash my app slash dev slash db URL. And my company slash my app slash prod slash db URL. This makes it easy to organize parameters and grant access by path. Alamda function in dev can read everything and slash my company slash my app slash dev, but not in prod. You can call get parameter for a single value or get parameters by path to retrieve everything under a path. So it's super useful for loading configurations. Parameter Store also has an advanced tier that's 100,000 parameters, 8 KB size limit, and parameter policies. Parameter policies let you set TTLs on parameters that is like auto deletion after expiration. Notification on changes via event bridge or notification on no change events. This advanced setting costs about $0.05 per parameter per month. Now on the other hand for Secrets Manager. This is the newer, more feature rich service specifically designed for secrets. The key differentiator is automatic rotation here. Secrets Manager can automatically rotate your secrets on a schedule like every, let's say, 30 or 90 days. For RDS, Aurora, and a few other AWS services, it can rotate the database password and update both the secret and database automatically using a Lambda function. Secrets Manager costs about $0.40 per secret per month plus $0.05 per 10,000 APA calls. As you can see, it's more expensive than the parameter store, but you get the rotation, integration with adias, and built-in secret generation here. Secrets Manager also supports multi-region secrets. You designate a primary region and then create replicas in other regions. Secret Manager keeps the replicas in sync with the primary. This is useful for multi-region applications or for disaster recovery scenarios. You use parameter store when you have configuration data, but not secrets. You want a free option which is standard tier. You don't need rotation here. You're not integrating with adias or automatic password rotation. You're not storing things like API keys for external services, feature flags, or application configuration values. You want to use secret managers on the other hand when you have actual secrets like database passwords, API keys, or sensitive credentials. You do need automatic rotation here. If you're using adias, Aurora, or similar databases and one managed credential rotations, again, you want to use Secrets Manager. If you need cross-region replication of secrets, again, use Secrets Manager. And if you need to generate strong random secrets automatically, then you want to use again Secrets Manager. An important point here is parameter store can reference secrets in secret manager. You can have a parameter store entry that points to a secret manager secret. This is generally useful when you have applications that already use parameter store, but you want certain values to live in secrets manager for rotation purpose. On for a pulse check here, a scenario time. Your application needs to access adias my SQL database. The security team requires the database password to be rotated every 30 days and that to automatically, which service should you use to store the password? The answer here is AWS Secrets Manager. You know, Secrets Manager has the built-in integration with adias for automatic password rotation using Lambda. Parameter store can store passwords, but doesn't automatically rotate them. The 30-day automatic rotation requirement is the deciding factor here. On for a trap spotlight, the example sometimes describe a scenario where both services could technically work, but one is clearly better than the other. You want to look for the deciding factor here. Database password rotation then go for Secrets Manager. Application configuration with no rotation than its parameter store. API key from third party that doesn't change that's parameter store. If cost is a priority, then it's parameter store again. If compliance requires automatic rotation, then you know its Secrets Manager. For a memory hook that might help you remember, parameter store is like a filing cabinet for documents you read. Secrets Manager is like a safe with an automatic lock that changes the combination periodically. Let's move on to section five now, AWS Certificate Manager. Let's briefly cover AWS Certificate Manager or in short ACM. This is the AWS service for managing SSL or TLS certificates. When you set up HTTPs on a web service, you need SSL or TLS certificate. Without ACM, you had had to buy certificates from a certificate authority, install them on your new servers, renew them every year and manage the rotation all by yourself. ACM eliminates all of these. ACM lets you provision SSL or TLS certificates for free. AWS handles the certificate, authority work, validates your domain ownership and issues you a certificate. The certificate is automatically renewed before expiration, so you don't have to remember to do that. ACM integrates with AWS services that need certificates. For example, elastic load balancers can use Thank you. certificates. And that's how you make your ALB serve HTTPS traffic. Cloud front distributions use ACM certificates. That's how you serve HTTPS content from the edge. API gateway uses ACM certificates for custom domain names. So when you build secure architectures with these services, you use ACM. A critical limitation that you want to remember is that public ACM certificates can only be used with AWS services. You can't download the private key and use it in your own EC2 instances or on premise services. For those scenarios, you have two options. Use ACM private certificate authority to issue private certificates that then you can deploy anywhere within your organization or regenerate certificates externally and import them into ACM. ACM certificates are regional by default. If you need a certificate for a Cloud front distribution which is global, you must create or import the certificate in US East one regardless of where your other resources are. This is a common exam trap. One for a trap spotlight. For Cloud front, ACM certificates must be in US East one. This is because Cloud front is a global services that use US East one for its control plane. If a question describes setting up HTTPS on Cloud front and asks where the certificate must be, the answer is certainly always US East one. One for a memory hook. ACM is set it and forget its certificates. Remember it like that. It's free, it's automatic renewal, it's integrated with AWS services. Just remember, Cloud front needs them to be in US East one specifically. Let's move on to section six. Cloud HSM. That's when you need hardware. Cloud HSM is a service that's frequently tested in comparison to KMS. So let's understand the distinction. KMS uses AWS manage software for encryption. AWS manages the keys used, the APIs to encrypt and decrypt. It's serverless, fully managed and easy to use. Most AWS users only need KMS. Cloud HSM on the other hand is different. Cloud HSM provides dedicated hardware that's actual hardware security modules in AWS for you. HSM stands by the way for hardware security module. These are physical, tamper, resistant devices that meet certain level three compliance. With Cloud HSM you have a dedicated piece of hardware for your encryption keys with you having full control. AWS cannot access the keys. This matters in three specific scenarios. First, regulatory compliance. Some industries require keys to be stored in physical hardware that you control. Banking, government and certain healthcare scenarios have requirements like this. Second, when you need single tenant hardware, KMS is multi tenant. Your keys live alongside other customers keys in AWS's managed infrastructure. Cloud HSM is on the other hand single tenant. Your hardware is dedicated to you. Third, when you need specific cryptographic capabilities that KMS doesn't offer, like SSL or TLS offload acceleration or Oracle transparent data encryption. Cloud HSM deploys inside your VPC. Each HSM is in a specific AZ. For high availability you deploy multiple HSMs across multiple AZs. They're managed in clusters. There is no free tier. Cloud HSM is significantly more expensive than KMS. Typically thousands of dollars per month. You use Cloud HSM either directly through Cloud HSM client software or through KMS custom key stores. This is where you configure KMS to use Cloud HSM as the backing key store. You get the integration benefits of the KMS with the hardware security of the Cloud HSM. An important factor remember, Cloud HSM is the right choice for SSEC with S3. Service side encryption with customer provided keys require you to manage the keys yourself and Cloud HSM is generally great for that. Redshift can also use Cloud HSM directly for database encryption and key management. One for a pulse check, it's a test scenario. A financial services company has regulatory requirements stating their encryption keys must be in a dedicated single tenant hardware with level three compliance and AWS must have no access to the keys which service to the need. You know the answer is Cloud HSM. The key signals here are dedicated single tenant hardware. FIPS 142 level three if you see that that's level three compliance and that AWS has no access to the keys. KMS does provide the same level three compliance too but it's multi tenant. The dedicated hardware requirements point specifically here to Cloud HSM. KMS is like a high security bank vault that you share with other customers whereas Cloud HSM is like having your own personal vault that's fully isolated that only you have the keys to. So it's higher security cost more but then there is more responsibility. On to section number seven, AWS WAF application layer protection. Now let's shift gears to network and application security. We start with AWS WAF or web application firewall. WAF protects your web applications from common application layer attacks. The key phrase here is application layer that's layer seven in the OSI model which is HTTP or HTTPS. WAF inspects the actual HTTP request and responses including headers, body and URI strings. This is different from a network firewall like security groups which work at layer three and layer four. WAF deploys on five AWS resources, application load balancer, API gateway, Cloud Front, AppSync GraphQL, API and Cognitor user pool. Notice that network load balancer is not in this list. NLB operates at layer four that's TCP and UDP and WAF is layer seven. If you need WAF protection with NLB you at need to use global actuator with WAF on ALB behind it. The core concept in WAF is web ACL, web access control list. A web ACL contains rules that determine what to do with web requests. For each request, WAF evaluates the rules and either allows blocks or counts the request. There are several types of rules that you can create. IPset rules block or allow specific IP addresses. Each IPset can hold up to 10,000 IP addresses. For more you create multiple rules. Strang matching rules look up for specific strings in headers, body or URI. For example, blocking requests that contain SQL injection patterns or cross-site scripting attempts. Size constraint rules block requests where headers, body or URI exceed certain sizes. That's useful for preventing buffer overflow attempts. Joe match rules block requests from specific countries. This overlaps with Claude friend's geo restriction, but this is more granular. Rate-based rules count occurrences of events. For example, if more than, thousand requests come from say one IP in five minutes, then block that IP. This is great for protecting against brute force attacks and basic DDoS attempts. You can also use managed rule groups that's pre-built collection of rules from AWS or third parties. These are groups for common attacks like Ovasp, top 10, bot protection, known bad inputs and more. You add a managed rule group for your web ACL and immediately get protection against those threats. Web ACLs are typically regional with one exception. Claude front web ACLs are global because Claude front is global. So if you're protecting an ALB in US East one, your web ACL is in US East one. If you're protecting Claude front, your web ACL is global. A reusable concept here is rule groups. That means you can package multiple rules together and reuse them across multiple web ACLs. This is great for consistency across your environments. One for a top spotlight. The exam often tests WAF deployment options. Remember, WAF works with ALB, API gateway, Claude front, app sync, GraphQL and Cogniter user pool, not with NLB or EC2 directly. If a question mentions wanting to protect an NLB, the answer often involves global accelerator plus ALB plus WAF, not WAF directly on NLB. Now, one for a memory hook. Think of WAF as your web application's bodyguard. It checks every visitor's HTTP request and block suspicious ones based on the rules you'd define. Just remember it, it works on the layer seven stuff that's HTTP and HTTPS, not on the raw TCP or UDP traffic. Let's now go on to section 8, AW shield, DDoS protection. Now, let's talk about AW shield protection against distributed denial of service attacks. A DDoS attack is when many sources flood your application with traffic, overwhelming it and preventing legitimate users from accessing your service. These attacks can be at layer 3 or 4, that is sin floods, UDP floods, reflection attacks, or it can be at layer 7, that's HTTP floods or application layer attacks. AW shield comes in two tiers. AW shield standard is free for every AW's customer. It's automatically activated, there is no configuration needed. It protects against common layer 3 and layer 4 attacks, sin or UDP floods, reflection attacks, and other network layer attacks. Every AW service benefits from shield standard by default. This is the basic DDoS protection at no cost. AW shield advanced, on the other hand, is the premium tier. It costs about $3,000 per month per organization, a flat fee that's not per resource. Shield advanced provides additional protection for EC2 ELB, that's ALB, NLB, and CLB, Cloud Front, Global Accurator, and Route 53. So what do you get for all that $3,000? There is 24/7 access to AW's DDoS response team called the DRT. If you are on data attack you can engage AWS engineers to help you mitigate it in real time. There is cost protection that is during a DDoS attack, your AWS cost can spike, that is data transfer, auto scaling, spin-up, resources, etc. Shield advance protects you from these usage spike costs, cost by the attacks. There's advanced reporting, you get detailed visibility into the attacks you're experiencing and how they are being mitigated. Basic application layer DDoS mitigation that shield advance automatically creates, evaluates and deploys AWS WAF rules to mitigate layer seven attacks in real time. This is hugely powerful, the system adapts to the attack as it happens. Now there's also AWS Firewall Manager, which is a different beast altogether. Firewall Manager helps you manage security rules across multiple AWS accounts in and AWS organization. From a central security account, you can configure WAF rules, shield advance protections, security groups, network firewall rules and route 53 resolver DNS firewall rules that apply across all the accounts. This is enterprise scale security policy management. So how do they all fit together? WAF is for granular protection in specific resources. Shield is for DDoS protection, standard is free for everyone, advanced for high value targets. firewall manager is for managing policies centrally across an entire organization. A common comprehensive setup that's used is firewall manager to deploy WAF rules across the organization, shield advance for critical resources plus cloud front in the front of everything for additional protection. For a quick pulse check now, a startup hosts their website on AWS, they're getting basic DDoS attacks now. They have no special budget for security, what protection do they have automatically? It's pause and think. The answer is AWS shield standard because it's free, it's automatically activated for every AWS customer and protects against common layer 3 and layer 4 DDoS attacks. The startup here doesn't have to do anything to get this baseline protection. If they grow and become a higher value target, they can consider upgrading to shield advanced. For a top spotlight, don't confuse the tiers. Shield standard is automatic free and covers basic network layer attacks. Shield advanced is $3,000 per month, it includes a response team, cost protection and automatic layer 7 mitigation. If the question says free DDoS protection, then that's standard. If the question mentions cost protection during attacks or 24/7 response team, then that's advanced. On for a memory hook here, shield standard is like the basic alarm system that comes with every AWS account. Shield advanced is like hiring a 24/7 security team plus insurance. Standard is for everyone advanced for valuable targets. On to section 9, threat detection trio, GodDuty, Inspector and Macy. Now let's cover the three main threat detection services. These analyze your AWS environment automatically and alert you to security issues. They're often tested as comparison questions on the exam, so understanding them and their distinction is key here. Let's start with Amazon GodDuty. This is your intelligent threat discovery for your AWS account. It uses machine learning algorithms, anomaly detection and third party threat intelligent feeds to find suspicious activity. GodDuty analyzes multiple data sources continuously. CloudTrail events looking for unusual API calls or unauthorized deployments. CloudTrail S3 data events that's tracking access to your buckets. VPC flow logs looking for unusual internal traffic patterns or unusual IP addresses. DNS logs detecting compromised EC2 instances trying to send data through DNS queries. Optional features extend to EKS audit logs, RDS and Aurora logging activity, EBS volumes and Lambda network activity. It's one click to enable, so no software to install here, no agents to manage at all. It's a 30 day free trial. GodDuty automatically generates findings when it detects issues, unusual API calls, port scanning, communication with known malicious IP addresses, cryptocurrency mining activity and more. You set up event bridge rules to react to GodDuty findings, send notification via SMS, trigger Lambda functions to auto remediate or integrate with your security incident management. GodDuty has a dedicated finding type of cryptocurrency mining attacks. This is increasingly common as attackers compromise EC2 instances to mine cryptocurrency at the victim's expense. Next is Amazon Inspector. Inspector is about automated security assessments of your various workloads. It runs one-rability scans against three specific targets, EC2 instances, container images in Amazon ECR and Lambda functions. For EC2 instances, Inspector uses the SSM agent to scan the operating system for known vulnerabilities and check for unintended network accessibility. For container images, Inspector scans them as they are pushed to ECR. For Lambda functions, Inspector scans the function code and package dependencies for vulnerabilities. It works against a database of CVES, called common vulnerabilities and exposures, which is the industry standard catalog of known security vulnerabilities. Inspector continuously monitors your infrastructure. New vulnerabilities discovered in dependencies will be flagged automatically. Inspector assigns a risk code to each vulnerability so you can prioritize remediation. It sends findings to EventBridge and integrates with AWS security hub for centralized security management. The key thing to remember about Inspector is that it only accesses EC2, ECR container images and Lambda functions, not S3 buckets, not RDS, not any other services. As the question asks about scanning EC2 for vulnerabilities, Inspector is often the answer. Then we have, finally, Amazon Meshie. Meshie is specifically focused on data privacy and discovering sensitive data in S3. Meshie uses machine learning and pattern matching to scan S3 buckets and identify sensitive data, personal identifiable information like names, addresses, social security numbers, craycard numbers and other PII data. It then alerts to you where the sensitive data exists. This is crucial for compliance scenarios, like GDPR, HIPAA, etc., all have requirements about knowing where sensitive data lives and protecting it appropriately. Meshie just automates this discovery. Meshie sends finding to EventBridge for automation. You can integrate it with security hub for centralized security findings. The trio works together beautifully, GodDuty detects malicious activity, Inspector identifies vulnerabilities in your infrastructure and Meshie finally identifies sensitive data that needs protection, so together they give you a comprehensive security visibility. One for a quick pulse check, rapid-file scenario here, for each you want to identify the service. Scenario 1 detect when an EC2 instance is being used to mind cryptocurrency. The answer is GodDuty because it uses anomaly detection on crowd-tile and BPC flow logs. Scenario 2 scan all EC2 instances for software vulnerabilities. The answer is Inspector because it provides vulnerability assessment for EC2. Scenario 3 find S3 buckets containing personally indifiable information. The answer is Meshie because it provides sensitive data discovery in S3 buckets. Scenario 4 alert when unusual APA calls are made in AWS account. The answer is GodDuty because it analyzes cloud trail for anomalies. And finally scenario 5 scan container images in ECR before deployment. The answer is Inspector because it assesses container images on push. Don't confuse these three. GodDuty is threat detection finding malicious or suspicious behavior. Inspector is vulnerability assessment that's finding weaknesses to be exploited and finally Meshie is data classification that's finding sensitive information. Three different jobs, three different services. A memory hook here, GodDuty watches for intruders that's threats. Inspector think of it like it checks for weak locks, vulnerabilities and Meshie identifies valuable items in the house that sends to data. All three protect but each look at different things. Let's now move on to section number 10, exam traps and gochers. Let's cover the common security traps that catch people on the exam. So trap number one, secret manager versus parameter store. The deciding factor is usually rotation. You need automatic rotation, especially for RDS, then go for secrets manager. If you're just storing configuration without rotation, then parameter store is the option, especially if it's free standard tier. If cost is a factor, again parameter store is cheaper or free. Trapp number two, KMS versus cloud HSM. This is multi tenant manage software. Cloud HSM on the other hand is single tenant dedicated hardware. If you see the term dedicated hardware, single tenant, FIPS level three with full key control, then that's cloud HSM. Otherwise default to KMS. Trapp number three, AWS manage keys versus customer manage keys. AWS manage keys are free but you can't rotate manually or share across accounts. Customer manage keys on the other hand cost $1 per month, but you control rotation and can share. If the question mentions cross account access or specific rotation requirements, customer manage keys are generally the answer. Trapp number four, where ACM certificates live. ACM certificates are regional except for cloud front which requires a certificate in US East 1 specifically. If a question about Cloud Front SSL setup asks where the certificate must be, the answer is always US East 1. Crap number 5. WAF deployment locations. WAF works with ALB, API Gateway, Cloud Front, Appsing GraphQL, Cognitor User Pool, and so forth. Not with NLB directly. If a question describes wanting WAF protection for an NLB, the architecture involves global accelerator and ALB. Crap number 6. Sheel standard versus advanced. Standard is automatically enabled, it's free, and covers basic layer 3 to 4 attacks. Advanced costs about $3,000 per month, per organization, and includes the response team, cost protection, and automatic layer 7 mitigation via WAF. Crap number 7. GodDuty versus Inspector versus Meshie. GodDuty detects malicious activity through log analysis. Inspector scans easy to container images and lambda for vulnerabilities. Meshie on the other hand discovers PII in S3. There's three different services, three different jobs so match the keywords, threat detection, vulnerability scanning, or sensitive data discovery. Crap number 8. Camus key policy is mandatory. Unlike most AWS resources where IAM alone grants access, Camus keys requires both IAM permissions and a permissive key policy. For cross-account access, both account policies must allow it. Crap number 9. Encrypted EBS snapshot sharing requires four steps. Customer managed key, shared the snapshot, update the key policy for cross-account, and copy with target accounts key, missing any of these steps fails the sharing. Crap number 10. Multi-region Camus keys are not global. They are separately managed in each region but have the same key material. Data encrypted in one region can be decrypted in another without re-encryption. Use cases include global DynamoDB and Aurora. Crap number 11. HTTPS termination location matters. If HTTPS terminates at cloud front, traffic from cloud front to origin can still be over HTTPS which is recommended or HTTP. If HTTPS terminates at ALB, traffic from cloud front to ALB must support HTTPS. And finally, Crap number 12. Inspector scope. Inspector only assesses easy to continue images in ECR and Lambda, not S3, not RDS, not any other services. If a question asks about scanning S3 buckets, it's likely Meshie. So onto our final section exam quick tips. Let me give you the rapid-fire summary to lock all of what we've learned in. Encryption Fundamentals. Symmetric means one key AS256 for fast bulk encryption. AS Symmetric key, which is key pair RSA or ECC, is used for digital signatures and external scenarios. At rest, protect store data, intransit protects network traffic. You want to use both generally. KMS is a central key management. AWS own keys are free, it's hidden. AWS managed keys are free, it's visible, but it's service-specific. Customer managed keys cost a dollar per month, but you've got full control. Symmetric keys are the default choice and asymmetric are used for special cases. Key policies are mandatory and combined with IAM. Multi-region keys are used for global applications. Secrets Manager. It provides automatic rotation, it's expensive, but powerful, it's perfect for RDS database passwords. Parameter store are cheaper or free for standard tier, use it for configuration data or hierarchical paths. You choose based on rotation needs and cost sensitivity. ACM, free SSL or TLS certificates, automatic renewal, integrated with AWS services. Cloud front requires certificates in US East 1 specifically. Cloud HSM is a dedicated single tenant hardware, provides level 3 compliance requirements, use for strict compliance requirements, it's expensive, but full control. WAF provides layer 7 application firewall, ALB API gateway, cloud front, app sync, cognitive, can be used with NLB directly, web ACLs with rules block, allow or count. Shield standard is automatic, it's free, it's layer 304 DDoS protection, shield advance cost about $3,000 per month, there's a response team, there's cost protection, there's automatic WF integration for layer 7. Firewall manager provides centralized policy management across an organization. Guard duty can be used for threat detection through log analysis, inspector is used for vulnerability scanning of EC2, ECR images, Lambda, Macy handles PII discovery in S3, that is 3 services, 3 jobs. The decision framework I want you to remember is encryption requirement, then it's KMS by default, Cloud HSM use that for compliance, if secrets need rotation, then secrets manager, if it's config data, use parameter store, you want web application protection, think WAF, you want DDoS protection, think shield, if you want threat detection, think guard duty, for vulnerability scanning, think inspector, and for PII sensitive data discovery, think Macy. All right, so that's episode 18 on security and encryption. We have covered an enormous amount today, we started with AWS shared responsibility model and the encryption fundamentals, that is symmetric versus asymmetric, addressed versus transit, we did a deep dive on KMS including key types, key policies, key rotation, and multi-region keys, we compared secrets manager and parameter store for storing secrets and configuration, we touched on ACM for SSL or TLS certificates, we explored Cloud HSM for hardware based encryption, then we shifted to network and application security, that's WAF for application layer protection, shield for DDoS defense and firewall manager for centralized policy management. We covered the threat detection trial, that's guard duty for threats, inspector for vulnerabilities and Macy for sensitive data, we then worked through 12 common exam drops. The big takeaway here is security in AWS is led, no single service provides complete protection, you combine identity that's IAM encryption, that's KMS, secrets management, that secrets manager, network controls that's security groups in ACLs, VPC, application protection that is WAF, DDoS defense that is shield and threat detection that's guard duty inspector and Macy into a comprehensive security posture. Master how these services all work together and you'll handle the security questions on the exam with confidence. We have now completed 18 main episodes, your coverage for the solutions architect exam is becoming truly comprehensive, we've learned compute, storage, databases, networking, serverless messaging, content delivery, monitoring, disaster recovery, and now security, you're well on your way to exam mastery. If this episode helps security concepts finally click for you, please consider to leave a five star rating on my podcast and share it with anyone studying for the AWS exam, it genuinely helps the channel grow. Also let me know in the comments did the new intractive format work for you on this dense security content, should I continue using the pulse checks and trap spotlights, your feedback shapes future episodes. Until next time, keep building, keep securing, and I will see you in the next episode, this is Baloo signing off bye.