ज्ञानकोष

साइटको CDN को रूपमा आफ्नो Amazon CloudFront खाता प्रयोग गर्नुहोस्

CloudFront पढ्न र invalidation हरू सिर्जना गर्न अनुमति प्राप्त AWS पहुँच कुञ्जी (access key) सिर्जना गर्नुहोस् र यसलाई जडान गर्नुहोस्, ताकि साइट तपाइँको आफ्नै CloudFront वितरणमा चलाउन सकियोस्।

यसलाई जोड्दा तपाईंलाई हुने फाइदा

तपाईंको आफ्नै AWS खाता जोड्नाले तपाईंलाई हाम्रो CDN को सट्टा तपाईंको CDN मा साइट राख्न दिन्छ। जोन, ट्राफिक र बिल तपाईंको खातामा हुन्छन्, र तपाईं अझै पनि आफ्नो Zinn® ड्यासबोर्ड भित्रबाटै क्यास पसल गर्न (purge) र CDN का सेटिङहरू परिवर्तन गर्न सक्नुहुन्छ — प्यानलहरू बीच स्विच गर्नु पर्दैन।

सुरु गर्नु अघि

एउटा AWS खाता। यो कनेक्सनका लागि एउटा IAM प्रयोगकर्ता सिर्जना गर्नुहोस् जसको नीतिले CloudFront पढ्ने पहुँच र cloudfront:CreateInvalidation को अनुमति दिन्छ, जुन क्यास पसल गर्नका लागि आवश्यक हुन्छ।

तपाईंको आफ्नै डोमेन सर्भ गर्नका लागि, CloudFront लाई us-east-1 क्षेत्रको AWS Certificate Manager मा त्यसको लागि एउटा प्रमाणपत्र पनि चाहिन्छ। अन्य कुनै पनि क्षेत्रमा रहेका प्रमाणपत्रहरू CloudFront का लागि अदृश्य हुन्छन्, चाहे तपाईं जुनसुकै क्षेत्रमा काम गर्नुहुन्छ।

१. AWS मा कुञ्जी (key) सिर्जना गर्नुहोस्

AWS कन्सोलमा IAM → Users खोल्नुहोस्, यो कनेक्सनले काम गर्नुपर्ने प्रयोगकर्ता छनोट गर्नुहोस् (एउटा समर्पित प्रयोगकर्ता सिर्जना गर्नुहोस् — आफ्नो रुट (root) खाता कहिल्यै प्रयोग नगर्नुहोस्), यसको Security credentials ट्याब खोल्नुहोस् र, Access keys अन्तर्गत, Create access key छनोट गर्नुहोस्। प्रयोगको केसका रूपमा Other छान्नुहोस्, अगाडि बढ्नुहोस्, र Create access key छनोट गर्नुहोस्। Access key IDSecret access key प्रतिलिपि गर्नुहोस् — AWS ले सेक्रेट कुञ्जी एक पटक मात्र देखाउँछ। प्रत्येक IAM प्रयोगकर्ताले एक पटकमा दुईवटा कुञ्जीहरू राख्न सक्छ।

२. यसलाई यहाँ जोड्नुहोस्

आफ्नो ड्यासबोर्डमा Integrations खोल्नुहोस् र Connect an account छनोट गर्नुहोस्। समूहको रूपमा Your own CDN र खाताको रूपमा Amazon CloudFront छान्नुहोस्, Access key IDSecret access key भर्नुहोस्, र Connect account थिच्नुहोस्।

कुनै पनि कुरा बचत हुनु अघि तपाईंले टाँस्नुभएको कुरा हामी परीक्षण गर्छौँ। काम नगर्ने कुञ्जी कहिल्यै भण्डारण गरिँदैन, र जवाफले त्यसमा के खराबी थियो भन्ने बताउँछ। काम गर्ने कुञ्जीलाई हाम्रो सेक्रेट्स भल्ट (secrets vault) मा इन्क्रिप्ट गरेर राखिन्छ — हाम्रो डेटाबेसमा कहिल्यै राखिँदैन — र पुन: कहिल्यै देखाइँदैन, तपाईंलाई पनि देखाइँदैन।

त्यसपछि के हुन्छ

  • साइटको CDN ट्याब खोल्नुहोस्। Where this site is served from अन्तर्गत, यो खाता गन्तव्यको रूपमा देखिन्छ। यसलाई छनोट गर्नुहोस् र पुष्टि गर्नुहोस्; हामी तपाईंको खातामा साइटको कन्फिगरेसन निर्माण गर्छौँ, यसलाई जाँच गर्छौँ, र त्यसपछि मात्र साइटलाई सारेर लैजान्छौँ, ताकि सार्ने क्रममा साइट सुचारु नै रहोस्।
  • सोही ट्याबबाट तपाईं साइटको क्यास पसल (purge) गर्न सक्नुहुन्छ र आफ्नो खातामा यसको CDN सेटिङहरू परिवर्तन गर्न सक्नुहुन्छ।
  • तपाईंले जोड्दा, कुञ्जीले के-के गर्न सक्छ भनेर हामी जाँच गर्छौँ: तपाईंको जोन वा गुणहरू सूचीबद्ध गर्ने, कुनै एकलाई विस्तारमा पढ्ने, क्यास पसल गर्ने, सेटिङहरू र — भेन्डरसँग उपलब्ध भएमा — भौगोलिक नियमहरू परिवर्तन गर्ने। कनेक्सनको छेउमा रहेको चेकलिस्टले हामीले तीमध्ये कुन पुष्टि गर्न सक्यौँ भनेर देखाउँछ, त्यसैले तपाईंले खातामा साइट सार्नु अघि नै छुट्नुभएका अनुमतिहरू देखिन्छन्।
  • Deploy a site to your own CDN account ले खाताहरू बीच साइट सार्ने कार्यलाई विस्तारमा समेट्छ।

यदि यो जोडिएन भने

तपाईंको डोमेन जोड्न सकिँदैन। us-east-1 मा यसका लागि कुनै प्रमाणपत्र छैन। त्यो क्षेत्रको AWS Certificate Manager मा एउटा अनुरोध गर्नुहोस्, अनि पुनः प्रयास गर्नुहोस्।

पसल (Purging) असफल भयो। प्रयोगकर्ताको नीतिमा cloudfront:CreateInvalidation छैन। यसलाई थप्नुहोस्; कुञ्जी परिवर्तन हुँदैन।

यसले कुञ्जी अस्वीकृत भएको भन्छ। प्रायः सधैँ तीनवटा कुराहरूमध्ये एक हुन्छ: यससँगै प्रतिलिपि भएको स्पेस वा लाइन ब्रेक, म्याद सकिएको कुञ्जी, वा तपाईंले प्रतिलिपि गरेपछि रद्द गरिएको वा पुनः उत्पन्न गरिएको कुञ्जी। एउटा नयाँ सिर्जना गर्नुहोस् र यसलाई पुनः टाँस्नुहोस्।

यो जोडिन्छ, तर पछि केही कुरा असफल हुन्छ। कुञ्जीले प्रमाणिकरण गर्छ तर कार्यका लागि आवश्यक अनुमति यसमा छैन। माथि सूचीबद्ध अनुमतिहरूसहित एउटा नयाँ कुञ्जी सिर्जना गर्नुहोस्, त्यसपछि पुरानो कनेक्सन विच्छेद गर्नुहोस् र नयाँ कुञ्जी जोड्नुहोस्।

विच्छेद गर्दै

Integrations खोल्नुहोस्, खाता खोज्नुहोस् र Disconnect थिच्नुहोस्। त्यसले भण्डारण गरिएको कुञ्जीलाई तुरुन्तै हटाउँछ। यसलाई प्रयोग गरिरहेको जुनसुकै कुरा यसको पछिल्लो कार्यमा रोकिन्छ, र यसमा निर्भर स्क्रिनहरूले चुपचाप असफल हुनुको सट्टा सो कुरा बताउँछन्।

विच्छेद गर्नाले पहिले नै भइसकेका कार्यहरू पूर्ववत हुँदैनन् — तपाईंको खातामा हामीले परिवर्तन गरेका रेकर्डहरू, डिप्लोयमेन्टहरू वा सेटिङहरू जस्ताको त्यस्तै रहन्छन्। यदि तपाईंलाई कुञ्जी नै लिक भएको हुन सक्छ जस्तो लाग्छ भने, भेन्डरमा गएर पनि यसलाई रद्द गर्नुहोस्; विच्छेद गर्नाले हाम्रो प्रतिलिपि हट्छ, उनीहरूको हट्दैन।

ब्लगबाट पछिल्लो

हामीले हस्तीङ, एसइओ र ठूलो मात्रामा वेबसाइटहरू सञ्चालन गर्ने बारेमा के लेखिरहेका छौँ।

होस्टिंग तहबाट एसईओ र लिङ्क निर्माण: सन् २०२६ को अपरेटरको दृष्टान्त

२०२६ मा होस्टिङले इन्डेक्सिङ र लिङ्क इक्विटीलाई कसरी आकार दिन्छ: पेजहरूलाई इन्डेक्स राख्ने, पुराना डोमेनहरूमा साइट बनाउनुअघि तिनको जाँच गर्ने, फुटप्रिन्ट बिनाको लिङ्क बिल्डिङ, र SEO का लागि पूर्वाधारले के गर्न सक्छ र के सक्दैन भन्ने बारे स्पष्ट धारणा।

पोष्ट पढ्नुहोस्

WordPress लाई छिटो र सुरक्षित बनाउँदै: कार्यसम्पादन र प्लगइन चेकलिस्ट

छिटो र सुरक्षित WordPress का लागि एउटा व्यावहारिक चेकलिस्ट: सर्भर-स्तरको क्याचिङ, प्रति-साइट अब्जेक्ट क्याच, चलाउन लायक केही सीमित प्लगइनहरू, स्ट्याकलाई अध्यावधिक राख्ने, र WooCommerce पृष्ठहरू जुन तपाईंले कहिल्यै क्याच गर्नु हुँदैन।

पोष्ट पढ्नुहोस्

२०२६ मा म्यानेज्ड वेब हस्टिङ कसरी छनौट गर्ने: एक खरिदकर्ताको मार्गदर्शक

राम्रो म्यानेज्ड होस्टिंगलाई कन्ट्रोल प्यानल भएको सस्तो सर्भरबाट खासमा के ले छुट्याउँछ — माइगेसन, ब्याकअप, आइसोलेसन, वास्तविक क्याचिङ र इमानदार स्केलिंग — र तपाईं प्रतिबद्ध हुनु अघि यसको मूल्याङ्कन कसरी गर्ने।

पोष्ट पढ्नुहोस्

ब्लग पढ्नुहोस्

अझै पनि अल्झिनुभयो?

सबै योजनाहरूमा सहयोग समावेश गरिएको छ, हेल्पडेस्क दिनको 24 घण्टा खुला रहन्छ, र तपाईंले हाम्रा कुनै पनि 58 भाषाहरूमा हामीलाई लेख्न सक्नुहुन्छ—हामी तपाईंले बुझ्ने भाषामा जवाफ दिन्छौं।

सम्पर्क समर्थन सबै लेखहरू