Remote state is the foundation of team-scale Terraform operations. When a single engineer manages infrastructure on a personal project, local state stored in terraform.tfstate is adequate — it is always on the engineer's machine and always up to date. When a team of engineers manages shared infrastructure, local state breaks immediately: two engineers working from different machines have different state files, concurrent applies can overwrite each other's changes, and there is no recovery path when a laptop with the state file is lost or corrupted. Remote state solves all of these problems by storing state in a centralised, shared location with locking to prevent concurrent modifications and versioning to enable recovery. The S3 backend with DynamoDB locking is the AWS standard: it is inexpensive (pennies per month), reliable (eleven nines durability on S3), fast (DynamoDB lock acquisition takes milliseconds), and auditable (S3 access logs record every state read and write).
Terraform workspaces add a second dimension to state management: the ability to maintain multiple independent state files from the same configuration directory. A workspace is a named state context — 'terraform workspace new staging' creates a new workspace that uses a separate state file while sharing all of the same .tf configuration files. The production and staging workspaces can both manage their own VPCs, databases and compute resources independently, using the same module code. Workspaces solve a different problem than modules — they handle environment multiplicity within a single code base, not code reuse across different infrastructure concerns. Understanding when to use workspaces versus separate directories (or separate repositories) is a key architectural decision that affects how easily teams can manage environment drift, review infrastructure changes, and implement RBAC across environments.