AWS re:Invent 2019 which concluded last week marked another milestone for Amazon and the cloud computing ecosystem. Some of the new AWS services announced this year will become the foundation for upcoming products and services.

Though there have been many surprises, AWS didn’t mention or announce some of the services that were expected by the community. My own predictions for AWS re:Invent 2019 were partially accurate.

Based on the wishlist and what was expected, here is a list of hits and misses from this year’s mega cloud event:

Hits of AWS re:Invent 2019

1) Quantum Computing Delivered through Amazon Braket

Today In: Innovation
After IBM, Microsoft, and Google, it was Amazon’s turn to jump the quantum computing bandwagon.

Amazon Braket is a managed service for quantum computing that provides a development environment to explore and design quantum algorithms, test them on simulated quantum computers, and run them on different quantum hardware technologies.

PROMOTED

Grads of Life BRANDVOICE
| Paid Program
5 Myths About High School Interns (And Why You Should Hire Them)
Google Cloud BRANDVOICE
| Paid Program
5 Ways To Secure Your Business In A Multi-Cloud World
UNICEF USA BRANDVOICE
| Paid Program
Fleeing Violence In Guatemala, A Young Family Yearns For Safety
This new service from Amazon lets customers use both quantum and classical tasks on a hybrid infrastructure. It is tightly integrated with existing AWS services such as S3 and CloudWatch.

Amazon Braket has the potential to become one of the key pillars of AWS compute services.

2) Leveraging Project Nitro

Project Nitro is a collection of hardware accelerators that offload hypervisor, storage, and network to custom chips freeing up resources on EC2 to deliver the best performance.

Amazon has started to launch additional EC2 instance types based on custom chips powered by the Nitro System. The Inf1 family of EC2 delivers the best of the breed hardware and software combination to accelerate machine learning model inferencing.

Along with Nitro, Amazon is also investing in ARM-based compute resources. Amazon EC2 now offers general purpose (M6g), compute optimized (C6g), and memory optimized (R6g) Amazon instances powered by AWS Graviton2 processor that use 64-bit Arm Neoverse cores and custom silicon designed by AWS.

Going forward, Amazon will launch additional instance types based on Graviton2 processors that will become cheaper alternatives to Intel x64-based instance types.

3) Augmented AI with Human in the Loop

Remember Amazon Mechanical Turk (MTurk)? A crowdsourced service that delegates jobs to real humans. Based on the learnings from applying automation to retail, Amazon encourages keeping the human in the loop.

More recently, Amazon launched SageMaker Ground Truth – the data labeling service powered by humans. Customers can upload raw datasets and have humans draw bounding boxes around specific objects identified in the images. This increases accuracy while training machine learning models.

With Amazon Augmented AI (Amazon A2I), AWS now introduces human-driven validation of machine learning models. The low-confidence predictions from an augmented AI model are sent to real humans for validation. This increases the precision and accuracy of models while performing predictions from an ML model.

Amazon continues to bring humans into the technology-driven automation loop.

4) AI-driven Code Review and Profiling through Amazon CodeGuru

Amazon CodeGuru is a managed service that helps developers proactively improve code quality and application performance through AI-driven recommendations. The service comes with a reviewer and profiler that can detect and identify issues in code. Amazon CodeGuru can review and profile Java code targeting the Java Virtual Machine.

This service was expected to come from a platform and tools vendor. Given the heritage of developer tools, I was expecting this from Microsoft. But Amazon has taken a lead in infusing AI into code review and analysis.

CodeGuru is one of my favorite announcements from AWS re:Invent 2019.

5) Decentralized Cloud Infrastructure – Local Zones and AWS Wavelength

When the competition is caught up in expanding the footprint of data centers through traditional regions and zones, Amazon has taken an unconventional approach of setting up mini data centers in each metro.

The partnership with Verizon and other telecom providers is a great move from AWS.

Both, Local Zones and AWS Wavelength are game-changers from Amazon. They redefine edge computing by providing a continuum of compute services.

Bonus: AWS DeepComposer

Having launched DeepLens in 2017 and DeepRacer in 2018, I was curious to see how AWS mixes and matches its deep learning research with a hardware-based, educational device.

AWS DeepComposer brings the power of Generative Adversarial Networks (GAN) to music composition.

Misses of AWS re:Invent 2019

1) Open Source Strategy

Open source was conspicuously missing from the keynotes at re:Invent. With a veteran like Adrian Cockroft leading the open source efforts, I was expecting Amazon to make a significant announcement related to OSS.

Amazon has many internal projects which are good candidates for open source. From machine learning to compute infrastructure, AWS has many on-going research efforts. Open sourcing a tiny subset of these projects could immensely benefit the community.

The only open source project that was talked about was Firecracker which was announced last year. Even for that, Amazon didn’t mention handing it over to a governing body to drive broader contribution and participation of the community.

The industry expects Amazon to actively participate in open source initiatives.

2) Container Strategy

Containers are the building blocks of modern infrastructure. They are becoming the de facto standard to build modern, cloud native applications.

With Amazon claiming that 80% of all containerized and Kubernetes applications running in the cloud run on AWS, I expect a streamlined developer experience of deploying containerized workloads on AWS.

The current developer experience of dealing with AWS container services such as ECS, Fargate and EKS leaves a lot to be desired.

The only significant announcement from re:Invent 2019 related to containers was the general availability of the serveless container platform based on EKS for Fargate. Based on my personal experience, I found the service to be complex.

Both Microsoft and Google score high on the innovation of containerized platforms and enhancing the developer experience.

AWS has work to do in simplifying the developer workflow when dealing with containerized workloads.

3) VMware Partnership

Surprisingly, there was no discussion on the roadmap, growth and adoption of VMware Cloud on AWS. While the focus shifted to AWS Outposts, there has been no mention of the upcoming AWS managed services on VMware.

Though AWS Outposts are available on vSphere, the GA announcement had little to no mention of Outposts on VMware.

4) Simplified Developer Experience

AWS now has multiple compute services in the form of EC2 (IaaS), Beanstalk (PaaS), Lambda (FaaS) and Container Services offered through ECS, Fargate and EKS (CaaS).

Amazon recommends using a variety of tools to manage the lifecycle of the infrastructure and applications. Customers use CloudFormation, Kubernetes YAML, Cloud Developer Kit (CDK) and Serverless Application Model (SAM) to deal with each of the workloads running in different compute environments.

The current deployment model and programmability aspects of AWS are becoming increasingly complex. There is a need to simplify the developer and admin experience of AWS.

I was expecting a new programmability model from Amazon that would make it easier for developers to target AWS for running their workloads.

5) Custom AutoML Models for Offline Usage

Though AWS launched SageMaker Autopilot and Rekognition Custom Labels in the AutoML domain, it didn’t mention about enhancing AutoML-based language services for newer verticals and domains.

Custom models trained through Amazon’s AutoML services cannot be exported for offline usage in disconnected scenarios such as industrial automation. None of the services are integrated with AWS Greengrass deployments for offline inferencing.

Both Google and Microsoft offer exporting AutoML models optimized for the edge.

Amazon Comprehend service could be easily expanded to support newer verticals and domains such as legal and finance through AutoML.

Though the above announcements and services didn’t make it to this year’s re:Invent, I am sure they are in the roadmap.

Why Containers Originally Struggled with Persistent Storage

Containers are ephemeral by design. When a container process ends, its writable layer is discarded. This made containers excellent for stateless services but unsuitable for workloads that need to survive restarts or be shared across multiple container instances. Kubernetes addresses this by externalising storage from the pod lifecycle entirely.

The Two High-Level Tasks for Persistent Kubernetes Storage

To use persistent storage in Kubernetes you need to accomplish two things:

1. Attach a physical (or cloud) storage device to the Kubernetes cluster. This is done through a storage driver, ideally via the Container Storage Interface (CSI).
2. Grant the application access to that storage. This is done through Kubernetes storage objects — PersistentVolumes, PersistentVolumeClaims, and StorageClasses.

The Container Storage Interface (CSI)

The Container Storage Interface (CSI) is the standard mechanism for connecting an external storage system to a Kubernetes cluster. Before CSI existed, storage drivers had to be compiled directly into the Kubernetes codebase, which made adding or updating drivers slow and risky. CSI decouples storage drivers from the core Kubernetes binary, allowing storage vendors to ship and update drivers independently. CSI drivers are deployed as pods inside the cluster and communicate with the Kubernetes control plane through a well-defined API. Beyond flexibility, CSI also provides a consistent security boundary between the storage backend and the orchestrator.

PersistentVolumes (PVs)

A PersistentVolume (PV) is a cluster-level storage resource that exists independently of any pod. Think of it like a pre-provisioned virtual hard disk: it has a defined capacity, a filesystem, a name, and an access mode (e.g. ReadWriteOnce, ReadOnlyMany, or ReadWriteMany). Critically, its lifecycle is not tied to any pod. You can delete the pod that was using a PV and the PV — along with the data on it — remains intact until an administrator explicitly removes it.

PVs can be created in two ways:

• Static provisioning: An administrator manually creates PV objects in the cluster ahead of time.
• Dynamic provisioning: Kubernetes creates PVs on demand in response to a PersistentVolumeClaim, using a StorageClass to determine how to provision the backing storage.

PersistentVolumeClaims (PVCs)

A newly created PV is an isolated object — it is not attached to any pod or workload. The bridge between a pod and a PV is a PersistentVolumeClaim (PVC).

A PVC is a request for storage made by a namespace. It specifies the desired capacity, access mode, and optionally a StorageClass. Kubernetes matches the claim to a suitable PV (or dynamically provisions one) and binds them together. The pod then mounts the PVC as a volume, gaining access to the underlying storage.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard

Once bound, the PVC is referenced inside a pod’s volume specification:

volumes:
  - name: app-storage
    persistentVolumeClaim:
      claimName: my-app-pvc

StorageClasses

When you need many application instances, each requiring its own persistent storage, manually creating PVs and PVCs for every instance becomes unmanageable. A StorageClass solves this by defining a template for dynamic volume provisioning.

A StorageClass tells Kubernetes how to provision storage: which CSI driver to use, what parameters to pass (disk type, replication factor, IOPS tier, etc.), and what reclaim policy to apply when a PVC is deleted. When a PVC references a StorageClass, Kubernetes automatically creates a matching PV using that class’s provisioner — no administrator intervention required.

A StorageClass also serves as an organisational tool. You can define multiple classes — for example, fast-ssd for latency-sensitive databases and standard-hdd for bulk data — and let application teams choose the appropriate tier via their PVC definition.

How the Pieces Fit Together

The flow for dynamic provisioning looks like this:

1. An administrator defines one or more StorageClasses, each backed by a CSI driver.
2. A developer (or automated deployment tool) creates a PersistentVolumeClaim referencing the desired StorageClass and capacity.
3. Kubernetes dynamically provisions a PersistentVolume via the CSI driver and binds it to the PVC.
4. The pod mounts the PVC as a volume and the application reads/writes data normally.
5. When the pod is deleted, the PV and its data survive. The reclaim policy on the StorageClass determines what happens to the PV when the PVC itself is deleted (typically Retain or Delete).

Key Concepts at a Glance

Further Reading

The official Kubernetes documentation on persistent volumes covers access modes, reclaim policies, volume binding modes, and topology constraints in detail and is the authoritative reference for production use.

What Is LXC?

LXC, short for Linux Containers, is an OS-level virtualization mechanism that lets you run multiple isolated Linux environments on a single host kernel. Each container shares the host kernel but has its own filesystem, process tree, network stack, and user space. LXC achieves this isolation through two core Linux kernel features:

• cgroups (control groups) — introduced in Linux kernel 2.6.24, cgroups allow fine-grained allocation and accounting of CPU, memory, block I/O, and network resources across process groups.
• namespaces — namespaces partition global kernel resources so that each container sees its own isolated view of the system (PID namespace, network namespace, mount namespace, etc.).

An LXC container behaves much like a lightweight virtual machine: it runs a full Linux user space, including an init process, and can host multiple services simultaneously. This makes LXC well-suited for scenarios where you want strong process isolation and a full OS environment without the overhead of hardware emulation.

What Is Docker?

Docker began as an internal project at PaaS company dotCloud and was open-sourced in 2013. In its early versions, Docker’s runtime was built directly on top of LXC. Over time Docker replaced LXC with its own container runtime (libcontainer, now part of runc and the broader OCI ecosystem), but it continues to rely on the same underlying kernel features—cgroups and namespaces.

Docker’s core daemon and CLI tools are written in Go. The key design philosophy that differentiates Docker from raw LXC is the single-process-per-container model: each container is expected to run one primary process (a web server, a database, a worker), making containers highly composable and easy to reason about.

Containers vs. Virtual Machines: A Quick Baseline

Both LXC and Docker are container technologies, so it helps to first distinguish containers from full virtual machines (VMs):

Because containers skip hardware emulation entirely, they start faster and consume fewer resources than VMs. The trade-off is that all containers share the host kernel, so a kernel vulnerability or misconfiguration affects all tenants on that host.

Core Differences Between LXC and Docker

1. Design Philosophy

LXC targets system containers: a container is meant to mimic a complete Linux OS instance. You can SSH into it, run multiple daemons (cron, syslog, your application), and manage it much like a traditional server. This makes LXC a close analogue to a lightweight VM.

Docker targets application containers: a container packages exactly one application process and its dependencies. This constraint encourages microservice-style architectures where each container does one thing well and can be scaled, replaced, or updated independently.

2. Image Layering and Portability

Docker introduced a layered, copy-on-write image format. Each instruction in a Dockerfile produces an immutable layer; layers are cached and reused across builds and deployments. This means:

• Images are content-addressed and reproducible.
• Pushing or pulling an image only transfers changed layers, saving bandwidth.
• Any host with a compliant OCI runtime can run the same image without reconfiguration.

LXC does not have a standardized image format in the same sense. Container templates exist, but moving a running LXC environment between hosts requires more manual effort.

3. Versioning and Rollback

Because Docker images are immutable and layered, versioning is built in. You tag images, push them to a registry, and roll back to a previous tag if a release introduces a regression. LXC containers are more like live systems—they accumulate changes over time, which makes disciplined rollback harder without additional tooling.

4. Ecosystem and Tooling

Docker benefits from a large ecosystem: Docker Hub provides hundreds of thousands of pre-built images; Docker Compose orchestrates multi-container applications locally; Kubernetes (and other orchestrators) natively speak the OCI image and container runtime standards that Docker helped define.

LXC’s ecosystem is smaller and more Linux-distribution-centric. LXD (the daemon layer maintained by Canonical that sits on top of LXC) improves the management story considerably, adding REST APIs, clustering, and a richer image server, but LXC/LXD remains less widely adopted in CI/CD pipelines compared to Docker.

5. Networking and Resource Management

Both LXC and Docker use kernel namespaces for network isolation and cgroups for resource limits. Docker’s higher-level networking model (bridge networks, overlay networks, user-defined networks) abstracts away much of the low-level configuration. LXC gives you more direct control, but that control comes with more configuration responsibility.

6. Access via Libvirt

LXC can optionally be managed through libvirt using its LXC driver (connect string: lxc:///). This lets you manage LXC containers alongside QEMU/KVM VMs through a unified API. Libvirt-managed LXC and native LXC are not fully interchangeable, so choose your management path early and stay consistent.

Side-by-Side Comparison

When to Choose LXC

• You need a full Linux OS environment inside a container (systemd, multiple services, SSH daemon).
• You are migrating traditional server workloads to containers incrementally and want minimal application changes.
• You need fine-grained control over container resources without an additional abstraction layer.
• You are already using libvirt and want a unified management plane for VMs and containers.

When to Choose Docker

• You are building or deploying microservices or twelve-factor applications.
• You need reproducible, versioned, portable application packages that run identically in dev, staging, and production.
• You want to integrate with a Kubernetes-based or CI/CD pipeline ecosystem.
• You want access to the large library of pre-built images on public registries.

Summary

LXC and Docker are complementary rather than strictly competing technologies. LXC excels when you need a container that behaves like a lightweight, full-featured Linux system. Docker excels when you need fast, portable, versioned application packaging with broad ecosystem support. For most modern cloud-native and DevOps workflows, Docker (or the broader OCI runtime ecosystem it spawned) is the pragmatic default. For workloads that demand full OS-level isolation without the overhead of a hypervisor, LXC—especially when managed via LXD—remains a compelling option.

Understanding both tools makes you a more versatile infrastructure engineer, since production environments frequently use VMs, LXC-style system containers, and Docker application containers in combination.

The core challenge is virtual-to-resource mapping: the framework required to connect hosted software components to real underlying infrastructure. Security tools designed for physical devices were not built with virtual functions in mind, and that gap is where most cloud-VM security incidents originate.

The good news is that meaningful risk reduction is achievable through an incremental, structured approach. The four steps below address the most critical attack surfaces in cloud-virtual environments.

Step 1: Protect Hosted Elements by Segregating Them

The first and most foundational step is network isolation. Any virtual function or hosted component that does not need to be directly reachable by end users should live inside a private subnetwork with no publicly routable addresses.

Consider a simple example: three features hosted inside a virtual edge device can be deployed either directly on the service data plane (addresses visible to all network users) or inside a private subnetwork (invisible from outside). If you deploy them on the public data plane, any of those features can be probed, enumerated and attacked. Hosting and management processes also become visible and vulnerable. Isolating them behind a private subnetwork removes that exposure entirely.

This is already standard practice in container-based deployments, both on-premises and in the cloud. Application components run inside private subnetworks, and only the specific API endpoints that users are intended to reach are exposed. The same discipline must be applied to Virtual Network Functions (VNFs): expose only the user-facing interfaces, and protect everything else with non-routable, access-controlled addresses.

Practical actions

• Deploy all internal VNF components into private subnets or VPCs with no public IP assignment.
• Use security groups or firewall rules to allow inbound traffic only on explicitly required ports and from defined sources.
• Apply micro-segmentation so that compromising one hosted component does not grant lateral access to others.

Step 2: Test and Review All Components Before Deployment

External attacks get most of the attention, but an insider threat or a deliberately introduced back-door vulnerability in a hosted feature is often more dangerous. Once a compromised component is deployed into service infrastructure, it becomes a trusted insider with open pathways to other infrastructure elements.

Private subnetworks help here too. If a new component can only communicate with other components inside the same service instance, a piece of malware introduced through a back-door fault is less likely to pivot to other services or affect other tenants. The blast radius is contained.

However, containment is not a substitute for proper security testing. Operators must enforce a rigorous lifecycle management and compliance process for every hosted feature and function. This means:

• Requiring vendors and suppliers to demonstrate that all new code undergoes formal security testing before release.
• Establishing an auditable compliance workflow that operators can independently validate — not just a vendor’s self-attestation.
• Treating third-party VNF code with the same scrutiny applied to any external dependency entering a production environment.
• Performing static analysis, dynamic testing and, where possible, independent penetration testing of new virtual functions before they are admitted to the service plane.

A well-designed compliance pipeline reduces the probability of both accidental vulnerabilities and deliberately seeded back-door faults making it into production.

Step 3: Separate Management APIs from the Service Plane

Management and orchestration APIs are inherently high-value targets because they control features, functions and service behaviour at a fundamental level. Exposing infrastructure management APIs to the same network plane as service traffic — or failing to isolate them from VNF management paths — creates a direct route to catastrophic compromise.

In NFV (Network Functions Virtualization) architectures, the Virtual Network Functions Manager (VNFM) — as defined by the ETSI NFV Industry Specification Group — is a particularly critical component. The VNFM is typically supplied by the VNF vendor and requires access to both infrastructure APIs and orchestration or deployment tooling. Poor design in this component can inadvertently open a gateway between user-accessible service paths and privileged infrastructure management APIs.

Securing this layer requires the following:

• Require VNF providers to submit their VNFM architecture — particularly the connections it makes to infrastructure and deployment/management APIs — for formal review before deployment.
• Enforce the principle that no service user, VNF, or VNFM associated with one service can access the infrastructure management API of another.
• Place management and orchestration APIs on a dedicated, isolated management network that is completely unreachable from the service data plane.
• Log all access to infrastructure management and orchestration APIs. Implement alerting for any unexpected access patterns or configuration changes, and review logs regularly to detect management access leaks early.

Step 4: Keep Virtual Network Connections Secure and Tenant-Isolated

Virtual networking provides agile, software-defined connectivity that can be reconfigured rapidly as features scale or redeploy. That flexibility is also a security liability: every time a virtual network change is made, there is a risk of creating an inadvertent cross-tenant or cross-service connection.

These misconfigurations can cause three categories of harm:

• Data plane leaks — traffic from one tenant’s user network becomes visible to another.
• Control plane leaks — one tenant’s management traffic bleeds into another service’s control path.
• Influence attacks — one user gains the ability to affect the service behaviour experienced by another user.

Strict policies and change-control processes around virtual connectivity significantly reduce the probability of these errors, but they cannot eliminate it entirely. The indirect relationship between a virtual network (which connects software features) and the underlying physical network (which carries actual user traffic) makes it easy for a misconfiguration to go undetected.

A practical mitigation is to integrate a network scanner or inventory verification tool as the final step of every virtual network change procedure. The tool should:

• Enumerate all devices and virtual devices currently visible on the virtual network.
• Compare that inventory against the expected service topology.
• Fail the change and trigger an alert if any unexpected connections or devices are detected.

Automated topology validation closes the gap between the logical configuration an operator intends and the actual network state that exists.

Summary: Four Steps for Cloud VM Security

Cloud-virtual networking is not simply traditional networking with a new label. It introduces an entirely different threat model — one that cannot be addressed by tools and practices designed for the era of purely physical network devices. Operators who treat these environments with the same security discipline they apply to physical infrastructure, while adding controls specific to the virtual layer, are best positioned to contain risk as cloud-native and NFV-based architectures continue to mature.

This article is based on a technical overview originally published by TechTarget SearchSecurity.