Skip to main content

29 Tekniikkaa

29Tekniikkaa
29Tekniikka logo
29Tekniikkaa

Recent Post

AWS:n pilviverkon ongelmat – VPC-yhteydet, DNS ja palveluiden väliset häiriöt

AWS-ympäristössä sovellus voi olla täysin kunnossa ja silti käyttäjälle näyttää siltä, että koko palvelu on rikki.
Tietokantaan ei päästä. API antaa timeoutin. ECS-palvelu ei löydä toista palvelua. Lambda toimii yhdessä ympäristössä mutta ei toisessa. S3:een pääsee selaimesta, mutta VPC:n sisällä oleva sovellus ei. Tai DNS-nimi ratkaistaan, mutta yhteys ei koskaan muodostu.
Näissä tilanteissa katse kääntyy helposti sovelluskoodiin. Se ei kuitenkaan aina ole oikea paikka aloittaa.
AWS:n verkkoympäristössä liikenne kulkee usean eri kerroksen läpi. VPC, subnetit, route table -reititykset, security groupit, Network ACL:t, DNS, NAT Gatewayt, load balancerit, PrivateLink-yhteydet ja eri AWS-palveluiden omat verkko-ominaisuudet muodostavat kokonaisuuden, jossa yhden asetuksen muutos voi näkyä aivan toisessa paikassa.
Juuri siksi verkkohäiriöitä on usein vaikeampi selvittää kuin aluksi näyttää.
Tässä artikkelissa keskitytään tilanteisiin, joissa AWS:n pilviverkko toimii osittain, väärin tai ei lainkaan. Erityisesti tarkastellaan VPC-yhteyksiä, DNS-ongelmia ja tilanteita, joissa usean AWS-palvelun välinen liikenne katkeaa.

Kun yhteys ei toimi, älä aloita security groupeista

➠ Yksi tavallisimmista virheistä on avata security group ja alkaa lisätä sääntöjä.
➠ Jos sovellus ei pääse tietokantaan, ensimmäinen ajatus voi olla: Sallitaanko portti 5432?
➠ Jos vastaus on ei, ongelma on löytynyt. Mutta jos vastaus on kyllä, tutkiminen ei ole vielä valmis.
➠ Liikenteen pitää ensin löytää oikea reitti. Sen jälkeen DNS-nimen pitää tarvittaessa ratketa oikeaan osoitteeseen. Vasta sen jälkeen security groupin ja muiden verkkosääntöjen merkitys voidaan arvioida kunnolla.

➠ Tuotantoympäristössä ongelma voi siis olla esimerkiksi tällainen:

Sovellus

↓

DNS

↓

Route table

↓

NAT / Internet Gateway / VPC endpoint

↓

Security Group

↓

Kohdepalvelu

➠ Jos yksi kohta ketjusta ei toimi, sovelluksen näkökulmasta kaikki näyttää samalta: yhteys epäonnistuu.
➠ Tämän takia verkkovian selvittämisessä kannattaa erottaa toisistaan ainakin kolme kysymystä:
1. Löytääkö sovellus kohteen?
2. Löytääkö verkko reitin kohteeseen?
3. Saako liikenne kulkea reittiä pitkin?
➠ Nämä ovat eri asioita.

VPC näyttää yksinkertaiselta, kunnes ympäristö kasvaa

Pienen AWS-projektin VPC voi olla hyvin suoraviivainen. Siinä saattaa olla muutama subnet, ECS-palvelu, tietokanta ja internetiin menevä liikenne.
Kun ympäristö kasvaa, kuva muuttuu nopeasti.
Samaan kokonaisuuteen voi tulla esimerkiksi:
  • julkisia ja yksityisiä subnet-verkkoja
  • useita Availability Zoneja
  • NAT Gatewayt
  • Application Load Balancer
  • RDS
  • ECS tai EKS
  • Lambda-funktioita
  • VPC endpointteja
  • erillisiä VPC-verkkoja
  • Transit Gateway
  • VPN- tai Direct Connect -yhteyksiä
  • keskitetty DNS
  • useita AWS-tilejä
Tässä vaiheessa pelkkä “VPC toimii” ei oikeastaan kerro kovin paljon.
Oleellista on tietää, mikä liikenne kulkee missäkin.

Public subnet ei tarkoita automaattisesti internet-yhteyttä

Termit aiheuttavat tässä paljon sekaannusta.
Subnetia kutsutaan yleensä julkiseksi silloin, kun sen route table sisältää reitin Internet Gatewaylle. Se ei kuitenkaan tarkoita, että jokainen subnetissa oleva resurssi olisi suoraan internetistä saavutettavissa.
Esimerkiksi EC2-instanssi tarvitsee myös julkisen IPv4-osoitteen tai muun soveltuvan yhteysratkaisun, ja liikenteen pitää olla sallittu verkkosäännöissä.
Vastaavasti private subnetissa oleva palvelu voi päästä internetiin NAT Gatewayn kautta ilman, että palvelu itse on julkisesti saavutettavissa.
Tämä on yksi AWS:n verkkosuunnittelun perusasioista, mutta käytännössä juuri näissä eroissa syntyy paljon väärinkäsityksiä.

Private subnetin ulospäin menevä liikenne

➠ Moni tuotantopalvelu kannattaa sijoittaa private subnetiin. Se on järkevää esimerkiksi silloin, kun sovelluksen ei tarvitse vastaanottaa liikennettä suoraan internetistä.
➠ Silloin syntyy kuitenkin toinen kysymys:
➠ Miten palvelu pääsee ulos?
➠ Jos ECS-taski tai EC2-instanssi tarvitsee yhteyden ulkopuoliseen API-palveluun, liikenteelle täytyy olla toimiva reitti.

➠ Tyypillinen ratkaisu on:

Private subnet

↓

Route table

↓

NAT Gateway

↓

Internet Gateway

↓

Internet

➠ Jos route table puuttuu tai osoittaa väärään NAT Gatewayhin, yhteys voi epäonnistua kokonaan.
➠ Sama ongelma voi näkyä myös sovelluksen riippuvuuksissa. Esimerkiksi kontti käynnistyy normaalisti, mutta käynnistyksen aikana tarvittava ulkoinen API-kutsu jää odottamaan.
➠ Sovelluksen lokissa näkyy silloin helposti vain timeout.
➠ Todellinen ongelma voi olla verkossa.

NAT Gateway ei korjaa kaikkea

NAT Gatewayn kanssa tehdään joskus liian suoraviivainen oletus:
Private subnet + NAT Gateway = internet toimii.
Todellisuudessa mukana on useita ehtoja.
Private subnetin route table tarvitsee oikean reitin NAT Gatewaylle. NAT Gatewayn täytyy olla käytettävissä, ja sen oma subnet tarvitsee reitin Internet Gatewaylle.
Myös security groupien, Network ACL -sääntöjen ja DNS:n täytyy olla kunnossa.
Lisäksi NAT Gateway ei ole ratkaisu kaikkeen AWS-palveluiden väliseen liikenteeseen.
Jos sovellus käyttää esimerkiksi S3:a tai DynamoDB:tä, VPC endpoint voi olla arkkitehtuurin kannalta parempi ratkaisu kuin liikenteen kierrättäminen NAT Gatewayn kautta.
Tässä kohtaa verkon suunnittelu alkaa liittyä myös kustannuksiin.
Jos suuri määrä private subnetissa olevia palveluita siirtää liikennettä NAT Gatewayn kautta AWS:n sisäisiin palveluihin, ratkaisu voi olla teknisesti toimiva mutta tarpeettoman kallis.

DNS-ongelmat ovat usein vaikeampia kuin porttiongelmat

DNS on yksi niistä asioista, jotka toimivat pitkään niin huomaamatta, ettei niitä juuri ajatella.
Sitten jokin muuttuu.
Sovellus yrittää yhdistää osoitteeseen:
database.internal.example
ja alkaa saada virhettä:
Name or service not known
Tässä ei vielä ole kyse security groupista.
Jos nimeä ei pystytä ratkaisemaan IP-osoitteeksi, liikenne ei pääse edes siihen vaiheeseen.
AWS:ssä DNS liittyy esimerkiksi VPC:n DNS-asetuksiin, Route 53 Resolveriin, private hosted zoneihin ja mahdollisiin hybridiyhteyksiin.

VPC:n DNS-asetukset kannattaa tarkistaa ensin

VPC:n DNS hostnames- ja DNS resolution -asetukset vaikuttavat siihen, miten nimien ratkaisu toimii VPC-ympäristössä.
Jos nämä asiat on rakennettu eri tavalla eri ympäristöihin, seurauksena voi olla hyvin hämmentävä tilanne:
  • development toimii
  • staging toimii
  • production ei toimi
Sovelluskoodi on sama.
Ympäristö ei ole.
Tällaisessa tilanteessa kannattaa verrata ympäristöjen verkkokonfiguraatioita eikä lähteä muuttamaan sovellusta sokkona.

Private hosted zone voi olla oikea ratkaisu – tai väärin yhdistetty

➠ Route 53:n private hosted zoneilla voidaan hallita sisäisiä DNS-nimiä VPC:n sisällä.
➠ Esimerkiksi:
api.company.internal
database.company.internal
payments.company.internal
➠ voi olla sisäiseen käyttöön tarkoitettu nimistö.
➠ Ongelma syntyy helposti, jos private hosted zone on liitetty väärään VPC:hen tai puuttuu yhdestä ympäristöstä.
➠ Silloin DNS toimii toisessa VPC:ssä mutta ei toisessa.
➠ Tilanne voi näyttää sovellustiimin silmissä tältä:
“API-palvelu on käynnissä, mutta sitä ei löydy.”
➠ Palvelu voi todellisuudessa olla täysin terve. Vain nimipalvelu ei tunne sitä siinä verkossa, josta pyyntö tulee.
➠ Tämän takia DNS:n testaaminen kannattaa tehdä suoraan siitä ympäristöstä, jossa ongelma esiintyy.
➠ Esimerkiksi kontissa tai EC2-instanssissa voidaan tarkistaa:
nslookup api.company.internal
tai:
dig api.company.internal
➠ Jos nimi ei ratkea, HTTP-clientin tai sovelluskoodin tutkiminen ei ole vielä ensimmäinen tehtävä.

"DNS toimii, mutta yhteys ei" on tärkeä havainto

Tämä on yksi hyödyllisimmistä rajauksista verkkovian tutkimisessa.
Jos:
dig database.company.internal
palauttaa oikean IP-osoitteen, DNS ei todennäköisesti ole enää pääongelma.
Sen jälkeen voidaan tutkia yhteyttä.
Esimerkiksi:
nc -vz database.company.internal 5432
Tällainen testi kertoo jo enemmän kuin pelkkä sovelluksen virheilmoitus.
Jos DNS toimii mutta TCP-yhteys ei muodostu, katse siirtyy reititykseen ja liikenteen sallimiseen.
Jos TCP-yhteys muodostuu mutta sovellus ei saa vastausta, ongelma voi olla jo tietokannan, TLS:n, autentikoinnin tai sovellusprotokollan puolella.
Tällä tavalla ongelmaa voi rajata ilman, että koko ympäristöä tarvitsee käydä läpi.

Security Group ei ole sama asia kuin Network ACL

➠ AWS:n verkkosäännöissä menee helposti käsitteet sekaisin.
➠ Security Group toimii resurssitasolla ja on tilallinen. Network ACL toimii subnet-tasolla ja on tilaton.
➠ Käytännössä tämä tarkoittaa sitä, että Network ACL -sääntöjen kanssa pitää huomioida liikenteen molemmat suunnat ja tarvittavat ephemeral-portit.
➠ Jos NACL on liian rajoittava, yhteys voi epäonnistua vaikka security group näyttää täysin oikealta.

➠ Tällaisessa tilanteessa kannattaa katsoa liikenteen koko polku:

Lähde

↓

Subnet

↓

Route table

↓

NACL

↓

Security Group

↓

Kohde

➠ Yhden säännön avaaminen ei auta, jos liikenne ei koskaan pääse siihen asti.

Kun AWS-palvelut eivät löydä toisiaan

➠ Nykyisissä AWS-ympäristöissä sovellus harvoin käyttää vain yhtä palvelua.

➠ Yksi käyttäjän tekemä toiminto voi aiheuttaa ketjun:

ALB

↓

ECS

↓

RDS

↓

S3

↓

SQS

↓

Lambda

↓

ulkoinen API

➠ Jos yksi yhteys katkeaa, käyttäjä voi nähdä vain yleisen virheen.
➠ Esimerkiksi tilaussivun lataus voi onnistua lähes kokonaan, mutta yksi SQS-kutsu jää odottamaan. Lopulta koko HTTP-pyyntö aikakatkaistaan.
➠ Silloin on tärkeää selvittää, missä kohtaa ketju pysähtyy.
➠ Ei riitä, että tarkistetaan:
“Onko ECS terve?”
➠ ECS voi olla täysin terve, vaikka sen yhteys SQS:ään tai ulkopuoliseen API-palveluun ei toimisi.

VPC endpointit muuttavat liikenteen rakennetta

AWS:n omiin palveluihin voidaan käyttää VPC endpointteja. Tämä on erityisen hyödyllistä private subnet -ympäristöissä.
Esimerkiksi S3- tai DynamoDB-liikenne voidaan toteuttaa VPC:n kautta ilman, että kaikkea liikennettä tarvitsee kierrättää NAT Gatewayn kautta.
Endpoint-tyyppi ja käyttötapa vaikuttavat siihen, miten yhteys toimii.
Siksi ongelmatilanteessa kannattaa selvittää:
  • käytetäänkö endpointia
  • mikä endpoint-tyyppi on kyseessä
  • onko endpoint oikeassa VPC:ssä
  • liittyvätkö tarvittavat subnetit endpointiin
  • ovatko endpointin policy-säännöt oikein
  • ratkaiseeko DNS palvelun odotetulla tavalla
Endpoint policy voi esimerkiksi sallia liikenteen vain tiettyihin resursseihin.
Tällöin verkkoyhteys voi teknisesti olla olemassa, mutta pyyntö hylätään käytäntöjen vuoksi.

Cross-service-ongelmat ovat usein vaikeimpia

➠ Yksittäinen EC2-instanssi on suhteellisen helppo tutkia.
➠ Monipalveluympäristö ei ole.

➠ Kuvitellaan esimerkiksi tuotantopalvelu, jossa käyttäjän pyyntö kulkee näin:

Internet

↓

CloudFront

↓

ALB

↓

ECS

↓

RDS

↓

SQS

↓

Lambda

↓

S3

➠ Jos käyttäjä ilmoittaa, että “sivu on joskus hidas”, mahdollisia syitä on valtava määrä.
➠ Ongelma ei välttämättä edes esiinny jokaisella pyynnöllä.
➠ Yksi Availability Zone voi käyttäytyä eri tavalla kuin toinen. DNS-vastaus voi ohjata liikenteen eri kohteeseen. Yksi backend-palvelu voi olla kuormitettu. Ulkoinen API voi hidastua. Yksi yhteyspooli voi tulla täyteen.
➠ Tässä kohtaa lokien lukeminen yksi palvelu kerrallaan ei aina riitä.
➠ Tarvitaan korrelaatiota.

Distributed tracing auttaa löytämään oikean kohdan

Kun pyyntö kulkee usean palvelun läpi, trace-tunnisteesta tulee erittäin hyödyllinen.
Esimerkiksi:
Request ID: 7f31…
voi yhdistää saman pyynnön tapahtumat eri palveluissa.
Silloin voidaan nähdä esimerkiksi:
ALB 25 ms
ECS 40 ms
RDS 780 ms
SQS 15 ms
S3 20 ms
Tulos muuttaa tutkimuksen luonnetta.
Sen sijaan että kysytään:
“Miksi AWS on hidas?”
voidaan kysyä:
“Miksi tämä pyyntö käyttää lähes 800 ms RDS-kutsuun?”
Se on paljon parempi lähtökohta.
AWS X-Ray, CloudWatch ja OpenTelemetry-pohjaiset ratkaisut voivat olla tässä hyödyllisiä ympäristön rakenteesta riippuen.

VPC Peering ei tarkoita, että kaksi verkkoa ovat automaattisesti yhteydessä

VPC Peering on yksinkertainen konsepti, mutta käytännössä siihen liittyy useampi vaihe.
Jos VPC A:n palvelun pitäisi päästä VPC B:n tietokantaan, tarvitaan ainakin:
  • peering-yhteys
  • oikeat route table -reitit
  • liikenteen sallivat security group -säännöt
  • tarvittaessa NACL-säännöt
  • toimiva DNS-ratkaisu
Yksi puuttuva reitti riittää rikkomaan yhteyden.
Lisäksi VPC Peering ei tue kaikkia verkkotopologioita samalla tavalla kuin keskitetty Transit Gateway -malli. Kun VPC:itä ja AWS-tilejä alkaa olla paljon, verkon hallinta kannattaa suunnitella erillisenä kokonaisuutena.

Transit Gateway tuo järjestystä, mutta myös uuden vianetsintäkerroksen

➠ Usean VPC:n ympäristössä Transit Gateway voi olla järkevä tapa keskittää verkkoyhteyksiä.
➠ Sen jälkeen liikenne ei kuitenkaan kulje enää vain:
VPC A → VPC B

➠ vaan esimerkiksi:

VPC A

↓

Transit Gateway

↓

Route table

↓

VPC B

➠ Transit Gatewayn omat route table -asetukset tulevat mukaan.
➠ Jos yhteys ei toimi, pitää siis tietää sekä lähde-VPC:n että Transit Gatewayn reitityksestä.
➠ Tässä kohtaa hyvä dokumentaatio alkaa olla käytännön työkalu eikä pelkkä hallinnollinen asia.
➠ Jos kukaan ei tiedä, mikä VPC saa puhua minkäkin VPC:n kanssa, verkko-ongelmien selvittämisestä tulee nopeasti hidasta.

AWS-ympäristöissä "toimii stagingissa" ei kerro vielä paljon

Yksi käytännön ongelma on ympäristöjen välinen ero.
Esimerkiksi stagingissä voi olla:
ECS → NAT Gateway → Internet
kun tuotannossa käytetään:
ECS → VPC Endpoint → AWS service
Sovellus on sama.
Verkkopolku ei ole.
Tämän vuoksi tuotanto-ongelmaa ei aina voi päätellä vertaamalla vain sovelluksen ympäristömuuttujia.
Kannattaa verrata ainakin:
  • VPC:t
  • subnetit
  • route tablet
  • security groupit
  • NACL:t
  • DNS-asetukset
  • VPC endpointit
  • NAT Gatewayt
  • load balancerit
  • IAM-roolit ja endpoint policyt
  • AWS-tilit ja alueet
Erityisen hyödyllistä on verrata infrastruktuuria Infrastructure as Code -määrittelyihin. Jos ympäristö rakennetaan esimerkiksi Terraformilla, muutokset voidaan jäljittää paljon helpommin kuin käsin tehdyssä ympäristössä.

Tyypillinen tuotantovika: sovellus käynnistyy, mutta ei pysty tekemään työtään

Tämä on hyvä esimerkki siitä, miksi verkko-ongelmia ei kannata tutkia vain käynnistysvirheiden perusteella.
ECS-taski voi käynnistyä täysin normaalisti.
Health check voi mennä läpi.
CPU ja muisti näyttävät normaaleilta.
Silti sovellus voi olla käytännössä käyttökelvoton, jos se ei saa yhteyttä tietokantaan tai ulkoiseen palveluun.
Lokissa voi näkyä esimerkiksi: Connection timed out
Timeout ei kuitenkaan kerro, miksi yhteys aikakatkaistiin.
Mahdollisia syitä ovat esimerkiksi:
  • DNS ei ratkea
  • reitti puuttuu
  • NAT Gateway ei ole käytettävissä
  • security group estää liikenteen
  • NACL estää liikenteen
  • kohde ei kuuntele portissa
  • väärä IP-osoite
  • väärä VPC
  • väärä AWS Region
  • endpointin policy estää pyynnön
  • ulkoinen palvelu ei vastaa
Siksi timeout on oire, ei diagnoosi.

Näin itse ongelmaa kannattaa rajata tuotannossa

➠ Verkkovian selvittämisessä kannattaa välttää liian suurta korjausliikettä heti alussa.
➠ Jos kaikki säännöt avataan väliaikaisesti, NAT Gateway vaihdetaan ja DNS-asetuksia muutetaan samaan aikaan, ongelman alkuperä voi kadota näkyvistä.
➠ Parempi tapa on rajata vikaa pala kerrallaan.

Onko nimi ratkaistavissa?

Testaa DNS siitä ympäristöstä, jossa ongelma esiintyy.

Onko kohteeseen reitti?

Tarkista route table ja tarvittaessa VPC Reachability Analyzer.

Saako liikenne kulkea?

Katso security groupit ja NACL:t.

Kuunteleeko kohde?

Varmista, että palvelu tai tietokanta todella kuuntelee kyseisessä osoitteessa ja portissa.

Kulkeeko liikenne odotettua reittiä?

Tarkista NAT Gateway, VPC endpoint, Transit Gateway tai peering tilanteen mukaan.

Onko kyseessä DNS-, verkko- vai sovellusongelma?

Kun nämä erotetaan toisistaan, tutkiminen muuttuu huomattavasti helpommaksi.

Reachability Analyzer on hyödyllinen silloin, kun reittiä on vaikea nähdä

AWS:n VPC Reachability Analyzer on käytännöllinen työkalu tilanteissa, joissa yhteys pitäisi toimia mutta ei toimi.
Sen avulla voidaan analysoida, onko kahden verkkopisteen välillä mahdollinen yhteys ja missä kohdassa polku estyy.
Se ei korvaa kaikkea vianetsintää, mutta se voi säästää paljon aikaa ympäristössä, jossa on useita route tableja ja verkkosääntöjä.
Erityisen hyödyllinen se on silloin, kun ongelma näyttää ensi silmäyksellä security group -virheeltä, mutta todellinen syy on reitityksessä.

Verkkosuunnittelu vaikuttaa myös kustannuksiin

AWS-verkon tekninen toimivuus ja kustannustehokkuus kulkevat usein yhdessä.
NAT Gateway on hyvä esimerkki.
Jos suuri määrä liikennettä kulkee NAT Gatewayn kautta ilman todellista tarvetta, kustannukset kasvavat. Lisäksi arkkitehtuuri voi olla monimutkaisempi kuin olisi tarpeen.
Vastaavasti VPC endpointit voivat olla järkevä ratkaisu AWS-palveluihin suuntautuvalle liikenteelle, mutta niidenkin käyttö kannattaa suunnitella käyttötapauksen mukaan.
Verkkoa ei siis kannata rakentaa vain kysymällä:
“Saadaanko tämä toimimaan?”
Parempi kysymys on: “Miten liikenteen pitäisi kulkea, jotta ratkaisu on turvallinen, luotettava ja järkevän hintainen?”

Suomessa toimivissa yrityksissä verkon luotettavuus korostuu

➠ Suomalaisissa yritysympäristöissä AWS:ää käytetään hyvin erilaisissa ratkaisuissa. Pilveen siirtyvät esimerkiksi verkkokaupat, SaaS-palvelut, teollisuuden järjestelmät, taloushallinnon ratkaisut ja asiakasportaalit.
➠ Monessa ympäristössä AWS ei myöskään ole ainoa verkon osa.
➠ Yrityksellä voi olla edelleen omia palvelimia, toimipisteiden verkkoja, VPN-yhteyksiä tai muita järjestelmiä, joiden kanssa pilvipalveluiden pitää keskustella.
➠ Silloin DNS ja reititys muuttuvat vielä tärkeämmiksi.
➠ Esimerkiksi yrityksen sisäinen ERP voi olla omassa ympäristössään, kun uusi AWS:ssä toimiva palvelu käyttää sitä API:n kautta. Jos yhteys katkeaa, AWS-sovellus voi näyttää olevan viallinen, vaikka varsinainen ongelma on hybridiverkon toisella puolella.
➠ Tällaisissa ratkaisuissa verkkoa kannattaa käsitellä osana koko järjestelmäarkkitehtuuria eikä erillisenä infrastruktuurikerroksena.

Mitä hyvä AWS-verkkoympäristö näyttää käytännössä?

Hyvä verkko ei tarkoita sitä, että jokainen asia on monimutkainen.
Päinvastoin.
Hyvässä ympäristössä pystyy vastaamaan melko nopeasti kysymyksiin:
  • mistä tämä liikenne tulee
  • minne sen pitäisi mennä
  • mitä reittiä se kulkee
  • missä DNS-nimi ratkaistaan
  • mikä sääntö sallii liikenteen
  • mikä sääntö voi estää sen
  • miten liikenne palveluiden välillä näkyy lokissa
  • miten yhteys voidaan testata ilman sovellusta
Jos näihin kysymyksiin ei pystytä vastaamaan, ongelma ei välttämättä ole yksittäisessä AWS-asetuksessa. Verkkorakenne itsessään voi olla liian vaikea ylläpitää.
Silloin kannattaa korjata myös rakennetta, ei vain tämänhetkistä vikaa.

Lopuksi

AWS:n verkkohäiriöt ovat harvoin yhden napin painalluksella ratkaistavia ongelmia. VPC, DNS, reititys, security groupit, endpointit ja AWS-palveluiden omat verkkoasetukset vaikuttavat toisiinsa.
Siksi tuotannossa tärkeintä ei ole arvata nopeasti, mikä asetus on väärin. Tärkeämpää on pystyä seuraamaan yhden pyynnön matkaa lähtöpisteestä kohteeseen.
Kun tiedetään, että DNS toimii mutta TCP-yhteys ei, tutkimusalue pienenee.
Kun reitti on kunnossa mutta security group estää liikenteen, tiedetään seuraava korjaus.
Kun kaikki verkkotasolla toimii mutta palvelu antaa edelleen timeoutin, katse voidaan siirtää sovellukseen tai kohdepalveluun.
Tällainen rajaus kuulostaa yksinkertaiselta. Tuotannossa se säästää kuitenkin paljon aikaa.
AWS-verkon hyvä suunnittelu ei ole vain sitä, että palvelut saadaan keskustelemaan keskenään. Yhtä tärkeää on, että yhteyksien toiminta voidaan myöhemmin todentaa ja vikatilanteessa selvittää ilman arvailua.
Jos AWS-ympäristö on kasvanut usean VPC:n, AWS-palvelun, hybridiyhteyden ja tuotantopalvelun kokonaisuudeksi, verkkorakenteen läpikäynti kannattaa tehdä ennen kuin yksittäisiä ongelmia alkaa korjata yksi kerrallaan. Usein juuri siinä vaiheessa löytyy myös turhia reittejä, epäselviä riippuvuuksia ja ratkaisuja, joita ei enää tarvita.