
## 🔍 Overview

In Part 1, we deployed a private Employee Directory API using Lambda, API Gateway and Interface Endpoints. Now, we’ll:

- Enable **secure cross-VPC access** using **VPC Peering** and **PrivateLink**
- Add **IAM-based SigV4 authentication** to protect the API

## 🌐 Cross-VPC Access with PrivateLink

If you want consumers in a **different VPC/account** to call your API:

### 1. **Enable Private DNS** (already done)

Ensure `private_dns_enabled = true` on your `aws_vpc_endpoint`.

### 2. **VPC Peering or Transit Gateway**

For same-account cross-VPC:

```go
resource "aws_vpc_peering_connection" "peer" {
  vpc_id        = aws_vpc.main.id
  peer_vpc_id   = aws_vpc.other.id
  auto_accept   = true
}

resource "aws_route" "to_peer" {
  route_table_id         = aws_route_table.main.id
  destination_cidr_block = aws_vpc.other.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.peer.id
}
```

For different-account, use **PrivateLink with NLB** + Endpoint Service (optional advanced setup).

## 🔐 Add IAM-Based Authentication

We now want **IAM-authenticated** access to our API.

### 1. Update API Gateway Method

```go
resource "aws_api_gateway_method" "get" {
  rest_api_id   = aws_api_gateway_rest_api.private_api.id
  resource_id   = aws_api_gateway_resource.employee.id
  http_method   = "GET"
  authorization = "AWS_IAM"
}
```

### 2. Create IAM Role for Client

```go
resource "aws_iam_user" "api_client" {
  name = "internal-api-client"
}

resource "aws_iam_policy" "invoke_api" {
  name   = "InvokePrivateAPI"
  policy = jsonencode({
    Version: "2012-10-17",
    Statement: [{
      Effect: "Allow",
      Action: "execute-api:Invoke",
      Resource: "arn:aws:execute-api:${var.region}:${data.aws_caller_identity.current.account_id}:${aws_api_gateway_rest_api.private_api.id}/*"
    }]
  })
}

resource "aws_iam_user_policy_attachment" "attach" {
  user       = aws_iam_user.api_client.name
  policy_arn = aws_iam_policy.invoke_api.arn
}
```

### 3. Test with SigV4

Install AWS CLI or use [awscurl](https://github.com/okigan/awscurl):

```bash
awscurl --service execute-api \
  --region us-east-1 \
  --access_key <AKIA...> \
  --secret_key <SECRET> \
  https://<rest-api-id>.execute-api.us-east-1.amazonaws.com/prod/employee/1002
```

You can now control access by IAM policies and optionally federate via Cognito/SAML if needed.

---

## ✅ Summary

We’ve now:

- Enabled secure cross-VPC access using PrivateLink/VPC peering
- Enforced IAM-based authentication using `AWS_IAM`
- Set up a realistic, secure, internal API stack

Next article: Add observability (CloudWatch Logs + X-Ray), throttling and versioned deployments with stages.

---


Extend your private API Gateway with secure access from other VPCs using PrivateLink and enforce IAM-based authentication.

Private API Gateway - Part 2: Secure Cross-VPC Access with PrivateLink and IAM Authentication


## 🔍 Overview

Private API Gateway allows you to expose REST APIs that are only accessible inside your VPC. No public internet access. This is ideal for internal microservices, backend systems, or APIs you want fully private.

### Scenario
We'll implement a secure internal **Employee Directory API** using AWS Lambda, API Gateway (private), and VPC Interface Endpoints. The API will be accessible **only inside the VPC**.

## 🧱 Prerequisites

- AWS CLI or Terraform
- A VPC with private subnets
- curl or Postman
- Basic understanding of:
  - API Gateway
  - Lambda
  - IAM
  - VPC endpoints (interface)

## 🛠️ Architecture

```
[ EC2 in VPC ] ---> [ VPC Endpoint ] ---> [ Private API Gateway ] ---> [ Lambda (Employee Directory) ]
```

Only resources inside the VPC can reach the API through the interface endpoint.

## 🔧 Step-by-Step Deployment (Terraform)

### 1. Create VPC, Subnet, and Security Group

```go
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true
}

resource "aws_subnet" "private" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "us-east-1a"
  map_public_ip_on_launch = false
}

resource "aws_security_group" "vpce_sg" {
  name        = "vpce-sg"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = [aws_vpc.main.cidr_block]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}
```

### 2. Deploy the Lambda Function

Use the Python code below and package it:

```bash
mkdir employee-directory && cd employee-directory
vi index.py  # lets use our mini lambda below
zip employee_directory.zip index.py
```

```python
import json

EMPLOYEES = {
    "1001": {"id": "1001", "name": "Qais N", "role": "DevOps Engineer"},
    "1002": {"id": "1002", "name": "Abz Ab", "role": "Backend Engineer"},
    "1003": {"id": "1003", "name": "James John", "role": "Product Manager"},
}

def lambda_handler(event, context):
    path = event.get("path", "")
    method = event.get("httpMethod", "")

    if method == "GET" and path.startswith("/employee/"):
        emp_id = path.split("/")[-1]
        emp = EMPLOYEES.get(emp_id)
        if emp:
            return {"statusCode": 200, "body": json.dumps(emp)}
        return {"statusCode": 404, "body": json.dumps({"error": "Employee not found"})}

    if method == "GET" and path == "/employee":
        return {"statusCode": 200, "body": json.dumps(list(EMPLOYEES.values()))}

    return {"statusCode": 400, "body": json.dumps({"error": "Unsupported operation"})}
```

```go
resource "aws_iam_role" "lambda_exec" {
  name = "lambda_exec_role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [{
      Action = "sts:AssumeRole",
      Principal = { Service = "lambda.amazonaws.com" },
      Effect = "Allow",
    }],
  })
}

resource "aws_lambda_function" "employee_directory" {
  filename         = "employee_directory.zip"
  function_name    = "employee_directory"
  role             = aws_iam_role.lambda_exec.arn
  handler          = "index.lambda_handler"
  runtime          = "python3.9"
  source_code_hash = filebase64sha256("employee_directory.zip")
}
```

### 3. Create Private API Gateway and Integration

```go
resource "aws_api_gateway_rest_api" "private_api" {
  name        = "employee-directory-api"
  endpoint_configuration { types = ["PRIVATE"] }
}

resource "aws_api_gateway_resource" "employee" {
  rest_api_id = aws_api_gateway_rest_api.private_api.id
  parent_id   = aws_api_gateway_rest_api.private_api.root_resource_id
  path_part   = "employee"
}

resource "aws_api_gateway_method" "get" {
  rest_api_id   = aws_api_gateway_rest_api.private_api.id
  resource_id   = aws_api_gateway_resource.employee.id
  http_method   = "GET"
  authorization = "NONE"
}

resource "aws_api_gateway_integration" "lambda_integration" {
  rest_api_id             = aws_api_gateway_rest_api.private_api.id
  resource_id             = aws_api_gateway_resource.employee.id
  http_method             = aws_api_gateway_method.get.http_method
  type                    = "AWS_PROXY"
  integration_http_method = "POST"
  uri                     = aws_lambda_function.employee_directory.invoke_arn
}
```

### 4. Configure VPC Endpoint and Policy

```go
resource "aws_vpc_endpoint" "api_gw" {
  vpc_id             = aws_vpc.main.id
  service_name       = "com.amazonaws.${var.region}.execute-api"
  vpc_endpoint_type  = "Interface"
  subnet_ids         = [aws_subnet.private.id]
  security_group_ids = [aws_security_group.vpce_sg.id]
}

resource "aws_api_gateway_deployment" "deployment" {
  rest_api_id = aws_api_gateway_rest_api.private_api.id
  stage_name  = "prod"
  depends_on  = [aws_api_gateway_integration.lambda_integration]
}

resource "aws_api_gateway_rest_api_policy" "restrict_to_vpce" {
  rest_api_id = aws_api_gateway_rest_api.private_api.id
  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Deny",
        Principal = "*",
        Action = "execute-api:Invoke",
        Resource = "*",
        Condition = {
          StringNotEquals = {
            "aws:SourceVpce" = aws_vpc_endpoint.api_gw.id
          }
        }
      }
    ]
  })
}
```

## 🧪 Test the Setup

1. SSH into an EC2 inside the VPC
2. Run:

```bash
curl https://<rest-api-id>.execute-api.<region>.amazonaws.com/prod/employee
curl https://<rest-api-id>.execute-api.<region>.amazonaws.com/prod/employee/1002
```

✅ Should return valid responses inside the VPC (inside EC2)
❌ Should be blocked from public internet

---

## 📌 Summary

- Built a fully private Employee Directory API
- Integrated it with Lambda + API Gateway
- Made it VPC-only using Interface Endpoints
- Secured access with SourceVpce IAM policy

Great for internal-only microservices, B2B APIs, or compliance-sensitive systems.

🧼 Destroy with:

```bash
terraform destroy
```

Part 2 coming out soon on: DynamoDB, PrivateLink cross-VPC, or IAM auth with SigV4!
---

Learn how to deploy a secure, private-only API Gateway inside your VPC using interface endpoints, resource policies, and VPC integration.

Securing APIs in AWS: Private API Gateway + VPC Endpoint Deep Dive


## Introduction

In this deep dive, we'll explore how to configure AWS Route 53 to route user traffic to the region with the lowest latency and automatically fail over to another region if the primary becomes unhealthy. This setup ensures high availability and optimal performance for global applications.

Why Should You Care?
Implementing latency-based routing with health checks in Route 53 allows your application to:

- Serve users from the nearest healthy region, reducing latency.
- Automatically reroute traffic during regional outages, enhancing resilience.
- Maintain high availability without manual intervention.

## Prerequisites

- Basic understanding of AWS Route 53 and DNS concepts.
- An AWS account with Route 53 and CloudWatch access.
- A domain name registered with Route 53 (if hosted on Cloudflare or elsewhere, make sure you delegate the domain to Route 53 or create a subdomain to subdelegate).
- Terraform installed on your local machine.

## Architecture Overview

We'll deploy identical applications in two AWS regions: us-east-1 and eu-west-1. Each region will have:

- An Application Load Balancer (ALB) fronting the application.
- A Route 53 health check monitoring the ALB's /health endpoint.
- A latency-based DNS record directing traffic to the region with the lowest latency.

If a health check fails, Route 53 will exclude that region from DNS responses, effectively failing over to the healthy region.

## Step-by-Step Guide

1. Set Up ALBs in Both Regions
Deploy your application behind an ALB in both us-east-1 (US Virginia) and eu-west-1 (EU Ireland). Ensure each ALB has a listener on port 80 and a target group with healthy targets.

2. Create Route 53 Health Checks
Define health checks for each ALB's /health endpoint.

```go
resource "aws_route53_health_check" "us_east" {
  fqdn              = "alb-us-east-1.example.com"
  port              = 80
  type              = "HTTP"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 30
}

resource "aws_route53_health_check" "eu_west" {
  fqdn              = "alb-eu-west-1.example.com"
  port              = 80
  type              = "HTTP"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 30
}
```

## 3. Configure Latency-Based DNS Records

Create latency-based DNS records pointing to each ALB, associating them with the respective health checks.

```go
resource "aws_route53_record" "us_east" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = "r53-demo.moabukar.co.uk"
  type    = "A"

  alias {
    name                   = "alb-us-east-1.example.com"
    zone_id                = "Z35SXDOTRQ7X7K" // Replace with your ALB's zone ID
    evaluate_target_health = true
  }

  set_identifier = "us-east-1"
  region         = "us-east-1"
  latency_routing_policy {
    region = "us-east-1"
  }

  health_check_id = aws_route53_health_check.us_east.id
}

resource "aws_route53_record" "eu_west" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = "r53-demo.moabukar.co.uk"
  type    = "A"

  alias {
    name                   = "alb-eu-west-1.example.com"
    zone_id                = "Z32O12XQLNTSW2" // Replace with your ALB's zone ID
    evaluate_target_health = true
  }

  set_identifier = "eu-west-1"
  region         = "eu-west-1"
  latency_routing_policy {
    region = "eu-west-1"
  }

  health_check_id = aws_route53_health_check.eu_west.id
}
```

Note: Replace zone_id values with the correct zone IDs for your ALBs. You can find these in the AWS documentation.

## Apply on TF

```bash
terraform init
terraform apply
```

Verify that the DNS records are created and health checks are active.

## Test the Setup

- Normal Operation: When both regions are healthy, Route 53 directs users to the region with the lowest latency based on their location.

- Simulate Failure: Stop the application in us-east-1 to trigger a health check failure.

- Failover: Route 53 detects the failure and stops including us-east-1 in DNS responses. Traffic is rerouted to eu-west-1.

- Recovery: Restart the application in us-east-1. Once the health check passes, Route 53 includes it again in DNS responses.

## Monitoring and Observability

- Route 53 Console: Monitor health check statuses and DNS records.

- CloudWatch: Set up alarms for health check failures to receive notifications.

- Logs: Enable query logging in Route 53 to analyze DNS queries.

## Conclusion

By configuring latency-based routing with health checks in Route 53, you ensure your application serves users from the nearest healthy region, providing low latency and high availability. This setup is crucial for global applications where performance and uptime are paramount.

References:

- [AWS Route 53 Latency-Based Routing](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-latency.html)

- [AWS Route 53 Health Checks](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html)

- [Terraform AWS Provider Documentation](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/route53_health_check)


A hands-on guide to configuring AWS Route 53 for latency-based routing across multiple regions, incorporating health checks for automatic failover.

Route 53 Deep Dive: Multi-Region Latency Routing with Health-Based Failover


## Introduction

Running out of IP addresses in AWS EKS can be a subtle yet critical issue. It often manifests as pods stuck in a pending state or nodes failing to join the cluster, leading to deployment bottlenecks and potential downtime. Understanding the root cause and implementing effective solutions is essential for maintaining cluster health and scalability. Now, there are many ways to fix this, but this is one way.

## Understanding the Problem: IP Exhaustion in EKS

EKS utilises the AWS VPC CNI plugin to assign IP addresses to pods. Each EC2 instance (node) has a limit on the number of Elastic Network Interfaces (ENIs) and secondary IP addresses it can support, determined by the instance type. When the number of pods exceeds the available IPs, EKS attempts to allocate additional ENIs. However, if the subnet lacks sufficient IP addresses, this allocation fails, resulting in errors like:

```json
{
  "code": "InsufficientFreeAddresses",
  "message": "One or more of the subnets associated with your cluster does not have enough available IP addresses for Amazon EKS to perform cluster management operations."
}
```

This issue is particularly prevalent in dynamic environments with frequent pod scaling, where IP addresses are rapidly consumed.

## Diagnosing IP Exhaustion

To identify IP exhaustion:

- Monitor cluster events for errors related to pod scheduling.
- Use `kubectl describe nodes` to inspect the number of allocated IPs and ENIs.
- Check subnet IP utilization via the AWS Console or CLI.

## Solution: Optimising IP Allocation with WARM_IP_TARGET

The AWS VPC CNI plugin maintains a warm pool of IP addresses to expedite pod networking. By default, it pre-allocates a significant number of IPs, which can lead to unnecessary IP consumption. Adjusting the WARM_IP_TARGET environment variable in the aws-node DaemonSet allows for better control over IP allocation.

### Steps to Adjust WARM_IP_TARGET

1. Modify the AWS CNI DaemonSet:

Reduce the number of pre-allocated IPs per node by setting WARM_IP_TARGET to a lower value (e.g., 5):

```bash
kubectl set env daemonset aws-node -n kube-system WARM_IP_TARGET=5
```

This change instructs the CNI to maintain only 5 unused IP addresses per node, freeing up IPs in the subnet.

2. Monitor IP Address Availability:

Use `kubectl describe nodes` to observe the number of allocated IPs and ENIs.

3. Verify the Fix:

After applying the configuration, monitor the cluster to ensure that pods are scheduled successfully and the InsufficientFreeAddresses error no longer appears.

## Additional Considerations for Long-Term Scalability

While adjusting WARM_IP_TARGET addresses immediate IP exhaustion issues, consider the following for long-term scalability:

1. Subnet Design:

Ensure subnets are appropriately sized. For larger clusters, consider using /20 or /16 CIDR blocks to provide ample IP addresses.

2. Instance Types:

Select EC2 instance types with higher ENI and IP limits to accommodate more pods per node.

3. Prefix Delegation:

Enable prefix delegation to assign a /28 block of IPs to each ENI, significantly increasing the number of IPs available per node. This can be done by setting the ENABLE_PREFIX_DELEGATION environment variable to true in the aws-node DaemonSet:

```bash
kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
```

Note: Ensure your subnets have sufficient contiguous IP address space to support prefix delegation.

## Conclusion

IP address exhaustion in EKS is a common challenge that can hinder cluster scalability and reliability. By tuning the WARM_IP_TARGET setting and considering subnet design, instance selection, and prefix delegation, you can effectively manage IP allocation and maintain a healthy, scalable EKS environment.


EKS IP Exhaustion: Running out of IPs, one way to fix it


## Kubernetes as a Cloud Control Plane: Deep Dive into AWS ACK with kind

Kubernetes isn't just about container orchestration anymore — it's become the de facto control plane for everything. With Custom Resource Definitions (CRDs) and controllers, we can now describe and manage virtually any resource declaratively — whether it's an app, an S3 bucket, or an RDS instance. That’s where AWS Controllers for Kubernetes (ACK) come in.

ACK lets us manage AWS resources like RDS or EC2 the same way we manage Deployments and Services: using YAML manifests. The idea is powerful — replace scattered IaC tooling with a unified K8s-native approach. And if you’re already deploying everything through Argo CD, Flux, or Helm, why not include your cloud infra?

But does it actually hold up?

That’s what this post explores — we’ll walk through an end-to-end demo running ACK on a local kind cluster. 

⚙️ Environment Setup

```bash
mkdir ack-demo
cd ack-demo
```

🐳 Start Docker and Create Your Local Cluster
Ensure Docker is running. We’ll use it to spin up a local Kubernetes cluster using kind.

```bash
kind create cluster --config kind.yaml
```

```yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: dot
nodes:
- role: control-plane
  kubeadmConfigPatches:
  - |-
    kind: InitConfiguration
    nodeRegistration:
      kubeletExtraArgs:
        node-labels: "ingress-ready=true"
  extraPortMappings:
  - containerPort: 8080
    hostPort: 8080
    protocol: TCP
  - containerPort: 443
    hostPort: 443
    protocol: TCP
```

dot.nu:

```bash
#!/usr/bin/env nu

source  scripts/common.nu
source  scripts/kubernetes.nu
source  scripts/ack.nu
source  scripts/crossplane.nu

def main [] {}

def "main setup" [] {

    rm --force .env

    main create kubernetes aws

    kubectl create namespace a-team

    kubectl --namespace a-team apply --filename rds-password.yaml

    main apply ack

    main apply crossplane --preview true --provider aws

    (
        kubectl apply 
            --filename crossplane-providers/cluster-role.yaml
    )

    (
        kubectl apply
            --filename crossplane-providers/provider-kubernetes-incluster.yaml
    )

    kubectl apply --filename dot-sql-config.yaml

    main wait crossplane

    main print source
    
}

def "main destroy" [] {

    main destroy kubernetes aws

    main delete ack
}
```

```bash
devbox shell
chmod +x dot.nu
./dot.nu setup
source .env
```

The kind.yaml file defines networking + node settings tailored for ACK.

## 🧬 ACK CRDs: AWS Infra as K8s Resources

Once the ACK controllers are installed, Kubernetes gains a bunch of new CRDs that represent AWS services — from RDS and S3 to EC2 subnets and VPCs.

Let’s take a look:

```bash
kubectl get crds | grep k8s.aws
```

You’ll see CRDs like:

```bash
dbinstances.rds.services.k8s.aws
vpcs.ec2.services.k8s.aws
subnets.ec2.services.k8s.aws
securitygroups.ec2.services.k8s.aws
...
```

Each CRD represents an AWS resource you can now define using a Kubernetes manifest. Think of it as Terraform, but via kubectl apply.

## 🚀 Deploying the ACK RDS Controller (locally with kind)

Since we’re using kind, not EKS, there’s no IRSA — so we authenticate with static AWS credentials injected into a K8s secret.

You already did this with ./dot.nu setup, but for clarity:

```bash
kubectl create ns ack-system

kubectl create secret generic ack-creds \
  -n ack-system \
  --from-literal=AWS_ACCESS_KEY_ID=<key> \
  --from-literal=AWS_SECRET_ACCESS_KEY=<secret>
```

Install the RDS ACK controller with Helm:

```bash
helm repo add ack https://aws.github.io/eks-charts
helm repo update

helm install ack-rds-controller ack/ack-rds-controller \
  -n ack-system \
  --set aws.region=us-east-1 \
  --set aws.secret.name=ack-creds
```

Now your cluster has a controller watching DBInstance resources and creating matching RDS instances in AWS.

## 🏗️ Defining an RDS PostgreSQL Instance (and dependencies)

Creating a DB in AWS isn’t one resource — it’s VPCs, Subnets, Gateways, RouteTables, and finally the DBInstance.

Here’s a peek from rds.yaml:

```yaml
apiVersion: ec2.services.k8s.aws/v1alpha1
kind: VPC
metadata:
  name: my-db
spec:
  cidrBlock: 11.0.0.0/16
---
apiVersion: ec2.services.k8s.aws/v1alpha1
kind: InternetGateway
metadata:
  name: my-db
spec:
  vpcRef:
    from:
      name: my-db
---
apiVersion: ec2.services.k8s.aws/v1alpha1
kind: Subnet
metadata:
  name: my-db-a
spec:
  cidrBlock: 11.0.1.0/24
  availabilityZone: us-east-1a
  vpcRef:
    from:
      name: my-db
...
apiVersion: rds.services.k8s.aws/v1alpha1
kind: DBInstance
metadata:
  name: my-db
  annotations:
    services.k8s.aws/region: us-east-1
spec:
  dbInstanceClass: db.t3.micro
  engine: postgres
  engineVersion: "16.3"
  allocatedStorage: 20
  masterUsername: masteruser
  masterUserPassword:
    name: my-db-password
    key: password
  dbInstanceIdentifier: my-db
  publiclyAccessible: true
  dbSubnetGroupRef:
    from:
      name: my-db
  vpcSecurityGroupRefs:
    - from:
        name: my-db
Also, create a Secret with the DB password:
```

Also, create a Secret with the DB password:

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: my-db-password
stringData:
  password: MySuperSecretPassw0rd!
```

Apply all resources:

```bash
kubectl apply -f rds-password.yaml
kubectl apply -f rds.yaml
```

Check the instance status:

```bash
kubectl get dbinstances.rds.services.k8s.aws
```

Once it's STATUS=available, your RDS instance is live.

## 🔍 Observability in ACK: Where’s the Feedback?

Once you start working with ACK, you’ll quickly hit a snag: visibility into resource states is... primitive at best.

You might try this:

```bash
kubectl -n a-team get \
  vpcs.ec2.services.k8s.aws,internetgateways.ec2.services.k8s.aws,routetables.ec2.services.k8s.aws,securitygroups.ec2.services.k8s.aws,subnets.ec2.services.k8s.aws,dbsubnetgroups.rds.services.k8s.aws,dbinstances.rds.services.k8s.aws
```

Output:

```bash
NAME    ID                       STATE
my-db   vpc-07cdab5bba559b994   available
...
my-db   subnet-0340...          available
...
my-db   db-2NOHJMPDDGYBPY6MH... creating
```
You get barebones info like STATE or STATUS, but it’s inconsistent and often misleading. Some resources use STATE, others use STATUS, and many don’t update accurately.

### 😡 Case Study: Broken Subnet

```bash
kubectl describe subnet.ec2.services.k8s.aws my-db-x
```

Yields:

```bash
Message: api error InvalidParameterValue: Value (us-east-1x) for parameter availabilityZone is invalid
Type:    ACK.Terminal
```

That’s actually helpful — the AZ doesn’t exist. But now try describing a working DBInstance:

```bash
kubectl describe dbinstance.rds.services.k8s.aws my-db
```

You’ll get a dump of AWS metadata with no intuitive indication of what’s actually happening. You have to hunt down .status.dbInstanceStatus and hope it says something like available or configuring-enhanced-monitoring.

No Ready condition. No events. No unified status format. ACK controllers don’t expose standard Kubernetes conditions. That’s not just annoying — it breaks integrations with Argo CD, Crossplane, and others.

AWS Controllers for Kubernetes


## Introduction

AWS EKS defaults to the VPC CNI plugin, assigning VPC IPs to pods via ENIs. While straightforward, this setup limits pod density per node and consumes VPC IPs rapidly. To overcome these constraints, deploying Calico with IPIP or BGP offers a scalable alternative.

## Why Replace AWS VPC CNI?

- Pod Density Limitations: ENI and IP limits per instance type restrict the number of pods per node.
- VPC IP Consumption: Each pod consumes a VPC IP, leading to potential exhaustion.
- Complex Networking: Managing ENIs and secondary IPs adds complexity.

Calico addresses these issues by providing flexible IP address management and networking modes.
Calico Docs

## Calico Networking Modes

- IPIP (IP-in-IP): Encapsulates pod traffic, allowing for scalable networking without consuming VPC IPs.
- BGP (Border Gateway Protocol): Distributes routing information between nodes, enabling efficient traffic routing.

## Calico Docs

- [Calico Docs](https://docs.tigera.io/calico/latest/getting-started/kubernetes/managed-public-cloud/eks/ipip)


## Setup

Manually: `eksctl create cluster --name calico-cluster --without-nodegroup`

Using Terraform:

We're going to use community modules for the VPC and EKS cluster to avoid reinventing the wheel and keep things simple. 

Providers:

```hcl
provider "aws" {
  region = "us-west-2"
}

variable "cluster_name" {
  default = "calico-eks-cluster"
}

variable "region" {
  default = "us-west-2"
}
```

Create VPC & subnets:

```hcl
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "3.14.2"

  name = "calico-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["us-west-2a", "us-west-2b"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = true

  tags = {
    Name = "calico-vpc"
  }
}
```

Create EKS Cluster without nodegroup:

```hcl
module "eks" {
  source          = "terraform-aws-modules/eks/aws"
  version         = "20.4.0"
  cluster_name    = var.cluster_name
  cluster_version = "1.27"

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  enable_irsa = true

  manage_aws_auth = true
  create_node_security_group = true

  eks_managed_node_groups = {}

  node_security_group_additional_rules = {
    ingress_self_all = {
      description = "Node to node communication"
      protocol    = "-1"
      from_port   = 0
      to_port     = 0
      type        = "ingress"
      self        = true
    }
  }

  tags = {
    Environment = "dev"
    Terraform   = "true"
  }
}
```

`terraform init`
`terraform apply`

## Configure Calico as CNO

```bash
aws eks --region us-west-2 update-kubeconfig --name calico-eks-cluster # Configure kubectl to use the new cluster

kubectl delete daemonset aws-node -n kube-system # Delete the AWS VPC CNI plugin
```

## Deploy Calico

```bash
# install calico operator
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.29.3/manifests/tigera-operator.yaml
```

## Calico installation

For IPIP mode, we need to set the `ipPools` to use the `IPIP` encapsulation mode.

```yaml
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  kubernetesProvider: EKS
  cni:
    type: Calico
  calicoNetwork:
    bgp: Disabled
    ipPools:
      - cidr: 192.168.0.0/16
        encapsulation: IPIP
        natOutgoing: Enabled
        nodeSelector: all()
```

For BGP mode, we need to set the `bgp` to `Enabled` and configure the `ipPools` to use the `BGP` encapsulation mode.

```yaml
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  kubernetesProvider: EKS
  cni:
    type: Calico
  calicoNetwork:
    bgp: Enabled
    ipPools:
      - cidr: 192.168.0.0/16
        encapsulation: None
        natOutgoing: Enabled
        nodeSelector: all()
```

depending on which one you use, run `kubectl apply -f <file>.yaml` to deploy Calico.

## Add node groups

We add node groups after the Calico installation to ensure that the nodes are created with the correct configuration.

Update your Terraform configuration to add node groups:

```hcl
module "eks" {
  # ... existing configuration ...

  eks_managed_node_groups = {
    calico_nodes = {
      desired_capacity = 2
      max_capacity     = 3
      min_capacity     = 1

      instance_types = ["t3.medium"]
      subnet_ids     = module.vpc.private_subnets
    }
  }
}
```

`terraform apply`

## Why Node Groups Are Added After Calico Installation

If you create node groups before removing the AWS VPC CNI (aws-node), the following happens:

- Nodes boot up with the AWS VPC CNI already running.
- Each node tries to attach ENIs and configure VPC IPs.
- This conflicts with Calico's CNI once you install it.
- Even worse: nodes may go NotReady or your pods may fail to get Calico-managed IPs.

## Verify Calico

```bash
kubectl get pods -n calico-system
```

## Configure BGP Peering (optional)

If you want to use BGP peering, you need to configure the BGP peering between the nodes and the VPC.

If using BGP mode and need to configure peering:

Disable Node-to-Node Mesh:

```bash
calicoctl patch bgpconfiguration default -p '{"spec": {"nodeToNodeMeshEnabled": false}}'
```

Configure Global BGP Peer:

```yaml
apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
  name: global-peer
spec:
  peerIP: <peer-ip>
  asNumber: <asn>
```

`kubectl apply -f bgp-peer.yaml`


EKS without VPC CNI: Deploying Calico with IPIP and BGP


## 🔍 Overview

AWS PrivateLink enables secure, private connectivity between VPCs and services hosted on AWS without exposing traffic to the public internet. It's essential for secure service-to-service communication across accounts or VPCs.

In this post, we'll implement a working PrivateLink setup with Terraform: one VPC exposing a service (via NLB), and another VPC accessing it (via interface endpoint). We'll use two Terraform providers to simulate cross-account setup.

---

## 🛠️ Architecture

```
[ Service Provider VPC ]                  [ Service Consumer VPC ]
[ EC2 (httpd) ] -> [ NLB ] -> [ Endpoint Service ] <- [ VPC Endpoint ] <- [ EC2 ]
```

The service is hosted on a private EC2 behind a Network Load Balancer. An Endpoint Service is created from the NLB. The consumer VPC accesses it through an Interface VPC Endpoint.

---

## 🧱 Prerequisites

- Terraform ≥ 1.0
- Two AWS profiles or roles simulating service provider and consumer
- Basic networking knowledge (subnets, NLB, SGs)

---

## 🧩 Step 1: Service Provider VPC with NLB and Endpoint Service

```go
provider "aws" {
  alias  = "provider"
  region = "us-east-1"
}

resource "aws_vpc" "provider" {
  provider   = aws.provider
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "provider_subnet" {
  provider          = aws.provider
  vpc_id            = aws_vpc.provider.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "us-east-1a"
}

resource "aws_security_group" "provider_sg" {
  provider = aws.provider
  vpc_id   = aws_vpc.provider.id

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/16"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_instance" "provider_instance" {
  provider        = aws.provider
  ami             = "ami-0c94855ba95c71c99"
  instance_type   = "t2.micro"
  subnet_id       = aws_subnet.provider_subnet.id
  security_groups = [aws_security_group.provider_sg.id]
  user_data       = <<-EOF
                #!/bin/bash
                echo "Hello from PrivateLink Service Provider" > index.html
                nohup python -m SimpleHTTPServer 80 &
                EOF
}

resource "aws_lb" "nlb" {
  provider           = aws.provider
  name               = "privatelink-nlb"
  internal           = true
  load_balancer_type = "network"
  subnets            = [aws_subnet.provider_subnet.id]
}

resource "aws_lb_target_group" "tg" {
  provider    = aws.provider
  name        = "privatelink-tg"
  port        = 80
  protocol    = "TCP"
  vpc_id      = aws_vpc.provider.id
  target_type = "instance"
}

resource "aws_lb_target_group_attachment" "tg_attachment" {
  provider         = aws.provider
  target_group_arn = aws_lb_target_group.tg.arn
  target_id        = aws_instance.provider_instance.id
  port             = 80
}

resource "aws_lb_listener" "listener" {
  provider          = aws.provider
  load_balancer_arn = aws_lb.nlb.arn
  port              = 80
  protocol          = "TCP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.tg.arn
  }
}

resource "aws_vpc_endpoint_service" "service" {
  provider                    = aws.provider
  acceptance_required        = true
  network_load_balancer_arns = [aws_lb.nlb.arn]
}
```

---

## 🧩 Step 2: Service Consumer VPC with VPC Endpoint

```go
provider "aws" {
  alias  = "consumer"
  region = "us-east-1"
}

resource "aws_vpc" "consumer" {
  provider   = aws.consumer
  cidr_block = "10.1.0.0/16"
}

resource "aws_subnet" "consumer_subnet" {
  provider          = aws.consumer
  vpc_id            = aws_vpc.consumer.id
  cidr_block        = "10.1.1.0/24"
  availability_zone = "us-east-1a"
}

resource "aws_security_group" "consumer_sg" {
  provider = aws.consumer
  vpc_id   = aws_vpc.consumer.id

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["10.1.0.0/16"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_vpc_endpoint" "consumer_endpoint" {
  provider           = aws.consumer
  vpc_id             = aws_vpc.consumer.id
  service_name       = aws_vpc_endpoint_service.service.service_name
  vpc_endpoint_type  = "Interface"
  subnet_ids         = [aws_subnet.consumer_subnet.id]
  security_group_ids = [aws_security_group.consumer_sg.id]
}
```

---

## 🧪 Testing

- Accept the VPC Endpoint connection from the Provider side.
- SSH into an EC2 in the Consumer VPC and use:

```bash
curl http://<interface-endpoint-dns-name>
```

You should see:

```
Hello from PrivateLink Service Provider
```

---

## 🔐 Security Notes

- Ensure correct SGs between NLB and Endpoint
- Use IAM condition keys or resource policies if needed
- Enable VPC Flow Logs for visibility

---

## 📌 Summary

- We implemented AWS PrivateLink with real infra using Terraform
- Service is exposed internally via NLB and Interface Endpoint
- Setup is secure, scalable, and avoids internet exposure

Next steps? Add DNS, IAM auth, or cross-region routing!

---

A hands-on technical guide to implementing AWS PrivateLink between VPCs using Terraform.

AWS PrivateLink with Terraform


- [**Introduction**](#introduction)
  - [**What's the Deal?** 🚄](#whats-the-deal-)
  - [**Why Switch?** ⚡](#why-switch-)
    - [Motivation for Migration 🛫](#motivation-for-migration-)
  - [**The Planning Phase 📝**](#the-planning-phase-)
    - [Research](#research)
    - [Assessment 📋](#assessment-)
    - [Mapping 🗺️](#mapping-️)
    - [Test Plans 🧪](#test-plans-)
  - [**The Migration Phase (Summarised) 🚀**](#the-migration-phase-summarised-)
    - [Step-by-Step 👟](#step-by-step-)
    - [Tech Stack 🛠️](#tech-stack-️)
  - [Architecture](#architecture)
  - [Deep dive of the Migration (step-by-step)](#deep-dive-of-the-migration-step-by-step)
    - [Distribution Scaffolding](#distribution-scaffolding)
    - [Replicating CDN X Behaviors](#replicating-cdn-x-behaviors)
    - [Deploying to cdn-staging](#deploying-to-cdn-staging)
    - [Integration Testing](#integration-testing)
    - [Non-Production Deployment](#non-production-deployment)
    - [External Test Deployment](#external-test-deployment)
    - [Preview Domains](#preview-domains)
    - [Production Deployment](#production-deployment)
    - [Roll Forward and Observe](#roll-forward-and-observe)
    - [Rollback Plan](#rollback-plan)
  - [Security \& various other aspects of the Migration 🛡️](#security--various-other-aspects-of-the-migration-️)
    - [Key Security Measures](#key-securitymeasures)
  - [Enhancing Security at the Origin](#enhancing-security-at-theorigin)
  - [Certificates \& Protocols](#certificates--protocols)
  - [Customization \& Flexibility](#customization--flexibility)
  - [Logging \& Traceability](#logging--traceability)
  - [Caching Strategies in CloudFront: Do's and Don'ts](#caching-strategies-in-cloudfront-dos-anddonts)
  - [Desired Outcomes](#desired-outcomes)
  - [Limitations](#limitations)
  - [Caching mechanism proposals](#caching-mechanism-proposals)
  - [Challenges faced](#challenges-faced)
  - [The Challenge (one of them)](#the-challenge-one-ofthem)
  - [Incremental Migration: A Safer Approach](#incremental-migration-a-saferapproach)
  - [Replicating Configurations](#replicating-configurations)
  - [Testing the Waters](#testing-the-waters)
  - [Rollback plan](#rollback-plan-1)
  - [Lessons Learned 📚](#lessons-learned)
  - [Key Takeaways 👇](#key-takeaways-)
- [Conclusion](#conclusion)

# **Introduction**

## **What's the Deal?** 🚄
****

![Trainline logo](/images/tl.png)

- Trainline is Europe's leading train and coach app. To put it simply, we are a one-stop-shop for train and coach travel. Every day, we gather routes, prices, and travel times from over 270 rail and coach operators in 45 countries, so that everyone can buy tickets quickly and save time, effort, and money. With millions of users relying on their platform, delivering high-performance content is crucial for ensuring an exceptional user experience. Running 24/7 & with over 100+ million users, such a system needs to always be highly available, easily scalable and our CDN game has to be strong!

- While our previous CDN served us well, we recognized the need to grow and adapt, which led us to explore new CDN alternatives like AWS CloudFront

![CDN](/images/cdn.png)
A content delivery network (CDN) is a geographically distributed group of servers that work together to provide fast delivery of internet content.

## **Why Switch?** ⚡
****

![Under Construction](/images/under-construction.png)

### Motivation for Migration 🛫

Akamai served us well, but as our needs evolved, AWS CloudFront offered better:

- No More Manual Work 🛠️: Streamlined CDN management by cutting out manual processes - the CDN change process is now managed by Terraform Automation.

- Cost-Effective 💰: AWS CloudFront fit well within our budget.

- API Goodness 🤖: Robust APIs made our automation workflows even better.

- DIY Configs 🎛️: Self-service features freed us from additional pro services.

- Automate All The Things 🔄: Full-stack deployment automation, thanks to Infrastructure-as-Code.

- Easy Certs 🔐: AWS Certificate Manager simplified our SSL/TLS needs.

- Cloud-Native 🛡️: Built for high availability and low latency globally.

- Docs and Support 📚: AWS responded quickly and had all the info we needed.

---

## **The Planning Phase 📝**

In the Planning Phase, which spanned over six weeks, we had a core team of 8 - 6 core engineers, 1 team lead & 1 engineering manager.

Switching CDNs is no small task. Here's how we prepared:

### Research

- Origins 🌐: Our primary content source was AWS-hosted ALBs, backends, and S3 buckets. Seamless AWS integration made setting this up a breeze.

- Cache Rules 🚀: We set cache behaviors tailored for different content types (static, dynamic, API responses).


- Extra Features 🌟:

  - Lambda@Edge: Custom Lambda functions added on-the-fly tweaks at the edge locations. Think URL rewriting, and user auth.
  - Geo-Restrictions 🌍: To comply with legal stuff, we used CloudFront’s geo-blocking.
  - Data Squeeze 🗜️: Gzip compression minimized data transfer and sped things up.
  - SSL/TLS with ACM 🔒: Integrated seamlessly with Amazon Certificate Manager for our security needs.

### Assessment 📋

We started by reviewing our existing Akamai configurations:

- List of Assets: Documented all static and dynamic assets.
- Edge Rules: Cataloged all caching and forwarding rules.

### Mapping 🗺️

We then mapped Akamai features to their AWS CloudFront equivalents.

- Cache Policies: Mapped to CloudFront’s caching settings.
- Forwarding Rules: Mapped to Lambda@Edge functions.

### Test Plans 🧪

- Proof of Concept: Tested CloudFront with a single, low-traffic asset.
- Performance Benchmarks: Used tools like WebPageTest for speed comparison.
- We used preview distributions to test our configurations before deploying them to production.

---

## **The Migration Phase (Summarised) 🚀**

During the Migration Phase, which lasted about four to six months, we looped in our QA teams, developers, and had weekly syncs with internal stakeholders. 

![Migration Architecture](/images/migration-arch.png)

### Step-by-Step 👟

Phase 1: Small-Scale Testing
- We created our internal CloudFront Terraform module.

```go
# Our rough module structure
module "cloudfront-distribution" {
  source  = "<module_source>"
  version = "<module_version>"

  cloudfront_functions   = "function_demo"
  default_cache_behavior = [<Default Cache Behaviour ARN goes here>]
  domain_names           = ["thetrainline.com", "trainline.eu"]
  environment_type       = "Production"

  custom_origins         = ALB
  description            = "CloudFront Distribution for Trainline"
  http_version           = HTTP/2
  waf_name               = "CDN-WAF"
}
```

- Set up CloudFront Distribution: Created a new distribution via our custom module
- DNS Routing: Used Cloudflare for DNS testing. 
- Monitor and Tweak: Observed performance through Kinesis logs.

Phase 2: Full Migration

- Gradual Traffic Routing: Increased the weight for CloudFront in Route 53. (In small incrmements) - 5% > 10% > 25% > 50% > 75% > 100%
- Final Checks: Ensured all assets and rules were correctly migrated.
- Traffic Switchover: Moved 100% traffic to CloudFront.

### Tech Stack 🛠️

- Terraform: Infrastructure as Code for CloudFront configurations.
- AWS Route 53: DNS management.
- Kinesis Logging: Real-time logging.
- Spacelift: Terraform state management & CICD for Terraform.
- Terratest: Automated module testing.
- AWS ACM & Shield: SSL certificates and DDoS protection.
- Custom WAF Module: Our home-brewed Web Application Firewall module.
- Internal CDN-CloudFront Module: Custom module for easier CloudFront setup.
- OPA Policies: Compliance checks.

## Architecture

General Architecture of our CDN

![CDN Architecture](/images/cdn-general.png)

![Pre-Migration](/images/pre-migration.png)

![Post-Migration](/images/post-migration.png)

## Deep dive of the Migration (step-by-step)

In this section, we deep dive into the migration steps and the considerations that shaped our migration journey.

### Distribution Scaffolding

We developed an internal scaffolding tool. This tool simplifies the initial setup, and generates a PR to create new Spacelift stacks (we use these to manage our Terraform configuration) and a CDN distribution template based on our CDN module. It's a streamlined way to kick off new CDN distribution creation. A new repository is created with the pattern of "cdn-distribution-<distribution-name>"

One repository per distribution: We created a separate repository for each distribution. This allowed us to manage changes and deployments independently. It also was a neat way to handle granular control and isolated deployments.

### Replicating CDN X Behaviors

We aimed to copy the CDN X behaviours onto AWS CloudFront, ensuring the transition maintained functionality and performance across different domains.

### Deploying to cdn-staging

To facilitate testing, we deployed changes to the cdn-staging environment. Triggering a manual deployment in Spacelift allowed for comprehensive testing.

### Integration Testing

We created test suites to verify intended behaviours and policies. These suites were triggered manually and via continuous integration (CI) for every commit in the main repository. Tests were mocked in Jest against an origin.

### Non-Production Deployment

Before going live, we started with non-production deployments. The CDN- repository housed the Terraform code for CDN resource creation. Staging deployments were performed against a mock origin.

### External Test Deployment

After successful staging, external test deployments were initiated to confirm expected behaviours and policies.

### Preview Domains

We set up a preview domain for testing our production CDN configurations. This allowed for robust testing and minimized risks during the live environment switch.

### Production Deployment

Finally, we moved to production. The changes were closely monitored to ensure a seamless transition.
Network Changes and DNS Flip
Our networking team handled DNS changes and gradually shifted the traffic from CDN X to CloudFront.

### Roll Forward and Observe

After the DNS flip, we observed CDN performance for a week to validate the migration's effectiveness.

### Rollback Plan

We had a well-defined rollback plan to mitigate any unforeseen issues, ensuring minimal user disruption.
We did this for over 300+ domains that were migrated fully from CDN X to CloudFront including the main site www.thetrainline.com, all European sites and many other domains owned by Trainline.

![CDN Migration](/images/cdn-migration-graph.png)

Graph showing after we fully migrated from CDN X to CloudFront (CDN X in blue and CloudFront in orange)

## Security & various other aspects of the Migration 🛡️

When migrating to a CDN setup, it's not just about speed and efficiency. Security is equally important. Let's dig into how we layered our security during this migration.

### Key Security Measures

- Attack Prevention: We deployed AWS Shield Advanced for robust DDoS protection and AWS WAF to guard against common web threats like SQL injections and XSS.

- Rate & Traffic Control: AWS WAF's rate-based rules helped us handle sketchy traffic surges. We also used DataDome for behavioural analysis, identifying bad bots and rogue IPs.

- Data Encryption & Access: Using CloudFront's field-level encryption, we ensured that sensitive information stays secure. IAM policies dictate who has access to what, so there's no funny business.

- Monitoring & Alerts: All critical data goes to Splunk, where we've set up alerts for unusual behaviour. This keeps us in the loop and ready to act.

## Enhancing Security at the Origin

Origin Access Identity (OAI) secures our S3 bucket, while custom headers add another layer of security for Application Load Balancers (ALB).

## Certificates & Protocols

AWS Certificate Manager auto-renews our SSL certificates. We support TLS 1.3 and 1.2, sticking to the latest encryption standards. We also used the latest ciphers.

## Customization & Flexibility

Lambda@Edge and CloudFront Functions handle domain redirects and request customization. We also make use of CloudFront's geo-headers to adapt content based on user location.

## Logging & Traceability

All logs flow into an S3 bucket before landing in Splunk for deeper analysis. Our Infrastructure as Code (IaC) approach ensures all CDN config changes are version-controlled.

By keeping our focus on these key areas, we managed to secure our CDN migration without any major hiccups. With these measures in place, we're not just faster; we're also more secure.

## Caching Strategies in CloudFront: Do's and Don'ts

Caching can dramatically improve your website's performance, but it's not as straightforward as it seems. In this section, we'll delve into some key considerations for setting up caching policies, with a special focus on AWS CloudFront.

## Desired Outcomes

- Versioned Assets: Always use versioned asset names. This allows you to set longer cache durations without the need for a CDN-level cache reset.

- Cache-Control: Application teams should be setting the cache-control headers directly within the app. You can use the s-maxage directive specifically for CDN-level caching and max-age for both browser and CDN caching.

- S3 Backend: If your resources are in an S3 bucket, ideally the Cache-Control header should be set on the S3 objects themselves.

## Limitations

- File Extensions: Unfortunately, CloudFront doesn't let you set caching policies based on file extensions directly.

- Negative Match: You can't set up rules like "cache this but not that within the same directory." This complicates scenarios where you'd like varying cache durations for similar endpoints.

- Arbitrary Headers: Conditional caching based on the existence of arbitrary headers isn't straightforward either.

## Caching mechanism proposals

- Default to Max-Age 0: If Cache-Control is not set at the origin, it's a good practice to set the default max-age to zero. This prevents sensitive data from being accidentally cached.

- Log Analysis: Regularly review your logs to adjust your caching strategy, ensuring you're not sacrificing security for performance or vice versa.

## Challenges faced

Switching a major domain from one CDN to another is no small task. Let's delve into how we approached migrating www.thetrainline.com from CDN X to CloudFront, given its complexity and high traffic volume.

## The Challenge (one of them)

www.thetrainline.com used to account for a whopping 70%+ of all CDN X traffic for Trainline, with over 8500 lines of JSON configurations. A direct switch to CloudFront could risk downtime and disruptions, something we wanted to avoid.

## Incremental Migration: A Safer Approach

When we decided to migrate from CDN X to CloudFront, we knew we had to tread carefully to ensure a smooth transition without disruptions. Here's a streamlined version of our approach:

## Replicating Configurations
We began by replicating the essential CDN X configurations in CloudFront for a specific subset of requests. This groundwork was crucial for a successful migration.

## Testing the Waters

Rather than making an abrupt switch, we opted for a gradual transition. We used Route53 weighted DNS to direct a portion of our traffic to CloudFront while maintaining a watchful eye on performance and any potential issues that might arise.

## Rollback plan
Recognising that no migration is entirely risk-free, we reduced the TTL on the CNAME record for www.thetrainline.com to 5 minutes well in advance of the migration. If anything went awry during the process, we could quickly revert all requests back to CDN X. This safety net gave us the confidence to proceed.

## Lessons Learned 📚

In a short span of less than 9 months, and with just a small team, we pulled off the mammoth task of migrating from CDN X to AWS CloudFront. This wasn't a mere lift-and-shift; it was more like re-engineering the aeroplane while in flight!

We had to rethink our architecture, break down our CDN monolith into more manageable parts, and pave the way for a smoother transition. The automated frameworks we set up ensured faster and safer changes during deployment.

## Key Takeaways 👇

- Planning: No matter how straightforward a project seems, don't skimp on planning. A little planning upfront can save you hours of work down the line.

- Route 53 Magic & Cloudflare: Use Route 53's weighted records and CNAMEs for a smooth DNS transition. It's like a GPS for your data packets.

- Read Up, Level Up: Spend time with CloudFront's & AWS docs. It'll save you hours of debugging and redesign. Trust us, you don't want to learn CDN features the hard way.

- Think Before You Leap: Always consider the architectural differences between your current CDN and the one you're migrating to. One size doesn't fit all; the trick is to tailor-fit your solutions.

- Lambda@Edge Limits: If you're planning on using Lambda@Edge, understand its scaling model. And don't hesitate to contact AWS if you need to extend your quotas, particularly for large-scale deployments.

- HTTPS All The Way: Make sure to redirect all HTTP traffic to HTTPS for added security. You can set this up easily in CloudFront.

- WAF Magic: Use AWS WAF with CloudFront to protect against common web exploits. With just a few clicks, you can secure your application without breaking a sweat.

- Use IaC: Infrastructure as Code, particularly Terraform, can be a lifesaver. It streamlines your operations, making changes quicker and less error-prone.

- Rollback Plan: Always have a rollback strategy when making changes. If things go south, you should be able to revert to the previous state ASAP.

- DDoS Protection: Employ rate limiting and other DDoS protection mechanisms to shield your services.

- Phased Migration: Especially for high-traffic domains, consider migrating in phases. This helps in risk mitigation and allows for easier troubleshooting.

- Monitoring: Don't just set it and forget it. Keep a constant eye on performance metrics. Your future self will thank you.

# Conclusion

Migrating a CDN is not just a technical task; it's a strategic move that impacts your organization on multiple levels. For those in leadership positions and on the engineering frontlines, the insights gained from such an endeavour are invaluable.

Plan carefully, understand the constraints, and invest time in learning about the features and limitations of your chosen services. Security should be a core focus, not an add-on. Leverage tools that facilitate a smoother transition, and don't underestimate the importance of monitoring performance metrics.

The experiences and challenges faced during a migration offer a unique learning opportunity. Use it as a chance to refine processes, improve collaboration, and further develop technical skills across your team.

In short, a CDN migration is a significant commitment but, if executed well, it can lead to streamlined operations, improved performance, and a stronger security posture.

Acknowledgements:

To wrap things up, this migration was a massive team effort and a learning experience for all of us. We've seen tangible benefits, from some cost savings to better automation/self-service and even improved site performance. What's next, you ask? We have loads of projects that we are currently working on and hopefully, aim to share with you soon. Stay tuned!


How we migrated our CDN to AWS CloudFront at Trainline


## Introduction

### Why Consider a NAT Instance Over a NAT Gateway?

AWS offers NAT Gateways as the default, fully managed solution for letting private subnet resources reach the internet. However, NAT Gateways can be pricey:
- **Hourly cost:** ~₹3.75/hour (varies by region)
- **Data transfer cost:** Additional ₹3.75/GB on top of standard data transfer

For small dev/test environments or personal labs, these costs can add up quickly. In contrast, a NAT Instance is just a normal EC2 instance configured to perform IP forwarding and NAT. It’s typically much cheaper to run a small instance (`t3.micro`) than a NAT Gateway, especially if your traffic volume is modest.

### How NAT Works (Big Picture)
**NAT (Network Address Translation)** is a way for devices on a private network to communicate with the outside world using a single (or a small number of) public IP(s). In AWS:
1. **Private Subnet** resources route outbound traffic to a NAT device (gateway or instance).
2. **NAT Device** replaces the private source IP with its own public IP.
3. **Return traffic** from the internet is routed back to the NAT device, which translates it back to the private source IP.

The AWS NAT Gateway handles this as a managed service. A **NAT Instance** is a do-it-yourself approach:
- You pick an EC2 AMI and instance type.
- You enable IP forwarding and set up iptables rules for NAT.
- You configure your private subnet route table to point `0.0.0.0/0` traffic at the NAT Instance.

---

## High-Level Comparison

| Feature                | NAT Gateway                       | NAT Instance                          |
|------------------------|-----------------------------------|---------------------------------------|
| **Managed Service**    | Yes (HA if deployed in multiple AZs) | No (you manage patching, health, etc.)|
| **Cost**               | Hourly + data transfer surcharges | EC2 hourly cost + standard data transfer |
| **Complexity**         | Very low                          | Medium (iptables, IP forwarding)      |
| **Ideal Use Case**     | Production/high-volume            | Dev/test/labs or cost-sensitive setups|

---

## Step-by-Step: Setting Up a NAT Instance Manually

Below is a straightforward approach using Amazon Linux 2 or Ubuntu. You can adapt it as needed.

### 1. Launch an EC2 in a Public Subnet
- **AMI**: Amazon Linux 2 or Ubuntu (lightweight, widely supported).
- **Instance Type**: `t3.micro` for small workloads; scale up if needed.
- **Network**: Must be in a **public subnet** that has a route to an Internet Gateway.
- **Security Group**:
  - Inbound: Typically just SSH (port 22 from your IP or VPC CIDR) and maybe ICMP for debugging.
  - Outbound: Usually all traffic is allowed.
- **Elastic IP**: Allocate an Elastic IP and associate it to this instance to maintain a stable public IP.

### 2. Enable IP Forwarding

SSH into the instance and enable forwarding:

```bash
sudo su -
echo 1 > /proc/sys/net/ipv4/ip_forward

# Make forwarding persistent across reboots
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p
```

### Configure iptables for NAT

On Amazon Linux 2 or Ubuntu, set up iptables to NAT outgoing traffic:

```bash
# Flush existing rules first (careful in production!)
iptables -F
iptables -t nat -F

# MASQUERADE traffic going out the public interface (often named eth0)
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Forward packets (replace eth0 with your interface if it differs)
iptables -A FORWARD -i eth0 -o eth0 -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

# Persist iptables rules (varies by distro)
service iptables save 2>/dev/null || iptables-save > /etc/sysconfig/iptables
```

### Update Private Subnet Route

In your private subnet’s Route Table:

- Destination: `0.0.0.0/0`

- Target: The Instance ID of the NAT Instance

### Verify

Create a test EC2 in the private subnet, SSH in (bastion or Session Manager), and run:

```bash
curl https://google.com
```

If it responds, your NAT Instance is up!

## Method 2: Automated Setup with Packer & Terraform (Recommended)

For more repeatable deployments (e.g., multiple regions/accounts), it’s better to bake an AMI with the NAT settings pre-applied and spin it up via Terraform. That way, you avoid repeating manual steps.

### Step A: Create a Packer Template

Below is a Packer HCL example (packer-nat.hcl). It builds an AMI from Amazon Linux 2, enables IP forwarding, and configures the iptables NAT rules.

```hcl
packer {
  required_plugins {
    amazon = {
      version = ">= 0.0.1"
      source  = "github.com/hashicorp/amazon"
    }
  }
}

variable "aws_region" {
  type    = string
  default = "us-east-1"
}

source "amazon-ebs" "nat_instance" {
  region               = var.aws_region
  instance_type        = "t3.micro"
  ami_name             = "custom-nat-{{timestamp}}"
  source_ami_filter {
    filters = {
      name                = "amzn2-ami-hvm-*-x86_64-gp2"
      root-device-type    = "ebs"
      virtualization-type = "hvm"
    }
    owners      = ["137112412989"] # Amazon Linux 2 official owner
    most_recent = true
  }
  ssh_username         = "ec2-user"
}

build {
  name    = "nat-instance-ami"
  sources = ["source.amazon-ebs.nat_instance"]

  provisioner "shell" {
    inline = [
      "echo 1 > /proc/sys/net/ipv4/ip_forward",
      "echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf",
      "sysctl -p",
      "iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE",
      "iptables -A FORWARD -i eth0 -o eth0 -j ACCEPT",
      "iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT",
      "service iptables save 2>/dev/null || iptables-save > /etc/sysconfig/iptables"
    ]
  }
}
```

### Step B: Build the AMI

```bash
packer build -var aws_region=us-east-1 packer-nat.hcl
```

| This will create a new AMI (named custom-nat-<timestamp>) in your account.

### Step C: Use the AMI in Terraform

```go
# main.tf

provider "aws" {
  region = var.aws_region
}

resource "aws_security_group" "nat_instance_sg" {
  name        = "nat-instance-sg"
  description = "Security Group for NAT instance"
  vpc_id      = var.vpc_id

  ingress {
    description      = "SSH from my IP"
    from_port        = 22
    to_port          = 22
    protocol         = "tcp"
    cidr_blocks      = [var.my_ip_cidr]
  }

  # Egress can be wide open for NAT traffic
  egress {
    from_port        = 0
    to_port          = 0
    protocol         = "-1"
    cidr_blocks      = ["0.0.0.0/0"]
  }
}

resource "aws_instance" "nat_instance" {
  ami                         = var.nat_ami_id
  instance_type               = "t3.micro"
  subnet_id                   = var.public_subnet_id
  associate_public_ip_address = true
  vpc_security_group_ids      = [aws_security_group.nat_instance_sg.id]

  tags = {
    Name = "my-nat-instance"
  }
}

resource "aws_eip" "nat_instance_eip" {
  instance = aws_instance.nat_instance.id
  depends_on = [aws_instance.nat_instance]
}

resource "aws_route" "private_subnet_to_nat" {
  route_table_id         = var.private_subnet_rtb_id
  destination_cidr_block = "0.0.0.0/0"
  instance_id            = aws_instance.nat_instance.id
}

// Usage:

// Update variables (vpc_id, public_subnet_id, private_subnet_rtb_id, etc.) with your environment details.

// terraform init && terraform apply.

// Terraform will:

// - Launch an EC2 using the custom NAT AMI
// - Assign it a public IP via an EIP
// - Create a route in the private subnet’s route table, pointing default traffic to this NAT instance.
```

## Operational Tips

- **High Availability:** One NAT instance is a single point of failure. If you need robust HA, you’ll have to deploy multiple NAT instances in multiple AZs and handle failover logic. NAT Gateway does this automatically (in a multi-AZ deployment).

- **Scaling:** NAT Gateways auto-scale with traffic. For NAT Instances, you’ll need to monitor traffic and bump up the instance size or add more NAT instances if traffic grows.

- **Security:**

  - Keep OS packages up to date.
  - Restrict inbound SSH to your IP only.

  - The instance is publicly exposed, so ensure best practices are followed for patching and firewall rules.

- **Cost:** A small NAT Instance can run ~£4/month, whereas NAT Gateways can be ~£24/month + premium data transfer costs. For dev/test, which is a fair amount.

## Conclusion

- **Method 1 (Manual)** is a quick way to see how NAT Instances work in a single environment.

- **Method 2 (Automated via Packer & Terraform)** is ideal for repeated or multi-account deployments. You save both money (vs. NAT Gateway) and time (vs. manual config each time).

If your traffic is light and you’re comfortable managing an instance, NAT Instances are a great cost-saving option—especially for labs, side projects, and dev/test. Meanwhile, production setups might still justify the ease and auto-scaling reliability of NAT Gateways.

Why I replaced AWS NAT Gateway with a NAT Instance - and saved 20$ of dollar per month

The Ultimate Pathway to DevOps Revamped


In this article, we'll walk through creating a custom Amazon Machine Image (AMI) with [HashiCorp Vault](https://www.vaultproject.io/) baked in using [Packer](https://www.packer.io/), launching an EC2 instance with the generated AMI, and then configuring Vault to store and access secrets.

## Overview

This guide covers:

1. **Baking the Vault AMI with Packer:** Cloning the repository and running Packer to generate the AMI.
2. **Launching the Vault EC2 Instance:** Using the created AMI to spin up an EC2 instance.
3. **Configuring Vault:** Initializing, unsealing, and verifying Vault on the instance.
4. **Storing and Accessing Secrets:** A brief walkthrough on adding and retrieving secrets with Vault.

## Prerequisites

- An AWS account with appropriate IAM permissions.
- [Packer](https://www.packer.io/) installed locally.
- Optionally, the AWS CLI or Terraform to launch EC2 instances.
- Basic familiarity with HashiCorp Vault and AWS concepts.

## Step 1: Baking the Vault AMI with Packer

```bash
touch vault-ami.pkr.hcl
```

## Step 2: Build the AMI

```hcl
packer {
  required_plugins {
    amazon = {
      version = ">= 1.0.0"
      source  = "github.com/hashicorp/amazon"
    }
  }
}


variable "aws_region" {
  default = "us-east-1"
}

variable "ami_name" {
  default = "vault-server-ami"
}

variable "instance_type" {
  default = "t3.micro"
}

variable "source_ami" {
  default = "ami-090fa75af13c156b4" # Amazon Linux 2 (Change if using Ubuntu)
}

variable "ssh_username" {
  default = "ec2-user" # Use "ubuntu" for Ubuntu AMIs
}

# AWS Builder Configuration
source "amazon-ebs" "vault_ami" {
  region                      = var.aws_region
  source_ami                  = var.source_ami
  instance_type               = var.instance_type
  ssh_username                = var.ssh_username
  ami_name                    = var.ami_name
  ami_description             = "Pre-configured Vault AMI"
  associate_public_ip_address = true
  tags = {
    Name = "Vault AMI"
  }
}

# Provisioners (Runs the Vault install script)
build {
  sources = ["source.amazon-ebs.vault_ami"]

  provisioner "file" {
    source      = "install_vault.sh"
    destination = "/tmp/install_vault.sh"
  }

  provisioner "shell" {
    inline = [
      "chmod +x /tmp/install_vault.sh",
      "sudo /tmp/install_vault.sh"
    ]
  }
}
```

### Create the install script

```bash
#!/bin/sh

# Download and move latest Vault release to bin.
printf "\n\nFetching Vault binary"
cd /opt/ && sudo curl -o vault.zip https://releases.hashicorp.com/vault/1.13.1/vault_1.13.1_linux_amd64.zip
sudo unzip vault.zip
sudo mv vault /usr/bin/

# Create a user named vault to be run as a service.
printf "\n\nCreating vault user"
sudo useradd --system --home /etc/vault.d --shell /bin/false vault

# Configure Vault as a System Service
printf "\n\nConfiguring vault as system service"
sudo wget https://raw.githubusercontent.com/moabukar/vault-ami/main/non-tls/non-tls-vault.service
sudo mv  non-tls-vault.service /etc/systemd/system/vault.service
sudo mkdir /etc/vault.d
sudo chown -R vault:vault /etc/vault.d
sudo mkdir /vault-data
sudo chown -R vault:vault /vault-data
sudo mkdir -p /logs/vault/

sudo wget https://raw.githubusercontent.com/moabukar/vault-ami/main/non-tls/non-tls.hcl
sudo mv non-tls.hcl /etc/vault.d/vault.hcl

# Start vault as a service
printf "\n\nEnabling vault as a service"
sudo systemctl enable vault
sudo systemctl start vault
sudo systemctl status vault
```

Review the Packer configuration file (for example, vault-pkr.hcl) to see how Vault is installed and configured. Then, build the AMI using Packer:

```bash
packer build vault-ami.pkr.hcl
```

Note: If the configuration file has a different name (for example, packer.hcl), use that filename.

Packer will run through the steps (e.g., installing Vault, applying configuration, etc.) and output an AMI ID in your AWS account.

## Step 2: Launching the Vault EC2 Instance

With the AMI baked, launch an EC2 instance using the new AMI. You can use the AWS Management Console, CLI, or Terraform. For example, using Terraform

```go
provider "aws" {
  region = "eu-west-2"
}

variable "ami_id" {
  default = "ami-010b1877662d8747c"
}

resource "aws_instance" "vault" {
  ami                    = var.ami_id
  instance_type          = "t3.micro"
  key_name               = "vault-dev"
  vpc_security_group_ids = ["sg-06d59bbad808fc1ee"]


  tags = {
    Name = "Vault Server"
  }
}

output "vault_public_ip" {
  value = aws_instance.vault.public_ip
}

output "ssh_command" {
  description = "SSH into your Vault server"
  value       = format("ssh -i vault-dev.pem ec2-user@%s", aws_instance.vault.public_ip)
}
```

Replace ami-xxxxxxxx with the AMI ID from the Packer build, and update the key name, security group, and subnet ID as appropriate.

## Step 3: Configuring Vault on the Instance

Once your EC2 instance is up, SSH into it:

```bash
ssh -i your-keypair.pem ec2-user@<instance-public-ip>
```

Verify that Vault is installed:

```bash
vault --version
```

Next, initialize Vault. Important: The output will include your unseal key and root token—store these securely.

```bash
vault operator init -key-shares=1 -key-threshold=1
```

Then, unseal Vault using the unseal key provided:

```bash
vault operator unseal <unseal-key>
```

Once unsealed, you can log in with the root token:

```bash
vault login <root-token>
```

Step 4: Storing and Accessing Secrets
Now that Vault is running, you can store secrets. For example, to store a database password:

```bash
vault kv put secret/db password="SuperSecret123!"
```

To retrieve the secret:

```bash
vault kv get secret/db
```

This demonstrates how you can securely manage secrets using Vault.

Conclusion

You now have a full walkthrough to bake a Vault AMI using Packer, launch an EC2 instance with that AMI, configure Vault and start managing secrets securely. This approach streamlines deploying Vault in AWS and is a great addition to any DevOps workflow.


An end-to-end guide for baking a Vault AMI using Packer and deploying a Vault EC2 instance on AWS.

Deploying Vault with a Custom AMI


**A hands-on article on deploying an application on Kubernetes with Fargate.**

As promised, here is the second part of Fargate profiles on EKS. This article will look into deploying a “serverless” pod on EKS Fargate from scratch.

**Note:** We will use the eksctl CLI tool to do this for the purpose of this guide. Infrastructure as Code through Terraform or CloudFormation is advised if you are looking to set this up for your production workloads.

### Prerequisites:

*   Install eksctl command line utility [https://docs.aws.amazon.com/eks/latest/userguide/eksctl.htm](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html)l
*   Installing kubectl [https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)

**Create a Kubernetes cluster on AWS**

A single eksctl command will create the following resources:

*   A VPC with the suitable subnets and accompanying resources
*   K8s control plane
*   Fargate profile
*   IAM role for pod execution

**Note**: Feel free to change the name of the cluster and region.

eksctl create cluster --name eks-fargate --region eu-west-1 -- fargate

This process may take several minutes. When complete, you should see a similar output to show that the cluster is ready to go.

![](https://cdn-images-1.medium.com/max/1760/1*QbuPEpiu8-Rwy1ZNaIJySQ.png)

Cluster and Fargate profile creation

**Verifying the context**

kubectl config current-context

Alternatively, you can use **“kubectx”** to check your current and existing contexts. Install with “brew install kubectx” for Mac and “choco” for Windows.

![](https://cdn-images-1.medium.com/max/1760/1*vvOmaBq3JaxXqGZvR4Avfw.png)

Current context shows that the cluster has been created

**Checking nodes**

We can now check if the fargate profile is ready, it should display at least one Fargate node waiting for our deployments.

kubectl get nodes

![](https://cdn-images-1.medium.com/max/1760/1*Fw5-3lM5fq1-Pg1kWGM1-Q.png)

Fargate nodes ready

**Note:** the nodes that are running inside our VPC are not visible in the EC2 dashboard nor can you SSH into the nodes; they are fully managed and deployed by Fargate by means of “serverless” but you can SSH into a specific pod.

Also, since we haven’t specified the fargate profile by name, the default name for the fargate profile will be “fp-default”. As well as not specifying a namespace, the default namespace will be used to schedule fargate pods. These settings can be changed during setup by specifying the namespace for the Fargate pods.

**Creating a custom Fargate profile**

For the purpose of this guide, we can add an additional fargate profile to show that it can be customised. This can be done with the command:

eksctl create fargateprofile --namespace test --cluster eks-fargate --name fp-test

All pods deployed on the “test” namespace will be scheduled as Fargate pods. We must first create the namespace “test”. Now we can deploy some containers using a default nginx image on the “test” namespace.

**Creating the namespace and deploying pod onto the Fargate-specified namespace**

kubectl create ns test  
kubectl create deploy fargate-pod --image=nginx -n test

We can verify the pods are running by running the command:

kubectl get pods -n test -o wide

![](https://cdn-images-1.medium.com/max/1760/1*PTm6m1zp7fljiFs7GNvLLQ.png)

We can see the pod running on the Fargate node.

Now our pod is running as “serverless”. Well done !

**Clean up your environment**

Now make sure to delete your environment so that you don’t get a heavy billing from AWS :)

Make sure you delete the Fargate profile first and then the cluster itself.

eksctl delete fargateprofile --cluster eks-fargate --name fp-test  
eksctl delete cluster --name eks-fargate --region eu-west-1

Thank you and hope you enjoyed this !

References:

[**AWS Fargate profile**  
_Before you can schedule pods on Fargate in your cluster, you must define at least one Fargate profile that specifies…_docs.aws.amazon.com](https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html "https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html")[](https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html)

[**EKSworkshop.com**  
_The Fargate profile allows an administrator to declare which pods run on Fargate. Each profile can have up to five…_www.eksworkshop.com](https://www.eksworkshop.com/beginner/180_fargate/creating-profile/ "https://www.eksworkshop.com/beginner/180_fargate/creating-profile/")[](https://www.eksworkshop.com/beginner/180_fargate/creating-profile/)

**What’s next?**

*   Look into exposing the deployment through a service?
*   Look into AWS Load Balancer controller?
*   ALB ingress controllers?
*   Setting up CloudWatch logs in order to obtain application logs?

I’m currently on a journey to learn more about the ever-growing ecosystem of containers, container orchestration and the DevOps culture. Expect to see more articles and open-source contributions. Stay tuned for more !

A hands-on article on deploying an application on Kubernetes with Fargate.

Posts tagged with: aws