Understanding AWS Provider Dependency Updates in Infrastructure-As-Code: Empirical Study, Taxonomy, and Insights
Why this work is in the frame
A frame that forgets how it found something cannot be audited. These are the routes that admitted this work.
Bibliographic record
Abstract
Infrastructure-as-Code (IaC) automates the configuration of cloud platforms through code. As business needs evolve, IaC files often become complex, containing hundreds of lines and multiple dependencies. These configurations rely on third-party providers to provision system infrastructure. Practitioners regularly update IaC code to align with evolving cloud provider specifications (i.e., AWS, GCP, Azure) and to address security issues or defects. Although prior work highlights the risks of outdated dependencies, it remains unclear whether IaC practitioners consistently update provider dependencies in accordance with official releases. To address this gap, we conduct a mixed-method empirical study focused on the Amazon Web Services (AWS) provider, one of the most widely used providers for provisioning cloud infrastructures. We analyze 23,404 Terraform (TF) related commits from 194 open-source TF projects, focusing on: (i) technical lag, which captures how long AWS provider dependencies remain unchanged in code; (ii) the frequency of dependency updates; (iii) the code review effort involved in updating AWS provider dependencies; and (iv) the motivations behind such updates. Our findings reveal that Terraform developers frequently rely on outdated provider versions, with the technical lag increasing steadily from 2017 to early 2025, reaching a monthly average of approximately 9 months by 2025. Quantitative analysis reveals that only 1.86% of TF-related commits involve updates to AWS provider dependencies, indicating that such updates are not a priority. Moreover, related code reviews are substantial, affecting a median of 7 files across multiple directories. Through thematic analysis, we identify nine key motivations for updating the AWS provider dependencies, with the top three being: Providers Dependency Management, Terraform Compatibility Management, and Security Management. These insights highlight a clear need for better support and tooling to help practitioners manage provider updates more effectively, minimizing disruption while modernizing infrastructure. We recommend adopting automated dependency management tools and improved update workflows to reduce technical lag and lower the cost of staying up to date.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
Full frame distilled prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.
Codex and Gemma teacher scores by category
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.000 | 0.000 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.000 | 0.000 |
| Science and technology studies | 0.000 | 0.000 |
| Scholarly communication | 0.000 | 0.000 |
| Open science | 0.000 | 0.000 |
| Research integrity | 0.000 | 0.000 |
| Insufficient payload (model declined to judge) | 0.000 | 0.000 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from it