AWS Certified CloudOps Engineer - Associate (SOA-C03) #9 Domain 3-3 Deployment — Container Operations (ECS, EKS, ECR)
In #7 and #8 we covered infrastructure deployment and instance operations. This post is about container operations, newly added in SOA-C03. The old SOA-C02 had almost no container scope, but with the rename to CloudOps Engineer, ECS,EKS,ECR entered the exam scope. The exam asks not “how do you build containers” but “how do you operate them” (deployment, logging, scaling, image management).
ECS vs EKS: Which One Do You Choose #
| Item | ECS | EKS |
|---|---|---|
| Nature | AWS’s own container orchestrator | Managed Kubernetes |
| Learning curve | Low. Deeply integrated with AWS | High. The K8s ecosystem |
| When | Simply, within AWS | K8s standard,multi-cloud,existing K8s assets |
The core distinction is simple. If there is no compelling reason to need K8s (standard compatibility, existing assets, multi-cloud), choose ECS; if you must use the K8s ecosystem, choose EKS. When the requirement is to minimize operational burden, ECS is generally the answer, and especially so when paired with Fargate.
Launch Type: Fargate vs EC2 #
Both ECS and EKS require you to choose the compute that actually runs the containers.
| Type | Who manages the servers | When |
|---|---|---|
| Fargate | AWS (serverless). No instance management | Minimize operational burden, variable load |
| EC2 | You manage the instances | Fine-grained control,special instances,cost optimization |
“Run containers but don’t want to worry about patching and scaling instances” points to Fargate. Conversely, if you need GPUs or a specific instance type, or if utilization is high enough that EC2 is cheaper, that’s the EC2 launch type.
ECR: The Image Registry #
ECR is a private registry that stores container images. The operational points are as follows.
- Image scanning: Vulnerability (CVE) scanning on push or continuously. A staple of security operations
- Lifecycle policies: Automatically clean up old,unused images to manage storage cost
- Permissions: Control access with IAM and repository policies. Cross-account sharing is possible
- Replication: Cross-region,cross-account replication to shorten deployment latency and for DR
“Catch vulnerabilities in container images before deployment” points to ECR image scanning. “Images keep piling up and costs are rising” points to lifecycle policies.
Container Logging and Monitoring #
The CloudWatch concepts from #2 and #3 carry straight over to containers.
| Target | Operational method |
|---|---|
| Logs | ECS sends logs to CloudWatch Logs via the awslogs log driver. FireLens (FluentBit) enables other targets too |
| Metrics | Container Insights collects container metrics such as CPU,memory,task count |
| Tracing | Distributed tracing with X-Ray |
Container Insights is the key service in container monitoring. “See container-level performance for ECS and EKS at a glance” points to Container Insights. Basic EC2 metrics alone cannot see inside containers.
Deployment and Scaling Operations #
- Rolling update: Gradually replace tasks. The default deployment method
- Blue/green (CodeDeploy integration): Stand up the new version separately and switch over. Fast rollback
- Service Auto Scaling: Automatically adjust the task count based on metrics (CPU,request count)
- Task definition: Declares the container image,CPU,memory,environment variables,IAM role (task role)
One operational security point is the task role (Task Role). It’s the permission a container uses when it calls AWS APIs, and the proper practice is to grant least privilege per task, not via the EC2 instance role.
Exam Question Patterns #
- K8s isn’t strictly required and you want minimal operational burden → ECS + Fargate
- Run containers without instance management → Fargate
- Detect image vulnerabilities before deployment → ECR image scanning
- Costs rising from unused images → ECR lifecycle policies
- Container-level performance monitoring → Container Insights
- A container calls AWS APIs → task role (least privilege)
- A deployment that needs fast rollback → blue/green (CodeDeploy)
Common Pitfalls #
1) Thinking EC2 metrics let you see containers #
Basic EC2 metrics only see the whole instance. Container,task-level visibility requires Container Insights.
2) Granting container permissions via the instance role #
When multiple tasks share one instance, the instance role becomes excessive permission. Grant per-task least privilege with the task role.
3) Choosing the EC2 launch type when minimizing operational burden #
With no special reason, the answer for minimizing operational burden is Fargate.
4) Assuming logs go to CloudWatch automatically #
ECS sends logs to CloudWatch Logs only with a log driver (awslogs) or FireLens configuration.
Summary #
What we covered in this post:
- ECS (AWS-native, simple) vs EKS (managed K8s). No special reason, ECS
- Fargate (serverless, minimal operational burden) vs EC2 launch type (fine-grained control, cost). For minimal operational burden, Fargate
- ECR: image scanning (vulnerabilities), lifecycle policies (cost), cross-region replication
- Container-level metrics with Container Insights, logs with
awslogs, FireLens - Per-container least privilege with the task role. Don’t grant it via the instance role
Next: Domain 4-1 VPC Operations and Troubleshooting #
We’ve finished the deployment and automation domain. Next is the fourth domain, networking and content delivery.
In #10 Domain 4-1 Networking: VPC Operations and Connectivity Troubleshooting, I’ll cover route tables and gateways, the difference between security groups and NACLs, VPC peering and endpoints, and where to check and in what order when connectivity fails.