Comparing Cloud Cost Optimization Tools for Genomics

By Dr. Zubair Khalid, DVM, MS, PhD · 2026-11-11

Cloud cost optimization tools for genomics fall into two broad families. Some tools lower the unit price of compute, mainly by bidding on discounted spare capacity or by picking the cheapest instance that finishes the job in an acceptable time. Other tools lower the total amount of compute you buy, mainly by batching jobs well, ordering tasks so expensive machines never sit idle, and keeping data close to the compute that processes it. The rule of thumb for choosing between them is simple: if your workload is thousands of small, independent jobs, buy price reductions with spot-aware tools. If your workload is a long, tightly coupled pipeline, buy efficiency with a workflow manager and a tuned compute engine, and use discounted capacity only where the pipeline can tolerate interruption.

This article compares the concrete options that genomics groups actually use, grounds the comparison in published benchmarks, and shows how the numbers from real studies translate into decisions for your own lab.

Why genomics cloud bills get out of control

Genomic data has grown faster than most labs' compute budgets. High-throughput sequencers generate data at a pace that overwhelms local storage, and moving large datasets over the network consumes bandwidth and time, which is a large part of why cloud computing became the default answer for genome research [1]. The cloud solves the storage and scaling problem, but it introduces a billing model that punishes waste in ways an on-premises cluster never did. You pay for every hour a virtual machine runs, whether or not it is doing useful work, and you pay again for storage that outlives the project.

Three patterns drive most of the waste in cloud bioinformatics:

1. Idle compute inside pipelines. A whole-genome pipeline has stages with very different resource needs. Alignment wants fast local disk and many cores. Variant calling may be single-threaded. If you provision one large instance type for the whole workflow, the single-threaded stages run on hardware that is mostly idle, and you pay full price for the idle fraction.
2. Data movement. Reading input data from cloud object storage into VMs, then writing intermediates back, then reading them again in the next stage, adds cost at every hop. Pipelines that ignore data locality pay for the same bytes repeatedly.
3. Unbatched small jobs. Submitting ten thousand tiny jobs each on its own VM pays the VM startup tax ten thousand times. Strategic batching of individual genomes into shared compute runs is one of the lessons that came out of systematic benchmarking of whole-genome workflows on AWS [2].

These three problems explain why no single tool wins. A spot-bidding optimizer attacks unit price but does nothing about idle compute inside a badly shaped pipeline. A tuned distributed engine attacks the pipeline shape but still pays on-demand prices unless you combine it with discounted capacity. The tools compared below differ mainly in which of these levers they pull.

Comparing cloud cost optimization tools for genomics at a glance

The table below is the core of the comparison. Each row is a tool or approach that has been applied to real genomic workloads with published cost results. The "cost lever" column names the mechanism by which the tool saves money, because that mechanism, not the brand name, determines whether the tool fits your workload.

Spot-aware provisioning and bidding tools

Aether

Aether attacks the price side of the equation. It uses linear programming to optimally bid on and deploy combinations of underutilized cloud computing resources, which in practice means the discounted spare capacity cloud providers sell at steep reductions compared with on-demand rates [3]. The framing matters: rather than treating a single instance type as the unit of purchase, Aether treats the whole menu of available resource types as a portfolio and solves for the cheapest combination that meets your compute demand.

The published motivation is the widening gap between data production and analysis capacity across biology. Labs are generating data faster than their analysis capability grows, and buying fixed on-premises hardware or paying on-demand cloud rates both scale poorly. Aether's designers also emphasized a practical adoption path: the framework provides an easy transition from users' existing HPC pipelines, so a lab does not have to rewrite its science to cut its bill [3].

The pros and cons of this category are worth stating plainly. The pro is that discounted capacity is frequently priced at a small fraction of the on-demand rate, so the savings ceiling is high and the savings apply to every hour of compute. The cons are that the capacity can be reclaimed by the provider at short notice, which means your jobs must either checkpoint their state or be cheap to restart, and that the bidding model needs enough historical price information to be worth the trouble. A linear programming optimizer buying spot capacity is overkill for a lab that runs one exome a week. It earns its keep when the workload is large, heterogeneous, and divisible.

Preemptible-first batch processing

The simplest and most widely applicable cost optimization in genomics is not a product at all. It is the pattern of running every sample as an independent job on a preemptible (spot) virtual machine, with automatic retries when the machine is reclaimed. A large demonstration of this pattern processed 12,307 RNA-seq samples from public cancer compendia using two cloud configurations and examined the performance and cost profile of each, reaching per-sample processing costs as low as 0.09 US dollars with preemptible VMs [8]. Two design details made that number possible. First, the samples were processed independently, so no long-lived shared state had to survive a preemption. Second, the pipeline collected performance metrics as samples were processed, tracking the duration and resource consumption of each processing step, which is what turns a cost problem into an optimization problem rather than a mystery [8].

The same study reached a second conclusion that generalizes widely. Even though the computational demands of reference alignment and expression quantification had decreased considerably, preprocessing steps remained the optimization bottleneck, meaning that the expensive part of a pipeline is not always the part you expect [8]. Measure before you optimize.

Workflow management systems with cost controls

COSMOS and GenomeKey

Workflow management systems describe multistep analyses in a common language, execute them on clusters or clouds, and support re-entrancy, the ability to selectively re-execute parts of a workflow when inputs or configuration change and to resume from where execution stopped [14]. That re-entrancy is a direct cost control. If stage six of a twelve-stage pipeline fails at sample 8,000 of 10,000, a workflow manager with proper re-entrancy re-runs only the failed pieces instead of the whole cohort.

GenomeKey demonstrates the cost side of this category in detail. Built on COSMOS, a cloud-enabled workflow management system, GenomeKey implements an NGS whole-genome analysis workflow whose AWS implementation was shown to be fast, scalable, and cost-effective on both public benchmarking data and large heterogeneous clinical datasets [2]. The benchmarking produced two findings that apply to almost any cloud genomics project. The first is strategic batching of individual genomes, because per-genome overheads that are negligible for one sample become dominant across a cohort. The second is efficient cluster resource configuration, meaning that the machine types assigned to each pipeline stage should match that stage's actual resource profile rather than being uniform across the workflow [2]. The clinical target the authors set, whole-genome analysis rendered into medically actionable results within hours at per-genome economies in the tens of dollars, is a useful yardstick for any WGS pipeline costing exercise [2].

Choosing a workflow manager by prototyping

Because workflow managers differ in how much cost control they expose, the choice of manager is itself a cost decision. One research group approached this by prototyping, reimplementing the RiboViz ribosome profiling workflow, originally a Python script, inside candidate workflow management systems and evaluating how each supported incremental builds, re-entrancy, containers, and portability across HPC and cloud systems [14]. Their practical conclusion generalizes: the manager lets bioinformaticians delegate how workflows run to the manager and its developers, freeing them to focus on what the workflows should do [14]. For cost purposes, when you prototype, test two things specifically. Test whether a failed run resumes cheaply, and test whether the manager reuses cached outputs when only part of the configuration changes. Both behaviors translate directly into dollars on the next rerun.

Distributed compute engines and pipeline tuning

Hail on Spark clusters

For population-scale variant analysis, the dominant cost lever is the cluster configuration itself. A comparative study of genome-wide association study workloads deployed Spark clusters on both Google Cloud Platform and Amazon Web Services, used Hail for analysis and exploration of genomic variant datasets, and systematically evaluated numerous cluster configurations across four distinct whole-genome sequencing datasets [5]. The study's central result addresses the question every group asks before moving to the cloud, namely the trade-off between speed and cost. The evaluation found a successful compromise between the two, and, notably, the results were consistent across the two cloud providers, which suggests that the configuration discipline matters more than the provider choice [5].

The practical takeaway is that you should benchmark your own GWAS or variant QC workload across a small grid of cluster sizes and machine families before standardizing. The cheapest configuration is rarely the smallest one, because undersized clusters stretch runtimes into more billable hours, and the fastest configuration is rarely cost-optimal either. The compromise sits in the middle, and only measurement finds it.

SeQuiLa for distributed pileup

Algorithmic work can cut cloud costs in ways that no procurement decision can. Pileup analysis, the enumeration of base calls at each genomic position, is a building block of variant calling and genotyping, and straightforward implementations process all base calls from all alignments sequentially, which tends to make it the bottleneck of the entire assay [6]. SeQuiLa, a cloud-native distributed pileup implementation, combined a custom data-partitioning algorithm for alignment reads, a novel approach that processes alignment events using MD tags, and micro-optimizations of recurrent operations. The result was execution up to 6.5 times faster and memory usage up to 2 times lower than other state-of-the-art distributed tools, which the authors translate directly into substantial cloud cost reduction [6]. Because SeQuiLa deploys on any managed Kubernetes or Hadoop service available in public clouds, it fits into existing platform bills rather than adding a new one [6].

The general lesson holds beyond pileup. A 6.5 times speedup on a bottleneck stage cuts the bill for that stage by roughly the same factor, which is usually far larger than the discount any instance pricing scheme offers. Profile your pipeline, find the dominant stage, and check whether an algorithmically better implementation exists before buying more machines.

Job ordering, batching, and scheduling models

The Roundup approach on Elastic MapReduce

One of the earliest and most instructive cost optimizations in cloud genomics came from the Roundup comparative genomics resource. The team computed orthologous relationships among 902 fully sequenced genomes on Amazon's Elastic Compute Cloud, deploying the Elastic MapReduce web service to manage the ortholog processes, and completed 245,323 genome-to-genome comparisons in just over 200 hours at a cost of 8,000 US dollars [4]. The optimization mechanism was a predictive model. They created a model to estimate cloud runtime based on the size and complexity of the genomes being compared, and used it to determine in advance the optimal order in which jobs should be submitted [4].

Why does ordering matter? Because on a fixed-size cluster, the total bill equals the hourly cluster price times the wall-clock makespan. If long jobs are submitted last, the cluster drains toward the end, with most machines idle while a few stragglers finish. Ordering long jobs first and short jobs last keeps utilization high throughout the run. For workloads where job runtimes vary predictably with input properties, a simple runtime model plus longest-job-first ordering is one of the highest-return optimizations available, and it costs nothing but code.

Metaheuristic scheduling

Scheduling can also be treated as a formal optimization problem. In a cancer epigenomics workflow study, an improved particle swarm optimization algorithm was applied to map epigenomics workflow tasks onto cloud resources so that total cost was minimized under the pay-per-use billing model, and the improved scheduling reduced total cost by 6.83 percent compared with the traditional particle swarm optimization algorithm [11]. The absolute improvement is modest, but the structure of the result is instructive. Scheduling quality is a real, measurable, bounded cost lever. It will not halve your bill, but on a seven-figure annual cloud spend, single-digit percentage improvements from better task-to-resource mapping are worth pursuing after the larger levers, such as spot pricing and pipeline efficiency, have been pulled.

Managed science platforms: Terra, the Cancer Genomics Cloud, and AnVIL

A different class of option moves the cost optimization problem up a level. Managed platforms such as Terra (FireCloud) and the Seven Bridges Cancer Genomics Cloud provision virtual machines per task and charge you only for the compute each task uses, which removes an entire class of idle-time waste by construction [7]. A large medical imaging curation effort, methodologically relevant to genomics because it ran on the same NCI cloud resources, evaluated these platforms to run AI segmentation over more than 126,000 CT volumes from more than 26,000 patients. The computation used more than 21,000 virtual machines over the course of the run, completed in under 9 hours, compared with an estimated 522 days on a single workstation, at a total cost of 1,011.05 US dollars [7]. The per-VM cost was not the story. The story was that task-level provisioning, at extreme parallelism, converted an infeasible 522-day job into a 9-hour, four-figure bill.

For genomics specifically, the NHGRI AnVIL platform provides a secure cloud-based environment where research and education communities analyze genomic and biomedical data with safe storage and access in compliance with NIH policies, and where work can be shared to promote reproducible science [15]. The platform's own community polling, which surveyed returning and potential users about their backgrounds, technological comfort, computational needs, and preferences for training and support, found opportunities for adoption beyond the current user base and identified areas where training should be enhanced [15]. That last finding is a cost point in disguise. Training gaps cause expensive mistakes, such as orphaned storage and forgotten clusters, and platforms with structured onboarding reduce that class of waste.

The pros of managed platforms are task-level billing, built-in compliance for controlled-access data, and reproducible sharing. The cons are reduced low-level control, less ability to apply exotic optimizations such as custom bidding, and platform-specific fees on top of raw infrastructure. Groups bound by NIH data access policies often find the tradeoff easy, because the compliance features are not optional elsewhere.

Lightweight wrappers, appliances, and domain pipelines

Not every lab needs an optimizer. Some need only a fence.

RBioCloud is a lightweight framework for executing R scripts that use Bioconductor packages on cloud infrastructure. It offers simple command-line tools for managing the cloud resources, the data, and job execution, so that an analyst can move an analytical job from a personal workstation to the cloud without extensive knowledge of the cloud dashboard [9]. Its cost contribution is indirect but real. Analysts who manage cloud resources manually forget to terminate them. A framework that provisions and releases resources as part of job execution eliminates that leak.

MS-PyCloud applies the same philosophy to proteomics and glycoproteomics on AWS. It is an open-source pipeline with a graphical interface covering data file integrity validation, spectral assignment, false discovery rate estimation, protein inference, and quantitation, with comprehensive testing and versioning for reproducibility, and it scales seamlessly on public cloud infrastructure [10]. For a genomics reader, the relevant point is the open-source substitution itself. Replacing per-sample proprietary software license costs with versioned open-source tooling is a cost optimization that compounds with scale, and the pattern ports directly to genomics pipelines.

CloVR-Comparative shows what a fixed-cost appliance looks like. It bundles commonly used comparative microbial genomics tools into an automated pipeline that runs reference-free whole-genome alignments to determine unique, shared, and core coding sequences and SNPs, distributed as part of a virtual appliance that runs on a local desktop or on the Amazon EC2 cloud [13]. A representative dataset of 40 draft and complete E. coli genomes processes in under 36 hours on a local desktop or at a cost of under 20 dollars on EC2 [13]. For small microbial workloads, that predictability is the feature. You know the cost before you click.

Atlas2 Cloud rounds out this category with an explicit cost decomposition. The pipeline was enabled for personal genome analysis on two different cloud service platforms, a community cloud via the Genboree Workbench and a commercial cloud via AWS under a Software-as-a-Service model, and the authors published a detailed cost structure for exome analysis with cost projections across storage, compute, and I/O [16]. Publishing that three-way decomposition is itself the practice worth copying. Bills that are decomposed into storage, compute, and I/O can be optimized. Bills that arrive as one number cannot.

Benchmark-driven pipeline selection with vendor cost guidance

The last option category is measurement itself. For clinical NGS on Google Cloud Platform, a benchmark of Sentieon DNASeq and Clara Parabricks Germline compared the two ultra-rapid pipelines on five publicly available exome and five whole-genome samples, in terms of runtime, cost, and resource utilization, and found that the two performed comparably, with both viable for rapid cloud-based analysis [12]. The same work provides a tutorial aimed at easing implementation on GCP and cost guidance aimed at healthcare managers considering cloud-based NGS processing [12]. Two uses follow from this. If you are choosing between commercial accelerated pipelines, a head-to-head benchmark on data shaped like yours is worth more than any vendor claim. If you are writing a funding or budgeting proposal, published per-genome cost benchmarks from a tutorial source give you defensible numbers to plan against.

The caveat is that benchmark results age. Instance prices, software versions, and pipeline releases all change. Treat a published benchmark as a starting configuration to re-measure, not as a permanent answer.

How to compare these tools on the criteria that decide real choices

When you compare cloud cost optimization tools for genomics, five criteria separate the options that help from the options that complicate.

1. Which cost lever does it pull, and is that your actual problem? Diagnose your bill first. If you pay on-demand rates for interruptible work, a spot-aware tool such as Aether or a preemptible-first pattern is the right lever [8]. If your pipeline has idle gaps, batching and resource configuration, as demonstrated in the GenomeKey benchmarks, is the right lever [2]. If one algorithmic stage dominates runtime, engine replacement, as with SeQuiLa, is the right lever [6]. If your jobs are small and numerous, ordering and scheduling is the right lever.

2. Can your workload tolerate interruption? Discounted capacity is reclaimed unpredictably. Embarrassingly parallel per-sample workloads tolerate this trivially, which is why per-sample costs in the single-digit cents were achievable on preemptible VMs. Tightly coupled multi-hour stages do not tolerate it without checkpointing. A tool that bids on spare capacity is only a saving if the reclaimed work is cheap to redo.

3. Does it preserve re-entrancy and reproducibility? A cost optimization that forces you to abandon your workflow manager throws away re-entrancy, the selective re-execution capability that prevents expensive full reruns [14]. Prefer optimizations that operate under your existing workflow system, or that come bundled inside one.

4. Where does the data live relative to the compute? The founding rationale for cloud genomics is taking the tools to the data, avoiding large transfers of petabyte-scale public compendia [8]. Any tool or configuration that increases data movement erodes its own savings. Managed platforms colocated with major controlled-access datasets have an structural advantage here.

5. What does it cost to adopt and operate? A linear programming optimizer needs a modeling effort. A Spark cluster needs tuning expertise. The AnVIL community's own training-needs assessment makes the general point that technological comfort varies widely across the user base, and adoption support is part of the true cost [15]. A tool that one person on your team can operate next week may beat a tool that would save 10 percent more after a quarter of engineering.

Worked scenarios

Scenario 1: A massive comparative genomics batch. You need all-versus-all comparisons across hundreds of genomes, roughly the Roundup shape of problem: 245,323 genome-to-genome comparisons across 902 genomes on AWS, finished in just over 200 hours for 8,000 US dollars [4]. Your cost tools here are a runtime prediction model and deliberate job ordering on Elastic MapReduce, so long comparisons start first and the cluster never drains [4]. If your scale is microbial rather than the 902-genome scale, consider whether you need the cloud at all. Forty E. coli genomes cost under 20 dollars on EC2 or under 36 hours on a desktop, and the desktop is free after the purchase [13].

Scenario 2: A clinical whole-genome pipeline. You need repeatable WGS analysis with turnaround in hours and per-genome cost in the tens of dollars, the GenomeKey target [2]. Your primary tools are a workflow manager with re-entrancy and strategic batching with per-stage resource configuration on AWS [2]. If you are choosing a commercial accelerated pipeline such as Sentieon or Parabricks on GCP, use the published runtime, cost, and resource utilization benchmarks as your starting configuration and re-measure on your own samples [12]. Decompose your own bill into storage, compute, and I/O the way Atlas2 Cloud did for exome analysis, because each component optimizes differently [16].

Scenario 3: A population-scale GWAS. You are running association tests over whole-genome sequencing data with Hail on Spark. Your tool is configuration benchmarking. The published comparison across GCP and AWS cluster configurations found a concrete speed-versus-cost compromise and, usefully, consistent results across both providers, so invest your effort in the cluster configuration search rather than in switching clouds [5]. Combine the tuned cluster with discounted capacity for any embarrassingly parallel preprocessing stages.

Scenario 4: Tens of thousands of small, independent jobs. You are quantifying expression or extracting features across a huge cohort. This is the preemptible-first pattern's home turf. Independent per-sample jobs on preemptible VMs reached 0.09 US dollars per sample for RNA-seq quantification across 12,307 samples [8], and the same architectural pattern on managed platforms drove a 126,000-volume analysis to under 9 hours for about 1,000 dollars using more than 21,000 VMs [7]. The requirements are strict independence between jobs, automatic retries, and per-stage performance metrics so you can see where the next optimization belongs [8].

Common Mistakes and Limitations

Mistake 1: Optimizing the wrong stage. The most measurable surprise in the RNA-seq compendia study was that alignment and quantification were no longer the expensive parts, while preprocessing remained the optimization bottleneck [8]. Teams routinely spend weeks optimizing a stage that is a small fraction of the bill. Collect per-stage cost metrics before choosing a target.

Mistake 2: Uniform instance types across a heterogeneous pipeline. Efficient cluster resource configuration, matching machine types to each stage's resource profile, was a headline finding of the GenomeKey benchmarking [2]. Running every stage on the same large instance type is the default mistake.

Mistake 3: Ignoring the makespan. On a fixed cluster, cost is price times wall-clock duration, so idle time at the end of a run is pure waste. The Roundup ordering model exists precisely because unorderd jobs drain a cluster [4]. Submit long jobs first.

Mistake 4: Using spot capacity without a restart story. Discounted capacity is interruptible by design. If your jobs cannot checkpoint or re-run cheaply, the savings evaporate into repeated work. Reserve spot for workloads that tolerate preemption, and keep on-demand or checkpointed execution for coupled stages.

Mistake 5: Treating cloud provider choice as the cost decision. The GWAS benchmarking found configuration results consistent across both GCP and AWS [5]. Provider switching is expensive to execute and rarely the biggest lever. Cluster configuration, batching, and pipeline efficiency usually dominate.

Mistake 6: Forgetting storage, I/O, and licensing in the cost model. The Atlas2 cost structure explicitly separated storage, compute, and I/O, because they scale differently and optimize differently [16]. MS-PyCloud shows the license dimension, where open-source tooling removes proprietary per-use software costs entirely [10]. A cost model with only compute hours will understate your real bill.

Limitation: published numbers are snapshots. The costs in this article, 8,000 dollars for 245,323 comparisons [4], 0.09 dollars per sample [8], under 20 dollars for 40 microbial genomes [13], 1,011.05 dollars for a 126,000-volume analysis [7], and the 6.83 percent scheduling improvement [11], were measured under the prices, instance types, and software versions of their studies. Use them to understand relative magnitudes and mechanisms, then re-benchmark on your own data before committing a budget.

Limitation: every case needs its own measurement. Workload shape, data volume, and compliance requirements differ enough between groups that no comparison, including this one, substitutes for a small pilot on your own pipeline.

Frequently Asked Questions

What are the best cloud cost management tools for genomics?

There is no single best tool. The best choice depends on your workload shape. Spot-aware provisioning frameworks such as Aether suit large interruptible batches, workflow managers such as COSMOS suit long clinical pipelines, distributed engines such as Hail and SeQuiLa suit population-scale analytics, and managed platforms such as Terra and AnVIL suit controlled-access data. Match the tool to the lever that dominates your bill.

How do spot and preemptible instances reduce genomics costs?

Cloud providers sell spare capacity at steep discounts, and spot or preemptible instances access it. The catch is that the provider can reclaim the machine at short notice, so the pattern works well only for independent, restartable jobs with automatic retries. Embarrassingly parallel per-sample analyses are the ideal match.

Is AWS or Google Cloud cheaper for genomics workloads?

Published benchmarking of GWAS workloads on Spark clusters found that the speed-versus-cost compromise was consistent across both providers [5]. The practical implication is that cluster configuration, batching, and pipeline efficiency matter more than the choice between AWS and GCP, so benchmark your own workload rather than assuming one provider wins.

Do I need a workflow management system to control cloud costs?

You do not strictly need one, but it helps in two direct ways. Re-entrancy lets you re-run only failed or changed portions of a pipeline instead of everything, and structured resource management prevents forgotten VMs and clusters. If you are choosing one, prototype your actual pipeline in the candidates and test resume behavior before committing.

How much does whole-genome analysis cost in the cloud?

Published benchmarks report per-genome costs in the tens of dollars for clinical-grade WGS workflows, and per-sample costs in the cents for lighter tasks such as RNA-seq quantification on preemptible VMs. Exact figures depend heavily on pipeline, instance pricing, and data volumes at the time you run, so treat any published number as a planning starting point and re-measure.

What is the cheapest way to run thousands of small genomic jobs?

Batch aggressively, order long jobs first so the cluster does not drain, run on preemptible VMs with automatic retries, and keep every job independent so a reclaim costs one retry rather than a wave. This combination of batching, ordering, and discounted capacity is what produced the smallest per-job costs in published genomics studies.

Sources

1. Genome research in the cloud.
2. Scalable and cost-effective NGS genotyping in the cloud.
3. Aether: leveraging linear programming for optimal cloud computing in genomics.
4. Cost-effective cloud computing: a case study using the comparative genomics tool, roundup.
5. Scalability and cost-effectiveness analysis of whole genome-wide association studies on Google Cloud Platform and Amazon Web Services.
6. Cloud-native distributed genomic pileup operations.
7. Cloud-based large-scale curation of medical imaging data using AI segmentation.
8. A cloud-based workflow to quantify transcript-expression levels in public cancer compendia.
9. RBioCloud: A Light-Weight Framework for Bioconductor and R-based Jobs on the Cloud.
10. MS-PyCloud: A Cloud Computing-Based Pipeline for Proteomic and Glycoproteomic Data Analyses.
11. Cancer Diagnosis Epigenomics Scientific Workflow Scheduling in the Cloud Computing Environment Using an Improved PSO Algorithm.
12. Rapid NGS Analysis on Google Cloud Platform: Performance Benchmark and User Tutorial.
13. CloVR-Comparative: automated, cloud-enabled comparative microbial genome sequence analysis pipeline.
14. Using prototyping to choose a bioinformatics workflow management system.
15. Insights into the Datasets, Tools, and Training Needs of the AnVIL Community: 2024.
16. Atlas2 Cloud: a framework for personal genome analysis in the cloud.