AWS cloud and DevOps: serverless, CI/CD and cost control
ozeida designs, migrates and operates AWS infrastructure for businesses from Saltillo, Coahuila, Mexico: serverless architecture (Lambda, DynamoDB, S3, CloudFront), infrastructure as code, CI/CD pipelines with gates before production, cost control and a security baseline (identity, least-privilege permissions, encryption, tested backups). Nearshore, in US Central time.
Updated
What we do
Serverless architecture
Systems with no servers to patch: Lambda (Rust or your language), DynamoDB or Postgres, S3, CloudFront, Cognito. You pay for use, not for machines left running.
Migration to AWS
From on-prem servers, shared hosting or another cloud, in stages and with a rollback plan.
Infrastructure as code
With CDK or SAM: the whole environment rebuilds from the repository; nothing is clicked together in the console.
CI/CD with real gates
Every change passes tests, review and checks before reaching production; deployments can be rolled back.
Cost control
An inventory of what you pay for, what's unused, what can be turned off or right-sized, and budget alarms so it doesn't creep back up.
Security baseline
Accounts and least-privilege permissions, encryption, tested backups, access logging. Not sold as a separate "audit": it's part of the work.
How we work
Inventory
What you have, what it costs, what fails and what depends on what. With read-only access to your account.
Plan in stages
Each stage has a verifiable outcome (a workload migrated, a pipeline running, a lower bill) and a way back.
Execution with evidence
Every deployment records what changed and how it was verified. "Deploy succeeded" is not "the application works"; we check the second one.
Handover or operations
Documentation and a session with your team, or we keep operating it with monitoring.
SRE & observability
What you get
- Reproducible infrastructure in your repository and your AWS account.
- A CI/CD pipeline with tests, gates and reversible deployments.
- A cost report with concrete actions and budget alarms in place.
- An architecture diagram and document your team can actually read.
- Monitoring and alarms ready for ozeida Quality Control. Quality Control
Migration: assessment and cutover
Before moving anything we run an inventory with read-only access to what you have: what runs, what depends on what, what fails and what it costs. That decides what gets migrated, in what order, and what shouldn't move. The migration runs in stages; every stage has a cutover window agreed in writing, a tested rollback plan and an abort rule. We don't promise nobody will notice; we promise that if something goes wrong, you're back on the previous state.
How do you know if our infrastructure is ready to migrate to AWS?
With an inventory, not an assumption:
- What runs. Applications, databases, scheduled jobs, file shares, third-party integrations.
- What depends on what. Which app talks to which database, what runs overnight, who has access to what. Whatever isn't documented gets discovered by observing the system, not by asking.
- What fails and what hurts. Outages, backups nobody has restored, a server nobody wants to touch.
- What it costs today. Hardware, licenses, power, maintenance hours, and what it would cost on AWS using the public AWS Pricing Calculator (https://calculator.aws/) with your measured workloads.
The output is a written plan: what moves first, what moves later, what gets redesigned as serverless instead of copied as-is, and what stays where it is.
Will the migration disrupt operations?
It runs in stages so that any disruption is bounded and known in advance. Every stage has:
- An agreed cutover window. A day and time when that workload switches, chosen with the people who run the process (not month-end close, not the busiest shift).
- Checks before cutover. The workload runs on AWS in parallel or with test data first, and gets verified with the users who matter.
- A tested rollback plan. How to return to the previous state, how long it takes and who executes it. Rehearsed before cutover, not improvised during it.
- An abort rule. Which signal (an error, a response time, a report that doesn't reconcile) forces a rollback, decided beforehand so nobody argues about it at 2 a.m.
Typical order: workloads with the fewest dependencies and the most pain first (a reporting database, backups, a public site); internal applications next; the systems everyone uses all day last, with the rollback plan already rehearsed in earlier stages.
What is a rollback plan, and why does it matter more than a promise?
A rollback plan is the written, tested procedure to put a workload back where it was if the stage fails: data, DNS, access, and who does what. A "zero downtime" promise can't be backed; a rollback plan can be executed. That's why it's what we deliver.
When is migrating to AWS not worth it?
When the workload is stable, already right-sized and the on-prem cost is still lower than the AWS estimate, the inventory says so. Also when an old application can't move without a rewrite nobody is going to fund: then it's better to isolate it, back it up properly and migrate everything around it.
AWS and DevOps FAQ
Why AWS and not another cloud?
It's where we have the most experience and where the serverless model (Lambda, DynamoDB, CloudFront) gives you systems with no servers to patch and pay-per-use cost. If you're already on another cloud, we evaluate it; we don't force a migration.
What does "serverless" mean in plain terms?
AWS runs your code only when someone uses it and you pay for that use, with no machines on 24/7 and no operating system to update. For most business applications it's cheaper and easier to operate.
Can you lower our AWS bill?
We can review it with read-only access and tell you what's unused, what can be shut off and what can be right-sized, with the estimated savings per line. How much it drops depends on what's there; we don't promise a percentage before seeing the account.
Does our team need to know AWS?
Not to start. We deliver infrastructure as code and documentation; if your team wants to run it, we train them during handover. If not, we operate it.
How do you keep a deployment from breaking production?
A pipeline that runs tests and checks before deploying, reversible deployments, and post-deploy verification that the application works, not just that the deploy finished.
Do you work in our AWS account or yours?
Yours, whenever possible. The account, the data and the infrastructure belong to the client; we come in with scoped permissions.
How do you assess whether our infrastructure is ready to move to the cloud?
With a read-only inventory: what runs, what depends on what, what fails and what it costs. From that evidence we define what moves, in what order, what gets redesigned as serverless, and what shouldn't move.
Will the migration disrupt our operations?
It runs in stages, each with a cutover window agreed in writing, checks before cutover, a tested rollback plan and an abort rule. Any disruption is bounded and known in advance; if something fails, you go back to the previous state.
You may also need
AI implementation
LLM assistants and agents, automation and AI over your data, with a success metric and a hard spending cap. Nearshore team in Saltillo, Mexico.
See AI implementationCustom software
Web apps, portals and internal tools with Next.js, Rust and AWS. Code in your repo, tested and documented. Nearshore team in Saltillo, Mexico.
See custom softwareSRE & observability
Monitoring, complete alarm views, service-level objectives and incident response, with a plain-language dashboard. Nearshore SRE team in Saltillo, Mexico.
See SRE & observability
What keeps you up at night about your infrastructure?
Servers to patch, manual deployments or a bill you can't explain: tell us and we'll tell you where to start.