AWS ECR: वह Container Registry जिसकी आपके ECS Fargate को ज़रूरत है (और क्यों यह टूटने तक अदृश्य रहता है)

AWS ECR क्या है और आपको इसकी परवाह क्यों करनी चाहिए?

AWS ECR (Elastic Container Registry) Amazon का प्रबंधित container image स्टोरेज है। इसे एक निजी Docker Hub की तरह समझें, लेकिन AWS में बनाया गया है। हर बार जब आप ECS Fargate पर कोई container चलाते हैं, तो task को एक image खींचनी पड़ती है कहीं से — और ECR वह जगह है जहाँ अधिकांश टीमें अपना रखती हैं।

1 जुलाई 2026 को, किसी भी गंभीर cloud deployment के लिए container orchestration बुनियादी ज़रूरत है। यदि आप ECS Fargate चला रहे हैं, तो आप लगभग निश्चित रूप से ECR का भी उपयोग कर रहे हैं। लेकिन बात यह है: ECR एक तरह से अदृश्य है। यह तब तक काम करता है जब तक यह बंद न हो जाए, और जब यह टूट जाता है, तो error messages अनुपयोगी होते हैं। एक task इसके साथ शुरू होने में विफल रहता है ResourceInitializationError। आपके साथी कंधे उचकाते हैं। छह महीने बाद, आपको पता चलता है कि पाँच साल की untagged images आपकी registry में पड़ी हैं, जो चुपचाप आपसे स्टोरेज के लिए महीने के $400 ले रही हैं। इस मार्गदर्शिका में उन हिस्सों को शामिल किया गया है जिन्हें ECR documentation नज़रअंदाज़ कर देता है: pulls वास्तव में कैसे काम करते हैं, private-subnet tasks विफल क्यों होते हैं, और अपने बिल को उचित कैसे रखें।

ECR, ECS Fargate के साथ कैसे काम करता है

जब कोई ECS Fargate task शुरू होता है, तो उसे एक container image खींचने की आवश्यकता होती है। task में स्थानीय रूप से Docker स्थापित नहीं होता है — यह Amazon के प्रबंधित बुनियादी ढांचे पर चल रहा है। इसलिए Fargate agent ECR तक पहुँचता है, authenticate करता है, और image डाउनलोड करता है।

वह authentication वह मुख्य हिस्सा है जिसके बारे में कोई बात नहीं करता है। आपका Fargate task उपयोगकर्ता नाम (username) और पासवर्ड के साथ लॉग इन नहीं करता है। इसके बजाय, यह एक IAM role का उपयोग करता है — विशेष रूप से, execution role जो आपने task को सौंपा है। ECR उस role की permissions की जाँच करता है। यदि role image को पढ़ सकता है, तो बढ़िया। यदि नहीं, तो task चुपचाप विफल हो जाता है (आपको एक generic error मिलता है)।

ECR भी एक विशिष्ट AWS region में रहता है। यदि आपका task इसमें है us-east-1 और आपकी image इसमें है eu-west-1, तो task इसे बिना अतिरिक्त कॉन्फ़िगरेशन के नहीं खींच सकता। यह आमतौर पर कोई समस्या नहीं है, लेकिन यह जानने लायक है।

IAM permissions: अदृश्य दीवार

यह वह जगह है जहाँ ज़्यादातर लोग ठोकर खाते हैं। आपके ECS task को एक execution role की आवश्यकता होती है — वह पहचान जिसका उपयोग वह images खींचने, logs लिखने और अन्य AWS सेवाओं से बात करने के लिए करता है। उस role को ECR से पढ़ने के लिए विशिष्ट permissions की आवश्यकता होती है।

न्यूनतम कुछ इस तरह दिखता है:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:BatchCheckLayerAvailability"
      ],
      "Resource": "arn:aws:ecr:us-east-1:REPLACE_WITH_ACCOUNT_ID:repository/REPLACE_WITH_REPO_NAME"
    },
    {
      "Effect": "Allow",
      "Action": "ecr:GetAuthorizationToken",
      "Resource": "*"
    }
  ]
}

वह दूसरा statement महत्वपूर्ण है। GetAuthorizationToken वह एकमात्र ECR action है जो किसी विशिष्ट repository पर लागू नहीं होता है — यह विश्व स्तर (globally) पर लागू होता है। इसके बिना, आपका task ECR पर authenticate भी नहीं कर सकता है, और बाकी सब कुछ विफल हो जाता है।

यदि आप इसमें गड़बड़ी करते हैं, तो आपका task इसमें बैठता है PROVISIONING एक मिनट के लिए, फिर इसके साथ विफल हो जाता है ResourceInitializationError। ऐसा कोई log नहीं है जो कहे "अरे, आपका IAM role ECR को नहीं पढ़ सकता है।" त्रुटि (error) अस्पष्ट है। इसलिए जब कोई task शुरू नहीं होता है तो जाँचने वाली पहली चीज़ execution role है।

Private subnet विफलताएँ और वे क्यों होती हैं

मान लीजिए कि आपका Fargate task एक private subnet (अच्छा सुरक्षा अभ्यास) में है। इसकी कोई सीधी इंटरनेट पहुँच नहीं है — सभी आउटबाउंड ट्रैफ़िक एक NAT gateway से होकर जाते हैं। अब आपका task ECR से एक image खींचने का प्रयास करता है।

ECR एक AWS सेवा है, इसलिए यह इंटरनेट पर रहती है (एक तरह से — तकनीकी रूप से इसके public और VPC endpoints दोनों हैं)। जब आपका private-subnet task ECR के public endpoint तक पहुँचता है, तो request NAT gateway से होकर जाती है, वापस आती है, और चाहिए काम करना। आमतौर पर यह करता है।

लेकिन कभी-कभी ऐसा नहीं होता है। यदि आपका NAT gateway आपके task से एक अलग AZ में है, या यदि आपने route tables को गलत तरीके से कॉन्फ़िगर किया है, तो request चुपचाप विफल हो जाती है। या यदि आपके security groups पोर्ट 443 (HTTPS) पर egress को रोकते हैं, तो ECR प्रतिक्रिया नहीं दे सकता है।

इसका समाधान आमतौर पर इनमें से एक होता है:

1. ECR के लिए एक VPC endpoint का उपयोग करें। अपने VPC में एक VPC endpoint बनाएँ, और Fargate सार्वजनिक इंटरनेट के बजाय endpoint के माध्यम से image खींचता है। यह अधिक सुरक्षित और तेज़ है।
2. सुनिश्चित करें कि आपका NAT gateway पहुँच योग्य (reachable) है। Route tables जाँचें — ECR का ट्रैफ़िक NAT के माध्यम से रूट होना चाहिए।
3. आउटबाउंड HTTPS खोलें। ECR तक पहुँचने के लिए आपके task के security group को पोर्ट 443 पर egress की आवश्यकता है।
4. CloudWatch logs जाँचें। यदि आप error message से आगे गहराई में जाते हैं तो आपके task के CloudWatch log group में अक्सर सुराग होते हैं।

यदि आप एक private subnet में हैं, तो एक VPC endpoint स्वर्ण मानक (gold standard) है। यह सभी ट्रैफ़िक को AWS के अंदर रखता है, NAT शुल्कों से बचाता है, और तेज़ है। इसे एक बार सेट अप करें, फिर इसके बारे में भूल जाएँ।

ECR प्राइसिंग और image क्लिनअप को समझना

ECR की लागत सरल है: आप संग्रहीत (stored) image डेटा के लिए भुगतान करते हैं। कोई प्रति-खिंचाव (per-pull) शुल्क नहीं, कोई प्रति-पुश (per-push) शुल्क नहीं। बस स्टोरेज।

पेंच यह है: आपके द्वारा पुश की जाने वाली हर image layer हमेशा के लिए संग्रहीत हो जाती है जब तक कि आप इसे हटा नहीं देते। यदि आप एक ही image tag को बार-बार (जैसे "latest" tag) पुश करते हैं, तो हर पुश अंदर ही अंदर एक नई image होती है। कुछ वर्षों के बाद, आपके पास हज़ारों untagged images वहाँ पड़ी होंगी।

बेस OS और पैकेजों के आधार पर एक सिंगल image 500 MB से 2 GB तक की हो सकती है। उसे सैकड़ों या हज़ारों बिल्ड्स से गुणा करें, और आप टेराबाइट्स देख रहे हैं। लगभग $0.10 प्रति GB प्रति माह की दर से, यह महँगा है।

समाधान एक lifecycle policy है। यह एक नियम है जो कहता है "किसी भी image को हटा दें जिसका 30 दिनों में उपयोग नहीं किया गया है" या "प्रति tag केवल अंतिम 10 images रखें।" यहाँ एक उचित उदाहरण दिया गया है:

{
  "rules": [
    {
      "rulePriority": 1,
      "description": "Keep last 10 images",
      "selection": {
        "tagStatus": "tagged",
        "countType": "imageCountMoreThan",
        "countNumber": 10
      },
      "action": {
        "type": "expire"
      }
    },
    {
      "rulePriority": 2,
      "description": "Delete untagged images after 30 days",
      "selection": {
        "tagStatus": "untagged",
        "countType": "sinceImagePushed",
        "countUnit": "days",
        "countNumber": 30
      },
      "action": {
        "type": "expire"
      }
    }
  ]
}

यह अंतिम 10 tagged images को रखता है और 30 दिनों से पुरानी किसी भी untagged images को हटा देता है। जब आप ECR सेट अप करते हैं तो इसे लागू करें, और आपको कभी भी आश्चर्यजनक $400 का बिल नहीं मिलेगा।

ECR समस्याओं को डिबग करना

जब कोई task शुरू होने में विफल रहता है, तो error message आमतौर पर बेकार होता है। लेकिन उत्तर लगभग हमेशा इनमें से एक होता है:

1. खराब IAM permissions. Execution role repository को नहीं पढ़ सकता है।
2. गलत repository या region. Task इसकी तलाश कर रहा है app.example.com/myimage:latest इसमें us-east-1, लेकिन आपने इसे यहाँ पुश किया eu-west-1.
3. नेटवर्क की समस्याएँ। Private subnet, security groups, या route tables ECR तक पहुँच को रोक रहे हैं।
4. Image मौजूद नहीं है। आपने एक tag पुश किया, फिर उसे हटा दिया, फिर उसका उपयोग करने का प्रयास किया।
5. ECR API थ्रॉटलिंग (throttling)। दुर्लभ, लेकिन यदि आप एक बार में सैकड़ों images खींच रहे हैं, तो ECR आपको rate-limit कर सकता है।

समस्या निवारण के लिए:

• IAM कंसोल में task के execution role की जाँच करें। क्या इसके पास ECR permissions हैं?
• Task के लिए CloudWatch logs group जाँचें। अक्सर इसके आउटपुट में एक सुराग छिपा होता है awslogs आउटपुट।
• उसी VPC में एक EC2 इंस्टेंस से मैन्युअल रूप से image खींचने का प्रयास करें। यदि वह काम करता है, तो समस्या task कॉन्फ़िगरेशन में नेटवर्किंग या IAM की है।
• VPC endpoint को देखें (यदि आप इसका उपयोग कर रहे हैं)। क्या यह task के subnet से पहुँच योग्य है?

निष्कर्ष

ECR जटिल नहीं है, लेकिन इसके विवरणों से चूकना आसान है। यह आपके ECS task और बाहरी दुनिया के बीच बैठता है, और यदि इसे गलत कॉन्फ़िगर किया गया है, तो सब कुछ रुक जाता है। सही करने वाली तीन चीज़ें हैं: IAM permissions (इसमें शामिल GetAuthorizationToken), नेटवर्क एक्सेस (विशेष रूप से private subnets में), और image क्लिनअप (lifecycle policies)। उन तीनों को करें, और ECR अच्छे तरीके से अदृश्य हो जाता है — यह बस काम करता है, और आपका बिल उचित रहता है।

गुण

• पूरी तरह से प्रबंधित — स्वयं संचालित करने के लिए कोई container registry नहीं
• IAM के साथ एकीकृत — fine-grained access control अंतर्निहित है
• सस्ता — केवल स्टोरेज के लिए भुगतान करें, कोई प्रति-पुल (per-pull) शुल्क नहीं
• तेज़ — images उसी AWS region में रहती हैं जिसमें आपके tasks हैं
• VPC endpoints उपलब्ध हैं — सुरक्षा और गति के लिए ट्रैफ़िक को AWS के अंदर रखें
• Lifecycle policies — स्वचालित क्लिनअप बिल के आश्चर्यों को रोकता है

दोष

• Error messages अपारदर्शी हैं — "ResourceInitializationError" आपको कुछ नहीं बताता
• क्षेत्रीय — एक region में images बिना वर्कअराउंड के दूसरे region में tasks को दिखाई नहीं देती हैं
• कोई अंतर्निहित नोटिफिकेशन्स नहीं — आपका image स्टोरेज बिना किसी चेतावनी के बढ़ सकता है
• IAM जटिलता — execution role के कई हिस्से होते हैं
• VPC endpoint सेट अप मैन्युअल है — private-subnet एक्सेस को सुरक्षित करना आसान होना चाहिए
• Untagged image क्लिनअप मैन्युअल है — lifecycle policies डिफ़ॉल्ट रूप से सक्रिय नहीं होती हैं

सावधानी

यह मार्गदर्शिका प्लेसहोल्डर मानों (placeholder values) का उपयोग करती है: repository नाम हैं REPLACE_WITH_REPO_NAME, अकाउंट IDs हैं REPLACE_WITH_ACCOUNT_ID, और regions सामान्य उदाहरण हैं। हमेशा अपने AWS अकाउंट से वास्तविक मानों को प्रतिस्थापित करें। इनमें से किसी भी कॉन्फ़िगरेशन को प्रोडक्शन में डिप्लॉय करने से पहले, पहले उन्हें सैंडबॉक्स (sandbox) वातावरण में टेस्ट करें। IAM परिवर्तन और नेटवर्किंग कॉन्फ़िगरेशन चल रहे वर्कलोड्स को बाधित कर सकते हैं, इसलिए सावधानी से बदलाव करें और रोलबैक प्लान रखें। अपने जोखिम पर आगे बढ़ें, और सत्यापित करें कि सभी प्लेसहोल्डर्स को वास्तविक, सही मानों से बदल दिया गया है।

अक्सर पूछे जाने वाले प्रश्न

• मैं अपने CI/CD पाइपलाइन से ECR पर image कैसे पुश करूँ?
• एक public और private ECR repository में क्या अंतर है?
• क्या मैं AWS के बाहर से ECR image खींच सकता हूँ?
• सुरक्षा कमजोरियों के लिए मैं ECR images को कैसे स्कैन करूँ?
• मेरा ECR बिल अचानक इतना अधिक क्यों है?
• क्या मुझे ECR का उपयोग करने की आवश्यकता है, या मैं Docker Hub या किसी अन्य रजिस्ट्री का उपयोग कर सकता हूँ?
• मैं अपने ECR repository तक पहुँचने के लिए किसी अन्य AWS अकाउंट को अनुमति कैसे दूँ?
• यदि मैं उस image को हटा दूँ जिसका उपयोग कोई running task कर रहा है, तो क्या होगा?

टैग्स

#aws #ecr #ecs #containers #fargate #devops #cloudnative #iam