Containers on AWS: a quick guide



Containerisation allows development teams to move quickly and deploy more efficiently


Instead of virtualising the hardware stack (as you would with virtual machines), containers run on top of the OS kernel, virtualising at the OS level.

Here are the most popular container formats available:




In 2010, a company known as Docker helped transform cloud containerisation. This new way of architecting paved the way for the DevOps movement. But what made containers so popular? Thanks to the huge improvements in virtualisation and the rapid increase of cloud computing, containers can allow for isolated workloads based on an OS, exposing and accessing only what is necessary.

Within just a few years, Amazon Elastic Container Service (ECS) was introduced in November 13, 2014 and was the primary way to run containers in the public cloud. ECS is a container management service that allows you to run Docker containers on a cluster.




Google released Kubernetes in June 2014, which was later released to the Cloud Native Computing Foundation (CNCF) community the following year. The Google Cloud Platform and Microsoft Azure were early adopters to Kubernetes, but with GCP being the only public cloud provider to have a working service called Google Kubernetes Engine (GKE). GKE was launched in 2015 and Azure Kubernetes Service (AKS) was released in the Fall of 2017 into preview mode.



Amazon EKS

Amazon Elastic Container Service for Kubernetes (EKS) is a fully managed service that makes it easy for you to use kubernetes on EKS runs upstream Kubernetes so you can connect to it with kubectl just like a self managed Kubernetes. AWS Introduced EKS at re:Invent 2017 and claims to upstream Kubernetes by using countless AWS growing services.



AWS Fargate

AWS has a hidden service that neither GCP or Azure have. AWS Fargate is a new service for running containers without needing to manage the underlying infrastructure. Fargate supports ECS and EKS but is also often closely compared with Lambda. You pay per computing second used without having to worry about the EC2 instances.

Managing Kubernetes can be complicated and usually requires a deep understanding of how to schedule, manage your masters, pods, services, and additional orchestration of architecture on top of the virtualisation that was already abstracted from you.

Fargate takes all of this away by streamlining deployments. The game-changer is that you do not need to start with Fargate, but that you can use EKS or ECS then migrate your workloads to Fargate when your program has matured further.





KOPS was the go to method of deploying Kubernetes on ECS via EC2 instances or on EC2 instances. KOPS is an open sourced project that makes running kubernetes easy. KOPS is built using EC2 instances. KOPS provides a multitude of controls on deployments and good support for high availability.


Containers are not just a hype, but they could be the future for at least the next few years. With AWS finally joining the Kubernetes club, and Fargate being a strong game-changer, anything is possible. However, there is is still a lot of unanswered questions that we hope will be addressed.

EKS and Fargate are currently limited in Ohio and Virginia regions, but you should see a big push to use these services as more regions get rolled out.


What do we do in the meantime? I’m reminded of this quote:


“All we have to decide is what to do with the time that is given us.”


Until then, I believe KOPS will be the best method to use.


What containers do you use on AWS and are you waiting to explore with AWS EKS or Fargate? Let us know by contacting us here.

Check also my previous blog post on Container security here


Get in Touch.

Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.

    Container security: How to differ from the traditional



    Containerisation in the industry is rapidly evolving


    No, not shipping containers, but cloud containers. Fortune 500 organisations all use containers because they provide portability, simple scalability, and isolation. Linux distros have long been used, but this has since changed. Microsoft has now started to support Windows-based containers with Windows Server 2016 running on Windows Core or Nano. Even with a lot of organisations using containers, we are still seeing a lot of them reverting back to how security was for traditional VMs.


    If you already know anything about containers, then you probably know about Kubernetes, Docker, Mesos, CoreOS, but security measures still need to be carried out and therefore this is always a good topic for discussion.



    Hardened container image security

    Hardened container image security comes to mind first, because of how the image is deployed and if there are any vulnerabilities in the base image. A best practice would be to create a custom container image so that your organization knows exactly what is being deployed.

    Developers or software vendors should know every library installed and the vulnerabilities of those libraries. There is a lot of them, but try to focus on the host OScontainer dependencies, and most of all the application code. Application code is one of the biggest vulnerabilities, but practising DevOps can help prevent this. Reviewing your code for security vulnerabilities before committing it into production can cost time, but save you a lot of money if best practices are followed. It is also a good idea to keep an RSS feed on security blogs like Google Project Zero Team and  Fuzz Testing to find vulnerabilities.

    Infrastructure security

    Infrastructure security is a broad subject because it means identity management, logging, networking, and encryption.

    Controlling access to resources should be at the top of everyone’s list. Following the best practice of providing the least privileges is key to a traditional approach. Role-Based Access Control (RBAC) is one of the most common methods used. RBAC is used to restrict system access to only authorized users. The traditional method was to provide access to a wide range of security policies but now fine-tuned roles can be used.

    Logging onto the infrastructure layers is a must needed best practice. Audit logging using an API cloud vendor services such as AWS CloudWatchAWS CloudTrailsAzure OMS, and Google Stackdriver will allow you to measure trends and find abnormal behaviour.

    Networking is commonly overlooked because it is sometimes referred to as the magic unicorn. Understanding how traffic is flowing in and out of the containers is where the need for security truly starts. Networking theories make this complicated, but understanding the underlying tools like firewalls, proxy, and other cloud-enabled services like Security Groups can redirect or define the traffic to the correct endpoints. With Kubernetes, private clusters can be used to send traffic securely.

    How does the container store secrets? This is a question that your organization should ask when encrypting data at rest or throughout the OSI model.


    Runtime security

    Runtime security is often overlooked, but making sure that a team can detect and respond to security threats whilst running inside a container shouldn’t be overlooked. The should monitor abnormal behaviours like network calls, API calls, and even login attempts. If a threat is detected, what are the mitigation steps for that pod? Isolate the container on a different network, restarting it, or stopping it until the threat can be identified are all ways to mitigate if a threat is detected. Another overlooked runtime security is OS logging. Keeping the logs secured inside an encrypted read-only directory will limit tampering, but of course, someone will still have to sift through the logs looking for any abnormal behaviour.

    Whenever security is discussed an image like the one shown above is commonly depicted. When it comes to security, it is ultimately the organization’s responsibility to keep the Application, Data, Identity, and Access Control secured. Cloud Providers do not prevent malicious attackers from attacking the application or the data. If untrusted libraries or access is misconfigured inside or around the containers then everything falls back on the organization.

     Check also my blog post Containers on AWS: a quick guide

    Get in Touch.

    Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.