Securing Compute Workloads: EC2, Containers, and Lambda

IMDSv2 protects an instance role's credentials by making the instance metadata service at 169.254.169.254 require a session token, which the request primitives behind most server-side request forgery (SSRF) flaws cannot obtain. With IMDSv1, a single GET returns the role's temporary credentials, so any SSRF flaw, misconfigured proxy, or open redirect that makes the application fetch an internal URL becomes credential theft.

Under IMDSv2, a client first sends a PUT with the X-aws-ec2-metadata-token-ttl-seconds header to get a token, then presents it in the X-aws-ec2-metadata-token header on every read. Typical SSRF primitives can issue simple GETs but not a custom-header PUT, so the chain breaks. Security groups and network ACLs do not help here: metadata traffic never leaves the instance, so it is not filtered by them.

The hop limit

HttpPutResponseHopLimit is the IP TTL on the token response. With a hop limit of 1, the response dies at the first network hop, so processes on the host (such as the CloudWatch or SSM agents) still get tokens, but containers on a bridged network, which sit one hop further away, do not. A hop limit of 2 is what lets containers reach IMDSv2. The hop limit only constrains the token response, so it does nothing while IMDSv1 is still allowed: a container can simply use a token-less GET. Blocking containers needs HttpTokens=required and a hop limit of 1 together. Setting HttpEndpoint=disabled turns the service off for everything on the instance, host agents included.

Enforcing IMDSv2 for existing and future instances

The settings that decide an instance's metadata options apply in a fixed order of precedence: launch parameters win over the account-level IMDS defaults for the Region, which win over the AMI's ImdsSupport=v2.0 setting. A default is therefore only a default: a launch that explicitly asks for HttpTokens=optional still succeeds. Only two things make an IMDSv1 launch fail:

• A deny: an SCP or IAM policy that denies ec2:RunInstances when ec2:MetadataHttpTokens is not required (and denies ec2:ModifyInstanceMetadataOptions so running instances cannot be switched back).
• Account-level IMDSv2 enforcement (the HttpTokensEnforced account setting), which rejects launches and modifications that would leave IMDSv1 enabled.

Across an organization, EC2 declarative policies in AWS Organizations set these account-level IMDS settings centrally, and member accounts cannot change them locally. Existing instances are not altered by any default: change each one with ModifyInstanceMetadataOptions (Systems Manager Automation can do this at scale), and find stragglers with the AWS Config rule ec2-imdsv2-check or the CloudWatch MetadataNoToken metric, which counts IMDSv1 calls still being made.

The detection backstop is GuardDuty's UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS, which fires when an instance role's credentials are used from outside AWS: evidence the metadata service has already leaked.

An instance profile is the right way to give an EC2 workload AWS permissions because it delivers the role's temporary, automatically rotated credentials through the metadata service, so nothing long-lived is ever stored on the host. The alternatives people reach for each reintroduce a stored secret:

Making stolen instance credentials useless off the instance

Even role credentials can be copied. AWS adds two condition keys to every request signed with EC2 role credentials: aws:Ec2InstanceSourceVpc (the VPC the instance runs in) and aws:Ec2InstanceSourcePrivateIPv4 (its primary private IP). Comparing them with where the request actually came from pins the credentials to their network. A typical deny statement in an SCP says:

• deny when aws:Ec2InstanceSourceVpc does not equal ${aws:SourceVpc} (or aws:Ec2InstanceSourcePrivateIPv4 does not equal ${aws:VpcSourceIp});
• only for EC2 role credentials: scope it with a Null condition that ec2:SourceInstanceARN is present, or the statement also denies IAM users and every other role;
• except when aws:ViaAWSService is true, so services calling onward on the role's behalf (for example S3 to KMS) still work.

This works only where requests reach AWS through VPC endpoints, because aws:SourceVpc and aws:VpcSourceIp exist only for endpoint traffic. The near-misses are instructive: aws:SourceIp is not present on requests that arrive through a VPC endpoint, so comparing the instance IP with it never matches; and merely requiring that aws:SourceVpc is non-null admits an attacker who replays the credentials through an endpoint in their own VPC. The comparison between the instance's VPC and the request's VPC is what does the work.

A golden AMI is a hardened, tested base image that every instance launches from, so fleet hardening happens before boot instead of on each running host. EC2 Image Builder turns that into a managed pipeline: a base image, an ordered list of build components (install agents, remove packages, apply hardening; Amazon-managed STIG hardening components, and CIS hardening components published by CIS through AWS Marketplace), test components that validate the result, and distribution of the finished AMI or container image across Regions and accounts. Images inherit the baseline, including IMDSv2-required metadata defaults and pre-installed SSM and CloudWatch agents.

Keeping the golden image current

An Image Builder pipeline runs manually or on a schedule, and the schedule has a start condition:

• EXPRESSION_MATCH_ONLY: build every time the cron expression matches, even if nothing changed.
• EXPRESSION_MATCH_AND_DEPENDENCY_UPDATES_AVAILABLE: at each match, build only if a newer base image or component version resolves.

Image Builder can only detect an update when the recipe refers to versions with semantic-version wildcards (for example x.x.x). A recipe that pins exact versions always resolves to the same inputs, so the dependency-driven condition never fires. Rebuilding promptly after an upstream change, and never when nothing changed, therefore takes all three pieces: a frequent schedule, the dependency-update start condition, and wildcard versions in the recipe.

Choosing the image-building tool

Patching running fleets

Running instances still drift, which is Systems Manager Patch Manager's job. Patch baselines define which classifications and severities are approved (with auto-approval delays); patch policies, created through Quick Setup, apply scan and install schedules across an organization's accounts and Regions in one configuration (the older approach pairs patch groups with maintenance windows per account). Compliance flows into Systems Manager Compliance and on to Security Hub CSPM.

Know the boundary: Patch Manager patches operating system packages. Amazon Inspector also reports vulnerable language packages (pip, npm, Maven JARs) that an application bundles. A server can therefore be "patch compliant" while Inspector shows an open critical finding; that fix is a dependency update in the application build and a redeploy, not another patch run. That is the continuous-validation loop in Skill 3.2.4: Patch Manager acts, Inspector verifies.

Storage defaults close the loop. Enable EBS encryption by default per Region so every new volume and snapshot is KMS-encrypted, and build AMIs from encrypted snapshots. Key policies and cross-account snapshot sharing belong to Domain 5.

Amazon Inspector is the continual vulnerability scanner for EC2, ECR images, and Lambda: you enable it (organization-wide through a delegated administrator) and it discovers and re-assesses resources automatically instead of running one-off assessments.

• EC2: agent-based scanning uses the SSM Agent to inventory packages, so the instance must be a Systems Manager managed node; agentless scanning (hybrid scan mode) assesses EBS snapshots for instances that are not.
• ECR: images in repositories with enhanced scanning, covered in the ECR section below.
• Lambda: standard scanning finds vulnerable dependencies in function packages and layers; code scanning also inspects your own function code for flaws such as injection and embedded credentials.

Reading a finding's scores

A critical CVE on an unreachable instance can rank below a moderate one on an internet-facing host, so prioritise by the Inspector score.

The pattern the exam rewards is the remediation loop: findings flow to Security Hub CSPM for aggregation and to EventBridge for action, such as running Patch Manager, starting an Image Builder pipeline to rebuild the golden AMI, notifying the owner, or failing a deployment. Inspector sees what is installed; GuardDuty Runtime Monitoring (next section) sees what is happening.

GuardDuty Runtime Monitoring detects threats inside running workloads, such as a process starting a cryptocurrency miner, a reverse shell, or a binary being modified, which complements Inspector's static view of known vulnerabilities. It uses a GuardDuty security agent that reports process, file, and network events, and it covers three targets:

Automated agent configuration also creates the VPC endpoint the agent uses to send telemetry.

Fargate prerequisites that fail quietly

On Fargate, tasks that run without the sidecar simply show as uncovered. Check that:

• tasks run on platform version 1.4.0 or later;
• the task execution role can pull from ECR (ecr:GetAuthorizationToken plus the pull actions), because the sidecar image comes from a GuardDuty-owned ECR repository even when your own images come from elsewhere;
• tasks have a network path to ECR (NAT or ECR endpoints);
• no SCP or permissions boundary denies guardduty:SendSecurityTelemetry.

Lambda and the other protection plans

Runtime Monitoring does not support Lambda. GuardDuty Lambda Protection covers functions agentlessly by analysing their network activity logs, which is how it flags a hijacked function talking to a cryptocurrency mining pool (finding type CryptoCurrency:Lambda/BitcoinTool.B). EKS Protection analyses Kubernetes audit logs (control-plane activity), while Runtime Monitoring watches inside the nodes and containers; enabling both gives the fullest EKS coverage.

Amazon ECR is where container security starts, because every downstream control depends on trusting what is in the registry. Four controls matter: scanning, immutable tags, repository policies, and encryption.

Scanning: type, frequency, and re-scan duration

Continuous scanning is a frequency of enhanced scanning only. It does not run forever: Inspector's ECR re-scan duration decides how long an image stays monitored, and images outside the window become inactive and are no longer rescanned. You set two durations:

• a push date duration: 3, 7, 14, 30, 60, 90 or 180 days, or Lifetime;
• an image re-scan duration in one of two modes, either last in use (the default) or last pull date, from 3 to 180 days. Last-in-use tracking only sees images running on ECS or EKS clusters; an image run some other way, such as directly with Docker on an EC2 host, records no in-use activity, so only its pull and push dates count.

New accounts start with short (14-day) windows, so a long-running image deployed outside ECS or EKS silently drops out of monitoring unless the push-date duration is extended (Lifetime keeps it monitored indefinitely).

Immutable tags

With tag immutability, a tag can never be overwritten to point at a different image. Without it, someone can push a new image as myapp:prod and every task definition using that tag silently deploys the replacement, a supply-chain attack scanning does not stop. Referencing images by digest is the strictest form of the same idea.

Repository policies and cross-account pull

A cross-account pull needs permission on both sides. The registry account's repository policy grants the consuming principals the three pull actions: ecr:BatchGetImage, ecr:GetDownloadUrlForLayer and ecr:BatchCheckLayerAvailability. The puller also needs ecr:GetAuthorizationToken, which is a registry-wide action on resource *: it cannot be granted in a repository policy and must sit in the puller's own identity policy (for ECS, the task execution role). Keep push rights to the CI/CD role.

Encryption and provenance

Repositories encrypt images with AES-256 or KMS; choose a customer managed key for key-level access control and CloudTrail visibility of decryption. Lifecycle policies expire stale images. Image signing (AWS Signer with Notation) addresses provenance, not vulnerabilities.

The most reliably tested distinction in container security is the two roles attached to an ECS task — because they answer different questions:

The trap: secrets referenced in the task definition's secrets block — injected as environment variables from Secrets Manager or SSM Parameter Store at startup — are fetched by the execution role. Secrets fetched by application code at runtime use the task role (delivered via the container credentials endpoint, per-task, so co-located tasks never share credentials). Granting the wrong role is the classic broken deployment, walked through in the final section.

Fargate hardens the substrate: each task runs in its own isolated environment with a dedicated kernel — no shared host to escape to, no privileged containers, no host-path mounts, and AWS patches the underlying infrastructure. Within any task, set readonlyRootFilesystem in the container definition so a compromised process cannot modify its own filesystem, drop non-root users in the image, and keep containers from running with elevated Linux capabilities.

The other two ECS roles

Two more roles act for ECS itself, never for your containers. The service-linked role (AWSServiceRoleForECS) is created automatically and lets ECS manage network interfaces for awsvpc tasks and register targets with load balancers. The ECS infrastructure role is one you create so ECS can manage infrastructure for specific features, such as Amazon EBS volumes attached to tasks or VPC Lattice. Neither grants the application anything: runtime API access is always the task role.

EKS security at specialty level reduces to three controls; deep Kubernetes administration is out of scope, but these are fair game.

Least-privilege pod identity. The anti-pattern is giving the node's instance role every permission any pod might need — every pod on the node then holds the union. The fix is per-pod credentials: IAM Roles for Service Accounts (IRSA) associates an IAM role with a Kubernetes service account through the cluster's OIDC identity provider — pods assume the role with sts:AssumeRoleWithWebIdentity using a projected service account token, and the role's trust policy names the specific service account. The newer EKS Pod Identity feature reaches the same goal with less setup: an EKS-run agent and a direct association between role and service account, no per-cluster OIDC provider registration. Either way, the exam answer to "one pod needs S3 access, others must not have it" is pod-level identity, never node-role inflation. Blocking pods from the node's instance metadata (or enforcing IMDSv2 with hop limit 1) closes the fallback path to node credentials.

Control-plane audit logs. EKS can ship five control-plane log types to CloudWatch Logs — api, audit, authenticator, controllerManager, and scheduler. They are off by default; the audit and authenticator streams are the ones that answer "who did what to the cluster," and GuardDuty's EKS audit log monitoring consumes this activity for threat detection.

Private endpoint. The cluster API server endpoint is public by default. Disable public access (or restrict it to allowlisted CIDRs) and enable the private endpoint so kubectl and node-to-control-plane traffic stay inside the VPC — an internet-reachable API server is an unnecessary attack surface even with authentication in front of it.

Lambda has two independent permission surfaces, and questions turn on which one is broken. The execution role governs what the function can do: the service assumes it at invocation and hands its credentials to your code. Least privilege means one role per function, not a shared role with accreted permissions.

The resource-based policy governs who may invoke the function. When S3, SNS, or an EventBridge rule invokes a function, the service principal (for example s3.amazonaws.com) needs lambda:InvokeFunction in the function's policy. That grant creates the confused-deputy risk: without conditions, a resource in a stranger's account could trigger your function through the trusted service.

Scoping service grants: aws:SourceArn and aws:SourceAccount

aws:SourceArn names the triggering resource, and aws:SourceAccount names the account that owns it. For S3 you need both: S3 bucket ARNs contain no account ID, so if your bucket is deleted and someone re-creates the same name in another account, a SourceArn-only condition still matches. aws:ResourceAccount is not a substitute: it describes the account owning the resource being called, which is the function's own account, not the bucket's.

EventBridge rules versus EventBridge Scheduler

The console adds a rule's resource-policy statement automatically; infrastructure as code does not, so a CloudFormation or CDK deployment must declare the permission (for example an AWS::Lambda::Permission resource) or the rule's invocations fail.

VPC attachment, environment variables, signing

VPC attachment is about egress, not ingress: it lets the function reach private resources like RDS and removes default internet access (add a NAT gateway or VPC endpoints), but it does not change who can invoke the function; invocation always flows through the Lambda API and IAM. Environment variables are encrypted at rest with KMS; prefer Secrets Manager for real secrets so rotation exists. Code signing with AWS Signer lets Lambda reject unsigned or modified packages.

The secure way to administer compute is Systems Manager Session Manager: IAM-authorized shells with no inbound ports, no bastion hosts, no SSH keys, and session logging to S3 or CloudWatch Logs. The other options each give up one of those properties, and the exam separates them by requirement.

Two details trip people up. First, an EC2 Instance Connect Endpoint removes the need for a public IP or bastion, but it still needs the instance's security group to allow port 22 or 3389 from the endpoint (and the endpoint's outbound rules to reach the instance); inbound rules on the endpoint's own security group are not used. Because this is a network rule, getting it wrong shows up as a connection timeout rather than an IAM access-denied error. Second, port forwarding is how a laptop GUI client reaches a private database without opening any inbound rule: Session Manager forwards a local port through a managed node to the remote host. Only native Session Manager shell sessions record what was typed and shown; SSH over Session Manager and port-forwarding sessions carry an encrypted or opaque stream, so their contents are not logged.

Pipeline vulnerability scanning means finding flaws in code, dependencies, and infrastructure as code before they reach production, at each stage from the developer's editor to the image registry. The exam guide names Amazon CodeGuru Security, but AWS ended support for CodeGuru Security on 20 November 2025; its jobs moved to Amazon Q Developer and Amazon Inspector. (CodeGuru Profiler, a performance tool, is a different product.)

The distinction to hold: registry scanning happens after push, so it can report a bad image but cannot keep one out of a shared registry. Gating means scanning in the build. Remediation is the same loop as runtime: findings to Security Hub CSPM and EventBridge, fixes through the dependency file or the base image, then a rebuild.

Protecting a generative AI application means mitigating the risks in the OWASP Top 10 for LLM Applications with controls around the model, because the model itself cannot be trusted to refuse. The risks most often mapped to AWS controls:

Amazon Bedrock Guardrails

A guardrail is a reusable, versioned policy evaluated on input and output, with content filters, denied topics, word filters, sensitive information filters, contextual grounding checks and a prompt attack filter. It applies when you pass its ID and version on an inference call, or on any text through the ApplyGuardrail API.

• Sensitive information filters take an action per entity type (or custom regex) and per direction: block rejects the whole input or response; mask (anonymize) replaces the entity with a placeholder such as {PHONE} and lets the rest through. Choose block when any occurrence must stop the exchange; choose mask when the rest of the content is still useful without the entity.
• The prompt attack filter only evaluates input you mark as user input. With InvokeModel or InvokeModelWithResponseStream, wrap the user's text in the guardrail's input tags; with the Converse API, use guard content blocks. Untagged text, including user content embedded in an untagged prompt template, is not checked for prompt attacks, and tagging the developer's own instructions would make them look like attacks.

Logs keep the original

Bedrock model invocation logging records the request and response as sent, so a guardrail masking PII in the application does not mask it in the logs. Attach a CloudWatch Logs data protection policy to the log group to mask identifiers at rest in the log view, and grant logs:Unmask only to those who may see the originals (S3 log destinations need their own controls).

Agents and excessive agency

A Bedrock agent acts through action groups, usually Lambda functions. Limit the blast radius in layers: give each action group function a least-privilege role; enforce business limits (amounts, record scope) in the function code rather than trusting the model to respect them; and turn on user confirmation for high-impact functions so a person approves each call. These matter most when an agent reads untrusted content, such as emails returned by another tool, because instructions hidden in that content (indirect prompt injection) arrive as tool output rather than as tagged user input.

Instance not a Systems Manager managed node. An instance missing from Fleet Manager (so Session Manager, Patch Manager, Inspector agent-based scanning and GuardDuty's EC2 agent all fail) has one of three causes, checked in this order:

1. Agent: the SSM Agent is not installed, not running, or too old.
2. Permissions: either an instance profile with AmazonSSMManagedInstanceCore, or Default Host Management Configuration (DHMC), which lets Systems Manager manage instances with no instance profile by having the agent use the AWSSystemsManagerDefaultEC2InstanceManagementRole service role.
3. Network path: in private subnets, interface endpoints for ssm and ssmmessages (recent agents use ssmmessages where older ones used ec2messages, so many setups still create all three), or NAT egress.

DHMC has prerequisites of its own: SSM Agent 3.2.582.0 or later and IMDSv2 on the instance (it uses the instance identity from the metadata service). If an instance profile is attached, the agent uses it only when it allows ssm:UpdateInstanceInformation; otherwise it falls back to DHMC. An agent older than that minimum cannot use DHMC at all, so the agent version baked into an image matters as much as the setting itself.

Inspector not scanning an instance. Usually the same root cause, because agent-based EC2 scanning rides on SSM management. Fix SSM coverage first; agentless snapshot scanning is the fallback.

Scenario: the task that cannot read its secret. A new ECS service's tasks stop immediately with ResourceInitializationError: unable to pull secrets or registry auth. The failure is at startup, so this is execution-role territory. Check, in order: (1) the execution role grants secretsmanager:GetSecretValue on the secret ARN in the task definition's secrets block, plus kms:Decrypt if the secret uses a customer managed key; (2) it can pull the image (ecr:GetAuthorizationToken plus the pull actions, and the repository policy if ECR is cross-account); (3) tasks in private subnets can reach Secrets Manager and ECR: interface endpoints for secretsmanager, ecr.api and ecr.dkr, plus the S3 gateway endpoint ECR uses for image layers. Permissions added to the task role cannot fix a startup failure.

Lambda AccessDenied on invoke. The caller is refused before the function runs, so inspect the resource-based policy (or, for EventBridge Scheduler, the schedule's execution role): the invoker needs lambda:InvokeFunction, with aws:SourceArn and aws:SourceAccount matching the real source. The function's execution role is irrelevant to who may invoke it.