DEV Community: Florient DOGBE

Terraform : survivre à un state corrompu, guide de réparation sans tout détruire

Florient DOGBE — Tue, 13 Oct 2026 21:54:18 +0000

Un apply interrompu par un timeout réseau, un collègue qui lance un terraform apply depuis son poste pendant que la CI tourne, un state rm mal ciblé un vendredi soir : le résultat est toujours le même. Le state ne reflète plus l'infrastructure réelle, le plan propose de détruire une base de données de production, et toute l'équipe est bloquée.

La tentation est alors forte de « repartir propre » : vider le state, tout réimporter, ou pire, laisser Terraform recréer. C'est la pire décision possible sur un périmètre de production. Cet article détaille les manœuvres de récupération réelles, dans l'ordre où il faut les tenter, en partant du cas le plus fréquent : backend S3 + verrou DynamoDB.

Pourquoi un state casse, et pourquoi ça paralyse tout

Le state Terraform est une base de données, pas un fichier de cache. Il contient la correspondance entre les adresses de ressources du code (module.rds.aws_db_instance.main) et les identifiants réels du provider (prod-pg-01), plus les attributs lus au dernier refresh. Trois propriétés le rendent fragile :

Il est monolithique par workspace. Une corruption partielle bloque toutes les ressources du state, pas seulement la ressource fautive.
Il est versionné par un serial. Terraform refuse d'écrire un state dont le serial n'est pas supérieur à celui stocké, et refuse tout push dont le lineage (UUID du state) diffère. C'est une protection, mais aussi un mur quand on restaure une sauvegarde.
Il est protégé par un verrou externe. Si le process qui détenait le verrou meurt brutalement (runner CI tué, pod évincé, Ctrl-C mal géré), le verrou reste. Tout le monde est bloqué avec Error acquiring the state lock.

Les causes typiques de désynchronisation : apply partiel (certaines ressources créées, state non écrit), modification manuelle en console, refactoring de modules sans moved, suppression de ressources hors Terraform, ou double écriture concurrente.

Étape 0 : geler, sauvegarder, diagnostiquer

Avant toute commande qui écrit, on fige la situation.

Geler : désactiver les pipelines Terraform (workflow GitHub Actions, Tekton PipelineRun, ArgoCD auto-sync sur les ressources concernées) et annoncer un gel des apply manuels. Deux personnes qui réparent le même state en parallèle, c'est une corruption garantie.

Sauvegarder : le terraform state pull ne pose pas de verrou en écriture et donne une copie fidèle.

mkdir -p ~/tf-rescue && cd ~/tf-rescue
terraform state pull > state-$(date -u +%Y%m%dT%H%M%SZ).json
jq '{version, serial, lineage, resources: (.resources | length)}' state-*.json

Notez le serial et le lineage : ils seront indispensables pour toute restauration.

Diagnostiquer sans écrire : plan -refresh-only compare l'état réel au state sans proposer de changement de configuration. C'est l'outil de diagnostic le plus sous-utilisé.

terraform plan -refresh-only -lock=false -out=drift.tfplan
terraform show -json drift.tfplan | jq -r '
  .resource_drift[]? | "\(.address)\t\(.change.actions | join(","))"'

En CI, -detailed-exitcode renvoie 0 (aucun écart), 1 (erreur), 2 (écart détecté) :

terraform plan -refresh-only -detailed-exitcode -lock=false

Croisez ensuite avec la liste des ressources présentes dans le state :

terraform state list | wc -l
terraform state show aws_db_instance.main | head -30

Déverrouiller proprement

Inspecter le verrou DynamoDB

Avec le backend S3 historique, la table DynamoDB a pour clé primaire LockID (type String). Elle contient deux items par state : le verrou lui-même et un digest.

aws dynamodb get-item \
  --table-name terraform-locks \
  --key '{"LockID":{"S":"tf-state-prod/env/prod/terraform.tfstate"}}' \
  --query 'Item.Info.S' --output text | jq .

La sortie donne le ID du verrou, l'opération, le Who et le Created. Vérifiez que le process est réellement mort (pod terminé, job CI en échec) avant de déverrouiller. Forcer un verrou actif, c'est provoquer une double écriture.

terraform force-unlock -force 9f3c1a2b-4f0e-4b7d-8c21-7f1a0d2e5c33

Si le backend n'est plus initialisable, supprimez l'item directement :

aws dynamodb delete-item \
  --table-name terraform-locks \
  --key '{"LockID":{"S":"tf-state-prod/env/prod/terraform.tfstate"}}'

Le piège du digest `-md5`

Second item, souvent oublié : LockID = "<bucket>/<key>-md5" avec un attribut Digest. Terraform compare ce digest au contenu réel du fichier S3. Si vous restaurez une ancienne version du state via la console S3 sans passer par terraform state push, vous obtiendrez :

Error: state data in S3 does not have the expected content.

Dans ce cas, supprimez l'item digest : Terraform le recalculera au prochain apply.

aws dynamodb delete-item \
  --table-name terraform-locks \
  --key '{"LockID":{"S":"tf-state-prod/env/prod/terraform.tfstate-md5"}}'

Le verrou natif S3 (Terraform ≥ 1.11)

DynamoDB n'est plus obligatoire. Le backend S3 sait poser un verrou via un objet .tflock et If-None-Match.

terraform {
  backend "s3" {
    bucket       = "tf-state-prod"
    key          = "env/prod/terraform.tfstate"
    region       = "eu-west-3"
    encrypt      = true
    kms_key_id   = "arn:aws:kms:eu-west-3:111122223333:key/abcd-1234"
    use_lockfile = true
  }
}

Le déverrouillage manuel devient un simple aws s3api delete-object sur env/prod/terraform.tfstate.tflock.

Restaurer une version depuis le versioning S3

Si le state est tronqué, vide ou invalide en JSON, la restauration est la voie la plus rapide. Elle suppose que le versioning est actif sur le bucket — s'il ne l'est pas, arrêtez tout et activez-le avant de continuer à travailler.

aws s3api list-object-versions \
  --bucket tf-state-prod \
  --prefix env/prod/terraform.tfstate \
  --query 'reverse(sort_by(Versions,&LastModified))[:10].[VersionId,LastModified,Size]' \
  --output table

aws s3api get-object \
  --bucket tf-state-prod \
  --key env/prod/terraform.tfstate \
  --version-id 3HL4kqtJlcpXroDTDmjVBH40Nrjfkd \
  restored.tfstate

jq '{serial, lineage, resources: (.resources | length)}' restored.tfstate

Le bon réflexe est de pousser ce state plutôt que de l'écraser dans S3 : state push recalcule le digest et respecte le protocole du backend.

# Le serial doit être strictement supérieur à celui actuellement stocké
CURRENT=$(terraform state pull | jq -r '.serial')
jq --argjson s "$((CURRENT + 1))" '.serial = $s' restored.tfstate > push.tfstate
terraform state push push.tfstate

Si le lineage diffère (state recréé entre-temps), terraform state push -force push.tfstate passe outre. À n'utiliser qu'après avoir vérifié que le lineage cible correspond bien à la même infrastructure, sinon vous écrasez le state d'un autre environnement.

Validez immédiatement par un plan -refresh-only. Les ressources créées après la version restaurée apparaîtront comme « à créer » : ce sont vos orphelines, à importer.

Chirurgie du state

`state rm` et `state mv`

state rm retire une ressource du state sans la détruire. C'est l'outil pour sortir une ressource dont les attributs sont corrompus, avant de la réimporter proprement.

terraform state rm 'module.network.aws_nat_gateway.this[0]'
terraform state rm 'kubernetes_manifest.app_route'   # retire du state, la Route reste

state mv renomme une adresse — utile après un refactoring, mais préférez le bloc moved (déclaratif, versionné, rejouable en CI).

terraform state mv 'aws_instance.web' 'module.frontend.aws_instance.web'
terraform state mv -state-out=../network/terraform.tfstate \
  'module.vpc' 'module.vpc'   # découpage de state

Blocs `moved` et `removed`

moved {
  from = aws_instance.web
  to   = module.frontend.aws_instance.web
}

# Terraform >= 1.7 : retire du state sans détruire, en déclaratif
removed {
  from = aws_s3_bucket.legacy_logs

  lifecycle {
    destroy = false
  }
}

Ces blocs sont exécutés au plan, tracés dans Git et idempotents : contrairement aux commandes CLI, ils survivent au fait que l'ingénieur de garde ne soit pas celui qui a réparé.

Importer les ressources orphelines

Depuis Terraform 1.5, l'import est déclaratif et vérifiable au plan.

import {
  to = aws_db_instance.main
  id = "prod-pg-01"
}

import {
  to = kubernetes_deployment_v1.api
  id = "prod/api"
}

import {
  to = helm_release.ingress
  id = "openshift-ingress/nginx"
}

terraform plan -generate-config-out=generated.tf
terraform apply   # effectue l'import, aucune création

L'option -generate-config-out écrit une configuration HCL dérivée de l'objet réel : un gain de temps énorme sur une ressource à quarante attributs. Relisez-la, elle contient souvent des valeurs calculées à nettoyer.

Cas Kubernetes et OpenShift

Les ressources kubernetes_manifest utilisent un identifiant structuré. Soit la Route OpenShift suivante, créée à la main pendant l'incident :

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: api
  namespace: prod
  labels:
    app.kubernetes.io/name: api
    app.kubernetes.io/managed-by: terraform
spec:
  host: api.apps.cluster.example.com
  to:
    kind: Service
    name: api
    weight: 100
  port:
    targetPort: http
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect

Import correspondant :

import {
  to = kubernetes_manifest.api_route
  id = "apiVersion=route.openshift.io/v1,kind=Route,namespace=prod,name=api"
}

Attention : kubernetes_manifest exige un accès à l'API du cluster dès le plan. Si le point d'accès est injoignable (bastion, VPN coupé), le plan échoue avant même d'atteindre le state. Sur un cluster OpenShift, vérifiez d'abord :

oc whoami --show-server
oc auth can-i get routes -n prod

Le cas particulier de l'apply partiel

Quand un apply casse au milieu, Terraform écrit normalement un errored.tfstate local. Ne le perdez pas : il contient les ressources créées avant l'échec.

ls -l errored.tfstate
jq -r '.resources[].instances[].attributes.id' errored.tfstate | head
terraform state push errored.tfstate

Si ce fichier n'existe pas (runner CI détruit), reconstruisez par import. Ciblez les dépendances dans l'ordre, avec -target uniquement en mode récupération :

terraform apply -target=module.network -lock-timeout=10m
terraform apply   # convergence complète, sans -target

Terminez toujours par un apply non ciblé : -target laisse volontairement des parties du graphe non évaluées.

Bonnes pratiques de sécurité

Un state contient des valeurs sensibles en clair : mots de passe RDS, clés privées, tokens de ServiceAccount, contenu des kubernetes_secret. Traitez-le comme un secret, pas comme un artefact de build.

Chiffrement obligatoire : encrypt = true + kms_key_id dédié, et une bucket policy qui refuse toute écriture non chiffrée par cette clé (Condition sur s3:x-amz-server-side-encryption-aws-kms-key-id).
Versioning + rétention des versions non courantes (≥ 90 jours) et blocage des suppressions via une politique de cycle de vie ; le versioning est votre seule sauvegarde réelle.
IAM séparé lecture/écriture : les rôles de CI qui n'exécutent que plan n'ont besoin que de s3:GetObject et dynamodb:GetItem. Seul le rôle d'apply obtient s3:PutObject et dynamodb:PutItem/DeleteItem.
Pas de clés statiques : OIDC (GitHub Actions, GitLab) ou IRSA / Pod Identity côté Kubernetes.
Journalisation : activez les CloudTrail data events sur le bucket de state. Après un incident, savoir qui a écrit la version N-1 fait gagner des heures.
Réduire la surface : utilisez les arguments write-only / ressources ephemeral (Terraform ≥ 1.10/1.11) pour les mots de passe, et gérez les secrets Kubernetes via External Secrets Operator plutôt que via kubernetes_secret.
Jamais de terraform state pull dans un artefact CI ni dans un log. Le TF_LOG=DEBUG affiche des attributs sensibles.

Côté détection, un CronJob de drift sur le cluster vaut tous les post-mortems :

apiVersion: batch/v1
kind: CronJob
metadata:
  name: terraform-drift-detect
  namespace: platform-ops
spec:
  schedule: "0 6 * * 1-5"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 5
  jobTemplate:
    spec:
      backoffLimit: 1
      template:
        spec:
          serviceAccountName: terraform-readonly
          restartPolicy: Never
          containers:
            - name: terraform
              image: hashicorp/terraform:1.11
              command: ["/bin/sh", "-c"]
              args:
                - |
                  set -e
                  cd /workspace
                  terraform init -input=false -lock=false
                  terraform plan -refresh-only -lock=false -detailed-exitcode
              env:
                - name: AWS_REGION
                  value: eu-west-3
                - name: AWS_ROLE_ARN
                  value: arn:aws:iam::111122223333:role/tf-plan-readonly
                - name: AWS_WEB_IDENTITY_TOKEN_FILE
                  value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
              volumeMounts:
                - name: workspace
                  mountPath: /workspace
                - name: aws-token
                  mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
                  readOnly: true
              securityContext:
                allowPrivilegeEscalation: false
                runAsNonRoot: true
                capabilities:
                  drop: ["ALL"]
                seccompProfile:
                  type: RuntimeDefault
          volumes:
            - name: workspace
              emptyDir: {}
            - name: aws-token
              projected:
                sources:
                  - serviceAccountToken:
                      path: token
                      audience: sts.amazonaws.com
                      expirationSeconds: 3600

Un exit code 2 déclenche une alerte : vous découvrez la dérive le lundi matin, pas pendant l'astreinte.

Conclusion : les points clés

Sauvegardez avant de toucher à quoi que ce soit : terraform state pull > backup.json, puis notez serial et lineage.
Diagnostiquez en lecture seule avec plan -refresh-only -lock=false et -detailed-exitcode ; n'écrivez jamais sur la base d'une supposition.
Vérifiez qu'un verrou est mort avant de le forcer. Pensez à l'item -md5 dans DynamoDB, source d'erreurs incompréhensibles après restauration manuelle.
Restaurez via terraform state push, pas via la console S3 : le digest et le serial sont gérés pour vous.
Préférez le déclaratif au CLI : moved, removed et import sont versionnés, revus en pull request et rejouables ; state mv/rm restent des outils d'urgence.
-target est un mode récupération, jamais un mode de fonctionnement : terminez toujours par un apply complet.
Le state est un secret : KMS, versioning, IAM séparé lecture/écriture, CloudTrail, et surveillance de la dérive en continu.

La vraie leçon d'un state corrompu n'est pas la séquence de commandes, mais le fait qu'un seul state monolithique pour toute une production transforme n'importe quel incident mineur en blocage d'équipe. Découper les states par domaine de blast radius — réseau, données, workloads — reste la meilleure assurance.

FinOps on AWS: Hunting the Hidden Costs of NAT Gateways and Inter-AZ Egress

Florient DOGBE — Tue, 13 Oct 2026 21:46:02 +0000

Your AWS bill has a line item called "EC2-Other". Nobody looks at it. On a mid-sized Kubernetes or OpenShift platform it routinely accounts for 20–30% of total spend, and most of it is two things: NAT Gateway data processing and inter-Availability-Zone data transfer.

Unlike EC2 or RDS, these charges have no tag, no resource owner, and no obvious dashboard. They are the byproduct of architectural decisions made months ago — a pod scheduled in eu-west-1c talking to a Redis primary in eu-west-1a, a CI job pulling 400 GB of container images through a NAT Gateway, an S3 client that never got a Gateway Endpoint.

This article shows how to isolate these costs with Cost Explorer, quantify them precisely with VPC Flow Logs and Athena, and then kill them with VPC endpoints and zone-aware routing.

Context: why these costs are invisible

AWS charges network traffic in three independent ways that stack on top of each other:

Charge	Typical price (eu-west-1)	Billed on
NAT Gateway hourly	~$0.045/h per NAT GW	Per AZ, per NAT
NAT Gateway data processing	~$0.045/GB	Every byte in and out
Inter-AZ data transfer	$0.01/GB in + $0.01/GB out	Both sides charged
Internet egress	~$0.09/GB (first 10 TB)	Outbound only

Two properties make this dangerous:

Double billing on inter-AZ. A 1 GB transfer between two AZs costs $0.02, not $0.01. Both the sender and the receiver are charged.
NAT data processing applies to private AWS traffic too. A pod in a private subnet calling s3.eu-west-1.amazonaws.com without a Gateway Endpoint pays $0.045/GB plus the NAT hourly cost — for traffic that never leaves the AWS backbone.

On a Kubernetes cluster spread across three AZs with a default scheduler and no topology constraints, roughly 2/3 of all pod-to-pod traffic crosses an AZ boundary. A service mesh with mTLS sidecars, a Kafka cluster, or a chatty microservice architecture turns that into real money.

Concrete example: a platform pushing 30 TB/month through NAT and 50 TB/month of cross-AZ service traffic.

NAT processing: 30,000 GB × $0.045 = $1,350/month
NAT hourly (3 AZs): 3 × 730 × $0.045 = $98/month
Inter-AZ: 50,000 GB × $0.02 = $1,000/month

That is ~$29k/year for traffic nobody asked for.

Step 1: Isolate the cost in Cost Explorer

Start with the top-down view. The relevant usage types are NatGateway-Bytes, NatGateway-Hours, and DataTransfer-Regional-Bytes.

# NAT Gateway cost breakdown, last 3 months, grouped by usage type
aws ce get-cost-and-usage \
  --time-period Start=2024-03-01,End=2024-06-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" "UsageQuantity" \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --filter '{
    "Dimensions": {
      "Key": "USAGE_TYPE_GROUP",
      "Values": ["EC2: NAT Gateway - Data Processed", "EC2: NAT Gateway - Running Hours"]
    }
  }' \
  --output table

For inter-AZ transfer, filter on the regional data transfer usage type (the exact prefix depends on your region code):

aws ce get-cost-and-usage \
  --time-period Start=2024-05-01,End=2024-06-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" "UsageQuantity" \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --filter '{
    "Dimensions": {
      "Key": "USAGE_TYPE",
      "Values": ["EUW1-DataTransfer-Regional-Bytes"]
    }
  }'

This tells you how much. It does not tell you who. For that you need flow logs.

Step 2: Quantify with VPC Flow Logs + Athena

Enable flow logs with a custom format that includes the fields you actually need for cost attribution: pkt-srcaddr/pkt-dstaddr (the real endpoints behind a NAT), az-id, and flow-direction.

VPC_ID=vpc-0a1b2c3d4e5f67890
BUCKET=s3://my-flowlogs-bucket/vpc-flow-logs/

aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids $VPC_ID \
  --traffic-type ALL \
  --log-destination-type s3 \
  --log-destination $BUCKET \
  --max-aggregation-interval 60 \
  --destination-options FileFormat=parquet,HiveCompatiblePartitions=true,PerHourPartition=true \
  --log-format '${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status} ${vpc-id} ${subnet-id} ${instance-id} ${az-id} ${flow-direction} ${pkt-srcaddr} ${pkt-dstaddr} ${traffic-path}'

Use Parquet + Hive-compatible partitions. On a busy cluster, text-format flow logs will cost you more in Athena scans than the traffic you are trying to optimize.

Create the Athena table:

CREATE EXTERNAL TABLE IF NOT EXISTS vpc_flow_logs (
  version int, account_id string, interface_id string,
  srcaddr string, dstaddr string, srcport int, dstport int,
  protocol bigint, packets bigint, bytes bigint,
  start bigint, `end` bigint, action string, log_status string,
  vpc_id string, subnet_id string, instance_id string,
  az_id string, flow_direction string,
  pkt_srcaddr string, pkt_dstaddr string, traffic_path int
)
PARTITIONED BY (
  aws_account_id string, aws_service string, aws_region string,
  year string, month string, day string, hour string
)
STORED AS PARQUET
LOCATION 's3://my-flowlogs-bucket/vpc-flow-logs/AWSLogs/'
TBLPROPERTIES ('projection.enabled'='true',
  'projection.year.type'='integer','projection.year.range'='2024,2030',
  'projection.month.type'='integer','projection.month.range'='1,12','projection.month.digits'='2',
  'projection.day.type'='integer','projection.day.range'='1,31','projection.day.digits'='2',
  'projection.hour.type'='integer','projection.hour.range'='0,23','projection.hour.digits'='2',
  'projection.aws_account_id.type'='injected',
  'projection.aws_service.type'='injected',
  'projection.aws_region.type'='injected',
  'storage.location.template'='s3://my-flowlogs-bucket/vpc-flow-logs/AWSLogs/${aws_account_id}/${aws_service}/${aws_region}/${year}/${month}/${day}/${hour}'
);

Query A: top NAT Gateway consumers

traffic_path = 2 marks traffic routed through a NAT Gateway. Group by the real destination to find out what is being pulled.

SELECT
  srcaddr AS pod_or_node_ip,
  pkt_dstaddr AS real_destination,
  SUM(bytes) / 1024.0 / 1024 / 1024 AS gb,
  ROUND(SUM(bytes) / 1024.0 / 1024 / 1024 * 0.045, 2) AS nat_cost_usd
FROM vpc_flow_logs
WHERE year='2024' AND month='05'
  AND traffic_path = 2
  AND flow_direction = 'egress'
GROUP BY 1, 2
ORDER BY gb DESC
LIMIT 30;

Typical findings: *.amazonaws.com IP ranges (S3, ECR, STS, CloudWatch) at the top. Every one of those is a VPC endpoint away from being free or near-free.

Query B: inter-AZ traffic between private IPs

WITH enriched AS (
  SELECT
    f.az_id AS src_az,
    f.pkt_dstaddr,
    f.bytes,
    f.srcaddr
  FROM vpc_flow_logs f
  WHERE year='2024' AND month='05'
    AND flow_direction = 'egress'
    AND regexp_like(pkt_dstaddr, '^10\.')   -- stay inside the VPC CIDR
)
SELECT
  src_az,
  SUBSTR(pkt_dstaddr, 1, 7) AS dst_prefix,
  SUM(bytes) / 1024.0 / 1024 / 1024 AS gb,
  ROUND(SUM(bytes) / 1024.0 / 1024 / 1024 * 0.02, 2) AS interaz_cost_usd
FROM enriched
GROUP BY 1, 2
ORDER BY gb DESC
LIMIT 50;

To map IPs back to workloads, join against a dump of your pod inventory:

kubectl get pods -A \
  -o jsonpath='{range .items[*]}{.status.podIP}{","}{.metadata.namespace}{","}{.metadata.name}{","}{.spec.nodeName}{"\n"}{end}' \
  > pod-inventory.csv

# Upload to S3 and create an Athena table, or just grep locally for the top talkers
grep -F "10.0.34.112" pod-inventory.csv

Step 3: Kill NAT costs with VPC endpoints

Gateway endpoints (free)

S3 and DynamoDB Gateway Endpoints cost nothing — no hourly fee, no per-GB fee. There is no reason not to have them. For a cluster pulling images from ECR, the S3 endpoint alone often removes 40–60% of NAT traffic (ECR image layers live in S3).

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0a1b2c3d4e5f67890 \
  --service-name com.amazonaws.eu-west-1.s3 \
  --vpc-endpoint-type Gateway \
  --route-table-ids rtb-0private1 rtb-0private2 rtb-0private3

Interface endpoints (priced, but usually cheaper)

Interface endpoints cost ~$0.011/h per AZ + ~$0.01/GB. Compare against $0.045/GB through NAT: break-even is reached quickly, but create the endpoint in every AZ where you have workloads, otherwise you trade NAT cost for inter-AZ cost.

for SVC in ecr.api ecr.dkr sts logs monitoring elasticloadbalancing ec2 kms secretsmanager; do
  aws ec2 create-vpc-endpoint \
    --vpc-id vpc-0a1b2c3d4e5f67890 \
    --service-name com.amazonaws.eu-west-1.$SVC \
    --vpc-endpoint-type Interface \
    --subnet-ids subnet-0priv-a subnet-0priv-b subnet-0priv-c \
    --security-group-ids sg-0vpce \
    --private-dns-enabled \
    --tag-specifications 'ResourceType=vpc-endpoint,Tags=[{Key=cost-center,Value=platform},{Key=managed-by,Value=terraform}]'
done

Verify from inside the cluster that DNS now resolves to a private IP:

kubectl run netshoot --rm -it --restart=Never --image=nicolaka/netshoot -- \
  dig +short ecr.dkr.eu-west-1.amazonaws.com
# Expect 10.x.x.x, not a public IP

Step 4: Make the cluster zone-aware

Topology-aware routing for Services

Kubernetes 1.27+ (OpenShift 4.14+) supports trafficDistribution / topology-aware hints. When enabled, kube-proxy prefers endpoints in the same zone as the client.

apiVersion: v1
kind: Service
metadata:
  name: payments-api
  namespace: billing
  annotations:
    # Legacy mechanism, still honoured on older clusters
    service.kubernetes.io/topology-mode: Auto
spec:
  # Kubernetes >= 1.31 / OpenShift 4.18 — preferred field
  trafficDistribution: PreferClose
  selector:
    app: payments-api
  ports:
    - name: http
      port: 8080
      targetPort: 8080

Check that hints are actually populated — if there are not enough endpoints per zone, the control plane silently disables them:

kubectl get endpointslice -n billing -l kubernetes.io/service-name=payments-api -o yaml | grep -A4 hints

Spread workloads so hints can work

Topology-aware routing only helps if every zone has endpoints. Enforce it:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payments-api
  namespace: billing
spec:
  replicas: 6
  selector:
    matchLabels:
      app: payments-api
  template:
    metadata:
      labels:
        app: payments-api
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: payments-api
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: payments-api
      containers:
        - name: api
          image: registry.example.com/billing/payments-api:1.8.3
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 200m
              memory: 256Mi
            limits:
              memory: 512Mi

Keep stateful traffic in one AZ

For a cache or a non-replicated datastore, cross-AZ reads are pure waste. Pin consumers to the data:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: session-worker
  namespace: billing
spec:
  replicas: 3
  selector:
    matchLabels:
      app: session-worker
  template:
    metadata:
      labels:
        app: session-worker
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                  app: redis-primary
              topologyKey: topology.kubernetes.io/zone
      containers:
        - name: worker
          image: registry.example.com/billing/session-worker:2.1.0
          resources:
            requests:
              cpu: 100m
              memory: 128Mi

For Ingress, make sure the AWS Load Balancer Controller uses IP targets with cross-zone balancing disabled when traffic volume justifies it:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: payments
  namespace: billing
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/load-balancer-attributes: >-
      load_balancing.cross_zone.enabled=false
spec:
  ingressClassName: alb
  rules:
    - host: payments.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: payments-api
                port:
                  number: 8080

Disabling cross-zone balancing on an ALB is free of charge for the ALB itself but requires balanced target counts per AZ — which the topologySpreadConstraints above give you.

Security best practices

Cost optimization must not weaken your perimeter. A few rules:

Never replace a NAT Gateway with a public subnet. Moving nodes to public subnets eliminates NAT cost and your network isolation at the same time. Use VPC endpoints instead.
Scope endpoint policies. A default VPC endpoint policy is "Effect": "Allow", "Principal": "*", "Action": "*". Restrict it:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": ["s3:GetObject", "s3:PutObject", "s3:ListBucket"],
    "Resource": [
      "arn:aws:s3:::my-app-artifacts",
      "arn:aws:s3:::my-app-artifacts/*",
      "arn:aws:s3:::prod-eu-west-1-starport-layer-bucket/*"
    ],
    "Condition": {
      "StringEquals": {"aws:PrincipalOrgID": "o-exampleorgid"}
    }
  }]
}

Lock down the endpoint security group. Allow only TCP/443 from the VPC CIDR or from the node security group — not 0.0.0.0/0.
Keep egress filtering. If you remove NAT for AWS services, you still need an explicit egress path for third-party APIs. Use NetworkPolicy (or EgressFirewall on OpenShift) so pods cannot reach arbitrary destinations:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress
  namespace: billing
spec:
  podSelector:
    matchLabels:
      app: payments-api
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: openshift-dns
      ports:
        - protocol: UDP
          port: 5353
    - to:
        - ipBlock:
            cidr: 10.0.0.0/16   # VPC, covers the interface endpoints
      ports:
        - protocol: TCP
          port: 443

Protect the flow log bucket. It contains your internal topology. Enable SSE-KMS, block public access, and apply a lifecycle rule (30–90 days) — flow logs grow fast and become their own cost problem.
Least privilege for the flow logs role. The IAM role used by the VPC Flow Logs delivery service should only allow s3:PutObject on the specific prefix, with aws:SourceAccount / aws:SourceArn conditions to prevent the confused deputy problem.

Conclusion

Hidden network costs are not an AWS pricing anomaly; they are a direct reflection of your architecture. Three takeaways:

Measure before optimizing. Cost Explorer gives you the magnitude (NatGateway-Bytes, DataTransfer-Regional-Bytes). VPC Flow Logs in Parquet + Athena give you the attribution. Without pkt-dstaddr and traffic_path, you are guessing.
Gateway endpoints for S3 and DynamoDB are free and non-negotiable. Interface endpoints for ECR, STS, CloudWatch Logs and KMS pay for themselves above roughly 300–500 GB/month per service. Always deploy them in every AZ you run workloads in.
Zone awareness is a scheduling problem. trafficDistribution: PreferClose only works when topologySpreadConstraints guarantee endpoints in every zone. Pair them, and verify the hints are actually present in the EndpointSlices.

Build the Athena queries into a monthly report and attach the output to your FinOps review. The first pass typically removes 30–50% of NAT spend within a sprint; the inter-AZ part takes longer because it requires touching deployments — but it is the part that keeps growing with your traffic.