Skip to main content
This lesson focuses on securing container and compute services in AWS at the Associate level: Elastic Container Registry (ECR), App Runner, and AWS Batch. You’ll learn practical security controls you can realistically apply, how those controls map to common operational requirements, and exam-style reasoning for architecture and configuration choices.

​
Amazon ECR: basics and security considerations

Amazon Elastic Container Registry (ECR) is a fully managed container registry that hosts private and public repositories for Docker container images. When designing ECR security, focus on access control, vulnerability scanning, network privacy, and visibility. Key concepts and controls:
  • Access control: enforce least-privilege using IAM identity-based policies and, where appropriate, repository resource policies to restrict who can push, pull, or manage images.
  • Vulnerability scanning: enable automated image scanning (for example, ECR integrates with Amazon Inspector which uses the Trivy engine) to surface CVEs on push.
  • CI/CD integration: ECR integrates with CodeBuild, CodePipeline, CodeDeploy, and other build/deploy systems.
  • Visibility and auditing: use CloudWatch (metrics & logs), CloudTrail (API call history), and AWS Config (configuration and compliance checks).
  • Network privacy: use VPC interface endpoints (AWS PrivateLink) for ECR APIs and registry endpoints; ECR operations that rely on S3 typically use a gateway endpoint for S3.
Do NOT store container images in a publicly accessible S3 bucket. Docker registries require specific protocols and behaviors — ECR is the supported managed registry. Public S3 buckets expose data and are not appropriate for hosting container images.
Recommended operational steps (example checklist):
  1. Apply least-privilege IAM and repository policies:
    • Create roles for CI/CD systems (CodeBuild, pipelines) with minimal scope (push to specific repository, read-only for others).
    • Use repository policies for cross-account pulls when needed.
  2. Enable automated vulnerability scanning:
    • Turn on “scan on push” to get immediate scanning results by Amazon Inspector/Trivy.
    • Integrate scan results with Security Hub or a ticketing workflow for remediation.
  3. Keep registry traffic private:
    • Use VPC interface endpoints (PrivateLink) for ECR APIs and for the registry (ECR DKR).
    • Use gateway endpoints for S3 access when required.
  4. Centralize visibility:
    • Enable CloudTrail for API auditing.
    • Route image-pull/push logs and operational metrics to CloudWatch.
    • Use AWS Config for configuration tracking and compliance rules.
Practical CLI example — enable scan-on-push for a repository:
Example IAM policy (minimal push/pull permissions for a CI role):
Scenario: global e-commerce company using ECR
They require secure image storage, strict access to authorized identities and roles, and automatic vulnerability scanning. The steps above map directly to those requirements: least-privilege policies, scan-on-push, PrivateLink, and centralized monitoring.
An architecture diagram of an AWS Elastic Container Registry showing public registries (public.ecr.aws, quay.io) feeding a pull-through cache into development and production ECR repositories. It also shows integrations with AWS Inspector, CodeBuild/CodePipeline/CodeDeploy, AWS Security Hub, and an ECS production cluster via a VPC endpoint.

​
Logging, monitoring, and networking for ECR

Use the detection and audit “trifecta”:
  • CloudWatch — metrics, container lifecycle logs, scan notification metrics.
  • CloudTrail — complete API call history for push/pull and configuration changes.
  • AWS Config — monitor resource changes and enforce compliance rules.
Network connectivity:
  • ECR services use interface VPC endpoints (PrivateLink). These create ENIs in your subnets and keep ECR API and registry traffic inside the AWS network.
  • Gateway endpoints are only for S3 and DynamoDB; other services (including ECR) use interface endpoints.
Useful reference table: visibility and network controls
A slide titled "Elastic Container Repository" showing an AWS architecture diagram with a Prod and Test AWS account: an EC2 Docker instance inside a VPC using VPC interface endpoints (ECR API, ECR DKR, S3) to access Prod and Test ECR registries that contain listed images. The slide also notes standard AWS logging and emphasizes networking via interface endpoints.
Example question recap (exam-style guidance)
  • If a healthcare provider needs a detailed audit trail and quick troubleshooting:
    • Enable CloudTrail to capture API calls (full activity history).
    • Use CloudWatch for logs/operational metrics and set alarms.
    • Enable AWS Config to detect non-compliant changes.
  • Encryption:
    • Data in transit: TLS.
    • Data at rest: encrypted with AWS-managed KMS keys by default. For stronger key control, use customer-managed AWS KMS keys where supported, or encrypt sensitive artifacts before pushing them.

​
AWS App Runner: what it is and how to secure it

App Runner is a fully managed service that builds and runs web applications and APIs from source code or container images. It provides automatic scaling and abstracts infrastructure management. Security and operational features:
  • TLS and HTTPS endpoints: App Runner terminates TLS for secure in-transit traffic.
  • Data at rest: encrypted by AWS. App Runner typically does not provide a built-in option to use customer-managed KMS keys for its internal storage—consider client-side encryption or ensure any external stores are encrypted with customer-managed KMS.
  • VPC Connector: use App Runner’s VPC Connector for outbound access to resources inside your VPC (e.g., databases, caches). Note: the VPC Connector enables egress from App Runner into your VPC; it does not make the App Runner service endpoint privately accessible from within your VPC.
  • Visibility: use CloudWatch (logs & metrics), CloudTrail (control plane audit), and AWS Config.
When exam questions require that traffic not traverse the public internet:
  • Think about interface VPC endpoints (PrivateLink) or the specific service’s connector.
  • VPC peering and Direct Connect are not typically relevant for serverless managed services like App Runner when the question is about making service-to-VPC traffic private.
A colorful infographic showing a startup scenario asking how to deploy a web application securely and efficiently using AWS App Runner. It lists four numbered options (e.g., manually using EC2, using App Runner with automatic scaling, using Elastic Beanstalk then migrating, or using App Runner but disabling auto-scaling).

​
App Runner internals (high level)

  • App Runner front-ends traffic with a managed request router/load balancing layer, routes to application instances, and can attach to private VPC resources through VPC Connectors.
  • Under the hood it uses container orchestration (Fargate-like behavior) which is abstracted away — you do not manage the orchestration primitives.
  • For diagnostics and compliance, wire App Runner logs into CloudWatch and enable CloudTrail/Config for resource and control-plane tracking.
A quiz-style screenshot asking what measures a startup should take to ensure data is encrypted when using AWS App Runner. Four numbered multiple-choice options are shown (manual encryption, third‑party tools, rely on App Runner’s built‑in encryption + HTTPS, or disable encryption).

​
AWS Batch: purpose and security considerations

AWS Batch orchestrates batch computing workloads across EC2, EC2 Spot, and AWS Fargate. Security decisions for Batch focus on runtime environment hardening, IAM, networking, and data encryption for inputs/outputs. Core considerations:
  • Compute environment choices affect security posture: EC2 (more control), Fargate (less host management).
  • Data flow: jobs typically read inputs from S3, process, and write outputs to S3/DynamoDB — apply encryption and access control on these stores.
  • IAM: define least-privilege job roles (execution roles) that grant only the permissions required to read inputs and write outputs.
  • Logging & monitoring: push application logs to CloudWatch, enable CloudTrail for API auditing, and AWS Config for environment monitoring.
Design patterns and cost considerations:
  • Hybrid compute (On-Demand + Spot) balances cost and reliability: use On-Demand for critical jobs and Spot for fault-tolerant or retryable workloads.
  • Separate administrative and operational roles: admins manage compute environments and queues; developers submit jobs to scoped queues.
A slide titled "AWS Batch" showing an architecture diagram of AWS Batch application orchestration using AWS Fargate with components like an S3 input bucket, Lambda trigger, Fargate tasks, DynamoDB and CloudWatch. A caption on the left notes that AWS Batch emits logs and much is abstracted because it's a managed service.
Practical IAM guidance for multi-team workloads:
  • Create job queues per team or project and grant each team permission to submit only to their queue.
  • Use separate execution roles for job containers that limit S3/DynamoDB access to specific buckets/tables and actions.
  • Keep management privileges (create/modify compute environments and queues) restricted to an admin role.
An infographic quiz showing a scenario about a media company using AWS Batch and asking which IAM permission strategy to adopt. Four numbered answer options are displayed below the question.
Monitoring Batch jobs:
  • Integrate Batch with CloudWatch Logs for application stdout/stderr.
  • Create CloudWatch Alarms for job failures, unusual retry patterns, or throttling.
  • Use CloudTrail to detect changes to job definitions, queues, or compute environments.
An infographic describing a pharmaceutical company’s need for better monitoring, logging, and troubleshooting for AWS Batch jobs. It lists four numbered options to address this (enable retries; integrate with CloudWatch Logs and alarms; use AWS Lambda to check job status and notify; or store job outputs in S3 for manual review).

​
Practical examples and exam-style reasoning

IAM strategy for Batch:
  • Example approach: provide teams permission to submit only to their queue and to assume only their job-submission role. Administrative privileges for the Batch control plane are separate and limited to operations teams.
Monitoring strategy for Batch:
  • Send logs to CloudWatch Logs; create alarms for failure metrics; optionally push critical alerts to SNS or an incident system.

​
Summary checklist — security-focused

ECR
  • Enforce least-privilege with IAM and repository policies.
  • Enable automated image scanning (scan on push).
  • Use VPC interface endpoints (PrivateLink) to keep registry traffic private.
  • Enable CloudTrail, CloudWatch, and AWS Config for auditing and monitoring.
App Runner
  • Deploy from source or container images and enforce HTTPS/TLS.
  • Use App Runner’s built-in encryption for data at rest; for stricter key control, encrypt sensitive data prior to ingestion or ensure external stores use customer-managed KMS keys.
  • Use VPC Connectors for egress to VPC resources; use interface endpoints where available to keep API/registry traffic private.
  • Monitor with CloudWatch, CloudTrail, and AWS Config.
AWS Batch
  • Use hybrid compute (On-Demand + Spot) to balance cost and reliability.
  • Apply least-privilege IAM to job submission, execution roles, and management operations.
  • Send logs to CloudWatch and create alarms for rapid detection and response.
  • Ensure outputs (S3, DynamoDB, etc.) follow encryption and access-control policies.
For visibility and compliance across ECR, App Runner, and Batch, enable CloudTrail and AWS Config, and centralize logs and alerts in CloudWatch. These are the essential detective controls for managed compute services.

​
Further reading and references

Watch Video