Case Study
HAMS reached out with a one-line brief: "We're paying too much. Can you take a look?" Behind that sentence was a serverless API that had been running in production for years, handling real-time geolocation resolution for multiple systems across the business. The bill was growing month over month, and no one had a clear picture of which part of the architecture was responsible.
Before touching anything, Renaiss spent the first weeks pulling real production metrics, mapping cost drivers, and building a precise picture of how the API actually behaved at scale. That assessment phase was the whole job. The numbers revealed two completely different problems: one cost that scaled correctly with business growth, and one structural inefficiency that would keep compounding regardless of what else was optimized.
CloudFront was processing 1.64 billion requests per month with a 97% cache hit ratio. Replacing it with API Gateway's native caching — a seemingly simpler option — would have cost $5,800–$6,475/month before accounting for degraded performance across geographies. CloudFront stayed. The EFS dependency didn't. Every Lambda invocation was mounting a remote volume to query the geolocation database — 47 million times a month. We migrated the function to a container image that packages both the code and the full database together. Remote I/O disappeared from the hot path, execution time dropped by 3×, and the billing line stopped compounding. The daily update cycle was preserved through an automated pipeline that rebuilds and deploys the image every 24 hours.
CloudFront wasn't the problem. The assessment showed a 97% cache hit ratio and a cost structure proportional to real business growth. Touching it would have cost more.
Removing the EFS network call from the critical path eliminated the main latency driver. The function now reads from a local file packaged in the container image.
47 million monthly invocations were mounting a remote volume at runtime. Migrating to a container image with an embedded database eliminated the ETDataAccess-Bytes billing line entirely.
The update cycle was preserved without the EC2 instance. A pipeline rebuilds the container image with the updated geolocation database every day and deploys it automatically.
The update cycle was preserved without the EC2 instance. A pipeline rebuilds the container image with the updated geolocation database every day and deploys it automatically.
The engagement surfaced a gap in observability that wasn't visible in the original brief. Alerting was put in place before handoff, not after the next incident.
Infrastructure Assessment
We pulled real production metrics before making any recommendation. Cost attribution required understanding actual traffic patterns, cache behavior, and billing mechanics — not assumptions about what the architecture was supposed to do.
Cost Driver Analysis
Two separate cost centers emerged with different root causes. Distinguishing between a cost that scales correctly and one that compounds structurally determined which intervention made sense and which would have been a mistake.
CloudFront Evaluation
Two separate cost centers emerged with different root causes. Distinguishing between a cost that scales correctly and one that compounds structurally determined which intervention made sense and which would have been a mistake.
Lambda Migration to Container Image
We migrated the Lambda function from a traditional deployment package to a container image that embeds the full geolocation database. Remote I/O was removed from the execution path; execution time dropped by 3×.
Pipeline Automation & IaC
The EC2-based update script was replaced by an automated pipeline that rebuilds and deploys a new container image daily. The full stack was imported into Terraform, and alerting was implemented before handoff.
Alerting coverage implemented
The engagement surfaced a gap in observability that wasn't visible in the original brief. Alerting was put in place before handoff, not after the next incident.
Nearshore means hiring a tech team in a country geographically and culturally close to yours — typically within 1–3 time zones. For US companies, that means Latin America. You get real-time collaboration, overlapping work hours, and engineers who operate in English, without the communication friction that comes with offshore teams 10+ hours away.
We're based in Argentina — UTC-3. That means 4–5 hours ahead of the US West Coast and 2 hours ahead of the East Coast. In practice, we maintain a daily overlap of 4–6 hours with most US-based teams, which covers standups, code reviews, and real-time problem-solving without anyone working at midnight.
Our work sits at the intersection of cloud infrastructure, application architecture, and AI. Concretely: cloud-native architecture design, infrastructure automation, platform engineering, data pipelines, and GenAI integration. We don't do generic cloud support — we build and run systems that need to scale.
Our primary depth is in AWS. We also work with Azure and GCP depending on the client's existing stack — the goal is always to work within your environment, not to push a preferred vendor.
Yes — and it's one of the problems we work on most. App modernization usually means one or more of the following: breaking a monolith into services, re-platforming to cloud-native infrastructure, replacing outdated dependencies, or improving the CI/CD pipeline so your team can ship faster. We start with a technical assessment before recommending any approach.
© 2026 - Renaiss with love
