So far, we have seen AWS certifications for general knowledge: Cloud Practitioner (fundamentals), Solutions Architect (design), and DevOps Engineer (automation and operations). But AWS is huge, and there are areas so deep that they deserve their own specialized certification. These are the Specialty certifications: credentials that demonstrate deep expertise in a specific area of AWS. In this subchapter, we’ll see what they are, what areas they cover, and when it makes sense to pursue them.
The problem: AWS is too broad to know everything in depth
AWS has hundreds of services and covers very different fields: advanced networking, security, machine learning, big data, databases... No one can be a deep expert in everything. General certifications (like Solutions Architect) cover a lot, but in breadth, not in the maximum depth of each area. To prove that you are a specialized expert in a specific field, there are the Specialty certifications.
General certifications (SA, DevOps): BREADTH (know a lot about everything) Specialty certifications: DEPTH (expert in one area)
What are the Specialty certifications
Specialty certifications are AWS credentials that validate deep and specialized knowledge in a specific technical area. They are designed for professionals who have specialized in a field and want to demonstrate that expert mastery. They are usually demanding, because they go much deeper into their topic than the general certifications.
A Specialty certification says: "I don’t just know AWS in general; I am an EXPERT in [networking / security / ML / ...]"
Analogy: general certifications are like being a general practitioner (knows a bit of everything, handles many things), and Specialty certifications are like being a medical specialist (cardiologist, neurologist...): someone who has delved deeply into a specific area and is the expert reference in it. Both are valuable; the specialist is who you go to for deep problems in their field. In AWS, Specialty certifications accredit you as that specialist.
The areas of specialization
AWS offers Specialty certifications in several highly in-depth technical areas. The main ones include:
Specialty Areas (examples): 🌐 Advanced Networking → advanced and complex networking in AWS 🔒 Security → in-depth security (connects with Ch. 23) 🤖 Machine Learning → artificial intelligence and ML in AWS 📊 Data / Analytics → big data and analytics (connects with Ch. 29) ... (the offering evolves over time)
Each one corresponds to a field where specialization brings enormous value and where general knowledge is not enough. For example:
- The Security certification goes much deeper into everything we saw in Chapter 23 (and more): it’s for those dedicated to cloud security.
- The Advanced Networking certification goes far beyond basic networking (Chapter 6): for specialists in complex connectivity.
- The Machine Learning or Data certifications are for those dedicated to AI or data platforms (Chapter 29).
⚠️ The specific offering of Specialty certifications changes over time (AWS adds, removes, or renames certifications as technology evolves). The important thing is the concept: there are specialized certifications to accredit expert mastery in specific areas. Check the official AWS website for the current list.
When to pursue a Specialty?
Specialty certifications are not the first step nor for everyone. They make sense when:
- You have specialized (or want to specialize) in a specific area (security, networking, data, ML...).
- Your job focuses on that field and you want to prove your expert mastery.
- You already have a solid foundation (ideally, experience and perhaps an Associate or Professional certification) and want to go deeper in your specialty.
Typical path:
Fundamentals (Cloud Practitioner)
→ general certification (Associate / Professional)
→ experience and specialization in an area
→ SPECIALTY certification in that area (expert)💡 Don’t rush into Specialty certifications. First master the fundamentals and get a general certification; Specialty certifications come when you’ve already oriented yourself toward a specific field and want to be an expert reference in it. They are the cherry on top of a specialized profile, not the starting point.
The value of specializing
In a market where many people have general knowledge, specializing sets you apart. A certified expert in a high-demand area (like security or machine learning) is a highly sought-after and valued profile. Specialty certifications accredit that specialization and can open doors to very specific and well-paid roles.
Real-world example: an engineer has spent several years working in cloud security. She already has the Solutions Architect Associate and a lot of practical experience protecting AWS environments (IAM, encryption, threat detection... everything from Chapter 23 and more). She wants to position herself as a security specialist and stand out. She earns the Security Specialty certification, which goes extremely deep into her field. With that credential, her profile becomes that of a certified expert in AWS security, a highly demanded and scarce role. She goes on to lead her company’s cloud security and becomes a reference. Specialization, backed by the Specialty, positioned her as an expert where before she was “just another one.” For her, that was the certification that made her a specialist.
What you should remember
- AWS is so broad that no one is a deep expert in everything; general certifications cover breadth, and Specialty certifications cover depth in an area.
- Specialty certifications validate deep and specialized knowledge in a specific technical area (advanced networking, security, machine learning, data...). They are demanding. Like being a medical specialist versus a general practitioner.
- Each area connects with topics from the book taken to their maximum depth: Security (Ch. 23), Data (Ch. 29), Networking (Ch. 6)... ⚠️ The specific offering changes over time; check the official AWS website.
- They are not the first step: they make sense when you have specialized in a field, your job focuses on it, and you already have a solid foundation. 💡 First fundamentals and a general certification; Specialty certifications are the cherry on top of a specialized profile.
- Specializing sets you apart: a certified expert in a high-demand area is a highly sought-after and valued profile.
In the last subchapter of this chapter, we’ll look at a key certification for the central topic of this book, but which is not from AWS but from HashiCorp: the Terraform Associate.
Cloud, AWS & Terraform — From Zero to Expert
Chapter 1 · What is cloud computing
- 1.1 The traditional client-server model
- 1.2 Problems the cloud came to solve
- 1.3 On-premise vs cloud vs hybrid
- 1.4 The three service models: IaaS, PaaS, SaaS
- 1.5 The five pillars of cloud (according to NIST)
- 1.6 Real advantages: elasticity, pay-as-you-go, global availability
Chapter 2 · The cloud market and major providers
- 2.1 AWS, Azure and GCP: differences and market share
- 2.2 Why learn AWS first
- 2.3 Concepts that are universal among providers
Chapter 3 · Regions, availability zones and edge
- 3.1 What is an AWS region and how to choose it
- 3.2 Availability Zones: high availability by design
- 3.3 Edge locations and CloudFront
- 3.4 Latency, resilience and data sovereignty
Chapter 4 · Compute: EC2
- 4.1 Instances: types, families and when to choose each
- 4.2 AMIs, key pairs and Security Groups
- 4.3 Instance lifecycle
- 4.4 Elastic IPs and Placement Groups
- 4.5 Savings Plans vs Reserved vs On-Demand vs Spot
Chapter 5 · Storage: S3
- 5.1 Buckets, objects and keys
- 5.2 Storage classes (Standard, IA, Glacier…)
- 5.3 Versioning and object lifecycle
- 5.4 Bucket policies and ACLs
- 5.5 Static website hosting
Chapter 6 · Networking: VPC
- 6.1 What is a VPC and why you need it
- 6.2 Public and private subnets
- 6.3 Internet Gateway and NAT Gateway
- 6.4 Route Tables and Network ACLs
- 6.5 VPC Peering and endpoints
Chapter 7 · Identity and access: IAM
- 7.1 Users, groups, roles and policies
- 7.2 The principle of least privilege
- 7.3 Identity-based vs resource-based policies
- 7.4 MFA and temporary credentials (STS)
- 7.5 IAM security best practices
Chapter 8 · Managed databases
- 8.1 RDS: engines, Multi-AZ and read replicas
- 8.2 Aurora and its advantages over vanilla RDS
- 8.3 DynamoDB: key-value / document model
- 8.4 ElastiCache for in-memory cache
- 8.5 When to use each type of database
Chapter 9 · Why Infrastructure as Code
- 9.1 Problems with manual provisioning
- 9.2 Declarative vs imperative IaC
- 9.3 Terraform vs CloudFormation vs Pulumi vs CDK
- 9.4 The plan → apply → destroy cycle
Chapter 10 · HCL: the Terraform language
- 10.1 Resource, variable, output, locals blocks
- 10.2 Data types: string, number, bool, list, map, object
- 10.3 Expressions, references and built-in functions
- 10.4 Conditionals and loops (count, for_each, for)
Chapter 11 · Providers and state
- 11.1 How the AWS provider works
- 11.2 The terraform.tfstate file and its importance
- 11.3 Local state vs remote state (S3 + DynamoDB)
- 11.4 Essential commands: init, plan, apply, destroy, fmt, validate
Chapter 12 · Your first real infrastructure in Terraform
- 12.1 Create a VPC with subnets from scratch
- 12.2 Launch a public EC2 instance
- 12.3 Associate a Security Group and an Elastic IP
- 12.4 Outputs and references between resources
- 12.5 Team workflow: PR review of plans
Chapter 13 · Load balancing and auto scaling
- 13.1 Application Load Balancer vs Network Load Balancer
- 13.2 Target Groups, listeners and rules
- 13.3 Auto Scaling Groups: policies and metrics
- 13.4 Warm pools and lifecycle hooks
Chapter 14 · Serverless with Lambda
- 14.1 The Lambda execution model
- 14.2 Triggers: API Gateway, S3, DynamoDB Streams, SQS
- 14.3 Dependency management and layers
- 14.4 Cold starts and strategies to reduce them
- 14.5 Limits and anti-patterns
Chapter 15 · Messaging and events
- 15.1 SQS: standard vs FIFO queues, DLQ
- 15.2 SNS: topics, subscriptions, fan-out
- 15.3 EventBridge: event buses and rules
- 15.4 Patterns: pub/sub, decoupling, saga
Chapter 16 · Content delivery and DNS
- 16.1 Route 53: record types and routing policies
- 16.2 CloudFront: distributions, caches and origins
- 16.3 ACM: free SSL/TLS certificates
- 16.4 WAF integrated with CloudFront
Chapter 17 · Containers on AWS
- 17.1 Docker: quick review of key concepts
- 17.2 ECR: private image registry
- 17.3 ECS: task definitions, services, Fargate vs EC2
- 17.4 EKS: when Kubernetes and when not
Chapter 18 · Modules: reuse and composition
- 18.1 Anatomy of a Terraform module
- 18.2 Input variables, outputs and dependencies
- 18.3 Local modules vs Terraform Registry modules
- 18.4 Module versioning with Git tags
- 18.5 Design of generic vs domain-specific modules
Chapter 19 · Workspaces and environment management
- 19.1 Terraform workspaces: use cases and limitations
- 19.2 Directory strategy per environment (dev/stg/prod)
- 19.3 Terragrunt: DRY for environment configurations
- 19.4 Environment variables and .tfvars files
Chapter 20 · Remote backends and locking
- 20.1 Configure S3 + DynamoDB as backend
- 20.2 State locking: avoiding team corruption
- 20.3 State migration between backends
- 20.4 terraform import: bring existing resources into state
Chapter 21 · Infrastructure testing
- 21.1 Terraform validate and fmt in CI
- 21.2 Checkov and tfsec: static security analysis
- 21.3 Terratest: integration tests in Go
- 21.4 Contract testing between modules
Chapter 22 · Terraform in CI/CD
- 22.1 Basic pipeline: lint → plan → apply in GitHub Actions
- 22.2 Atlantis: GitOps for Terraform
- 22.3 Terraform Cloud / HCP Terraform
- 22.4 Drift detection and automatic reconciliation
Chapter 23 · Defense in depth
- 23.1 AWS Organizations and Service Control Policies
- 23.2 AWS Config: continuous compliance
- 23.3 GuardDuty: threat detection
- 23.4 Security Hub: centralized view
- 23.5 KMS: key management and rotation
- 23.6 Secrets Manager vs Parameter Store
Chapter 24 · Observability: logs, metrics and traces
- 24.1 CloudWatch Logs, metrics and alarms
- 24.2 CloudWatch Dashboards and Contributor Insights
- 24.3 X-Ray: distributed tracing
- 24.4 OpenTelemetry on AWS
- 24.5 Managed Grafana and Managed Prometheus
Chapter 25 · Cost optimization
- 25.1 AWS Cost Explorer and budgets with alerts
- 25.2 Trusted Advisor and Compute Optimizer
- 25.3 Rightsizing: how to detect overprovisioning
- 25.4 Savings Plans vs Reserved Instances: strategic decision
- 25.5 FinOps: culture and processes to control spending
Chapter 26 · High availability and disaster recovery
- 26.1 RTO and RPO: defining objectives
- 26.2 Strategies: backup/restore, pilot light, warm standby, multi-site
- 26.3 Route 53 health checks and automatic failover
- 26.4 AWS Backup: centralized backup policy
Chapter 27 · AWS Well-Architected Framework
- 27.1 The six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, sustainability
- 27.2 Well-Architected Tool: formal reviews
- 27.3 How to apply the framework in design decisions
Chapter 28 · Serverless architectures at scale
- 28.1 Event-driven architecture with Lambda + EventBridge
- 28.2 Saga pattern for distributed transactions
- 28.3 Step Functions: orchestration of complex workflows
- 28.4 Lambda@Edge and CloudFront Functions
Chapter 29 · Data platforms on AWS
- 29.1 Data Lake with S3, Glue and Athena
- 29.2 Kinesis Data Streams and Firehose for streaming
- 29.3 Redshift: data warehousing at scale
- 29.4 Lake Formation: data governance
Chapter 30 · Multi-account and landing zones
- 30.1 Why separate workloads into different accounts
- 30.2 AWS Control Tower and Account Factory
- 30.3 Centralized log and security management
- 30.4 Terraform at multi-account scale with shared modules
Chapter 31 · Platform Engineering and Internal Developer Platform
- 31.1 Golden paths and abstractions over Terraform
- 31.2 AWS Service Catalog
- 31.3 Backstage as a developer portal
- 31.4 Terraform modules as internal product
Chapter 32 · Relevant AWS certifications
- 32.1 Cloud Practitioner: is it worth it?
- 32.2 Solutions Architect Associate → Professional
- 32.3 DevOps Engineer Professional
- 32.4 Specialty: Security, Database, Networking
- 32.5 HashiCorp Terraform Associate
Chapter 33 · Projects to consolidate what you've learned
- 33.1 Project 1: serverless blog (S3 + CloudFront + Lambda + DynamoDB)
- 33.2 Project 2: REST API with ECS Fargate + RDS + ALB
- 33.3 Project 3: data platform with Glue + Athena + Redshift
- 33.4 Project 4: multi-account landing zone with Terraform and Control Tower
