Network Encryption — TLS, ACM, IPsec, and MACsec

Why Network Encryption Matters for ANS-C01

Encryption in transit is the foundation of confidentiality on AWS. Domain 4 task 4.3 of the ANS-C01 exam — "Implement and maintain confidentiality of data and communications of the network" — tests every encryption mechanism that AWS exposes: TLS at the edge, IPsec for VPN, MACsec for Direct Connect, DNSSEC for DNS resolution, ACM for public certificates, and ACM Private CA for internal certificates. Roughly 8 to 12 percent of ANS-C01 questions involve at least one of these mechanisms, and several questions in every exam combine multiple encryption layers (e.g., end-to-end TLS with mTLS at ALB plus MACsec on Direct Connect).

This study guide is a Specialty-depth walk through network encryption on AWS. We cover the TLS handshake and protocol versions, ACM-issued public certificates and ACM Private CA-issued private certificates, certificate deployment to ALB / NLB / CloudFront / API Gateway, the difference between TLS termination and TLS passthrough, IPsec parameters for AWS Site-to-Site VPN, MACsec configuration on Direct Connect dedicated connections (CAK/CKN, AES-256-GCM), DNSSEC zone signing on Route 53, certificate rotation strategies, mutual TLS (mTLS), and end-to-end encryption architectures.

By the end of this guide you should be able to design any encryption-in-transit architecture the exam asks for. We close with FAQ, scenario walkthroughs, and Mandarin trap callouts.

TLS Fundamentals: Handshake, Cipher Suites, and Versions

TLS (Transport Layer Security) is the cryptographic protocol that secures HTTP, AMQP, MQTT, and many other application protocols on top of TCP. AWS supports TLS 1.0, 1.1, 1.2, and 1.3 across services, but for compliance workloads (HIPAA, PCI DSS, FedRAMP) only TLS 1.2 and TLS 1.3 are acceptable.

The TLS handshake (high level)

A TLS handshake involves these steps (TLS 1.2):

1. ClientHello: client sends supported cipher suites, TLS versions, and Server Name Indication (SNI).
2. ServerHello: server selects cipher suite and TLS version, sends server certificate.
3. Certificate validation: client validates server certificate against trusted CA chain.
4. Key exchange: client and server agree on session keys (RSA, ECDHE, or DHE).
5. Finished: both sides confirm with HMAC of the handshake; encrypted application data begins.

TLS 1.3 simplifies this to a single round trip and removes legacy cipher suites (RSA key exchange, RC4, SHA-1, MD5). TLS 1.3 is significantly faster and more secure.

Server Name Indication (SNI)

SNI is a TLS extension in the ClientHello that indicates which hostname the client is trying to reach. SNI lets a single TLS endpoint serve multiple certificates for different hostnames on the same IP. CloudFront, ALB, and API Gateway all support SNI for multi-tenant TLS.

A subtle and exam-relevant detail: SNI is sent in plaintext during the ClientHello, before TLS encryption begins. This is why AWS Network Firewall and Route 53 Resolver DNS Firewall can read SNI for filtering even without TLS inspection.

Security policies on AWS

CloudFront and ALB use named "security policies" that bundle a TLS protocol version with an allowed cipher suite list. Common policies:

• ELBSecurityPolicy-TLS13-1-2-2021-06: TLS 1.2 + 1.3, modern ciphers.
• ELBSecurityPolicy-FS-1-2-Res-2020-10: TLS 1.2, forward-secrecy ciphers only.
• TLSv1.2_2021 (CloudFront): TLS 1.2 minimum, FS-only.

For ANS-C01 compliance answers, prefer security policies that mandate TLS 1.2 or 1.3 with forward secrecy. Older policies that allow TLS 1.0/1.1 are non-compliant.

AWS Certificate Manager (ACM)

ACM is the managed certificate service that issues, deploys, and rotates public TLS certificates for AWS services. ACM-issued public certificates are free, validated by DNS or email, automatically renewed 60 days before expiry, and integrated with ALB, NLB, CloudFront, API Gateway, and other services.

DNS validation vs email validation

DNS validation is the modern best practice — ACM creates a CNAME record at your DNS provider, the record proves you own the domain, and renewals happen automatically as long as the CNAME stays in place. Email validation requires manual confirmation each time and breaks if the domain owner email changes. For Route 53-hosted zones, ACM offers a one-click "Create record in Route 53" button that creates the validation CNAME automatically.

ACM region constraint for CloudFront

ACM certificates that you attach to a CloudFront distribution must be requested in us-east-1 (N. Virginia) regardless of where your origin lives. This is because CloudFront is a global service that uses us-east-1 as its control plane. Certificates in any other Region will not appear in the CloudFront console.

For all other AWS services (ALB, NLB, API Gateway, App Runner), the ACM certificate must be in the same Region as the resource. Cross-region certificate use is not supported.

ACM auto-renewal

ACM-issued public certificates are automatically renewed 60 days before expiry, provided the validation method (DNS CNAME or email) still works. ACM tries renewal multiple times in the 60-day window and emits CloudWatch Events on success or failure. EventBridge rules on ACM Certificate Approaching Expiration trigger alerting.

If DNS validation fails (e.g., the validation CNAME was deleted), ACM cannot renew. The certificate eventually expires and HTTPS breaks. Always set up alarms on the certificate expiration metric.

ACM imported certificates

You can import third-party certificates (from DigiCert, GoDaddy, Let's Encrypt) into ACM and deploy them to AWS services. Imported certificates do NOT auto-renew — you must manually re-import the new certificate before expiry. ACM emits CloudWatch metrics for imported certificate expiration so you can alarm on this.

ACM Private CA (Private Certificate Authority)

ACM Private CA is a managed Certificate Authority service for issuing private (internal) certificates. Use cases: internal microservices that need TLS but should not be trusted by the public internet, IoT device fleets with X.509 identity certificates, mTLS at ALB for B2B partners, internal corporate networks.

Root CA and subordinate CA

ACM Private CA supports a hierarchy: a root CA issues subordinate CAs, which issue end-entity certificates. The root CA is typically offline (used only to sign subordinates), while subordinates are online and issue working certificates. This is the standard PKI hierarchy and is what compliance auditors expect.

Pricing: each CA costs $400 per month while active. End-entity certificate issuance has per-certificate fees that decrease with volume. ACM Private CA is significantly more expensive than public ACM (which is free) — only use Private CA when you need actual private certificates.

Short-lived certificate patterns

ACM Private CA supports short-lived certificates (e.g., 24-hour TTL). Pair with a Lambda-based renewal automation that issues new certificates daily and pushes them to workloads via Systems Manager Parameter Store. This is the pattern for high-assurance environments where long-lived certs are a security risk.

Integration with ACM

You can issue ACM certificates backed by your Private CA. The certificate appears in ACM with the same lifecycle features (auto-renewal, deployment to ALB/CloudFront/etc.) but is signed by your private CA instead of Amazon's public CA. This is the cleanest way to deploy private certs to AWS services.

TLS Termination vs TLS Passthrough

A critical architectural choice: where does TLS terminate? AWS supports both termination and passthrough at different services:

• TLS termination at ALB: ALB decrypts TLS, performs Layer 7 inspection (host/path routing, WAF), and re-encrypts to backend (or sends plaintext on HTTP). The most common pattern.
• TLS passthrough at NLB: NLB does NOT decrypt TLS. The encrypted TCP stream passes through to the backend, which terminates TLS itself. Required when the backend needs to see the original TLS handshake (mTLS without ALB participation, custom TLS extensions).
• TLS termination at NLB: NLB CAN terminate TLS if you configure a TLS listener with an ACM cert. Used for HTTP/2 or other TCP-based TLS traffic where ALB's L7 features are not needed.
• TLS termination at CloudFront: CloudFront terminates TLS at the edge, then re-encrypts to origin. The CloudFront-to-origin connection uses a separate cert (the origin's cert).

End-to-end encryption design

For end-to-end encryption from client to backend, you can use:

• CloudFront → ALB → backend: TLS terminates at CloudFront (with viewer cert), re-encrypts to ALB (with origin cert), terminates at ALB, re-encrypts to backend EC2/ECS (with target cert). Three TLS hops.
• CloudFront → NLB → backend (passthrough): TLS terminates at CloudFront, re-encrypts to NLB (origin cert), passes through to backend, terminates at backend. Useful when backend needs the original headers.
• CloudFront → ALB → backend with mTLS: same as first pattern, but ALB authenticates client certificates.

For "the backend MUST see the original client certificate," the answer is NLB TLS passthrough. ALB mTLS authenticates the client at ALB and forwards X-Amzn-Mtls-Clientcert header to the backend, but the backend does not see the actual TLS handshake.

IPsec for AWS Site-to-Site VPN

AWS Site-to-Site VPN uses IPsec to encrypt traffic between an on-premises customer gateway and an AWS Virtual Private Gateway (VGW) or Transit Gateway (TGW). Each VPN connection has two tunnels for redundancy, each terminating on a different AWS-side IP.

IPsec parameters

AWS Site-to-Site VPN supports IKEv1 and IKEv2 for tunnel negotiation. Default phase 1 (IKE) and phase 2 (IPsec) parameters:

• IKE encryption: AES-128, AES-256
• IKE hash: SHA-1, SHA-256
• IKE Diffie-Hellman: groups 2, 14, 22, 23, 24
• IPsec encryption: AES-128, AES-256
• IPsec hash: SHA-1, SHA-256
• IPsec PFS group: 2, 5, 14-24
• Tunnel mode: tunnel (not transport)
• Authentication: PSK (default) or certificate (since 2018)

For ANS-C01, memorize that AWS supports IKEv2 + AES-256 + SHA-256 + DH group 14+ as the modern compliant baseline. Default tunnel uses PSK authentication; certificate-based authentication uses ACM Private CA.

Dead Peer Detection (DPD)

DPD is the IPsec mechanism for detecting tunnel failure. AWS uses DPD with a default timeout that determines how quickly the tunnel is marked down and traffic fails over. The DPD interval is configurable per tunnel, with shorter intervals giving faster failover but more keepalive overhead.

Accelerated VPN

Accelerated VPN routes traffic through AWS Global Accelerator's anycast network before the IPsec tunnel terminates at the VGW/TGW. This reduces latency for geographically distant sites by entering the AWS backbone at the nearest Global Accelerator edge. Accelerated VPN requires TGW (not VGW) and dynamic routing (BGP).

MACsec on Direct Connect

MACsec (Media Access Control Security, IEEE 802.1AE) is Layer 2 encryption that protects traffic between your on-premises router and the AWS Direct Connect router. It uses AES-256-GCM and is hardware-accelerated, providing line-rate encryption with sub-millisecond latency overhead.

When MACsec is required

MACsec is the answer when compliance mandates encryption on the physical link between on-premises and AWS, e.g., for government, financial services, and defense workloads. IPsec over Direct Connect (Public VIF) provides the same confidentiality at L3, but MACsec is L2 and protects against physical tap attacks on the leased line itself.

MACsec hardware requirements

MACsec on Direct Connect has strict prerequisites:

• Dedicated Direct Connect connection: 10 Gbps or 100 Gbps. MACsec is NOT supported on hosted connections or on 1 Gbps or below.
• MACsec-capable router on your side: supports IEEE 802.1AE with AES-256-GCM.
• MACsec-capable port on AWS side: select MACsec-capable when ordering the connection (not all locations support it).

CAK and CKN: the MACsec keys

MACsec uses a Connectivity Association Key (CAK) and a Connectivity-association Key Name (CKN) for mutual authentication and key derivation. CAK is the secret key (32-byte hex); CKN is the key identifier (16-byte hex name).

You generate CAK and CKN out of band, configure both ends with the same values, and AWS Direct Connect uses them to establish the MACsec session. Key rotation requires coordinated reconfiguration on both sides — a maintenance window is mandatory.

For higher-security deployments, use AWS KMS to generate the CAK so that AWS managed keys back the MACsec association. This is more operationally complex but auditable.

DNSSEC for Route 53

DNSSEC (Domain Name System Security Extensions) protects DNS responses against spoofing and cache poisoning by signing zone data with cryptographic keys. Route 53 supports DNSSEC for public hosted zones.

How Route 53 DNSSEC works

When you enable DNSSEC on a Route 53 public hosted zone, Route 53:

1. Generates a Key-Signing Key (KSK) using AWS KMS asymmetric key (ECC_NIST_P256, SIGN_VERIFY usage).
2. Generates a Zone-Signing Key (ZSK) internally.
3. Signs all zone records with the ZSK.
4. Signs the ZSK with the KSK (creating the DNSKEY record set signature).
5. Publishes a DS (Delegation Signer) record at the parent zone (typically the registry).

DNS resolvers that support DNSSEC validation follow the DS chain from the root zone down, verifying each signature. If any signature fails, the resolver returns SERVFAIL, protecting clients from spoofed responses.

DS record publication

For domains registered with Route 53 Domains, the DS record is published automatically at the registry. For externally registered domains, you must manually publish the DS record at your registrar. Failure to publish the DS record means DNSSEC validation never starts — the zone is signed but resolvers do not validate.

DNSSEC in private hosted zones

DNSSEC is NOT supported in Route 53 private hosted zones. Private hosted zones are inherently trusted (only resolved within VPCs you control) and DNSSEC is unnecessary. The exam may test this distinction.

Mutual TLS (mTLS) at ALB

ALB has supported mTLS since 2023. mTLS authenticates the client to the ALB using an X.509 client certificate, in addition to the standard server-to-client TLS authentication.

mTLS modes on ALB

ALB offers two mTLS modes:

• Passthrough mode: ALB validates that the client presents a certificate but does not verify the certificate against a CA truststore. The certificate is forwarded to the backend in the X-Amzn-Mtls-Clientcert header. The backend application performs validation. Useful for backward-compatible migrations.
• Verify mode: ALB validates the client certificate against a configured truststore (a bundle of trusted CA certificates). Invalid certificates are rejected at ALB. The cert is still forwarded in the header for backend logging.

mTLS truststores are configured per ALB listener, with the bundle stored in S3. The truststore can be rotated by updating the S3 object and triggering ALB to refresh.

mTLS use cases

mTLS at ALB is the canonical edge security answer for:

• IoT device fleets that need device-bound TLS authentication.
• B2B partner APIs where partners hold issued client certificates.
• Internal service-to-service authentication in zero-trust architectures.

Pair with ACM Private CA to issue the client certificates and ALB truststore.

Certificate Rotation Strategies

Certificate rotation is operational hygiene that the exam tests indirectly through "what happens at expiry" scenarios.

Strategy 1: ACM auto-renewal (default)

For ACM-issued public certificates with DNS validation, AWS handles renewal automatically. Action required: monitor CloudWatch Events for ACM Certificate Approaching Expiration and alarm on renewal failures. Failure causes: the validation CNAME was deleted, or the domain ownership changed.

Strategy 2: Imported certificate manual rotation

For imported certificates, manual rotation requires:

1. Obtain the new certificate from your CA before old expires.
2. Import into ACM.
3. Update ALB / CloudFront listener to use the new certificate ARN.
4. Wait for CloudFront propagation (~15 minutes).
5. Delete the old certificate.

Lambda + EventBridge automation can streamline steps 2-5. The exam often tests "automate certificate rotation" — the answer is Lambda triggered by EventBridge.

Strategy 3: ACM Private CA short-lived certs

For internal services with short-lived certs (24-hour TTL), use SSM Run Command or Lambda to rotate certificates daily. Push new certs to workloads via Systems Manager Parameter Store. This is the high-assurance pattern.

End-to-End Encryption Architectures

Three reference architectures the ANS-C01 exam may ask about:

Architecture 1: Client to backend with full TLS

Client → CloudFront (TLS 1.3, ACM us-east-1)
       → ALB (TLS 1.2, ACM regional)
       → EC2 backend (TLS 1.2 with ACM regional or self-signed)

Three TLS terminations. Each hop re-encrypts. WAF can inspect at CloudFront (decrypted view). End-to-end confidentiality is maintained because no plaintext flows over network.

Architecture 2: NLB passthrough for client cert visibility

Client (with X.509 cert) → NLB TLS passthrough
                         → EC2 backend (terminates TLS, validates client cert)

NLB forwards encrypted bytes; backend sees the original handshake including the client's X.509 cert. No L7 inspection at NLB. Used when backend MUST see original cert (e.g., legacy app with hard-coded cert validation logic).

Architecture 3: Hybrid with VPN over Direct Connect

On-premises → IPsec tunnel over Public VIF → AWS endpoint
On-premises → Direct Connect with MACsec → AWS Direct Connect router

Two encryption layers: MACsec at L2 protects the physical link; IPsec at L3 protects the IP packets. Used when compliance requires defense in depth on the leased line.

Common Scenarios

Scenario A: HIPAA-compliant end-to-end encryption

Requirement: a healthcare SaaS in eu-west-1 must enforce TLS 1.2+ end-to-end from client to RDS database.

Architecture:

• CloudFront with TLSv1.2_2021 security policy, ACM cert in us-east-1.
• ALB in eu-west-1 with TLS 1.2 listener, ACM cert in eu-west-1.
• ALB-to-EC2 backend using HTTPS target group with self-signed or ACM Private CA cert.
• EC2 to RDS using SSL-enforced parameter group (rds.force_ssl=1) and RDS CA cert in client.
• DNSSEC on Route 53 hosted zone.

Trap variant: a question that proposes using NLB with HTTP target group (no encryption from NLB to backend) — wrong, breaks end-to-end TLS.

Scenario B: MACsec-required Direct Connect for federal compliance

Requirement: federal customer needs L2 encryption on Direct Connect for FedRAMP High.

Architecture:

• Order a dedicated 10 Gbps Direct Connect at a MACsec-capable location (US-East-1 IAD or US-West-1 PDX).
• MACsec-capable router on customer side configured with CAK/CKN.
• AWS configures the matching CAK/CKN on the AWS-side port.
• Verify MACsec association with show macsec on customer router.

Trap variant: hosted connection or 1 Gbps connection — wrong, MACsec requires dedicated 10/100 Gbps.

Common Exam Traps

Other anti-patterns:

• Using ACM-issued public certificates as a CA for AWS Network Firewall TLS inspection — ACM does not issue CA certs, you must import.
• Forgetting to publish the DS record at the registrar after enabling DNSSEC — zone is signed but no validation.
• Using TLS 1.0/1.1 in compliance contexts — pick TLS 1.2+ security policies.
• Believing IPsec at L3 covers the same threat model as MACsec at L2 — they protect against different attacks.
• Trying to use ACM imported certificates with auto-renewal — imported certs do NOT auto-renew.
• Putting an ALB mTLS truststore in any S3 bucket without proper ALB IAM permissions.
• Forgetting that NLB TLS termination uses regional ACM certs in the NLB's Region.
• Using accelerated VPN with VGW (only TGW supports it) or with static routing (BGP required).

Operational Considerations

Certificate inventory and expiry monitoring

Maintain a single dashboard of all certificates across:

• ACM-issued (auto-renewing)
• ACM-imported (manual renewal)
• Self-signed certs on EC2 instances
• ACM Private CA-issued certs
• Third-party certs deployed outside ACM

Use AWS Config rule acm-certificate-expiration-check to track expiry and CloudWatch alarms for proactive alerting.

Logging and auditing

CloudTrail logs ACM API calls (RequestCertificate, ImportCertificate, DeleteCertificate). VPC Flow Logs do NOT show TLS payload. To audit TLS handshakes, enable ALB access logs (which show TLS version and cipher) and CloudFront access logs.

Cost optimization

Public ACM certificates: free. ACM Private CA: $400/month per CA + per-cert fees. mTLS: no extra ALB charge but needs Private CA. MACsec: included in dedicated DX port pricing (no extra fee). IPsec on VPN: included in VPN pricing.

The cost driver is ACM Private CA. If you only need internal certs for a few apps, evaluate self-signed certs (operational overhead) vs Private CA (managed but $400/month).

FAQ

Q1: Can I use a single ACM cert for both an ALB in eu-west-1 and a CloudFront distribution?

No. CloudFront requires the cert in us-east-1; ALB requires the cert in the same Region as the ALB (eu-west-1 in this case). You need two separate certs — one in us-east-1 for CloudFront, one in eu-west-1 for the ALB. Both can have the same domain name; both auto-renew via DNS validation if the domain is consistent.

Q2: When should I use NLB TLS passthrough instead of ALB TLS termination?

NLB TLS passthrough is required when the backend application MUST see the original TLS handshake — for example, mTLS with backend-side client cert validation, or custom TLS extensions (SNI-based logic at backend). For all other cases, ALB TLS termination is preferred because it enables L7 features (host/path routing, WAF). NLB passthrough also gives you full IP transparency without proxy headers.

Q3: Is MACsec faster or slower than IPsec on Direct Connect?

MACsec is faster. MACsec is hardware-accelerated at the physical layer and adds sub-millisecond latency. IPsec runs in software on the AWS-side router (or in hardware on premium models) and adds a few milliseconds. For high-throughput, low-latency workloads (HFT, real-time analytics), MACsec is the right answer.

Q4: How do I rotate the MACsec CAK without downtime?

MACsec CAK rotation requires coordinated reconfiguration on both customer and AWS side. AWS supports configuring two CAK/CKN pairs on a connection, allowing a make-before-break rotation: configure new pair on both sides, verify the new association is active, then remove the old pair. This avoids dropping the link during rotation. Schedule a maintenance window because misconfiguration can take down the link.

Q5: Does DNSSEC affect DNS query latency?

Slightly. DNSSEC adds signature data to DNS responses, increasing payload size from ~64 bytes to several hundred bytes. Validation requires the resolver to follow the DS chain, which involves additional queries to validate signatures. In practice, the latency increase is single-digit milliseconds for cached queries and tens of milliseconds for fresh queries. For most workloads, DNSSEC's security benefit outweighs the latency cost.

Q6: Can I use ACM Private CA to sign a server certificate for use outside AWS?

Yes. ACM Private CA can issue end-entity certificates that you export and use on any server (on-premises, third-party cloud, IoT device). The cert export gives you the certificate plus the private key. Note that exported certs are not auto-renewed — you manage the lifecycle outside ACM.

Q7: What is the difference between ACM Private CA and AWS KMS for cryptographic operations?

ACM Private CA issues X.509 certificates for TLS authentication. AWS KMS provides cryptographic primitives (encrypt/decrypt, sign/verify) but does not issue certificates. KMS is used for envelope encryption of data, signing arbitrary blobs, and managing key material. Some integrations use both — ACM Private CA may use a KMS key for the underlying CA private key.

Q8: How does TLS 1.3 differ from TLS 1.2 for ANS-C01?

TLS 1.3 reduces the handshake from two round trips to one (faster), removes legacy cipher suites (more secure), and adds 0-RTT mode (resumed connections without round trip). TLS 1.3 is supported on all modern AWS endpoints (ALB, CloudFront, NLB TLS listener, API Gateway). For ANS-C01, prefer security policies that enable TLS 1.3 in addition to TLS 1.2.

Q9: Can AWS Network Firewall TLS inspection use an ACM-issued certificate?

No. ACM does not issue CA certificates. Network Firewall TLS inspection requires a CA cert that you import into ACM (typically generated by ACM Private CA or an external CA, then exported and imported into ACM). The certificate ARN is referenced in the TLS inspection configuration.

Q10: How do I enforce TLS at the RDS database layer?

Use RDS-provided certificates (via the AWS-issued root CA chain) and force SSL with parameter groups (rds.force_ssl=1 for PostgreSQL, require_secure_transport=ON for MySQL). Clients connect with the RDS root CA bundle and verify the server certificate. For higher assurance, use IAM database authentication or RDS Proxy with TLS-required mode.

Summary: Network Encryption Answer Patterns

When you read an ANS-C01 question on network encryption, run through this checklist:

• Is the question about CloudFront certificates? → ACM in us-east-1.
• Is the question about regional ALB / NLB / API Gateway certs? → ACM in the same Region.
• Is the question about L2 encryption on Direct Connect? → MACsec on dedicated 10/100 Gbps.
• Is the question about L3 encryption on a leased line? → IPsec over Public VIF.
• Is the question about end-to-end encryption client to backend? → CloudFront → ALB → backend, all TLS terminated.
• Is the question about backend visibility into original client cert? → NLB TLS passthrough.
• Is the question about DNSSEC validation? → KMS ECC_NIST_P256 in us-east-1, public hosted zone only.
• Is the question about internal cert management? → ACM Private CA.
• Is the question about mTLS at the load balancer? → ALB mTLS with truststore from Private CA.

Master the certificate region constraints, the MACsec hardware requirements, the DNSSEC KMS rules, and the TLS termination/passthrough patterns, and ANS-C01 task 4.3 questions become predictable.

常考陷阱

• CloudFront 的 ACM 憑證必須在 us-east-1 — 不管 origin 在哪。
• ACM 不簽 CA 憑證 — Network Firewall TLS inspection 要 import CA，不能 request。
• MACsec 只支援 dedicated 10/100 Gbps — hosted connection 跟 1 Gbps 都不行。
• MACsec 需要 MACsec-capable port + MACsec-capable router — 訂 connection 時要選對 location。
• DNSSEC KMS 必須 ECC_NIST_P256, customer-managed, us-east-1 — 對稱、AWS-managed、其他 region 都會失敗。
• DNSSEC 只支援 public hosted zone — private hosted zone 不支援。
• DS record 要在 registrar 公告 — 不公告就沒人驗證，等於沒簽。
• ACM 自動續期只對 ACM-issued 憑證 — imported 憑證不會自動續期。
• Accelerated VPN 必須用 TGW + BGP — VGW 不支援，靜態路由也不支援。
• ACM Private CA 一個月 $400 — 不要為了一個服務開一個 CA。
• ALB mTLS truststore 放在 S3 — 要設對 ALB IAM 權限才能讀。
• TLS 1.0/1.1 不符合 HIPAA/PCI — 用 TLSv1.2_2021 或更新的 security policy。