How to to launch ECS Fargate container without public IP.

0

I've an ECS Fargate container app that server the API request over the public internet.

My understanding is that this API service container can be deployed on public subnet and that is configured with ALB DNS and target group. As we can see target group redirect the traffic to private IP of the ECS task, I guess we don't need public IP to enabled when launching the task. However when I attempt this on ECS task launch getting an error "Resourceinitializationerror: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve ecr registry auth: service call has been retried 3 time(s): RequestError: send request failed caused by: Post "https://api.ecr.eu-west-2.amazonaws.com/": dial tcp 52.94.53.88:443: i/o timeout"

If this is not workable and we need to enable public ip on the task launch, I'd prefer to restrict the public IP port access only to web service ALB for best security practice. Could someone suggest me the workable approach on this usecase pls? Thanks.

6 Risposte
2

You should not need a public IP for Fargate (https://docs.aws.amazon.com/AmazonECS/latest/userguide/fargate-task-networking.html)

The error message seems to indicate that the container could not pull from ECR. You might need to configure private endpoint for ECR. https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html

profile pictureAWS
Roly
con risposta un anno fa
2

Hello,

The problem you are facing is related to the outbound connectivity from your ECS tasks to the ECR Service endpoints.

You can create a NAT Gateway in your public subnet, and add it to the internet route (0.0.0.0/0) in your private subnet to allow your ECS tasks to connect with ECR service during Image pull.

If you do not want to use NAT Gateway, you can simply create VPC Endpoints in your VPC and associate them with your private subnets. This will allow your private subnets with connectivity to ECR endpoints through private link without having to create a IGW or NAT. Please refer this ECR VPC Endpoints for more details.

Please comment if you have questions/concerns with this suggestion.

Thank you!

profile pictureAWS
TECNICO DI SUPPORTO
con risposta un anno fa
0

Actually for Fargate Tasks you do not need to create the ECR VPN Endpoint https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html

There is a default VPC Endpoint enabled.

Copied and pasted portions of the text

Important Amazon ECS tasks hosted on Fargate don't require the Amazon ECS interface VPC endpoints.

Amazon ECS tasks hosted on Fargate using Linux platform version 1.3.0 or earlier only require the com.amazonaws.region.ecr.dkr Amazon ECR VPC endpoint and the Amazon S3 gateway endpoint to take advantage of this feature.

Amazon ECS tasks hosted on Fargate using Linux platform version 1.4.0 or later require both the com.amazonaws.region.ecr.dkr and com.amazonaws.region.ecr.api Amazon ECR VPC endpoints as well as the Amazon S3 gateway endpoint to take advantage of this feature.

Amazon ECS tasks hosted on Fargate using Windows platform version 1.0.0 or later require both the com.amazonaws.region.ecr.dkr and com.amazonaws.region.ecr.api Amazon ECR VPC endpoints as well as the Amazon S3 gateway endpoint to take advantage of this feature.

profile pictureAWS
Roly
con risposta un anno fa
  • Thanks @Roly,

    I'm able to deploy the ECS Fargate containers on Private Subnets now. However, just wondering the point "Amazon ECS tasks hosted on Fargate don't require the Amazon ECS interface VPC endpoints." - In the absence of dkr api vpc endpoints, I get an error "Resourceinitializationerror: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve ecr registry auth" After including these VPC endpoints, container launch event is successful. Any thoughts on this pls? Thanks.

  • So it is working, trying to understand the question ? For ECS Fargate, since it is serverless, we have created default VPC endpoints. So is the answer accepted ?

  • Slight correction here: "Important Amazon ECS tasks hosted on Fargate don't require the Amazon ECS interface VPC endpoints.". They don't require "ECS" endpoint, but they DO require ECR if you want to use ECR.

0

Thanks @Roly and @Venkat,

I followed the steps by referring https://aws.amazon.com/premiumsupport/knowledge-center/ecs-fargate-tasks-private-subnet/#:~:text=To%20run%20Fargate%20tasks%20in,over%20a%20private%20IP%20address.

i.e. configured ECR VPN endpoints, S3 Gateway, launched the containers on private subnets. Private subnets route table has NAT Gateway and ALB on public subnet with it NAT Gateway route settings. ECS Task / Service launched successfully, can see Target group registered with task private ip. However, when using the ALB DNS url, getting an error "test-dev-public-2055608301.eu-west-2.elb.amazonaws.com took too long to respond."

Any suggestions pls? Thanks.

con risposta un anno fa
  • see previous

0

NAT Gateway and VPC endpoints (AWS PrivateLink) are both paid options. So If user want to stay on Free Tier - seems there is NO option now ( after Public IP becomes to paid from Feb 24)

You just choose for what you pay -

  • NAT + NAT TRAFIC!!!! ( between ECR and ESC FARGATE for each pull ) - for me - its most expensive option.
  • Public Ip - 0.1 per hour => ~ $7 per month.
  • PrivateLink - 0.1 per hour => ~ $7 per month** PER ENDPOINT **, but as mentioned above - need 3 of them + trafic ( $0.01 per GB, not big, BUT if your service will by some error crash/restart over weekend - you can be very surprised by bill at Monday)

So, seems Public Ip is cheapest option right now.

Alex
con risposta 20 giorni fa
0

My application has many microservices, so it has different ECS Tasks. They are also deployed on multiple clusters, one for every customer.

Hence, we are paying a lot for Public IPs just to be able to pull some docker images. Is it possible to share the same public IP among multiple ECS Tasks?

desoss
con risposta 14 giorni fa

Accesso non effettuato. Accedi per postare una risposta.

Una buona risposta soddisfa chiaramente la domanda, fornisce un feedback costruttivo e incoraggia la crescita professionale del richiedente.

Linee guida per rispondere alle domande