Introduction
In 2025, COBOL is still a critical part of global enterprise operations. Despite being developed over 60 years ago, COBOL continues to power essential systems in finance, government, healthcare, and telecommunications. For many organizations, rewriting COBOL code is a non-starter due to its complexity, reliability, and cost of migration. Instead, there's growing momentum around modernizing how COBOL workloads are run—moving them from mainframes and on-prem hardware into cloud-native infrastructure.
This post explores how we containerized and deployed COBOL workloads on an Amazon EKS Kubernetes cluster using Amazon EFS for shared storage. The goal was to modernize legacy data processing pipelines without rewriting core COBOL logic, and to enable a future where ML services like Amazon SageMaker can integrate directly into the pipeline to assess and predict runtime errors in COBOL jobs.
Why Run COBOL in 2025? Business Logic Longevity
COBOL isn't just a legacy language—it’s the living, breathing business logic that keeps many companies running. Replacing it is risky. These systems are often deeply intertwined with operational processes, tested over decades, and maintained by specialists who understand the nuances. The smartest path forward isn’t always refactor—it’s reinforce.
Running COBOL in containers on Kubernetes lets organizations treat legacy code like first-class citizens in their modern architecture. It enables autoscaling, logging, observability, secrets management, and integration with the rest of the ecosystem via cloud-native patterns.
Architecture Overview: Kubernetes Pod Setup and EFS Mounting
At the core of this modernization effort is a Kubernetes cluster hosted on Amazon EKS. The cluster mounts an Amazon Elastic File System (EFS) volume into specific pods to provide consistent, shared, and persistent storage.
The key components of the architecture:
- COBOL Runtime Container: A Docker container built using GnuCOBOL, responsible for compiling and executing COBOL programs.
- Amazon EFS: A shared file system that persists COBOL input files and output results. Multiple pods can mount and read/write to the same volume.
- COBOL Executor Pod: A pod that runs the COBOL code on startup, processes a batch of data, enriches it, and either forwards it to PostgreSQL or logs an error.
- Error Logger Pod: Monitors errors written to an S3 bucket and preps them for SageMaker training and inference.
We use a CSI driver to mount EFS volumes directly to the COBOL executor pods. This ensures that when a COBOL program starts, it reads from EFS-mounted directories for input, and writes its enriched output or error results to a known shared location.
Challenges of Adapting COBOL Workloads for Kubernetes
Compatibility Issues
COBOL was never designed with containers in mind, so the first challenge is creating a build environment that packages a working COBOL runtime. We use gnucobol in an Ubuntu base image, compiled at build time. Static linking is used to avoid dependency hell in containers.
Some COBOL jobs require specific file formats, encoding types, or memory configurations that you’ll need to simulate in the container environment. It’s important to test jobs in isolation using representative data to validate behavior under load.
State Management
Kubernetes pods are ephemeral by design, but COBOL programs often rely on persisted file state. We use Amazon EFS to give the pods durable storage across restarts, deployments, and scale-outs.
Each job gets its own directory on EFS, structured by job ID or timestamp. We mount EFS with a ReadWriteMany policy, allowing multiple pods to collaborate if needed. This is crucial for multi-phase jobs where one COBOL pod enriches a file and another uploads it to a destination service.
Resource Constraints
COBOL jobs aren’t CPU-intensive, but they are sequential and memory-sensitive. We found that 512Mi of memory and 0.5 vCPU per job was sufficient, but we apply resourceLimits in the pod spec to avoid sprawl. Using Kubernetes Jobs instead of Deployments also ensures pods clean up after successful execution.
We use taints and tolerations to isolate these jobs on specific worker nodes dedicated to legacy workloads, avoiding interference with high-availability frontend or ML workloads running in the same cluster.
Monitoring and Logging
Because these pods run COBOL, not Node.js or Python, you don’t get rich stack traces or JSON logs. We redirect all COBOL output to stdout/stderr so it’s captured by FluentBit and sent to CloudWatch Logs. This makes it easier to correlate job runs with error messages and system performance.
We also label each job with metadata like jobType=cobol-run, dataset=customers, and status=success|error to allow for fine-grained log filtering and dashboarding in CloudWatch and Prometheus.
Custom Docker Image for COBOL Runtime
The Docker image used in the EKS cluster is minimal and purpose-built for COBOL. Below is the Dockerfile:
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y \
gnucobol \
gcc \
make \
&& apt-get clean
WORKDIR /app
COPY TransformCSV.cbl .
COPY run.sh .
RUN chmod +x run.sh
ENTRYPOINT ["./run.sh"]
The entry script looks like this:
#!/bin/bash
set -e
echo "Compiling COBOL job..."
cobc -x -free TransformCSV.cbl -o TransformCSV
echo "Running COBOL job..."
./TransformCSV
This script compiles and runs the COBOL job when the pod starts. The program reads a CSV from the EFS mount, processes it, and writes either a JSON output or error file.
Handling State and File Persistence
Amazon EFS provides the backbone for stateful behavior. We create a dedicated PersistentVolume and PersistentVolumeClaim using the EFS CSI driver. Then in the pod spec:
volumes:
- name: efs-volume
persistentVolumeClaim:
claimName: cobol-efs-pvc
containers:
- name: cobol-runner
image: <COBOL_IMAGE>
volumeMounts:
- name: efs-volume
mountPath: /mnt/data
This setup ensures all input files are accessible from /mnt/data/input, and output files go to /mnt/data/output. Each COBOL pod is idempotent—if a job fails, it leaves behind an error file with a timestamp and input hash so it can be retried or flagged for ML inspection. Those error files are written directly to S3.
Conclusion
Running COBOL on Kubernetes isn’t just a gimmick—it’s a survival strategy for enterprises sitting on decades of legacy logic. By wrapping COBOL programs into containerized workloads and deploying them to EKS with EFS, we bring observability, scalability, and modernization to systems that were never meant to live in the cloud.
This setup becomes even more powerful when integrated with modern data services. With errors logged to S3, another service prepares the data for SageMaker, and an ML model predicts which COBOL runs are likely to fail—proactively enhancing system reliability.
This project shows how legacy doesn’t mean outdated. With the right architecture, even COBOL can thrive in a cloud-native future.
Related Posts
