Infrastructure-as-Code (IaC) is an emerging technology in modern software delivery, leveraging code files to automate the configuration of cloud platforms. As business requirements evolve, IaC files are typically complex, containing hundreds of lines of code and dependencies, provisioning different cloud platforms. IaC relies on third-party providers to provision the software system infrastructure. IaC practitioners continuously maintain and evolve their code to introduce new features that adhere to the regularly updated cloud provider specifications (e.g., AWS, GCP, Azure) and address any security vulnerabilities or defects. Although prior work on software dependency management highlights risks associated with obsolete dependencies used by practitioners, it is still unclear whether practitioners consistently update their IaC provider dependencies in alignment with official releases. To shed light on this issue, we conduct an empirical study on dependency updates of the Amazon Web Services (AWS) provider as a widely-used provider to provision the prevalent AWS infrastructure. We empirically examined 14,398 commits from 29 relevant open-source projects that use Terraform, a widely used IaC tool, focusing on (i) whether practitioners perform updates on AWS provider dependency, (ii) the duration for which the AWS provider dependency remains unchanged in their code, and (iii) the typical practices followed by IaC practitioners when updating the AWS provider dependency. Our findings reveal that practitioners often do not update the dependencies of the AWS provider, and only 4.4% of the commits studied change their dependencies. Often, updates are delayed on average from 31 to 370 d over a span of 8 years. These findings suggest that practitioners may be cautious about potential backward incompatible changes, especially considering how AWS provider specifications continuously evolve with new cloud resource options.