For companies on AWS, or moving to it from other clouds or their own servers
A lower AWS bill and a simpler cloud setup
Cloud costs grow quietly: resources nobody switched off, oversized servers, data transfer nobody planned for, several clouds where one would do. I find out where the money goes, plan the savings and the migration, implement them as code, and hand over a setup your team can run.
Typical situations
Most cost problems are not one big mistake but many small ones that add up.
The bill keeps growing
Spending rises month after month, and nobody can say which product, team or environment it belongs to.
Several clouds, several bills
Workloads are spread over AWS, Azure, Google Cloud or your own servers, each with its own tools, contracts and know-how.
Test environments run like production
Development and staging run around the clock, at production size, although they are used a few hours a day.
Infrastructure nobody wants to touch
Set up by hand years ago, barely documented, and therefore risky and expensive to change.
Kubernetes without a plan
Clusters reserve far more capacity than the applications use, or run workloads that a simpler service would handle.
Case study: Talk-A-Bot
Talk-A-Bot Zrt., a conversational AI software company
2023–2025 · cloud infrastructure architect and migration lead
Talk-A-Bot ran its platform and its clients’ projects on three clouds: Google Cloud, Azure and AWS. I designed the consolidation onto a single, standardised AWS platform on Kubernetes (EKS) and carried it out.
- lower infrastructure costs
- 77%
- clouds consolidated onto one AWS platform
- 3 → 1
- fewer operational issues, through self-service
- 50%
The starting point
Three cloud providers, each with its own setup and its own bill; deployments that depended on manual steps; and a microservice platform that had to keep serving clients during the move.
What I did
- Designed the target platform on AWS EKS, with the whole infrastructure in Terraform and managed through Git
- Moved the client projects from Google Cloud, Azure and AWS to the new platform step by step
- Standardised deployments with shared Helm charts, so the teams could deploy on their own
- Encrypted and authenticated service-to-service traffic with Istio in strict mutual-TLS mode; secrets through External Secrets, cluster policies with Kyverno
- Introduced GitOps deployments with ArgoCD and staging environments: fast, repeatable and reviewable releases
Technology
- AWS EKS
- Terraform
- Helm
- ArgoCD
- Istio
- Kafka
- Kyverno
- External Secrets
- GitHub Actions
How the work is organised
Three phases, each with a written result. You decide after every phase whether to continue.
Cost and architecture review
Where the money goes, and why.
- Read-only access to billing and to the AWS accounts
- Costs broken down by service, environment and team
- A list of savings, each with its effort and its risk
- Architecture and security findings that affect costs
Savings and migration
The plan, carried out as code.
- Quick wins first: unused resources, right-sized servers, schedules for test environments
- Commitment discounts (Savings Plans) once usage is stable
- Migration or consolidation onto AWS, step by step
- Infrastructure in Terraform, deployments through CI/CD
Handover and training
Your team runs it and keeps the costs in view.
- Documentation and a walkthrough of the new setup
- Budgets, alerts and cost allocation tags, so overruns show up early
- Training for your developers and operators
- Optional ongoing operations and regular cost reviews
Scope and working model
Measured first
Savings are estimated from your own usage data, not from rules of thumb, and every recommendation comes with its effort and its risk.
Infrastructure as code
Changes go through Terraform and version control: reviewable, repeatable and documented, with no manual steps left behind.
Location and hours
Based in Alicante, Spain, working remotely with teams across Europe and beyond, on Central European Time (CET/CEST). Engagements in English or Spanish.
Confidentiality and access
A non-disclosure agreement is in place before any system access. Access is least-privilege and time-bound, and no production change is made without your agreement.
Outside the scope
- Software development: writing or rewriting application code. Where a code change would save money, I describe it and your developers implement it.
- Reselling cloud capacity or licences, and savings figures promised before the review.
I work as an independent consultant on AWS infrastructure, Kubernetes, CI/CD and automated compliance controls. See experience
Frequently asked questions
How much can we save?
That depends on where the costs come from, which is exactly what the review shows. The 77% at Talk-A-Bot came from consolidating three clouds into one; a single, well-run AWS account has less to gain. I don’t quote a figure before seeing the data.
Do you need access to our AWS account?
For the review, read-only access to billing and to the accounts is enough. Later changes are made only with your agreement, and through infrastructure as code wherever possible.
Will you change our application?
No. I work on the infrastructure: accounts, networks, clusters, deployments. If an application change would save money, for example caching or a different database setting, I describe it and your developers implement it.
Do we need Kubernetes?
Not necessarily. For a handful of services, managed options such as Amazon ECS or AWS Lambda are often simpler to run. The review recommends what fits the workload and the team.
We use Azure or Google Cloud. Can you help?
Yes, if the goal is to move the workloads to AWS: the Talk-A-Bot migration started from both. For ongoing work, I focus on AWS.
Can our team run the setup afterwards?
That is the aim. The handover includes documentation and training, and the setup uses widely known tools such as Terraform, Kubernetes and GitHub Actions instead of custom scripts.
Schedule a consultation
Describe your setup briefly: which clouds, roughly what you spend, and what worries you — the costs, a migration, or both. Please do not send passwords or access details through this form.