Most services today are developed with a microservice architecture where each component is deployed with multiple replicas on servers all over the world. When requests go between service components, the role of a load balancer is to route each request to the least loaded instance of the target component. There are many algorithms that evaluate different parameters and select an instance from those. One approach is to optimize for latency, i.e., choose the instance that will result in the lowest latency. However, this approach does not take into consideration the geographical distribution of servers, or when requests have to cross networking boundaries, i.e., go from one physical data center to another. Crossing networking boundaries comes with an increased cost as connecting two data centers far apart is an expensive task. Therefore, the cloud computing provider will charge this traffic more than when just sending traffic within a single data center. This study set out to use Google Traffic Director, a service mesh that has information about the whole system and can, therefore, offer locality-aware load-balancing that tries to minimize the amount of traffic that crosses networking boundaries. This is compared to a latency-based algorithm without a service mesh architecture, namely Expected Latency Selector. The study was set up to evaluate how the different approaches performed in terms of cost, latency, and resilience. This evaluation was performed by setting up two testing environments where both load-balancing algorithms could run and relevant metrics were collected. This was then tested in three different scenarios: no disturbance, random delay in a zone, and the final being a zone failing all requests. Results show that in a perfect environment, a locality-aware approach with Traffic Director can reduce the networking cost to an optimal level by only sending a negligible amount of requests cross-zone, while still performing equally well as the latency-based approach in terms of latency. However, when a delay or failure is introduced, Traffic Director, in our setup, keeps the same behavior of prioritizing the locality instead of distributing requests to other zones to even out the latency and circumvent the faulty servers. / De flesta online tjänsterna idag är utvecklade med en mikrotjänst arkitektur där varje komponent är distribuerad med många kopior på servrar över hela världen. När en förfrågan går mellan en tjänsts komponenter, är en lastbalanserares roll att dirigera en förfrågan till den minst belastade instansen av målkomonenten. Det existerar många algoritmer som evaluerar olika parametrar och väljer en instanser på det sättet. Ett tillvägagångssätt är att optimera för latens d.v.s. välja den instansen som kommer att ge lägst latens. Detta tillvägagångssätt kommer däremot inte ta den geografiska distributionen av servrar eller när en förfrågan behöver korsa nätverksgränser i åtanke. Att korsa nätverksgränser kommer med en öka kostnad eftersom att förbinda två datacenter är omständigt och dyrt. Därav kommer molntjänstleverantören att ta mer betalt för denna typ av nätverkstrafik än trafik som håller sig inom ett datacenter. Denna studie använde sig därav av Googles Traffic Director, en service mesh som erbjuder lokalitets-medveten lastbalansering som försöker minimera mängden trafik som korsar nätverksgränser, och jämför det med en latens-baserad algorithm kallad Expected Latency Selector. Studie evaluerar hur de två olika tillvägagångsätten presterar sett till kostnad, latens och resiliens. Evalueringen genomfördes genom att sätta upp två testmiljöer där båda algoritmerna kunde köras och relevant data samlades. Detta kördes sedan under tre olika scenarion: ingen störning, slumpmässig fördröjning och en zon där varje förfrågan misslyckas. Resultaten indikerar att in en perfekt miljö kan ett lokalitets-medvetet tillvägagångssätt med Traffic Director reducera nätverkskostnaden till en optimal nivå genom att endast skicka en försumbar mängd förfrågan till andra zoner, och samtidigt prestera ekvivalent med latens-baserade tillvägagångssättet sett till latens. Däremot, när en fördröjning eller misslyckande av förfrågan introduceras kommer Traffic Director att behålla samma beteende av att prioritera lokalitet istället för att distribuera förfrågningar till andra zoner för att jämna ut latensen och kringgå felaktiga servrar.