terraform-provider-aws: terraform refresh fails for aws_launch_configuration with InvalidAMIID.NotFound

This issue was originally opened by @matt-deboer as hashicorp/terraform#13433. It was migrated here as part of the provider split. The original body of the issue is below.

---

Terraform Version

0.9.2

Affected Resource(s)

• aws_launch_configuration

Terraform Configuration Files [example]

...
## get the ami id from latest packer build
data "aws_ami" "widget" {
  filter {
    name = "name"
    values = ["widget-template"]
  }
  owners = ["self"]
}

resource "aws_launch_configuration" "widget" {
  ...
  image_id = ""${data.aws_ami.widget.id}""
  ...
}

Error output:

Error refreshing state: 1 error(s) occurred:

* module.aws_agent.aws_launch_configuration.widget: aws_launch_configuration.widget: InvalidAMIID.NotFound: The image id '[ami-xxxxxxxx]' does not exist
	status code: 400, request id: a892c167-7942-4781-8af8-8f62dc57437a

Expected Behavior

terraform refresh should be able to succeed, even when the AMI associated with the current aws_launch_configuration has been deleted. terraform plan should show the resources (and affected dependencies) as needing change/rebuild.

Actual Behavior

terraform refresh encounters the error mentioned above

Steps to Reproduce

1. Construct an terraform configuration, using an aws_launch_configuration which pulls it’s image_id from a datasource, as in the example.
2. terraform apply to create the resources
3. delete the AMI (replace with a new/updated version)
4. run terraform refresh on the stack

Important Factoids

Our typical process involves the following steps:

1. Build AMI with packer, and upload to AWS
2. Provision ASGs using an aws_ami data source to reference the latest version of the AMI built in packer
3. More recently, we’ve started cleaning up old AMI’s that are no-longer needed, including some of the AMIs produced in step#1, after we have uploaded a newer version of that AMI. – we did confirm that there is exactly 1 version of the particular AMI present, but none of the previous versions.
4. We’re able to work around this by using terraform state rm on the affected aws_launch_configuration instances (since they’ll be re-created anyway)