When trying to deploy an AMI within our AWS account, terraform returns the following error:
`Error applying plan:
1 error(s) occurred:
Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.`
The AMI is able to be launched successfully via API or Web Console.
Here is the snippet from the terraform config:
resource "aws_instance" "management_node" {
ami = "${var.management_ami}"
availability_zone = "us-east-1b"
instance_type = "m4.xlarge"
key_name = "${var.aws_key_name}"
security_groups = ["${aws_security_group.private.id}"]
subnet_id = "${aws_subnet.us-east-1b-private.id}"
private_ip = "192.168.0.70"
tags {
Name = "Management Server"
}
}
Hi @darksheer - I can tell you that we use Terraform to launch instances using private AMIs on a daily basis, so my first guess would be that there's some difference in the authorization credentials used by Terraform and your Web Console / API tests.
Can you double check that when you're testing AMI access via the API vs Terraform you're using the same creds?
Let me know what you find and we'll get to the bottom of this one way or another! :+1:
Fixed the problem by going into the AMI and adding the hosting account to the permissions list, ensuring the make snapshot option was selected.
Why I had to do this, IDK. But resolved the issue.
Thanks for the quick response.
This seems to still be an issue when copying private AMIs from one account to another. As stated in the issue it is possible to create and ec2 instance with the AMI both in the console and through the CLI, but not with terraform which results with the error.
Error launching source instance: AuthFailure: Not authorized for images:
Just adding the account id to the permission list of the AMI does not seem like a long term solution to this bug which appears to be in the AWS provider.
EDIT: This comment was made before I found I had buggy terraform that was causing this. Read the next post to see the resolution of this problem.
This seems to still be an issue when copying private AMIs from one account to another. As stated in the issue it is possible to create and ec2 instance with the AMI both in the console and through the CLI, but not with terraform which results with the error.
This is exactly the scenario we are encountering. A dev built a Windows 2K19 ami in a dev AWS account that he has access to. We copied the AMI to a different region in that dev AWS account, and then shared the ami to the production AWS account, including checking the "can create volumes" option. Terraform cannot launch this ami in the prod account. Depending on what options I specify in the terraform, it says:
* aws_instance.node1_prod: 1 error(s) occurred:
* aws_instance.node1_prod: Error launching source instance: AuthFailure: Not authorized for images: [ami-0034a3016f8d3b3aa]
status code: 400, request id: ab7178f2-1e47-4439-b15a-0e5f58cf6415
or it says this when launching into a specific subnet:
* aws_instance.node1_prod: 1 error(s) occurred:
* aws_instance.node1_prod: Expected 1 AMI for ID: ami-0034a3016f8d3b3aa, got none
I'm at a loss how to get past this. I was using version 1.52.0 of the aws driver, so I re-init'd the project which installed 1.57.0 of the aws driver, and it did the same thing.
I'll research in the aws driver project specifically as mentioned above and see if I can find anything further.
Correction to the previous post: It turned out to be an issue with my terraform configs that resulted cross-AWS-account resources being defined and failed trying to create them. When it was in us-east-1, my terraform configs were creating things in the desired AWS account. In my terraform configs, I use aliases to refer to multiple regions. The absence of an AWS_PROFILE envvar made it fallback to "default", which was in a different AWS account because I didn't specify the "profile" in each provider that defined an alias. The error message was telling me that the account didn't have access to the ami, it just wasn't clear that terraform was doing some things in a different AWS account than I thought it was.
I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.