- Can you create a new an AppRunner service in a separate region from an ECR image? I read a bit about replication, but would like to get it working without additional complexity if possible. Does additional region introduce any additional permissions issues?
Otherwise, here's my current setup:
I have an AppRunner service running successfully in one region. I'm trying to spin up a service based off the same image in a second region, but I get problems similar to this repost question.
Specifically, the service is created but goes into OPERATION_IN_PROGRESS for a while until it dies & goes to status "Create failed".
Looking in deployment logs for event "Create service", I see:
01-25-2022 01:58:36 PM [AppRunner] Failed to pull your application image. Be sure you configure your service with a valid access role to your ECR repository.
01-25-2022 01:48:54 PM [AppRunner] Starting to pull your application image.
Following advice of the other re:Post question, I tried looking in Cloud Trail events originating from event source "ecr.amazonaws.com". I have tons of GetAuthorizationToken events, but looking at them doesn't give me much interesting information - they seem to pass & are using the role I expect them to.
A bit about permissions - I'm using the default AppRunnerECRAccessRole which I created through the UI when creating an AWS service. I'm reusing it to try & create different services. It has a policy with this JSON:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:DescribeImages",
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability"
],
"Resource": "*"
}
]
}
Any additional debugging tips for this specific scenario? If there is more generic advice for question #1 I'll try to follow it. I would like to "create a new service with same image in a region distinct from the image's region" if possible atm (even if that is inefficient long-term).
It is also a best practice to obtain container images from an ECR repository that is located in the same region you are running your containers in. AWS Regions are designed to be separate failure domains, so that if region A suffers a degradation in service, resources in region B will be unaffected. If you create inter-regional dependencies -- for example, by pulling container images from a different region -- then you are increasing your operational risk.