Cloud Composer Environment
Does ZopNight manage Cloud Composer Environment?
Cloud Composer runs a GKE cluster, a metadata database, and an Airflow web server continuously for every environment, so a substantial fixed hourly cost accrues even with zero DAGs running. ZopNight discovers environments via Cloud Asset Inventory, attributes the multi-component spend from billing actuals, and flags idle environments as savings candidates.
Rules that fire on Cloud Composer Environment
No active rule family targets Cloud Composer Environment today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
Cloud Composer is Google Cloud’s managed Apache Airflow service for workflow orchestration. Every environment runs a GKE cluster, database, and web server continuously, giving it a substantial fixed hourly cost even when no DAGs are running.
An orchestrator that never sleeps
A Composer environment is not one resource but a small standing stack: GKE nodes hosting the Airflow scheduler and workers, a managed database for Airflow metadata, a web server for the UI, and a Cloud Storage bucket for DAGs. Each has its own meter, and all run around the clock. The floor cost is what makes Composer distinctive: an environment orchestrating nothing bills nearly the same as one running a full DAG load, because the scheduler loop, database, and web server exist regardless. Charges scale up from that floor with environment size and worker autoscaling.
Rolling a stack of meters into one line
ZopDev discovers Composer environments via Cloud Asset Inventory and attributes their multi-component spend from billing export actuals, so the GKE, database, and web-server charges surface as one environment cost rather than scattered infrastructure lines. Environments are not schedulable through ZopNight (Airflow’s scheduler must run for schedules to mean anything), so idle environments are flagged in recommendations instead. In development projects, an unused Composer environment is frequently the single largest savings candidate.
The dev-environment trap
Waste follows a predictable arc. A team stands up a Composer environment to try Airflow, writes three DAGs, and the evaluation ends, but the environment persists at its full floor cost. Or per-developer environments are created for isolation when one shared environment with separate DAG folders would do. Or a production environment is sized for a migration burst and its worker floor never lowered afterwards.
Judging an environment’s pulse in the console
Google Cloud console → Composer → Environments lists each environment with its location and Airflow version. Opening the Airflow UI from there shows the DAG list and recent runs. An environment whose last successful DAG run is weeks old, or whose DAGs are all paused, is paying its full standing cost to orchestrate nothing.