Instant Failover with CloudFront Origin Groups

Introduction

30 Second Summary

Naisip mo na ba kung ano ang nangyayari kapag bumagsak ang isang buong AWS region? Para sa maraming websites, ibig sabihin nito ay total downtime. Kailangan ng users na maghintay habang may nag-fi-fix ng problema manually.

In this project, gagawa ka ng automatic failover system gamit ang CloudFront origin groups na nag-switch ng traffic sa secondary region sa loob ng ilang segundo kapag nag-down ang primary mo.

What You'll Build

I-pause mo ang iyong primary App Runner service para i-simulate ang regional outage, i-refresh ang browser, at makikita mo na automatic na nag-serve ang CloudFront mula sa ibang region nang walang manual intervention.

By the end of this project, you'll have:

• Isang CloudFront distribution na nag-se-serve ng iyong app sa buong mundo gamit ang isang URL, at automatic na nag-fa-failover sa secondary region kapag may outage.
• Hands-on experience sa pag-simulate ng regional outage at pag-verify ng instant failover at failback nang walang DNS propagation delays.
• Monitoring visibility sa pamamagitan ng CloudFront metrics para makita mo kung kailan exactly nangyari ang failover.
• Secret Mission: Mag-set up ng CloudWatch alarm na mag-e-email sa'yo kapag may detected na failover event.

Are there any prerequisites?

Oo. Kailangan mo ng dalawang running App Runner services (isa sa us-east-1, isa sa us-west-2) mula sa Part 1 project na "Build Multi-Region Apps on AWS". Kung hindi mo pa nagagawa ang Part 1, tapusin muna iyon bago simulan ang project na ito.

Before We Start

Before We Start...

Bago tayo sumabak sa hands-on work, i-lock in muna natin kung ano exactly ang binabuilds natin at bakit ito importante para sa'yo.

Verify App Runner Services and Grab URLs

Para mag-set up ng failover system, kailangan muna nating i-confirm na pareho mong App Runner services ay tumatakbo sa dalawang region.

Kung hindi healthy ang kahit isa sa kanila, walang gagana ang CloudFront failover configuration na gagawin natin sa susunod na steps. I-verify natin pareho at kunin ang mga URLs na kakailanganin natin.

In this step, get ready to:

• I-verify na Running ang App Runner service sa us-east-1.
• I-verify na Running ang App Runner service sa us-west-2.
• I-copy ang parehong service URLs para magamit sa CloudFront setup.

I-access ang App Runner sa us-east-1

Magsisimula tayo sa primary region. Kailangan mong kumpirmahin na tumatakbo ang service at kunin ang URL nito.

• Sa iyong AWS Management Console, i-type ang App Runner sa search bar sa itaas.
• I-click ang AWS App Runner sa search results.
• Tingnan ang region selector sa upper right corner ng console. Siguraduhing nakalagay ang US East (N. Virginia) us-east-1.
• Kung ibang region ang nakikita mo, i-click ang region selector at piliin ang US East (N. Virginia).
• Sa Services list, i-click ang pangalan ng iyong App Runner service.

Dapat makita mo ang Status na Running sa service overview. Ito ang confirmation na healthy ang service.

• Hanapin ang Default domain field sa service details.
• I-copy ang buong URL (mukhang https://[id].us-east-1.awsapprunner.com).
• I-paste ang URL sa isang bagong browser tab at pindutin ang Enter.

Dapat makita mo ang response mula sa iyong app na nagpapakita na mula ito sa us-east-1 region.

Hindi Running ang status?

Kung Paused ang status, i-click ang Actions at piliin ang Resume. Hintayin na mag-change ang status sa Running bago magpatuloy (mga 1-2 minuto).

Kung wala kang nakikitang App Runner service, bumalik sa Part 1 project (Build Multi-Region Apps on AWS) para i-deploy muna ang services.

Help me troubleshoot my App Runner service that is not in Running status

I-access ang App Runner sa us-west-2

Ngayon i-verify natin ang secondary region. Ito ang magiging backup origin kapag nag-set up na tayo ng failover.

• I-click ang region selector sa upper right corner ng console.
• Piliin ang US West (Oregon) us-west-2.
• Sa Services list, i-click ang pangalan ng iyong App Runner service sa region na ito.
• I-confirm na Running ang Status.
• I-copy ang Default domain URL (mukhang https://[id].us-west-2.awsapprunner.com).
• I-paste ang URL sa isang bagong browser tab at pindutin ang Enter.

Dapat makita mo ang response mula sa iyong app na nagpapakita na mula ito sa us-west-2 region.

Bakit dalawang region?

Ang bawat AWS region ay isang physically separate group ng data centers. Kapag nag-down ang isang buong region (rare pero nangyayari), lahat ng services doon ay maaapektuhan.

Sa pamamagitan ng pagkakaroon ng app mo sa dalawang region, kahit mag-down ang us-east-1, ang us-west-2 ay patuloy na magse-serve ng iyong users. Iyan ang foundation ng high availability.

Ano sa tingin mo ang mangyayari ngayon kung i-access mo ang dalawang URLs na ito nang sabay? Pareho silang gagana independently, pero walang automatic na paraan para mag-switch sa pagitan nila.

I-save ang parehong URLs

I-paste ang parehong App Runner URLs sa isang notepad o sticky note. Kakailanganin mo ang mga ito sa susunod na step para i-configure ang CloudFront origins.

Pareho mong App Runner services ay confirmed healthy at tumatakbo na sa dalawang region. Ngayon, handa ka nang gumawa ng CloudFront distribution na magbibigay ng isang global URL sa iyong app at automatic failover sa pagitan ng dalawang region na ito.

Create a CloudFront Distribution with the Primary Origin

Pareho na ngayong running at verified ang App Runner services mo sa dalawang region. Pero may problema: dalawang hiwalay na URL ang meron mo, at walang automatic na paraan para mag-switch kung mag-down ang isa.

Kailangan mo ng isang global entry point na nag-se-serve ng iyong app sa buong mundo. Sa step na ito, gagawa tayo ng CloudFront distribution na gagamit sa iyong us-east-1 service bilang primary origin.

In this step, get ready to:

• Gumawa ng CloudFront distribution gamit ang iyong us-east-1 App Runner service bilang origin.
• I-verify na nag-se-serve ang CloudFront ng response mula sa primary region sa browser.

Gumawa ng bagong CloudFront distribution

• Sa AWS Console search bar sa itaas, i-type CloudFront.
• I-click ang CloudFront sa search results.
• I-click Create distribution.

What is a CloudFront distribution?

Ang CloudFront distribution ay isang CDN (Content Delivery Network) configuration na nagdi-distribute ng iyong content sa mga edge locations sa buong mundo. Isipin mo itong isang global na front door para sa iyong app.

Sa halip na i-access ng users ang iyong App Runner service directly, daan muna sila sa CloudFront. Nag-se-serve ito ng content mula sa pinakamalapit na edge location, at puwede ring mag-route sa ibang origin kung may problema sa primary.

• Sa Distribution name field, i-type failover-demo.
• Piliin ang Single website or app.
• I-click Next.
• Sa Origin type dropdown, piliin ang Other.
• Sa Origin domain field, i-paste ang iyong us-east-1 App Runner domain (domain lang, walang https:// o trailing /).

Format ng origin domain

Ang i-pe-paste mo ay ang domain portion lang ng iyong App Runner URL. Kung ang full URL mo ay https://abc123.us-east-1.awsapprunner.com/, ang i-pe-paste mo lang ay abc123.us-east-1.awsapprunner.com.

• Sa Settings section, piliin ang Customize origin settings.
• Sa Viewer protocol policy, piliin ang HTTPS only.
• I-click Next.
• Sa Enable security protections page, leave the defaults at i-click Next.
• I-click Create distribution.

Dapat makita mo ngayon ang iyong bagong distribution sa CloudFront console na may status na Deploying.

Why HTTPS only?

Ang HTTPS only setting ay nag-e-ensure na encrypted ang lahat ng traffic sa pagitan ng users at ng iyong CloudFront distribution. Ito ay best practice para sa security, lalo na para sa production applications.

Hintayin ang deployment at i-test ang distribution

Ang CloudFront ay nagde-deploy ng iyong configuration sa edge locations sa buong mundo. Ito ay tumatagal ng mga 5-10 minuto.

• Hintayin na mag-change ang Last modified field mula Deploying sa isang date/time value.
• Kopyahin ang Distribution domain name value (mukhang d1234abcd5678.cloudfront.net).

What should I see?

Kapag deployed na ang distribution, ang Last modified column ay magpapakita ng date at time imbes na Deploying. Pwede kang mag-refresh ng page habang hinihintay.

Bago mo i-test ang CloudFront URL, ano sa tingin mo ang makikita mo? Isipin: saan naka-point ang iyong distribution ngayon?

• I-open ang bagong browser tab at i-paste ang iyong CloudFront distribution URL:

https://[[CLOUDFRONT_DOMAIN="d1234abcd5678.cloudfront.net"]]

Dapat makita mo ang response mula sa iyong primary region (us-east-1). Ito ang parehong response na nakita mo noong directly mong in-access ang us-east-1 App Runner URL.

Hindi mo nakikita ang expected response?

• I-check kung Deploying pa ba ang status ng distribution. Kung oo, maghintay pa ng ilang minuto at i-refresh.
• I-verify na walang https:// prefix o trailing / sa origin domain mo. I-edit ang origin sa Origins tab kung mali ang format.
• Subukang mag-open ng incognito o private window para ma-bypass ang browser cache.

I-troubleshoot ang CloudFront distribution ko na hindi nagre-respond.

Ang CloudFront distribution mo ay live na at nag-se-serve ng iyong app sa buong mundo gamit ang isang URL. Sa next step, i-co-configure natin ang origin group para sa automatic failover kapag nag-down ang primary region.

Configure the Origin Group for Automatic Failover

Sa nakaraang step, nagawa mo na ang CloudFront distribution at na-verify mo na nag-se-serve ito ng content mula sa iyong primary region (us-east-1).

Pero may isang malaking problema: isang origin lang ang meron ang distribution mo. Kung mag-down ang us-east-1, ma-down din ang buong site mo. Sa step na ito, mag-a-add ka ng secondary origin at gagawa ng origin group na automatic na mag-switch sa us-west-2 kapag may error ang primary.

In this step, get ready to:

• I-add ang us-west-2 App Runner bilang secondary origin sa CloudFront distribution.
• Gumawa ng origin group na may failover criteria para sa automatic switching.
• I-update ang default cache behavior para gamitin ang origin group.

Add the secondary origin

Bago ka makagawa ng origin group, kailangan muna ng CloudFront ang pangalawang origin. Ito ang magiging fallback destination kapag hindi na ma-reach ang primary.

• Sa AWS Console, siguraduhing nandoon ka pa sa CloudFront console.
• I-click ang iyong failover-demo distribution.
• Pumunta sa Origins tab.
• I-click ang Create origin button.

• Sa Origin domain field, i-paste ang iyong us-west-2 App Runner URL (domain lang, walang https:// o trailing /).
• Sa Name field, i-type ang secondary-us-west-2.
• I-click ang Create origin.

Dapat makita mo na ngayon ang dalawang origins sa iyong Origins tab: ang original na us-east-1 origin at ang bagong secondary-us-west-2.

Hindi lumalabas ang bagong origin?

Siguraduhing ang domain na ni-paste mo ay walang https:// sa simula at walang / sa dulo. Ang format ay dapat ganito: [id].us-west-2.awsapprunner.com.

help me troubleshoot why my CloudFront secondary origin is not appearing after I created it

Create the origin group

Ngayong meron ka nang dalawang origins, pwede ka nang gumawa ng origin group. Ito ang nagta-tie sa dalawang origins at nagsasabi sa CloudFront kung kailan dapat mag-switch.

• Sa Origins tab pa rin, hanapin ang Origin groups pane sa ibaba.
• I-click ang Create origin group.
• Piliin ang iyong dalawang origins at gamitin ang arrows para i-set ang priority: us-east-1 origin bilang primary (1) at us-west-2 origin bilang secondary (2).
• Sa Name field, i-type ang failover-group.

• Sa failover criteria, piliin ang mga HTTP status codes: 404, 500, 502, 503, 504.
• I-click ang Create origin group.

Dapat makita mo na ngayon ang failover-group sa Origin groups pane, na may dalawang members at ang failover criteria na pinili mo.

What does the origin group do?

Ang origin group ay nagsasabi sa CloudFront: "Kapag nakatanggap ka ng isa sa mga error codes na ito (404, 500, 502, 503, 504) mula sa primary origin, automatic na i-route ang request sa secondary origin." Nangyayari ito sa edge level, kaya walang DNS propagation delay.

Tandaan na ang failover ay gumagana lang para sa GET, HEAD, at OPTIONS requests. Hindi mag-fa-failover ang POST, PUT, o DELETE requests.

Hindi makita ang Origin groups pane?

Siguraduhing nasa Origins tab ka (hindi Behaviors o General). Ang Origin groups pane ay nasa ibaba ng individual origins list.

help me find the Origin groups pane in my CloudFront distribution console

Update the cache behavior to use the origin group

Ang origin group ay nagawa na, pero hindi pa ito ginagamit ng distribution. Kailangan mong i-update ang default cache behavior para i-point ito sa failover-group imbes na sa isang origin lang.

• Pumunta sa Behaviors tab ng iyong distribution.
• Piliin ang default behavior (Default (*) path pattern) at i-click ang Edit.
• Sa Origin and origin groups dropdown, piliin ang failover-group.
• I-click ang Save changes.

Hintayin na maging Enabled ulit ang distribution status. Mga 2-5 minuto ito.

Bakit kailangan i-update ang behavior?

Ang origin group ay isang configuration na naghihintay lang na gamitin. Ang cache behavior ang nagdedetermine kung aling origin (o origin group) ang tatanggap ng requests. Kung hindi mo i-update ang behavior, mag-se-serve pa rin ang distribution mula sa isang origin lang.

Bago mo i-test, ano sa tingin mo ang makikita mo kapag in-access mo ang CloudFront URL? Mag-iiba ba ang response?

• I-open ang iyong CloudFront URL sa browser (https://[your-cloudfront-domain].cloudfront.net).

Dapat makita mo pa rin ang response mula sa iyong primary region (us-east-1). Dahil healthy pa ang primary origin, ang CloudFront ay nag-se-serve pa rin mula doon. Ang failover ay mangyayari lang kapag may error ang primary.

Nakakita ka ba ng error sa CloudFront URL?

Kung nakikita mo ang error page, posibleng hindi pa tapos ang deployment. I-check ang Last modified field sa General tab. Dapat ito ay nagpapakita na ng date/time, hindi "Deploying".

Kung tapos na ang deployment at may error pa rin, subukang mag-open ng incognito/private window para ma-bypass ang cache.

help me troubleshoot why my CloudFront URL is showing an error after I configured the origin group

Ang origin group mo ay ready na. Sa ngayon, nag-se-serve pa rin ang CloudFront mula sa us-east-1 dahil healthy ito. Sa susunod na step, si-simulate natin ang outage at panoorin ang magic ng automatic failover.

Simulate a Regional Outage and Test Failover

Ang CloudFront distribution mo ay naka-configure na para sa failover, pero hindi mo pa napatunayan na gumagana talaga ito. Ang configuration na walang test ay assumption lang.

Sa step na ito, i-pa-pause natin ang primary App Runner service para i-simulate ang regional outage. Panoorin natin ang CloudFront na automatic na nag-switch sa secondary region nang walang manual intervention.

In this step, get ready to:

• I-pause ang primary App Runner service para i-simulate ang regional outage.
• I-verify ang automatic failover sa secondary region gamit ang CloudFront URL.
• I-test ang automatic failback kapag bumalik ang primary region.

I-pause ang primary App Runner service

Para i-simulate ang isang real regional outage, i-pa-pause natin ang App Runner service sa us-east-1. Kapag naka-pause ang service, hindi na ito tumatanggap ng traffic, kaya para na itong nag-down ang buong region.

• Sa AWS Console, i-search ang App Runner at i-click ito.
• Siguraduhing naka-set ang region sa us-east-1 (upper right corner ng console).
• I-click ang iyong App Runner service name para buksan ito.
• I-click ang Actions button.
• Piliin ang Pause.
• I-confirm ang pause kapag lumabas ang confirmation dialog.

Ang status ng service ay magbabago mula Running sa Operation in progress, at eventually sa Paused.

What happens when you pause an App Runner service?

Kapag nag-pause ka, nire-reduce ng App Runner ang compute capacity sa zero at tinatanggal ang ephemeral storage. Hindi na ito nagse-serve ng traffic.

Para sa CloudFront, parang nag-down ang origin. Magtri-trigger ito ng failover criteria dahil hindi na makakatanggap ng successful response ang CloudFront mula sa origin na ito.

• Hintayin na mag-change ang status sa Paused bago magpatuloy.

Hindi nagbabago ang status?

Kung nananatiling Operation in progress ang status pagkatapos ng 2 minuto, i-refresh ang page. Minsan hindi automatic na nag-u-update ang console display.

Help me troubleshoot my App Runner service not changing to Paused status

I-test ang failover

Ngayong naka-pause na ang primary origin, oras na para makita kung gagana ba talaga ang CloudFront origin group. I-test natin gamit ang CloudFront URL mo.

How does CloudFront detect the failure?

Kapag nag-request ang CloudFront sa primary origin at nakatanggap ng HTTP status code na kasama sa failover criteria mo (404, 500, 502, 503, 504), automatic itong mag-re-route ng request sa secondary origin.

Ang default connection timeout ay 30 seconds (3 connection attempts of 10 seconds each). Pero kapag nakatanggap kaagad ng error status code, mas mabilis ang failover.

• Maghintay ng mga 30-60 segundo pagkatapos maging Paused ang service.

Bago mo i-refresh ang CloudFront URL, isipin muna: ano sa tingin mo ang makikita mo sa browser? Ang dating response mula sa us-east-1, o ibang bagay?

• I-open ang isang bagong incognito o private window sa browser (para walang cached response).
• I-paste ang iyong CloudFront distribution URL at pindutin ang Enter.

Dapat makita mo na ngayon ang response ay mula sa us-west-2 (secondary region). Ang CloudFront ay automatic na nag-route ng traffic sa secondary origin dahil hindi na makakapag-serve ang primary.

Bakit incognito window?

Ang CloudFront ay nag-ca-cache ng responses sa edge locations. Kung gagamitin mo ang regular browser window, posibleng makikita mo pa rin ang cached response mula sa primary region. Ang incognito window ay walang existing cache, kaya fresh request ang gagawin nito.

Nakikita mo pa rin ang response mula sa us-east-1?

Kung hindi pa nag-switch ang response, subukan ang mga ito:

• Siguraduhing incognito o private window ang ginagamit mo.
• Maghintay ng karagdagang 30 segundo at subukang i-refresh ulit. Ang CloudFront ay may cached response na kailangan pang mag-expire.
• I-verify na talagang Paused na ang App Runner service sa us-east-1. Kung Operation in progress pa rin, hindi pa fully paused.

Help me troubleshoot why CloudFront is not failing over to my secondary origin

I-test ang failback

Ang failover ay kalahati lang ng kwento. Sa production, kapag bumalik ang primary region, gusto mong automatic na bumalik ang traffic doon. I-test natin ang failback sa pamamagitan ng pag-resume ng primary service.

• Bumalik sa App Runner console sa us-east-1 region.
• I-click ang iyong paused service.
• I-click ang Actions button.
• Piliin ang Resume.
• Hintayin na mag-change ang status sa Running (mga 1-2 minuto).

Pagkatapos maging Running ulit ang service, kailangan mo pang maghintay ng karagdagang 30-60 segundo bago i-test. Kailangan ng CloudFront ng oras para ma-detect na healthy na ulit ang primary origin.

Bago mo i-refresh ang CloudFront URL, ano sa tingin mo ang mangyayari? Babalik ba kaagad ang traffic sa us-east-1?

• Maghintay ng 30-60 segundo pagkatapos maging Running ang service.
• I-open ang isang bagong incognito window at i-paste ang CloudFront URL.

Dapat makita mo na bumalik na ang response sa us-east-1 (primary region). Ito ang automatic failback. Dahil healthy na ulit ang primary origin, ginagamit na ulit ito ng CloudFront bilang priority 1.

Hindi pa bumabalik sa us-east-1?

• I-verify na Running na talaga ang service sa App Runner console. Kung Operation in progress pa, hindi pa fully resumed.
• Subukang maghintay ng karagdagang 1 minuto. Ang CloudFront ay may short caching period para sa failover state.
• Gumamit ng panibagong incognito window para matiyak na walang cached response.

Help me troubleshoot why CloudFront is not failing back to my primary origin

Ngayong napatunayan na ang failover at failback, tingnan natin ang monitoring data para makita ang buong timeline ng nangyari.

• Bumalik sa CloudFront console.
• I-click ang iyong failover-demo distribution.
• Pumunta sa Monitoring tab.

Sa Monitoring tab, makikita mo ang error rate metrics na nag-spike noong nag-failover. Ito ang visual proof ng exact moment na nag-switch ang traffic mula sa primary patungo sa secondary origin.

What should I see in the Monitoring tab?

Hanapin ang error rate chart. Makikita mo ang spike na tumutugma sa panahon na naka-pause ang primary service. Pagkatapos mag-failover, babalik sa normal ang error rate dahil matagumpay na nagse-serve ang secondary origin.

Ang data na ito ay crucial sa production. Sinasabi nito sa'yo kung kailan exactly nangyari ang outage at gaano katagal bago nag-recover ang system.

What you just proved

Na-prove mo na ang CloudFront origin group ay gumagana bilang automatic failover mechanism. Walang DNS propagation delay. Walang manual intervention. Ang CloudFront ay nag-detect ng failure sa edge level at nag-route sa healthy origin within seconds.

Tandaan: ang failover ay gumagana lang para sa GET, HEAD, at OPTIONS HTTP methods. Hindi ito gagana para sa POST, PUT, o DELETE requests.

Mayroon ka na ngayong fully tested disaster recovery system. Napatunayan mo na kapag nag-down ang isang region, automatic at mabilis ang failover. Sa Secret Mission, gagawa ka ng alerting system para malaman mo kaagad kapag nangyari ang failover sa production.

Secret mission

Mag-set up ng CloudWatch Alarm para sa Failover Alerting

Automatic failover is great. But what if you don't know it happened? In this secret mission, you'll build an alert system that emails you the moment CloudFront detects an origin failure. Real production systems need this kind of visibility.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. Ang App Runner services mo ay may charges habang Running, pero ang CloudFront distribution ay covered ng Free Tier (1 TB data transfer + 10M requests/month).

Cost warning

Ang dalawang App Runner services mo ay may ongoing compute charges habang nasa Running state. Kung hindi mo na kailangan ang project na ito, i-pause o i-delete ang services para maiwasan ang unexpected charges.

Resources you used:

• CloudFront distribution (failover-demo).
• App Runner service sa us-east-1.
• App Runner service sa us-west-2.
• CloudWatch alarm (kung ginawa sa Secret Mission).
• SNS topic (kung ginawa sa Secret Mission).

Keep everything running

No action needed. Piliin ito kung actively building ka pa o gusto mong i-test ulit ang failover setup mo in the future.

• Ang dalawang App Runner services ay mananatiling Running at may minimal compute charges.
• Ang CloudFront distribution ay mananatiling Enabled at covered ng Free Tier para sa normal testing traffic.
• Ang CloudWatch alarm at SNS topic (kung ginawa) ay mananatiling active nang walang significant cost.

Pause - I'll come back to this later

I-pause ang App Runner services para walang compute charges. Ang CloudFront distribution ay mananatiling active pero walang significant cost dahil walang traffic.

• Pumunta sa App Runner sa us-east-1 region.
• I-click ang iyong service, piliin Actions, tapos Pause.
• I-confirm ang pause action.
• I-switch ang region sa us-west-2 at ulitin ang pause para sa second service.
• Ang CloudFront distribution ay pwedeng iwanang Enabled. Walang charges kung walang traffic.

Delete - I don't want to use this again

I-remove ang lahat ng project resources para walang natitirang charges. Sundin ang mga steps na ito sa tamang order.

• CloudFront: Pumunta sa CloudFront console. Piliin ang failover-demo distribution. I-click Disable at i-confirm. Hintayin na mag-update ang Last modified timestamp (mga ilang minuto). Pagkatapos, piliin ulit ang distribution at i-click Delete, tapos i-confirm ang deletion.
• App Runner (us-east-1): Pumunta sa App Runner sa us-east-1. I-click ang iyong service. Piliin Actions, tapos Delete. I-type ang confirmation text at i-click Delete.
• App Runner (us-west-2): I-switch ang region sa us-west-2. I-click ang iyong service. Piliin Actions, tapos Delete. I-type ang confirmation text at i-click Delete.
• CloudWatch alarm (kung ginawa): Pumunta sa CloudWatch console. I-click Alarms sa left navigation. Piliin ang iyong alarm. I-click Actions, tapos Delete.
• SNS topic (kung ginawa): Pumunta sa SNS console. I-click Topics sa left navigation. Piliin ang iyong topic. I-click Delete at i-confirm.

That's a Wrap!

That's a Wrap!

Magaling! Nagawa mo na ang isang production-grade disaster recovery system gamit ang CloudFront origin groups. Ang app mo ngayon ay may automatic failover na nag-switch ng traffic sa pagitan ng dalawang AWS region sa loob ng ilang segundo, nang walang manual intervention.

You've learned how to:

• Gumawa ng CloudFront distribution na may origin group na nag-co-configure ng dalawang origins (us-east-1 at us-west-2) para sa automatic failover gamit ang isang global URL.
• Nag-simulate ng regional outage sa pamamagitan ng pag-pause ng App Runner service at nakita mo mismo ang instant failover at automatic failback nang walang DNS propagation delays.
• Na-verify ang edge-level failover monitoring gamit ang CloudFront metrics para makita kung kailan exactly nangyari ang failover events.
• Secret Mission: Nag-set up ng CloudWatch alarm na nag-e-email sa'yo via SNS kapag may detected na failover event.

Ready to quiz yourself?