AWS / AMAZON WEB SERVICES
PROPELOO engineers AWS infrastructure — from VPC design and EKS/ECS workloads through RDS, Lambda, API Gateway, CloudFront and the Terraform that makes it reproducible. AWS has 200+ services. The skill is knowing which 15 to use for your specific requirements and how to connect them correctly.
AWS complexity is a real operational risk. Engineers who spin up infrastructure manually via the console — without Terraform, without proper VPC design, without IAM least-privilege — create systems that cannot be reproduced, cannot be audited and will fail in ways nobody expects. PROPELOO builds AWS infrastructure from first principles: everything in Terraform, private subnets for databases and internal services, IRSA for pod-level IAM, Secrets Manager for credentials, CloudTrail for API audit logging and multi-AZ for critical services. Not because it looks good on an architecture diagram — because it is the difference between infrastructure that survives its first incident and infrastructure that becomes the incident.
3-tier VPC design: public subnets for load balancers, private subnets for applications, isolated subnets for databases. Multi-AZ across 2-3 availability zones, VPC endpoints for S3/DynamoDB without NAT Gateway cost, PrivateLink for service-to-service.
EKS cluster in Terraform with managed node groups, Karpenter for cost-optimised node provisioning, IRSA for pod-level IAM, AWS Load Balancer Controller, External DNS and EFS CSI driver for stateful workloads.
Lambda functions with VPC access, Provisioned Concurrency for latency-sensitive functions, Lambda Layers for shared dependencies, Step Functions for orchestration, EventBridge for event-driven architectures.
Aurora PostgreSQL with read replicas, ElastiCache Redis cluster mode, DynamoDB with DAX caching, S3 with lifecycle policies and Intelligent-Tiering, Kinesis for real-time data streaming.
Least-privilege IAM policies per service, IRSA for Kubernetes pod IAM, AWS Organizations SCP for account-level controls, IAM Access Analyzer for policy validation, AWS Config rules for compliance.
Reserved Instance and Savings Plans strategy, Karpenter with Spot instances for non-critical workloads, S3 Intelligent-Tiering, right-sizing recommendations via AWS Compute Optimizer and monthly cost attribution by tag.
AWS is infrastructure-as-a-product. Every managed service you use is operational complexity you do not have to manage. Use managed services aggressively.
RDS is not just a PostgreSQL instance on EC2 — it is automated backups, multi-AZ failover, read replica management, minor version patching and parameter group management. ElastiCache is Redis without managing Redis cluster replication. Use managed services unless you have a specific reason not to: cost at scale, compliance requirements or capability gaps.
Axiom:
Infrastructure created manually in the AWS console cannot be reproduced, reviewed or audited. Terraform state represents the source of truth. Console access for exploration only. All resources created via terraform apply after pull request review.
Axiom:
Instance IAM roles give all pods on a node the same AWS permissions — a compromised pod gets access to everything the node can do. IRSA (IAM Roles for Service Accounts) gives each Kubernetes service account its own IAM role, scoped to exactly what it needs. This is the correct architecture for EKS.
Axiom:
A single-AZ RDS instance goes down for 20-30 minutes on instance failure. A Multi-AZ RDS fails over in 60-120 seconds. The cost difference is approximately 2x. For production workloads, Multi-AZ is a business continuity requirement, not an optional add-on.
Axiom:
Impact: ECS Fargate for most web applications. EKS when Kubernetes-specific tooling (Argo Rollouts, KEDA, Istio) is justified. Lambda for event processing, scheduled tasks and API endpoints with low invocation frequency.
Impact: RDS PostgreSQL for most applications. Aurora for write-heavy workloads or when you need Aurora-specific features (Global Database, Aurora Serverless). DynamoDB for truly unlimited scale with simple access patterns.
Impact: Single-region multi-AZ for most applications. Multi-region only when regulatory requirements mandate data residency in specific regions or when SLA requirements demand cross-region failover capability.
Impact: VPC endpoints for S3 and DynamoDB (free, eliminates NAT cost for those services). Interface endpoints for services with high traffic (SQS, Secrets Manager, ECR). NAT Gateway for remaining internet-bound traffic.
Impact: Secrets Manager for database credentials and API keys requiring automatic rotation. Parameter Store for configuration values that do not need rotation. Never plaintext in environment variable definitions.
Impact: CloudFront for static assets (S3 origin) is table stakes. CloudFront with ALB origin for cacheable API responses. Cloudflare over CloudFront when WAF quality and DDoS protection are priorities.
Complete AWS setup in Terraform: VPC, EKS/ECS, RDS, ElastiCache, CloudFront, Route53, ACM, IAM and CI/CD pipeline.
Event-driven Lambda architecture with API Gateway, SQS, EventBridge, Step Functions and DynamoDB — pay-per-use, zero idle cost.
Data warehouse on Redshift or Athena, ingestion via Kinesis/MSK, transformation with Glue, orchestration with MWAA (managed Airflow).
SaaS architecture with tenant isolation, per-tenant resource tagging, cost attribution and tenant-specific encryption keys via KMS.
Compute Optimizer analysis, Reserved Instance purchasing strategy, Karpenter Spot instance configuration — typically 25-40% cost reduction.
GuardDuty + Security Hub enablement, CloudTrail organisation trail, AWS Config rules, VPC Flow Logs and IAM Access Analyzer findings remediation.
Stack: Terraform (AWS provider), AWS CDK (TypeScript), Terragrunt (DRY Terraform), CloudFormation (legacy)
Stack: EKS (Kubernetes), ECS Fargate, Lambda, EC2 (Auto Scaling), Karpenter
Stack: Aurora PostgreSQL, RDS PostgreSQL, DynamoDB, ElastiCache Redis, S3, Kinesis
Stack: SQS, SNS, EventBridge, API Gateway, Step Functions, AppSync
Stack: IAM, Secrets Manager, KMS, GuardDuty, Security Hub, AWS Config
Stack: CloudWatch, X-Ray, CloudTrail, Datadog, Prometheus (ADOT)
Every service, Lambda function and CI/CD pipeline role has the minimum required permissions. No AdministratorAccess for application workloads. IAM Access Analyzer validates policies have no unintended public access.
Databases in isolated subnets (no route to internet). Applications in private subnets. Only load balancers in public subnets. Security groups restrict traffic to minimum required ports between specific security groups.
AWS Secrets Manager or Parameter Store SecureString for all credentials. Secrets injected at runtime via IRSA or task role. Secret scanning in CI/CD to catch accidental commits.
GuardDuty ML-based threat detection for AWS API calls, DNS queries and network traffic. Security Hub aggregates findings from GuardDuty, Inspector, Macie and Config into a single dashboard.
Organisation-level CloudTrail logs all API calls across all regions, stored in a centralised S3 bucket with S3 Object Lock (WORM) for tamper prevention. Required for regulatory audit.
Config rules check: no public S3 buckets, encryption at rest enabled for all data services, Multi-AZ enabled for RDS, EBS volumes encrypted, security groups not open to 0.0.0.0/0 on sensitive ports.
VPC topology, compute selection (EKS/ECS/Lambda), data services, security model and cost estimate.
AWS Organizations, Control Tower, account structure, CloudTrail org trail, Security Hub baseline.
VPC, subnets, security groups, NAT Gateway, VPC endpoints, Route53 hosted zones and ACM certificates.
EKS/ECS cluster, RDS, ElastiCache, S3 buckets, SQS queues and supporting services in Terraform.
GitHub Actions pipeline, ECR image repository, Terraform apply workflow and ArgoCD GitOps for EKS.
CloudWatch dashboards, Datadog integration, X-Ray tracing, alerting and runbook documentation.
GuardDuty, Security Hub, Config rules, IAM Access Analyzer review and penetration test preparation.
ECS Fargate for: simpler applications (1-10 services), teams without Kubernetes expertise, tight AWS integration (IAM task roles, CloudWatch logs without configuration). EKS for: applications needing Kubernetes-specific tooling (Argo Rollouts, KEDA, Istio), teams with existing K8s expertise, or systems where the broader K8s ecosystem provides real value. Fargate is not a stepping stone to EKS — it is a legitimate production choice.
Most immediate wins: Reserved Instances for predictable baseline compute (1-year No Upfront saves 30-40%), Savings Plans for Fargate and Lambda (covers across instance types), S3 Intelligent-Tiering for data accessed unpredictably, right-sizing with AWS Compute Optimizer recommendations, and Karpenter Spot instances for non-critical Kubernetes workloads. Typical outcome: 25-40% cost reduction on a mature AWS account.
AWS Organizations with multiple accounts: management account (billing only, no workloads), security account (CloudTrail logs, Security Hub aggregator), shared services account (internal tools, CI/CD), sandbox account (development experimentation), dev/staging/production accounts per environment. Account-level isolation is the strongest security boundary in AWS — a misconfiguration in one account cannot affect others.
IRSA (IAM Roles for Service Accounts) associates an IAM role with a Kubernetes service account, allowing pods to assume that role without any credentials in the container. Instance IAM roles (the alternative) give all pods on the same EC2 node the same permissions — a compromised pod gets everything the node can do. IRSA provides pod-level IAM isolation: each service has exactly the AWS permissions it needs and nothing more.