Cloud infrastructure and DevOps

The situation this usually starts from

• Deploys happen from someone's laptop, and that someone is on vacation next week
• The AWS console contains resources nobody remembers creating or paying for
• There are backups; nobody has ever restored one
• A regulator, auditor or enterprise customer sent a security questionnaire, and it's been open for two weeks
• “Monitoring” means a customer emails when it's down

What you get

Infrastructure as code. Your AWS infrastructure in Terraform: modular, parameterized, reviewable in pull requests. I also maintain CloudFormation-based infrastructures.

Compute sized to the need. ECS on Fargate for the simple start, self-managed k3s or EKS when the workload calls for Kubernetes. Hardened workloads either way: non-root containers, read-only filesystems, default-deny network policies. The full comparison is below, and the trade-offs get documented whichever direction we pick.

CI/CD with security gates. GitHub Actions pipelines that test, build, scan, and refuse to deploy images with critical vulnerabilities. CI credentials scoped to specific resources, so a leak is an inconvenience rather than an incident.

Monitoring you own. Prometheus, Grafana, Loki and Tempo, self-hosted so logs stay in your VPC. Alert rules defined as code, AWS budgets with spending alerts, and notifications for incidents and cost thresholds delivered on whatever channel you use (email, Slack, SMS) and routed to a person who answers.

Backups that are tested. Scheduled encrypted backups, retention policies, and automated restore verification, so “we can recover” is a fact with a timestamp.

DNS and mail configuration. Domain records managed properly, as code where the provider allows it, and mail set up the right way: DKIM, SPF and DMARC configured and monitored, so transactional and team email actually arrives.

DORA readiness. I operate a DORA-regulated production infrastructure today. Controls mapped article by article, incidents classified and queryable, evidence produced by the platform itself. If you're in scope, you're not my first.

Fargate or Kubernetes?

Both are on the table, and the honest answer depends on the workload.

ECS on Fargate

The right start for one normal web application running only on AWS. There are no nodes to patch and no cluster to operate: AWS runs the containers and you pay per task. CloudWatch covers monitoring, deploys stay simple, and the operational burden is close to zero. The limits: task definitions tie you to AWS, and you give up low-level control over the runtime.

Self-managed Kubernetes (k3s)

It earns its complexity when:

• Portability matters. Standard Kubernetes objects, Helm charts, operators and GitOps tooling move to another cloud, bare metal or on-premise far more easily than ECS definitions.
• You need operators, CRDs or complex Helm-based applications.
• You run several small clusters and want to avoid the per-cluster EKS control-plane fee.
• You need low-level node control: OS and kernel settings, upgrade timing, ingress and storage components, Spot instance strategy.
• The same stack must also run outside AWS: hybrid or on-premise.

With self-managed k3s, someone owns control-plane availability, backups, upgrades, patching and node replacement. In the infrastructures I run, that ownership is mine: it is exactly what the ongoing-operations model covers.

EKS

Sits in between: for a business-critical application that specifically requires Kubernetes, the managed control plane is generally safer than self-managed k3s, at the cost of the monthly fee.

I will tell you plainly which of the three the workload needs, including when the answer is the cheapest one.

In production: a regulated platform

The clearest proof of how I work is an infrastructure I run today: an EU platform regulated under DORA, built and operated entirely as code. DORA, the EU's Digital Operational Resilience Act, has applied to financial entities since January 2025 and obliges them to evidence encryption, audit trails, incident detection, backup testing and third-party risk controls.

• RPO ≤ 4h
• RTO 4-8h, rebuildable from code
• Restore verification: weekly, automated
• 0 open SSH ports
• CI blocks critical CVEs
• 24+ alert rules as code

What it looks like

• Everything as code. Modular Terraform with a live/modules split: reusable modules, one thin composition root per environment. Adding staging means a new directory, not a fork. Remote state lives in a versioned, encrypted S3 bucket with native locking.
• Kubernetes, self-managed. K3s, a CNCF-certified distribution, on EC2, at a scale where a managed control plane isn't justified. Workers run in an auto-scaling group driven by cluster-autoscaler.
• A network built for inspection. The databases sit in subnets with no internet route, so they are unreachable from the internet by routing, not just by firewall rules. Ingress is ports 80 and 443 from the load balancer's security group only. Egress is a short, explicit list of protocols.
• No SSH. Access goes through AWS SSM Session Manager only, and every session is logged in CloudTrail. Port 22 is closed across the infrastructure.
• Two databases, one module. Aurora PostgreSQL Serverless v2, instantiated twice from the same Terraform module. The application database gets read replicas; the double-entry ledger gets none, because it's write-heavy and replicas would add cost without benefit. TLS is enforced server-side, so a misconfigured client fails loudly.
• Hardened workloads. Non-root containers, read-only root filesystems, all capabilities dropped, default-deny network policies, resource quotas, and PodDisruptionBudgets configured so routine node drains don't turn into outages.

Backups that prove themselves

Aurora continuous backups with point-in-time recovery. Encrypted logical backups to S3 every 4 hours, versioned and lifecycle-archived. A weekly, fully automated restore verification job running against the real backup artifacts, and the whole infrastructure reconstructible from Terraform. Resulting objectives: RPO ≤ 4 hours, RTO 4-8 hours for full platform reconstruction.

CI/CD and observability

GitHub Actions with path filtering, so only changed components rebuild. Images are scanned on push, and the pipeline fails on any critical finding: the deploy does not proceed. Monitoring is self-hosted Prometheus, Loki, Tempo and Grafana; logs stay inside the VPC, which matters when they contain personal data under GDPR. All 24+ alert rules are defined as code.

The application writes structured audit records tagged for DORA, and Grafana queries them directly. Reportable ICT incidents are queryable the moment they happen instead of being assembled for the regulator after the fact.

DORA areas and their implementation

DORA area	Implementation
ICT risk management (Art. 5-15)	IaC-defined controls, reviewable and diffable in version control
Incident detection and handling (Art. 17)	Structured audit stream with DORA classification tags; Grafana rules alerting on it
Incident reporting (Art. 19)	Severity and service-affecting attributes make reportable incidents directly queryable
Resilience testing (Art. 24-27)	Automated weekly restore verification; scan-on-push gating in CI
Third-party risk (Art. 28)	Dedicated incident classification for provider failures
Record keeping	Retention of the audit stream in versioned, encrypted object storage

Identifiers, account numbers, domains and bucket names genericised here.

Also built and operated: self-hosted mail

For teams that need to own their email, whether for data residency, compliance, or a seat count where SaaS pricing stops making sense, I build and operate a containerized mail and identity stack: Postfix and Dovecot, Rspamd and ClamAV, DKIM, SPF and DMARC configured and monitored, one user directory for mail and internal services, and Grafana dashboards over all of it. Self-hosted email is an operations commitment. That is why it exists as an operated system, and why it pairs naturally with the ongoing-operations model.