DNS, Certificates & CDN

1. Amazon Route 53: DNS as a Managed Service

Route 53 is AWS's DNS service: it translates human-friendly domain names like bytecode-solutions.com into the IP addresses (or AWS resources) that actually serve traffic. Two concepts come up constantly:

• Hosted zones - a container for DNS records for a domain. Public hosted zones answer queries from the internet; private hosted zones answer queries only from within one or more VPCs.
• Record types - A/AAAA map a name to an IPv4/IPv6 address, CNAME maps a name to another name, and MX/TXT handle mail routing and verification/SPF records.

Beyond simple name-to-resource mapping, Route 53 supports routing policies that decide which answer to return when more than one target exists:

2. AWS Certificate Manager (ACM): Free, Renewing TLS

Every production site needs HTTPS, and HTTPS needs a TLS certificate signed by a trusted authority. ACM removes the operational pain of certificates entirely:

• Public certificates are free when attached to integrated AWS services such as CloudFront, Application Load Balancers, and API Gateway custom domains.
• Validation is DNS-based in almost every modern setup: ACM asks you to create a CNAME record proving you control the domain, which CDK can create automatically when the hosted zone lives in Route 53.
• Renewal is automatic for certificates that stay in use, eliminating the expired-certificate outages that plagued manually managed TLS.
• Wildcard and multi-domain (SAN) certificates let one certificate cover an entire family of subdomains, e.g. *.bytecode-solutions.com, so new subdomains never need a new certificate request.

3. Amazon CloudFront: Content Delivery at the Edge

CloudFront is AWS's content delivery network (CDN): a global mesh of edge locations that cache copies of your content close to your users. The first request for an asset is a cache miss and travels back to the origin; every subsequent request from nearby users is a cache hit served straight from the edge, often in single-digit milliseconds.

4. Reference Architecture: Static Site on S3 + CloudFront + Route 53

These three services combine into one of the most common patterns in AWS: serving a single-page application from a custom domain with HTTPS and global caching. This is the exact shape ByteCode uses to deploy its own React front ends: an S3 bucket holds the built assets, CloudFront caches and serves them over HTTPS using an ACM certificate, and a Route 53 alias record points the custom domain at the distribution.

Zooming into a single request shows how these pieces cooperate at runtime, from DNS resolution through the TLS handshake to the eventual cache hit or miss:

In CDK, the four pieces snap together in roughly this order: bucket, certificate, distribution, then DNS record. This is a trimmed version of the pattern used in ByteCode's own front-end stacks:

DOMAIN = "app.example.com"
ROOT_DOMAIN = "example.com"

# 1. S3 bucket configured for static website hosting
bucket = s3.Bucket(self, "WebsiteBucket",
    bucket_name="my-app-website",
    website_index_document="index.html",
    website_error_document="index.html",
    block_public_access=s3.BlockPublicAccess(
        block_public_policy=False,
        block_public_acls=False,
        ignore_public_acls=True,
        restrict_public_buckets=False,
    ),
)
bucket.grant_public_access()

# 2. ACM certificate - MUST live in us-east-1 for CloudFront to use it,
#    no matter which region the rest of the stack deploys to
certificate = acm.Certificate.from_certificate_arn(
    self, "SiteCertificate",
    certificate_arn=f"arn:aws:acm:us-east-1:{account_id}:certificate/{cert_id}",
)

# 3. CloudFront distribution: HTTPS only, custom domain, SPA error routing
distribution = cloudfront.Distribution(self, "SiteDistribution",
    default_root_object="index.html",
    default_behavior=cloudfront.BehaviorOptions(
        origin=origins.S3StaticWebsiteOrigin(bucket),
        viewer_protocol_policy=cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
    ),
    domain_names=[DOMAIN],
    certificate=certificate,
    error_responses=[
        cloudfront.ErrorResponse(http_status=403, response_http_status=200,
                                 response_page_path="/index.html", ttl=Duration.minutes(60)),
        cloudfront.ErrorResponse(http_status=404, response_http_status=200,
                                 response_page_path="/index.html", ttl=Duration.minutes(60)),
    ],
)

# 4. Route 53 alias record -> CloudFront (no CNAME, no extra DNS lookup cost)
hosted_zone = route53.HostedZone.from_lookup(self, "Zone", domain_name=ROOT_DOMAIN)

route53.ARecord(self, "SiteAliasRecord",
    zone=hosted_zone,
    record_name="app",
    target=route53.RecordTarget.from_alias(targets.CloudFrontTarget(distribution)),
)

Notice the S3StaticWebsiteOrigin (not the generic S3Origin): it targets the bucket's website endpoint, which is what makes directory paths resolve to index.html automatically. The error_responses list is what lets React Router own client-side navigation, and the alias record at the bottom is what makes the custom domain "just work" with zero extra DNS hops.

5. AWS WAF: Filtering Malicious Traffic at the Edge

AWS WAF is a web application firewall that inspects HTTP(S) requests against a Web ACL attached to CloudFront, an Application Load Balancer, API Gateway, or AppSync. Rules can be AWS Managed Rule Groups (covering SQL injection, known bad inputs, and bot control) or custom rules such as rate-based limits, geographic match conditions, and IP allow/deny lists.

6. AWS Shield: Always-On DDoS Protection

AWS Shield provides DDoS protection for internet-facing resources. Shield Standard runs automatically, at no charge, on every CloudFront distribution and Route 53 hosted zone, absorbing common network and transport-layer (layer 3/4) floods. Shield Advanced adds layer-7 detection, near-real-time attack visibility, and access to AWS's DDoS Response Team.

7. Amazon Cognito: Managed Identity and Authentication

Amazon Cognito covers two distinct jobs that are often confused because the console presents them side by side: User Pools handle authentication (who is this person?), and Identity Pools handle authorization to AWS services (what AWS resources can this person reach directly?). Each can be used independently, but they are frequently combined.

User Pools: Authentication and JWT Issuance

A User Pool is a managed user directory. It handles sign-up, sign-in, MFA, password policies, and token issuance. After a successful sign-in, Cognito returns three tokens:

• ID token - a JWT containing claims about the authenticated user (sub, email, custom attributes). This is what the app reads to know who is logged in, and what the HttpJwtAuthorizer on API Gateway validates.
• Access token - a JWT that authorizes calls to Cognito's own APIs (e.g. updating user attributes) and is checked by API Gateway when scope-based authorization is configured.
• Refresh token - a long-lived token (30 days by default) the app exchanges silently for a fresh ID and access token, keeping the session alive without re-prompting the user.

User Pools also support social and enterprise identity federation: users can sign in with Google, Apple, Facebook, or any SAML 2.0 or OIDC-compliant provider. Cognito acts as an OpenID Connect broker, normalizing the external identity into the same User Pool JWT your application already trusts. Pairing a User Pool with a Cognito (JWT) authorizer on API Gateway is the HttpJwtAuthorizer pattern this course builds in the API Gateway lesson, the Capstone's api_stack.py, and this very portal's own backend.

Identity Pools: Temporary AWS Credentials

An Identity Pool solves a different problem: it exchanges an identity token for short-lived AWS credentials so a client can call AWS services directly, without routing every request through a backend proxy. The pool accepts tokens from several sources:

• Cognito User Pool JWTs - the most common pairing
• Social provider tokens (Google, Apple, Facebook, Amazon) used without a User Pool
• Developer-authenticated identities - where your own backend asserts the user's identity to the pool
• Unauthenticated (guest) access - the pool assigns a restricted IAM role even to anonymous visitors

Under the hood, the Identity Pool calls STS AssumeRoleWithWebIdentity, passing the validated token and the ARN of a pre-configured IAM role. STS returns temporary credentials (an access key, secret key, and session token) that default to 1 hour and can be extended up to 12 hours via the IAM role's MaxSessionDuration setting. The client uses them to sign AWS API requests with SigV4. Separate IAM roles for authenticated and unauthenticated users control what each group can actually do.

Web Identity Federation

Web Identity Federation is the broader pattern that Identity Pools implement: a client presents a token from a trusted external identity provider (IdP), and AWS exchanges it for temporary IAM credentials via STS AssumeRoleWithWebIdentity. The trust relationship works as follows:

• An IAM role carries a trust policy permitting STS to assume it on behalf of a specific identity provider, with a condition matching the expected audience (your app's client ID).
• The client obtains a token from the IdP (Cognito User Pool, Google, Apple, etc.), sends it to STS via the Identity Pool, and receives back credentials scoped to that role's permission policy.
• The resulting credentials are short-lived and never stored as long-lived access keys on end-user devices - the key security advantage over distributing IAM credentials directly.

The sequence below shows the complete token exchange from a User Pool sign-in through to a direct S3 upload, the most common real-world application of Web Identity Federation:

The component view below shows how User Pools, Identity Pools, STS, and external identity providers fit together. A Cognito User Pool and a social IdP are both valid token sources for the same Identity Pool:

8. CloudFront Functions & Lambda@Edge: Running Your Own Code at the Edge

CloudFront Functions and Lambda@Edge let you run your own code at CloudFront's edge locations instead of, or before, reaching the origin. CloudFront Functions execute lightweight JavaScript: header rewrites, redirects, and simple authorization checks, in sub-millisecond time. Lambda@Edge runs full Lambda functions, with more languages, more memory, and longer execution windows, at regional edge caches for heavier transformations.

9. AWS Global Accelerator: Routing Non-Cacheable Traffic Globally

AWS Global Accelerator improves availability and performance for workloads that are not cacheable HTTP, by routing traffic over the AWS global network through two static anycast IP addresses, with automatic regional failover.

10. AWS Private CA: Issuing Internally Trusted Certificates

AWS Private CA is a managed private certificate authority for issuing certificates that should only ever be trusted inside your organization, the things ACM's free public certificates are not meant for: service-to-service mTLS, internal dashboards, and IoT device identities.

11. Putting It All Together: The Extended Reference Architecture

None of the six services above replace the Route 53 + ACM + CloudFront trio, they extend it: WAF and Shield add security at the perimeter, CloudFront Functions and Lambda@Edge run custom logic at the edge, Global Accelerator covers the non-cacheable traffic CloudFront was never built to serve, and Cognito and Private CA round out the identity and certificate needs that grow alongside a live site. The diagram below takes Figure 1's reference architecture and layers each of these services into the same scene, in the role it would actually play: