Atmora Tech

Cloud & Platform

AWS, built by people
who read the bill

We build and run AWS estates for enterprises: account structure, EKS platforms, Aurora fleets and the cost model that keeps all of it affordable. Deep on the services you will genuinely use, blunt about the ones you will not.

Overview

AWS engineering from Organizations and Control Tower down to Graviton instance sizing.

AWS ships around 240 services. A well-run enterprise estate uses perhaps 35 of them, and most of the discipline is in refusing the rest. We work with the primitives that have proven operationally boring at scale: EC2 and EKS, Aurora and RDS, S3, SQS, Lambda, Step Functions, and IAM done properly, which is the hard one.

Most of what goes wrong on AWS is identity or network. Roles that accumulate wildcard actions, cross-account trust nobody can draw on a whiteboard, VPC peering meshes that make an address collision inevitable. We design both explicitly, express them in Terraform, and enforce them with service control policies so a mistake fails at deploy time.

On cost we look at the same three things every time: instances running at 6 per cent utilisation, storage sitting on the wrong class, and NAT gateway charges from traffic that should never have left the VPC. Commitment purchases come last, after workloads have been right-sized. Buying reservations for waste locks the waste in for three years.

38%
compute cost cut after right-sizing and Graviton migration
1.9 days
average EKS minor version upgrade, rehearsal to production
3.5 hrs
from account request to a compliant, network-attached account

Capabilities

What this covers

Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.

  • Organizations and Control Tower

    Account vending, organisational units aligned to blast radius rather than the org chart, service control policies, and a break-glass account with its own separate alerting path.

  • EKS platform engineering

    Cluster design with Karpenter for node provisioning, IRSA for pod identity, and upgrade rehearsals on a booked schedule so Kubernetes version support never expires unnoticed.

  • Data services on AWS

    Aurora PostgreSQL and MySQL, DynamoDB access pattern modelling, S3 lifecycle and storage class policy, and Glue or Athena in the cases where a full warehouse would be overkill.

  • Serverless and event architecture

    Lambda, EventBridge and Step Functions for workloads with uneven load. We will also tell you when a small container running continuously is cheaper and considerably easier to debug.

  • Security and compliance controls

    GuardDuty, Security Hub, CloudTrail organisation trails and Config rules wired into a real triage rota. Findings that nobody owns are worse than having no findings at all.

  • Cost engineering and commitments

    Right-sizing, Graviton migration where the workload supports it, and a commitment ladder across Savings Plans and Reserved Instances sized to your genuine baseline rather than your peak.

Deliverables

What you get

  • Terraform modules for account vending, VPC, EKS and data services
  • IAM role catalogue with permission boundaries and the SCP set
  • EKS cluster upgrade runbook and rehearsal record
  • Cost model with a right-sizing backlog and commitment purchase plan
  • Security findings triage rota and escalation matrix
  • Well-Architected review findings with named owners and dates

Stack

What we build it with

  • Amazon EKS
  • Karpenter
  • Aurora PostgreSQL
  • DynamoDB
  • AWS Lambda
  • Amazon EventBridge
  • AWS Step Functions
  • AWS Control Tower
  • Amazon GuardDuty
  • AWS Graviton
  • Terraform
  • Datadog

Process

How the engagement runs

Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.

  1. Account and billing review

    We start with twelve months of Cost and Usage Report data and the IAM configuration. Both say more about how an organisation works than any interview does.

  2. Design against constraints

    Target account structure, network and identity model, presented with the trade-offs named: what each choice costs, and what it makes harder eighteen months later.

  3. Build and codify

    Everything lands as Terraform in your own repository, with CI checks, drift detection and modules versioned so that an upgrade arrives as a pull request.

  4. Workload onboarding

    Two or three real workloads move onto the new foundation with your engineers pairing, which is how the modules become genuinely usable rather than theoretically correct.

  5. Optimise and operate

    Right-sizing runs first, commitments second. We hand over a monthly cost review with named owners and a backlog that keeps working after we have gone.

When this is the wrong engagement

If your workload is a handful of stateless web services with predictable traffic, a managed platform such as App Runner or Fly.io will cost far less to operate than anything we would build for you on raw AWS.

FAQ

Questions we get asked

We already run on AWS. What would you actually change?

Usually three things: the account boundary, the IAM model and the storage class policy. Those cut the most risk and cost for the least disruption. We would not propose re-architecting applications that run acceptably today simply because a newer service now exists.

Is Graviton worth the migration effort?

For JVM, Go, Python and Node workloads, generally yes. Expect 15 to 25 per cent better price-performance and a rebuild rather than a rewrite. For anything with x86-specific native dependencies or a vendor-supplied binary the answer is often no, and we benchmark before recommending.

Do you use AWS support or handle escalation yourselves?

Both. We triage first, because most tickets raised against AWS turn out to be configuration issues on the customer side and a badly framed ticket costs days. When it is genuinely a platform problem, we write the case with the trace data attached.

How do you stop EKS becoming a full-time job?

Fewer and larger clusters, Karpenter instead of hand-managed node groups, and an upgrade cadence booked in the calendar rather than triggered by an end-of-support email. Most teams who find EKS painful run too many clusters with bespoke configuration in each.

Related

More in Cloud & Platform

Start a project

Tell us what is
breaking.

We reply within one working day, and the first call is with an engineer who would actually work on it — not an account manager. If we are not the right studio for the problem, we will say so on that call.

Start a project