Encryption in Transit (TLS/SSL)
Key concepts
TLS for data in motion
HTTPS listeners on load balancers
SSL/TLS certificates from ACM
End-to-end encryption
Perfect Forward Secrecy
Overview
Encryption in transit protects data as it moves between systems, preventing eavesdropping, tampering, and man-in-the-middle attacks. AWS provides multiple mechanisms to encrypt data in transit, with TLS (Transport Layer Security) being the primary protocol.
Understanding encryption in transit is essential for the SAA-C03 exam because it's fundamental to securing communications between users, applications, and AWS services. You must know how to implement TLS using AWS Certificate Manager (ACM), configure secure endpoints, and understand the differences between public and private certificates.
Minimum TLS Requirements
AWS requires TLS 1.2 minimum and recommends TLS 1.3 for all communications. Cipher suites with Perfect Forward Secrecy (PFS) using ECDHE or DHE are strongly recommended.
Focus on ACM integration with AWS services, certificate validation methods, the difference between public and private certificates, and how to enforce encryption in transit using bucket policies and security parameters.
Key Concepts
TLS Protocol Overview

TLS Versions
TLS (Transport Layer Security) is the cryptographic protocol that encrypts data in transit. AWS has deprecated older versions due to security vulnerabilities.
TLS Version Status
| TLS Version | Status | AWS Recommendation |
|---|---|---|
| TLS 1.0 | Deprecated | Do not use |
| TLS 1.1 | Deprecated | Do not use |
| TLS 1.2 | Required minimum | Acceptable |
| TLS 1.3 | Latest | Recommended |
AWS Certificate Manager (ACM)
ACM simplifies the provisioning, management, and deployment of SSL/TLS certificates:
ACM Certificate Types
ACM offers public certificates (free, issued by Amazon Trust Services) and private certificates (paid, issued by AWS Private CA). Public certs auto-renew and work with ACM-integrated services. Private certs offer custom validity and can be used for internal resources.
Certificate Types:
├── Public Certificates (FREE)
│ ├── Issued by Amazon Trust Services
│ ├── Domain Validated (DV) only
│ ├── Auto-renewal every 13 months
│ └── Used with ACM-integrated services
│
└── Private Certificates (PAID)
├── Issued by AWS Private CA
├── Custom validity periods
├── Organization/Extended Validation possible
└── Used for internal resourcesACM Certificate Validation Methods
Validation Methods
| Method | How It Works | Best For |
|---|---|---|
| DNS Validation | Add CNAME record to DNS | Automated renewal, preferred |
| Email Validation | Respond to email sent to domain contacts | Legacy, manual process |
Record Name: _a1b2c3d4e5.example.com
Record Type: CNAME
Record Value: _x1y2z3.acm-validations.aws.
Note: This record validates domain ownership
Must remain in DNS for auto-renewalACM-Integrated Services
ACM certificates work automatically with these AWS services:

ACM-Integrated Services
| Service | Use Case | Notes |
|---|---|---|
| Elastic Load Balancing | ALB, NLB HTTPS listeners | SNI support |
| Amazon CloudFront | CDN HTTPS delivery | Global edge |
| Amazon API Gateway | REST/HTTP API endpoints | Custom domains |
| AWS App Runner | Container web apps | Automatic TLS |
| AWS Elastic Beanstalk | Application deployments | Via load balancer |
| Amazon CloudFormation | Infrastructure templates | Certificate resources |
ACM Export Limitation
ACM certificates CANNOT be exported or used on EC2 instances directly. For EC2, use imported certificates or AWS Private CA.
How It Works
Certificate Deployment Flow

1. REQUEST
└── User requests certificate for domain(s)
2. VALIDATE
└── DNS validation (add CNAME) OR Email validation
3. ISSUE
└── ACM issues certificate (13-month validity)
4. DEPLOY
└── Associate with ALB, CloudFront, API Gateway
5. RENEW
└── Automatic renewal 60 days before expiry
(requires DNS validation record to remain)TLS Termination Options

TLS Termination Points
| Termination Point | Traffic After | Security Level | Use Case |
|---|---|---|---|
| CloudFront | HTTP to origin | Medium | CDN with HTTP origin |
| ALB | HTTP to EC2 | Medium | Standard web apps |
| ALB | HTTPS to EC2 | High | End-to-end encryption |
| NLB | Pass-through | Highest | TLS on backend |
Server Name Indication (SNI)
SNI Multi-Certificate Support
SNI allows multiple TLS certificates on a single IP address, enabling a single ALB to host multiple domains with different certificates. This reduces infrastructure costs and simplifies management.
Single ALB with multiple certificates:
HTTPS:443 Listener
├── Rule 1: Host = app1.example.com → Target Group 1
│ Certificate: app1.example.com
│
├── Rule 2: Host = app2.example.com → Target Group 2
│ Certificate: app2.example.com
│
└── Default: → Target Group 3
Certificate: default.example.com
Benefits:
- Multiple domains on one load balancer
- Reduced infrastructure costs
- Simplified managementAWS Service Encryption in Transit
S3 Encryption in Transit
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSSLRequestsOnly",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}RDS Encryption in Transit
Enable require_ssl parameter:
MySQL/MariaDB: require_secure_transport = 1
PostgreSQL: rds.force_ssl = 1
SQL Server: rds.force_ssl = 1
Connect with SSL:
mysql -h mydb.xxx.rds.amazonaws.com \
--ssl-ca=rds-ca-2019-root.pem \
--ssl-mode=VERIFY_IDENTITY
Certificate bundles available at:
https://truststore.pki.rds.amazonaws.com/VPC Endpoint Encryption
VPC Endpoints
All VPC Interface Endpoints use TLS by default:
Interface Endpoint → AWS Service
↓
Always TLS 1.2+
No additional configuration needed
Traffic encrypted on AWS backboneUse Cases
Use Case 1: Public Website with HTTPS
Scenario: Deploy a public website with HTTPS using ALB and ACM.

Solution:
- Request public ACM certificate for domain
- Use DNS validation (add CNAME record)
- Create HTTPS listener on ALB
- Configure HTTP to HTTPS redirect
- Cost: FREE (ACM public certificates)
Use Case 2: End-to-End Encryption
Scenario: Financial application requires encryption from client to database.
Solution:
- ACM certificate on ALB (client to ALB)
- Self-signed or Private CA certificate on EC2 (ALB to EC2)
- RDS with
require_sslenabled (EC2 to database) - VPC endpoints for AWS services (all internal traffic encrypted)
Use Case 3: Internal Microservices with Private CA
Scenario: Microservices need mutual TLS (mTLS) for service-to-service communication.
Solution:
- Deploy AWS Private CA
- Issue private certificates to each service
- Configure mutual TLS authentication
- Automatic certificate rotation via ACM
Use Case 4: Multi-Domain Application
Scenario: Single ALB serving multiple domains with different certificates.
Solution:
- Request ACM certificates for each domain
- Configure ALB HTTPS listener with SNI
- Add host-based routing rules
- Each domain uses its own certificate
Best Practices
ACM Best Practices
-
Use DNS validation over email validation
- Enables automatic certificate renewal
- No manual intervention required
- Keep CNAME records in DNS permanently
-
Request certificates in the correct region
- CloudFront: us-east-1 only
- Regional services: Same region as service
-
Use wildcard certificates carefully
*.example.comcovers one level only- Doesn't cover
example.com(apex) - Consider security implications
-
Monitor certificate expiration
- Set CloudWatch alarms for ACM events
- Use AWS Config rule
acm-certificate-expiration-check
TLS Configuration Best Practices
-
Enforce minimum TLS 1.2
- Configure security policies on ALB/CloudFront
- Use
ELBSecurityPolicy-TLS-1-2-2017-01or newer
-
Use Perfect Forward Secrecy (PFS)
- ECDHE cipher suites preferred
- Protects past sessions if key compromised
-
Implement HTTPS redirects
- ALB listener rules can redirect HTTP to HTTPS
- CloudFront can enforce HTTPS-only
-
Enable HSTS (HTTP Strict Transport Security)
- Add header:
Strict-Transport-Security: max-age=31536000 - Prevents downgrade attacks
- Add header:
Private CA Best Practices
-
Use for internal resources only
- EC2 instances, containers, IoT devices
- Service-to-service communication
-
Implement certificate hierarchy
- Root CA → Intermediate CA → End-entity certificates
- Protect root CA offline when possible
-
Define validity periods appropriately
- Shorter periods = more security, more rotation
- Balance security with operational overhead
Common Exam Scenarios
Exam Scenarios
| Scenario | Solution | Why |
|---|---|---|
| Public HTTPS website | ACM public certificate + ALB | Free, automatic renewal |
| CloudFront custom domain | ACM certificate in us-east-1 | CloudFront requires us-east-1 |
| EC2 instance needs certificate | Import certificate or use Private CA | ACM cant export to EC2 |
| Enforce HTTPS for S3 | Bucket policy with aws:SecureTransport | Denies HTTP requests |
| RDS encryption in transit | Enable force_ssl parameter | Forces TLS connections |
| Multiple domains on one ALB | SNI with multiple ACM certificates | One listener, multiple certs |
| Internal microservices TLS | AWS Private CA | Private certificates for internal use |
| Certificate for apex + www | Request both names in one certificate | Single cert, multiple names |
Common Pitfalls
Pitfall 1: Wrong Region for CloudFront Certificate
Mistake: Requesting ACM certificate in regional region for CloudFront.
Why it fails: CloudFront only uses certificates from us-east-1
Correct Approach: Always request CloudFront certificates in us-east-1
Pitfall 2: Email Validation Blocking Auto-Renewal
Mistake: Using email validation for ACM certificates.
Why it fails: Auto-renewal requires DNS validation; email needs manual intervention
Correct Approach: Always use DNS validation for production certificates
Pitfall 3: Assuming ACM Works on EC2
Mistake: Trying to install ACM certificate on EC2 instance.
Why it fails: ACM certificates cannot be exported; only work with integrated services
Correct Approach: Use imported certificates or AWS Private CA for EC2
Pitfall 4: Wildcard Certificate Misconceptions
Mistake: Expecting *.example.com to cover example.com or sub.sub.example.com.
Why it fails: Wildcards only cover one level of subdomains
Correct Approach: Include apex domain explicitly; request separate certs for deeper subdomains
Pitfall 5: Forgetting HTTP to HTTPS Redirect
Mistake: Only configuring HTTPS listener, leaving HTTP open.
Why it fails: Users accessing via HTTP get connection refused or unencrypted access
Correct Approach: Configure HTTP listener with redirect action to HTTPS
Related Services
Quick Reference
ACM Certificate Limits
ACM Limits
| Resource | Default Limit |
|---|---|
| Certificates per region | 2,500 |
| Domain names per certificate | 10 |
| Certificates per ALB | 25 (via SNI) |
| Private CAs per account | 200 |
ALB Security Policies
ALB Security Policies
| Policy | Min TLS | Recommended For |
|---|---|---|
| ELBSecurityPolicy-TLS13-1-2-2021-06 | TLS 1.2 | Most secure, TLS 1.3 support |
| ELBSecurityPolicy-TLS-1-2-2017-01 | TLS 1.2 | Standard compliance |
| ELBSecurityPolicy-2016-08 | TLS 1.0 | Legacy compatibility only |
ACM Pricing
ACM Pricing
| Certificate Type | Cost |
|---|---|
| Public certificates | FREE |
| Private CA | $400/month per CA |
| Private certificates | $0.75 per certificate/month |
CLI Commands
# Request public certificate
aws acm request-certificate \
--domain-name example.com \
--subject-alternative-names www.example.com \
--validation-method DNS \
--region us-east-1
# List certificates
aws acm list-certificates --region us-east-1
# Describe certificate
aws acm describe-certificate \
--certificate-arn arn:aws:acm:us-east-1:123456789012:certificate/xxxTest Your Knowledge
A company needs an SSL certificate for their CloudFront distribution. In which region must the ACM certificate be requested?
Which ACM validation method enables automatic certificate renewal?
A company wants to use ACM certificates on EC2 instances running a web application. What is the correct approach?
An ALB needs to serve multiple domains with different SSL certificates. Which feature enables this?