AWS Training
Modules Listen All tracks

← Design Secure Architectures

Starts this lesson and continues through 22 more to the end of certification prep.

Application protection, identity and secrets

Why this lesson matters

Task statement 1.2 asks for knowledge of "Security services with appropriate use cases (for example, Amazon Cognito, Amazon GuardDuty, Amazon Macie)", "Threat vectors external to AWS (for example, DDoS, SQL injection)" and "Application configuration and credentials security", plus the skill "Integrating AWS services to secure applications (for example, AWS Shield, AWS WAF, IAM Identity Center, AWS Secrets Manager)".

That's a lot of services, and the exam does not test them one at a time. It tests whether you can match the control to the layer. So the structure of this lesson is: layers 3 and 4, then layer 7, then identity, then secrets, then detection. One pass down the stack.

Shield Standard, Shield Advanced, WAF: which layer

The single clarifying quote, from What are AWS WAF, AWS Shield Advanced… (verified 2026-09-21):

"AWS WAF is a web application firewall that you can use to monitor web requests that your end users send to your applications and to control access to your content. Shield Advanced provides protection against distributed denial of service (DDoS) attacks for AWS resources, at the network and transport layers (layer 3 and 4) and the application layer (layer 7). AWS Firewall Manager provides management of protections like AWS WAF and Shield Advanced across accounts and resources, even as new resources are added."

Three services, three jobs: WAF inspects requests. Shield absorbs attacks. Firewall Manager applies both across accounts. If a question mentions "across all accounts, including new ones", the answer contains Firewall Manager.

Shield Standard's cost is the fact people need. Verbatim: "AWS Shield Standard is automatically included at no extra cost beyond what you already pay for AWS WAF and your other AWS services." You do not enable it, you do not pay for it, and "enable Shield Standard" is therefore a wrong answer whenever it appears as an action.

Shield Advanced — what it protects and what you get:

"Shield Advanced provides expanded DDoS attack protection for your Amazon EC2 instances, Elastic Load Balancing load balancers, CloudFront distributions, Route 53 hosted zones, and AWS Global Accelerator standard accelerators. Shield Advanced incurs additional charges. Shield Advanced options and features include automatic application layer DDoS mitigation, advanced event visibility, and dedicated support from the Shield Response Team (SRT)."

Memorise that resource list — EC2, ELB, CloudFront, Route 53 hosted zones, Global Accelerator standard accelerators. It is the answer to "which of these can Shield Advanced protect".

Cost detail that makes Shield Advanced the cheaper answer in some questions:

"Your Shield Advanced subscription covers the costs of using standard AWS WAF capabilities for resources that you protect with Shield Advanced. The standard AWS WAF fees that are covered … are the cost per protection pack (web ACL), the cost per rule, and the base price per million requests for web request inspection, up to 1,500 WCUs and up to the default body size." — Shield Advanced overview

And what it does not cover: Bot Control, the CAPTCHA rule action, web ACLs above 1,500 WCUs, and inspecting the request body beyond the default size. Also: "Enabling Shield Advanced automatic application layer DDoS mitigation adds a rule group to your protection pack (web ACL) that uses 150 web ACL capacity units (WCUs)."

⚠️ Billing goes to the payer account. "For accounts that are members of an AWS Organizations organization, AWS bills the Shield Advanced subscriptions against the payer account for the organization, regardless of whether the payer account itself is subscribed." And one subscription price covers all subscribed accounts in the same consolidated billing family.

What WAF can protect, and what it can do

The protected resource types, verbatim:

⚠️ Network Load Balancer is not on that list. Neither is EC2 directly. If a question puts a WAF in front of an NLB, that is the wrong answer — you'd front it with CloudFront or an ALB. This is one of the highest-frequency distractors in Domain 1.

The rule actions, and the one that wins design questions:

Behaviour Use
Allow all except what you specify public site, block attackers
Block all except what you specify restricted site, identifiable users
Count requests that match "track your web traffic without modifying how you handle it … This lets you confirm your new configuration settings before you switch your rules to allow or block matching requests."
CAPTCHA / silent challenge "help reduce bot traffic to your protected resources"

Count is the exam-correct answer to "how do we deploy a new rule safely?" Deploy in Count, observe, then switch to Block. Any option that says "deploy the rule in Block and monitor errors" is worse.

The criteria WAF can match on, verbatim, because it defines what WAF is for: originating IP addresses, originating country, values in request headers, specific strings or regex matches, length of requests, "Presence of SQL code that is likely to be malicious (known as SQL injection)", and "Presence of a script that is likely to be malicious (known as cross-site scripting)".

So SQL injection and XSS — both named in the exam guide's threat-vector list — are WAF's job. Not a security group's, not a NACL's. They are layer 7 content problems and only a layer 7 content inspector sees them.

Also available: rate-based rules — "rules can block or count web requests that not only meet the specified criteria, but also exceed a specified number of requests in a minute or in five minutes" — and managed rule groups from AWS and AWS Marketplace sellers, which is the low-operational-overhead answer when a question says "protect against common exploits without maintaining rules ourselves".

Cognito: user pools vs identity pools

This is a two-line distinction that people still get wrong under time pressure. Both quotes verbatim from What is Amazon Cognito? (verified 2026-09-21):

User pools — "Create a user pool when you want to authenticate and authorize users to your app or API. User pools are a user directory with both self-service and administrator-driven user creation, management, and authentication. … From a user pool, you can issue authenticated JSON web tokens (JWTs) directly to an app, a web server, or an API."

Identity pools — "Set up an Amazon Cognito identity pool when you want to authorize authenticated or anonymous users to access your AWS resources. An identity pool issues AWS credentials for your app to serve resources to users. … It can also optionally issue credentials for guest users."

User pool Identity pool
Is a user directory + OIDC IdP credentials broker
Returns JWTs (ID token, access token) temporary AWS credentials (via STS)
Answers "who is this person?" "what AWS resources may they touch?"
Guest / anonymous access — ✅ "unauthenticated identities"

The decision rule: if the answer involves the user's browser or mobile app calling an AWS API directly — S3, DynamoDB — you need an identity pool, because only an identity pool produces AWS credentials. If the app only calls your own API, a user pool alone is enough.

And neither requires the other: "User pools don't require integration with an identity pool" and "Identity pools don't require integration with a user pool."

Identity pools also give you the two access-control models the exam likes:

One more: WAF can protect a Cognito user pool (it's on the resource list above). Rate-limiting the sign-in endpoint is a real pattern and a plausible exam option.

Secrets: Secrets Manager and rotation

From Rotate AWS Secrets Manager secrets, verified 2026-09-21:

"Rotation is the process of periodically updating a secret. When you rotate a secret, you update the credentials in both the secret and the database or service. In Secrets Manager, you can set up automatic rotation for your secrets."

The three forms, verbatim:

Form Lambda needed?
Managed rotation — "for most managed secrets, you use managed rotation, where the service configures and manages rotation for you" "Managed rotation doesn't use a Lambda function."
Managed external secrets rotation — for secrets held by Secrets Manager partners "This doesn't require a Lambda function."
Rotation by Lambda function — "For other types of secrets" ✅ yes

⚠️ "Rotation always needs a Lambda function" is out of date. For managed secrets — an RDS credential, for instance — the service handles it. If an exam option offers "write a Lambda rotation function" against "enable managed rotation", prefer managed rotation on operational-overhead grounds.

⚠️ I did not verify the minimum rotation interval, the four-step rotation state machine (createSecret / setSecret / testSecret / finishSecret), or the single-user vs alternating-users strategies from a fetched page in this pass. Those are real and commonly examined — read rotate-secrets_lambda.html and rotate-secrets_strategies.html before relying on specifics.

Secrets Manager vs Systems Manager Parameter Store is a near-certain exam comparison, and I have not verified it from a fetched page here. What this lesson will commit to, because it's structural: Secrets Manager's distinguishing feature is built-in rotation. If a requirement says "rotate database credentials automatically", that is Secrets Manager. If it says "store a non-secret configuration value cheaply", that points at Parameter Store. Go and confirm the pricing and the SecureString details yourself before the exam.

The general principle behind this whole section — task statement 1.2's "Application configuration and credentials security" — is: no long-lived credentials in code, config files, environment variables or AMIs. An EC2 instance profile or a task role gives the application a rotating STS session for free. A question offering "store the access key in an encrypted environment variable" is always beaten by "attach an IAM role".

Detection: GuardDuty vs Macie

These two get confused because both are "security services that find problems". They look at different things.

GuardDuty — threat detection from logs:

"Amazon GuardDuty is a threat detection service that continuously monitors, analyzes, and processes AWS data sources and logs in your AWS environment. GuardDuty uses threat intelligence feeds, such as lists of malicious IP addresses and domains, file hashes, and machine learning (ML) models to identify suspicious and potentially malicious activity."

The foundational data sources, verbatim, and the fact that matters: "When you enable GuardDuty in an AWS account, GuardDuty automatically starts ingesting the foundational data sources associated with that account. These data sources include AWS CloudTrail management events, VPC flow logs (from Amazon EC2 instances), and DNS logs. You don't need to enable anything else."

CloudTrail management events, VPC flow logs, DNS logs — automatically, no configuration. That's the exam fact. GuardDuty is agentless for the foundational sources and does not sit in the data path.

Macie — sensitive data discovery in S3:

"Amazon Macie is a data security service that discovers sensitive data by using machine learning and pattern matching, provides visibility into data security risks, and enables automated protection against those risks."

Scope: S3 general purpose buckets. It produces two finding kinds — sensitive data findings ("multiple types of personally identifiable information (PII), financial information, and credentials data", via managed data identifiers, plus regex-based custom data identifiers) and policy findings ("such as a bucket that becomes publicly accessible").

Requirement Service
"Detect compromised credentials / cryptomining / C2 traffic" GuardDuty
"Find PII in our S3 buckets" Macie
"Tell us if a bucket becomes public" Macie policy finding (or Config / Security Hub)
"Aggregate findings against industry standards across accounts" Security Hub CSPM
"Find the root cause of a finding across log data" Amazon Detective

Both publish findings to EventBridge and Security Hub CSPM, which is the documented route to automated remediation: EventBridge "can route findings data to targets such as AWS Lambda functions and Amazon Simple Notification Service (Amazon SNS) topics". If a question asks how to respond to a finding automatically, the answer runs through EventBridge.

Check yourself

  1. A requirement says block SQL injection against an application behind a Network Load Balancer. What do you change?
  2. You need to roll out a new WAF rule without risking blocking real users. How?
  3. A mobile app must upload directly to S3 with per-user prefixes. User pool, identity pool, or both?
  4. "Enable AWS Shield Standard on the CloudFront distribution." Is that a valid action?
  5. Which service tells you a bucket contains credit card numbers? Which tells you an instance is talking to a known command-and-control IP?
Answers
  1. The architecture, not just the WAF. WAF cannot attach to an NLB — the supported list is CloudFront, API Gateway REST API, ALB, AppSync, Cognito user pool, App Runner, Bedrock AgentCore Gateway, Verified Access and Amplify. Put an ALB or CloudFront in front, then attach the web ACL.
  2. Deploy the rule with the Count action first — "track your web traffic without modifying how you handle it" — then switch to Block once the sampled requests look right.
  3. Both (or at minimum an identity pool). Direct S3 calls need AWS credentials, and only an identity pool issues those. A user pool authenticates and supplies the token you exchange.
  4. No. Shield Standard "is automatically included at no extra cost" — there is nothing to enable. Any option phrased as enabling or purchasing Shield Standard is a distractor.
  5. Macie for the credit card numbers (sensitive data discovery in S3). GuardDuty for the C2 traffic (it ingests VPC flow logs and DNS logs against threat intelligence feeds by default).

Teaching this section

← PreviousNetwork security controls and where they sitNext →Encryption and key management