Docker Containers and Microservices on AWS – SAP-C02 Study Guide

Purpose of This Lesson

Docker containers provide a lightweight way to package and run applications with their code, configuration, and dependencies. They are a foundational technology for Amazon Elastic Container Service (Amazon ECS) and many cloud-native microservices architectures.

This lesson focuses on the difference between virtual machines and containers, the architectural characteristics of microservices, and the AWS services commonly used to connect independently deployed application components.

Key Concepts

Virtual Machines Versus Containers

A virtual machine runs on a hypervisor and includes a complete guest operating system. Each VM has virtual hardware, an operating system, libraries, and application code.

A container runs on a host operating system through a container engine such as Docker. The container includes the application and its required dependencies, but normally does not include a separate full operating system. Containers share the host kernel while remaining isolated from one another.

Characteristic	Virtual machine	Container
Virtualization layer	Hypervisor	Container engine, such as Docker
Operating system	Each VM has its own guest OS	Containers share the host kernel
Startup time	Generally slower because the OS must boot	Generally faster because no guest OS boots
Resource overhead	Higher	Lower
Isolation model	Strong isolation through separate guest OS environments	Process and namespace isolation on a shared kernel
Packaging unit	VM image	Container image
Typical use	Full OS control, legacy workloads, strong environment separation	Portable application deployment and microservices

Containers are not simply smaller virtual machines. Their shared-kernel model provides efficiency and fast startup, but it also means that the container runtime and host operating system remain important parts of the security and operations model.

Docker Images and Containers

A Docker image is an immutable package containing the application binaries, runtime libraries, configuration defaults, and other dependencies required to create a container. A container is a running instance of an image.

An image can be stored in a registry and used repeatedly across development, testing, and production. Docker Hub is a public cloud-based registry, while AWS environments commonly use Amazon Elastic Container Registry (Amazon ECR) for private image storage and integration with AWS deployment workflows.

A typical lifecycle is:

1. Build an image from application source code and a Dockerfile.
2. Store and version the image in a registry.
3. Deploy the image as one or more containers.
4. Scale, replace, or roll back containers without rebuilding the application package.

Microservices Architecture

A microservices application is divided into independently deployable services organized around business capabilities. Examples include customer management, authentication, shopping cart, and payment processing.

Each service can be developed, deployed, monitored, and scaled independently. Services communicate through well-defined interfaces, commonly APIs or asynchronous messaging. A microservice may run in a Docker container, as an AWS Lambda function, or on another suitable compute platform.

Important characteristics include:

• Loose coupling: Services minimize direct dependencies on one another.
• Independent deployment: A change to one service does not require redeploying the entire application.
• Independent scaling: A high-traffic service can scale without scaling every component.
• Business-oriented boundaries: Services align with capabilities rather than technical layers alone.
• Technology flexibility: Different services can use different programming languages or frameworks when justified.
• API-based integration: REST APIs or other contract-based interfaces provide predictable communication.
• Asynchronous processing: Queues and event services can buffer work and reduce direct coupling.

Cloud-Native Application Composition

Cloud-native systems typically combine managed AWS services with application components. For example, a solution might use:

• Amazon ECS for long-running containerized services
• AWS Lambda for event-driven or short-lived functions
• Amazon API Gateway for API exposure and routing
• Amazon SQS for decoupling and buffering
• Amazon SNS or Amazon EventBridge for notifications and events
• Amazon DynamoDB for a highly scalable service-specific data store

The objective is not to use every available service. The architecture should select the simplest service that fits each component’s runtime, scaling, latency, and operational requirements.

Resilience and Operational Benefits

Separating an application into services can improve availability and deployment safety when each component is designed correctly. A service can be deployed across multiple Availability Zones, scaled independently, and replaced without taking the whole application offline.

However, microservices do not automatically create a resilient system. The architecture must still address:

• Retry behavior and timeouts
• Idempotency for repeated requests
• Service discovery and load balancing
• Failure isolation and cascading failures
• Data consistency between services
• Observability across distributed requests
• Authentication and authorization between services

Managed services such as Amazon ECS and AWS Lambda reduce infrastructure management, but application owners remain responsible for service design, configuration, and operational behavior.

Exam-Relevant Takeaways

• A VM includes a complete guest operating system; a container shares the host kernel.
• Containers generally start faster and use fewer resources than VMs, making them useful for elastic workloads.
• A Docker image is the packaged artifact; a container is a running instance of that image.
• Container images should be stored in a registry such as Amazon ECR or Docker Hub.
• Microservices are independently deployable components organized around business capabilities.
• Independent scaling is valuable when different application components receive different traffic levels.
• APIs and asynchronous messaging help reduce tight coupling between services.
• Amazon ECS can run Docker containers; AWS Lambda is an alternative for suitable event-driven functions.
• Microservices introduce distributed-systems complexity, including network failures, observability requirements, and data consistency challenges.
• Sharing the host kernel makes containers efficient, but it is also a fundamental difference from VM isolation.

Architecture Decision Guide

Requirement	Suitable direction	Reasoning
Package an application consistently across environments	Docker image	Bundles code and dependencies into a repeatable artifact
Run long-lived containerized services on AWS	Amazon ECS	Provides orchestration for deploying and managing containers
Run containers without managing the underlying servers	ECS with AWS Fargate	Uses a serverless container execution model
Run short-lived, event-driven code	AWS Lambda	Removes container and server management when the workload fits Lambda’s execution model
Decouple producers and consumers	Amazon SQS	Buffers messages and allows components to process work independently
Expose service endpoints to clients	Amazon API Gateway or an appropriate load balancer	Provides managed entry points for APIs and application traffic
Store data for a service with a managed NoSQL database	Amazon DynamoDB	Supports scalable, service-specific data storage when the access pattern fits
Share container images privately within AWS	Amazon ECR	Provides private image repositories and AWS integration

The choice between containers and Lambda depends on runtime requirements. Containers are appropriate when the application needs a custom runtime, long-running processes, specific operating-system packages, or more control over the execution environment. Lambda is often preferable for event-driven functions that can conform to its runtime, duration, and concurrency model.

Common Exam Traps

• Treating containers as full virtual machines: Containers do not normally contain an independent guest operating system.
• Assuming containers are automatically secure: Shared-kernel isolation does not eliminate the need for image scanning, least-privilege IAM, network controls, and host/runtime patching.
• Confusing an image with a container: The image is a versioned package; the container is the running workload created from it.
• Assuming microservices always improve an architecture: They can increase deployment and scaling flexibility, but they also add network calls, operational overhead, and distributed failure modes.
• Scaling the entire application for one busy component: A major benefit of microservices is independent scaling of services with different demand profiles.
• Using synchronous calls for every interaction: Queues and events can absorb bursts and reduce direct dependencies between services.
• Assuming managed orchestration eliminates application responsibility: ECS or Fargate manages parts of the infrastructure, but the architect must still design health checks, capacity, networking, security, and failure handling.
• Selecting Lambda solely because it is serverless: Lambda is not the best fit for every workload; custom runtimes, long-running processes, or container-specific requirements may favor ECS.

Real-World Engineer Notes

• Use immutable, versioned image tags or image digests for production deployments. Avoid relying on a mutable latest tag.
• Keep container images small to reduce deployment time, storage use, and cold-start or replacement overhead.
• Separate configuration and secrets from the image. Configuration should be injected through the deployment environment, and sensitive values should be managed with services such as AWS Secrets Manager or AWS Systems Manager Parameter Store.
• Design service APIs as contracts. Backward-compatible changes reduce coordination between independently deployed teams.
• Use timeouts, bounded retries, and circuit-breaking behavior to prevent one failing service from exhausting resources in its callers.
• Make message consumers and write operations idempotent because retries and duplicate delivery can occur in distributed systems.
• Use centralized logs, metrics, traces, and correlation identifiers. A request that crosses several services cannot be diagnosed reliably from isolated container logs.
• Match service boundaries to ownership and business capabilities, not merely to individual classes or small code modules.
• Consider the data boundary carefully. Independent services often benefit from owning their data, but cross-service reporting and transactions require deliberate patterns.

Quick Reference Summary

• Docker image: Immutable application package.
• Container: Running instance of an image.
• Container engine: Software that runs and isolates containers on a host.
• Shared kernel: The reason containers are generally lightweight and fast, and a key distinction from VMs.
• Microservice: Independently deployable application component organized around a business capability.
• Amazon ECS: AWS container orchestration service.
• AWS Fargate: Serverless compute option for running ECS tasks without managing container hosts.
• AWS Lambda: Event-driven compute option for suitable functions.
• API: Contract for synchronous service communication.
• Queue or event bus: Mechanism for asynchronous decoupling and workload buffering.

Flashcards

1. Q: What does a Docker image contain?

A: The application code, runtime dependencies, libraries, and configuration defaults needed to create a container.

1. Q: What is the difference between a Docker image and a container?

A: An image is the packaged artifact; a container is a running instance of that image.

1. Q: Why do containers usually start faster than virtual machines?

A: Containers share the host kernel and do not need to boot a separate guest operating system.

1. Q: What is the main resource-efficiency advantage of containers?

A: Multiple containers can share one host operating system instead of each carrying a full guest OS.

1. Q: What is a microservices architecture?

A: An architecture composed of independently deployable services aligned to business capabilities.

1. Q: Why is independent scaling useful in microservices?

A: Services with different traffic or resource requirements can scale separately, avoiding unnecessary scaling of the entire application.

1. Q: What mechanisms commonly connect microservices?

A: APIs for synchronous communication and queues or events for asynchronous communication.

1. Q: Which AWS service orchestrates Docker containers?

A: Amazon Elastic Container Service, or Amazon ECS.

1. Q: Which AWS service can run ECS containers without customer-managed servers?

A: AWS Fargate, used with ECS or Amazon EKS.

1. Q: What is a major operational risk introduced by microservices?

A: Distributed-systems complexity, including network failures, retries, observability, and data consistency challenges.

Practice Questions

Question 1

A company wants to deploy a web application as multiple independently scalable components. Each component must package its own libraries and runtime dependencies, and the company wants the same artifact promoted from testing to production. Which approach best meets these requirements?

A. Create a separate EC2 AMI for every application component.
B. Package each component as a Docker image and deploy the images as containers.
C. Install all components on one EC2 instance and scale the instance vertically.
D. Store each component’s source code in Amazon S3 and execute it directly.

Correct answer: B

Explanation: Docker images package application code and dependencies into portable, versioned artifacts. Each image can be deployed as an independently scalable container. AMIs package complete operating-system environments and are not the most direct fit for lightweight service packaging.

Question 2

A workload consists of customer, shopping-cart, authentication, and payment capabilities. The customer service receives substantially more traffic than the other components. An architect wants to deploy updates to the customer service without redeploying the rest of the application. Which design best supports these goals?

A. Deploy all capabilities in one container and scale the container as a unit.
B. Deploy each capability as an independently managed service with API-based communication.
C. Place each capability on a separate EC2 instance and require direct database access between them.
D. Use one Lambda function containing all application capabilities.

Correct answer: B

Explanation: Independently deployed microservices allow separate release cycles and scaling policies. APIs provide service contracts, while each component can scale according to its own demand.

Question 3

A team is migrating a containerized application to AWS. The team wants AWS to manage the underlying compute infrastructure while the application continues to run as long-lived Docker containers. Which option is most appropriate?

A. Amazon ECS using AWS Fargate
B. Amazon S3 static website hosting
C. Amazon DynamoDB Streams
D. Amazon CloudFront without an origin

Correct answer: A

Explanation: ECS manages container deployment and orchestration, while Fargate provides a serverless execution model that avoids managing the underlying container hosts. The other options do not provide general-purpose execution for long-running containers.

Question 4

A microservice calls another service synchronously. During traffic spikes, the downstream service becomes overloaded and requests begin timing out, causing failures to propagate back through the application. Which change most directly reduces this coupling for work that does not require an immediate response?

A. Increase the size of every EC2 instance.
B. Put an Amazon SQS queue between the services.
C. Store all service data in one shared database schema.
D. Package both services into the same container.

Correct answer: B

Explanation: An SQS queue buffers work and allows the producer and consumer to scale and fail independently. The consumer can process messages at its own rate, reducing the risk of synchronous overload propagation.

Question 5

An architect claims that moving an application from VMs to containers guarantees stronger isolation and eliminates the need to patch the operating system. Which response is most accurate?

A. Correct, because every container includes a separate operating system.
B. Correct, because the container image replaces all host security responsibilities.
C. Incorrect, because containers share the host kernel and still require secure image, runtime, and host management.
D. Incorrect, because containers cannot isolate application processes.

Correct answer: C

Explanation: Containers provide process-level isolation while sharing the host kernel. This improves efficiency but does not remove host, runtime, image, dependency, or configuration security responsibilities.