A container is a running instance of a container image: a packaged application filesystem with dependencies and execution metadata. Unlike a virtual machine, a typical container does not boot its own operating-system kernel. Instead, the container runtime uses host operating-system isolation mechanisms to separate processes, filesystems, and resource consumption. On Linux, namespaces provide isolation and control groups govern resources. This shared-kernel model generally allows containers to start quickly and use fewer resources than separate virtual machines.
Images make application delivery repeatable. For example, a team can build an image containing a web API and its required libraries, test it in a pipeline, publish it to a registry, and deploy the same image to production. Portability still has limits: the image must match the supported operating system and processor architecture, and the application may depend on external networking, storage, or cloud APIs. A container image is not the same as an Amazon Machine Image, or AMI. An AMI supplies an EC2 instance's operating-system environment; a container image supplies the application environment executed by a container runtime.
Cloud deployments normally combine a registry, an orchestrator, and compute capacity. The registry stores images, while the orchestrator schedules workloads, maintains the desired number of replicas, and coordinates updates and recovery. Amazon ECS is an AWS-native container orchestration option. Amazon EKS provides managed Kubernetes for teams that need Kubernetes APIs, tooling, or ecosystem integrations. AWS Fargate supplies managed compute for supported ECS and EKS workloads, removing the need to administer the underlying worker instances. ECS and EKS can also use EC2 capacity when workloads require greater host control or particular instance capabilities.
Choose containers for independently deployable APIs, background workers, batch jobs, or applications with conflicting dependency requirements. For example, an API service can scale separately from a queue-processing worker even when both use the same application image with different startup commands. Containers do not automatically make an application stateless: data in a container's writable layer is normally lost when that container is removed. Put durable data in an appropriate database, object store, or persistent volume, and design applications to tolerate replacement.
Image hardening begins during the build. Use maintained, minimal base images, remove unnecessary packages and build tools, install security updates, and run the application as a non-root user where supported. Use multistage builds to keep compilation dependencies out of the final image. Never bake credentials into image layers; deleting a secret in a later layer does not remove it from earlier layers. Scan operating-system packages and application dependencies, verify image provenance, and deploy approved images by digest to identify exact artifacts. A clean vulnerability scan is not proof that an image is secure.
Runtime controls are equally important. Avoid privileged containers and unnecessary host mounts, drop unneeded Linux capabilities, restrict network access, set CPU and memory limits, and use read-only root filesystems where practical. Give each workload narrowly scoped permissions rather than broad access through the host's identity. Because ordinary containers share a kernel, they are not equivalent to virtual machines as a security boundary. Stronger isolation may be necessary for mutually untrusted workloads.
For EC2-backed container hosts, harden the AMI, restrict administrative access, and maintain the kernel, runtime, and host agents. EC2 Image Builder can automate creation and testing of hardened AMIs and container images. AWS Systems Manager can support configuration, controlled administrative access, and patching of managed EC2 hosts; it does not replace rebuilding vulnerable application images. Patch container dependencies by rebuilding, testing, and redeploying images rather than manually changing running containers. Managed compute reduces host administration, but customers still remain responsible for their application code, images, permissions, and workload configuration.
AWS Fargate
AWS Systems Manager