AWS - Balancing - CloudFront

Posted Jul 18, 2020

By Grace L

50 min read

CloudFront
enable CloudFront
CloudFront distributions
- cache control headers
- presigned URLs
Configuring Secure Access and Restricting Access to Content

CloudFront

cloudFront

a web service
- a fast CDN service
- securely delivers data, videos, applications, and application programming interfaces (APIs) to customers globally with low latency and high transfer speeds.
speeds the distribution of static and dynamic web content to users
- such as HTML; CSS; JavaScript; and image.
provide additional security (especially against DDos)
- Build in DDoS attack protection.
integrated with many AWS services
- such as S3, EC2, ELB, Route53, Lambda
- both physical locations that are directly connected to the AWS global infrastructure
- and software that works seamlessly with services including AWS shield for DDoS mitigation,
- S3, Elastic Load Balancing, or EC2 as origins for your applications,
- AWS Lambda to run custom code close to your viewer.
provides a developer-friendly environment.
different from traditional CDN
- quickly obtain the benefits of high-performance content delivery
- without negotiated contracts, high prices, or minimum fees.

edge locations

locations are designed to serve popular content quickly to viewers.
cache content at edge location (data centers) for fast distribution to customers.
When user requests content that serve with CloudFront,
- the user is routed to the edge location that provides the lowest latency (time delay)
- content is delivered with the best possible performance.
- If the content is already in the edge location with the lowest latency,
  - CloudFront delivers it immediately
- If the content is not currently in that edge location,
  - CloudFront retrieves it from an S3 bucket / HTTP web server for the definitive version of your content.
As objects become less popular
- individual edge locations might remove those objects to make room for more popular content.

Regional Edge caches

help reduce the load on your origin resources
- minimizes the operational burden
- minimizes the costs of scaling the origin resources.
Regional edge caches
- are turned on by default for your CloudFront distributions, and do not need to make any changes to your distributions to take advantage of this feature.
are CloudFront locations that deployed globally and close to viewers.
- located between the origin server and the global edge locations
- serve content directly to viewers.
Regional edge cache has larger cache than individual edge location
- so objects remain in the Regional edge cache longer.

Origin Access Identity (OAI)

A virtual identity
- created OAI and associate it with your distribution.
- configure permissions
- CloudFront use the OAI to access and serve files to your users
- but users can’t use a direct URL to the S3 bucket to access a file there.
restricting users to the CloudFront distribution,
- enhance S3 distribution performance and create a better user experience
- not used to configure private viewing within CloudFront
- is not associated with an on-premise server; rather tied to S3 service.
Prevent users from bypassing CloudFront security restrictions to access the S3 origin bucket
- OAIs are applied to a CloudFront distribution,
- this allows access to end-users while protecting the direct URL to the S3 bucket.
OAIs append code to a bucket policy
- allowing CloudFront users access to a particular bucket.
- restrict users to use a presigned URL instead of directly accessing the origin S3 bucket.
S3 hosted website
- The endpoint URL can be altered.
- Security errors in S3 may require the enabling of Cross-Origin Resource Sharing (CORS)
- security measure
- When needing object backups
- When needing a resilient object
- When needing performance replication
- allowing a web application running in one domain to reference resources in another.
- configuring S3 Cross-Region Replication (CRR)
- A replication rule is needed, to set the source, destination, and IAM role.
- Versioning needs to be enabled on both buckets (source and the destination)
- Buckets need to be in different regions
- Object ownership and its associated storage tiers can be altered when going to a new region.
- CloudFront can be used to speed up the S3 service.
- Server access logs can be enabled for buckets that host websites.
- Apache-like server access logs can be enabled.
- index.html file
- default documented loaded when a visiting a bucket’s URL endpoint.
domain name
- The domain name within CloudFront can be visited by HTTP and HTTPS.
- A domain name is used to view distributed content in a browser.
- The domain name is generated when a distribution is created.

benefits

Key features for CloudFront include:

TCP/IP optimizations for the network path.
Keep-alive connections to reduce round-trip time.
SSL/TLS termination that is close to viewers.
Latency-based routing.
And regional edge caches.

benefits

Fast and global
- CloudFront is massively scaled and globally distributed.
- To deliver content to end users with low latency, CloudFront uses a global network that consists of edge locations and regional caches
Security at the edge
- provides both network-level and application-level protection
- Your traffic and applications benefit through various built-in protections,
  - such as AWS Shield Standard with no additional cost.
- use configurable features
  - such as AWS Certificate Manager (ACM) to create and manage custom Secure Sockets Layer (SSL) certificates with no extra cost.
Highly programmable
- CloudFront features can be customized for specific application requirements.
- integrates with Lambda@Edge to run custom code across AWS locations worldwide to move complex application logic closer to users to improve responsiveness.
- The CDN also supports integrations with other tools and automation interfaces for DevOps. It offers continuous integration and continuous delivery (CI/CD) environments.
Deeply integrated with AWS
- integrated with AWS, with both physical locations that are directly connected to the AWS Global Infrastructure and other AWS services.
- use APIs or the AWS Management Console to programmatically configure all features in the CDN.
Cost-effective
- no minimum commitmente, charges only for what you use.
- Compared to self-hosting
  - avoids the expense and complexity of operating a network of cache servers in multiple sites across the internet.
  - eliminates the need to overprovision capacity to serve potential spikes in traffic.
- CloudFront also uses techniques like collapsing simultaneous viewer requests at an edge location for the same file into a single request to your origin server.
- The result is
  - reduced load on the origin servers and reduced need to scale the origin infrastructure
  - result in further cost savings.
  - If the AWS origins is such as S3 or Elastic Load Balancing, you pay only for storage costs, not for any data transferred between these services and CloudFront.

CloudFront charges are based on actual usage of the service in four areas:

Data transfer out
- charged for the volume of data that is transferred out from CloudFront edge locations, measured in GB, to the internet or to your origin (both AWS origins and other origin servers).
- Data transfer usage is totaled separately for specific geographic regions, and then cost is calculated based on pricing tiers for each area.
- If you use other AWS services as the origins of your files, you are charged separately for your use of those services, including storage and compute hours.
HTTP(S) requests
- charged for the number of HTTP(S) requests that are made to CloudFront for the content.
Invalidation requests
- charged per path in your invalidation request.
- A path that is listed in your invalidation request represents the URL (or multiple URLs if the path contains a wildcard character) of the object that you want to invalidate from CloudFront cache.
- can request up to 1,000 paths/month from CloudFront at no additional charge.
- Beyond the first 1,000 paths, charged per path that is listed in your invalidation requests.
Dedicated IP custom Secure Sockets Layer (SSL)
- pay $600 per month for each custom SSL certificate that is associated with one or more CloudFront distributions that use the Dedicated IP version of custom SSL certificate support.
- This monthly fee is prorated by the hour.
- For example,
- custom SSL certificate was associated with at least one CloudFront distribution for just 24 hours (that is, 1 day) in a month, total charge for using the custom SSL certificate feature:
- (1 day / 30 days) * $600 = $20

enable CloudFront

specify origin servers
- like an S3 bucket or your own HTTP server.
- when CloudFront gets your files from the origin servers
- the files will then be distributed from CloudFront edge locations worldwild.
upload files to origin servers
- Your files is objects
- typically include webpages, images, and media files.
create a CloudFront distribution
- which tells CloudFront which origin servers to get the files from
  - when users request the files through your website or application.
- At the same time, specify details, such as
  - whether you want CloudFront to log all requests,
  - whether you want the distribution to be enabled as soon as it’s created.
CloudFront assigns a domain name to your new distribution
- can see the domain name in the CloudFront console.
- The domain name can also be returned in the response to a programmatic request, like a request from an API.
CloudFront sends the distribution's configuration (not content) to all its edge locations
- collections of servers in geographically dispersed data centers where CloudFront caches copies of your objects.

CloudFront has several options for enablement.

use a separate Canonical Name Record / CNAME for static content,
- the static content is cached straight from the origin server.
- most efficient
- but takes more effort to set up and manage.
point the entire uniform resource locator / URL to CloudFront
- easier to manage.
- can use URL patterns to stage dynamic content.
- All of the content goes through edge locations.

CloudFront distributions

example
- Route 53 resolves example.com on behalf of the client.
- A request is made to the CloudFront distribution.
- CloudFront looks at the S3 bucket for the content that it identifies as being stored statically.
- For any content that has a time to live of zero,
  - CloudFront will go directly to the Elastic Load Balancing load balancer
  - to go back to the origin server to pull the content.
- In this way, CloudFront delivers both static and dynamic content.

2 distribution types

Web distribution
- lets access to web content in any combination of up to 10 S3 buckets or custom origin servers.
Real Time Messaging Protocol / RTMP distribution
- always an S3 bucket.

To configure a cloudfront distribution to access a S3 private bucket:

Add truested signers to you distribution
Creat cloudfront key pairs for your trusted signers
Write the code that generates signed uniform resource locators (URLs)

  
// creates a distribution for an S3 bucket named awsexamplebucket, and also specifies index.html as the default root object
aws cloudfront create-distribution \
    --origin-domain-name awsexamplebucket.s3.amazonaws.com \
    --default-root-object index.html

// Instead of using command line arguments, you can provide the distribution configuration in a JSON file
aws cloudfront create-distribution \
    --distribution-config file://dist-config.json

// The file dist-config.json:
{
    "CallerReference": "cli-example",
    "Aliases": { "Quantity": 0 },
    "DefaultRootObject": "index.html",
    "Origins": {
        "Quantity": 1,
        "Items": [
            {
                "Id": "awsexamplebucket.s3.amazonaws.com-cli-example",
                "DomainName": "awsexamplebucket.s3.amazonaws.com",
                "OriginPath": "",
                "CustomHeaders": { "Quantity": 0 },
                "S3OriginConfig": { "OriginAccessIdentity": "" }
            }
        ]
    },
    "OriginGroups": { "Quantity": 0 },
    "DefaultCacheBehavior": {
        "TargetOriginId": "awsexamplebucket.s3.amazonaws.com-cli-example",
        "ForwardedValues": {
            "QueryString": false,
            "Cookies": { "Forward": "none" },
            "Headers": { "Quantity": 0 },
            "QueryStringCacheKeys": { "Quantity": 0 }
        },
        "TrustedSigners": {
            "Enabled": false,
            "Quantity": 0
        },
        "ViewerProtocolPolicy": "allow-all",
        "MinTTL": 0,
        "AllowedMethods": {
            "Quantity": 2,
            "Items": [ "HEAD", "GET" ],
            "CachedMethods": {
                "Quantity": 2,
                "Items": [ "HEAD", "GET" ]
            }
        },
        "SmoothStreaming": false,
        "DefaultTTL": 86400,
        "MaxTTL": 31536000,
        "Compress": false,
        "LambdaFunctionAssociations": { "Quantity": 0 },
        "FieldLevelEncryptionId": ""
    },
    "CacheBehaviors": { "Quantity": 0 },
    "CustomErrorResponses": { "Quantity": 0 },
    "Comment": "",
    "Logging": {
        "Enabled": false,
        "IncludeCookies": false,
        "Bucket": "",
        "Prefix": ""
    },
    "PriceClass": "PriceClass_All",
    "Enabled": true,
    "ViewerCertificate": {
        "CloudFrontDefaultCertificate": true,
        "MinimumProtocolVersion": "TLSv1",
        "CertificateSource": "cloudfront"
    },
    "Restrictions": {
        "GeoRestriction": {
            "RestrictionType": "none",
            "Quantity": 0
        }
    },
    "WebACLId": "",
    "HttpVersion": "http2",
    "IsIPV6Enabled": true
}

cache control headers

CloudFront reads cache control headers
- to determine how frequently to check the origin server for an updated version of that file.
The cache control header set on your files
- identifies static and dynamic content.
- can even have custom headers within the CloudFront distribution graphical user interface / GUI within the console.
Delivering all your content by using a single CloudFront distribution helps to ensure performance optimization on your entire website.
expiration period
- How long is a file kept at the edge location
  - set the expiration period by the cache control headers on files in origin server.
  - set one. If your files don’t change very often,
  - set to 0 seconds, CloudFront will revalidate every request with the origin server.
- best practice：
  - set a long expiration period,
  - implement a versioning system to manage updates to your files.
By default, if no cache control header is set
- each edge location checks for an updated version of file
- when it receives a request more than 24 hours after the previous time

3 ways to set content to expire / retire cached content

Use time to live, TTL (preferred)
- easiest but not immediate.
- Fixed period of time
- set the TTL for a particular origin server to 0,
  - CloudFront will still cache the content from that origin server.
- CloudFront make a GET request to origin with an If-Modified-Since header.
  - This header allows the origin server to signal that CloudFront can continue to use the cached content if the content has not changed at the origin server.
Change the object name (preferred)
- more effort but immediate.
- No name force refresh
- There might be some support for this option in some content management systems, or CMSs.
- CloudFront distributes objects to edge locations
  - only when the objects are requested,
  - not when you put new or updated objects in your origin server.
- Although you can update existing objects in a CloudFront distribution and use the same object names, it is not recommended.
  - If update an existing object in the origin server with a newer version that has the same name
  - an edge location won’t get that new version from your origin server until the object is updated and requested.
Invalidating an object
- Inefficient and expensive
- should be used sparingly for individual objects.
- bad solution because the system must forcibly interact with all edge locations.

presigned URLs

owner can grant any user permissions to access an S3 object.
- presigned URLs don’t require users to have AWS security credentials or permissions.
- A temporary URL that allows users to see assigned S3 objects using the creator’s credentials.
- Presigned URLs utilize the STS service.
if get an error when access an S3 object.
- presigned URL has expired
- was created using an IAM role, and that role’s temporary credentials have expired.
- Permissions of the URL creator have changed

Configuring Secure Access and Restricting Access to Content

For web distributions, CloudFront provides several options for securing content that it delivers.
The following are some ways you can use CloudFront to secure and restrict access to content:
- Configure HTTPS connections
- Use geo restriction (geoblocking)
  - Prevent users in specific geographic locations from accessing content
- access content by CloudFront signed URLs or signed cookies
  - do not want access by direct URL for the file.
  - Instead, access the files only by using the CloudFront URL, so that your protections work.
- Set up field-level encryption for specific content fields
- Use AWS WAF to control access to the content
- create a web access control list (web ACL) to restrict access to your content.
  - such as the IP addresses that requests originate from or the values of query strings,
  - CloudFront responds to requests
    - with the requested content
    - or with an HTTP 403 status code (Forbidden).
- Restrict access to content in S3 buckets
  - If use an S3 bucket as the origin for a CloudFront distribution
  - set up an origin access identity (OAI) to manage direct access to your content.

CloudFront Custom SSL Support

By default, content is delivered to viewers over HTTPS by using a CloudFront distribution domain name. (https://xxx.cloudfront.net/image.jpg)
CloudFronthas support custom Secure Sockets Layer, SSL
- can create your own certificate that will have the CloudFront.net domain,
- or can bring your own certificate if you have a specific domain name that you want to use.
Server Name Indication (SNI) Custom SSL
- relies on the SNI extension of the Transport Layer Security protocol
- allows multiple domains to serve SSL traffic over the same IP address
- CloudFront delivers content from each edge location, offers the same security as the Dedicated IP Custom SSL feature.
- Some older browsers do not support SNI
  - some users might not be able to access your content by older browsers.
  - these browsers will not be able to establish a connection with CloudFrontto load the HTTPS version of your content.
- no separate pricing for this feature.
  - use SNI Custom SSL with no upfront or monthly fees for certificate management.
  - Instead, pay normal CloudFrontrates for data transfer and HTTPS requests.
Dedicated IP Custom SSL works for all clients
- to deliver content to browsers that don’t support SNI
- CloudFront allocates dedicated IP addresses to serve your SSL content at each CloudFront edge location.
- To learn more about Dedicated IP Custom SSL certificate support, select the link.https://aws.amazon.com/cloudfront/custom-ssl-domains/
- When we approve your request, you can upload an SSL certificate and use the AWS Management Console to associate it with your CloudFront distributions.
- If you need to associate more than one custom SSL certificate with your CloudFront distribution, include details about your use case and the number of custom SSL certificates that you intend to use in the “Use Case and # of SSL Certs You Intend to Use” section of the form.

Using HTTPS with CloudFront

For web distributions, can configure CloudFront to

require viewers use HTTPS to request the objects
- encrypt connections when CloudFront communicates with viewers.
configure CloudFront to use HTTPS to get objects from your origin,
- encrypt connections when CloudFront communicates with your origin.
configure CloudFront to require HTTPS to communicate with both viewers and origin
- when CloudFront receives a request for an object:
  1. A viewer submits an HTTPS request to CloudFront.
  - There’s some SSL/TLS negotiation between the viewer and CloudFront.
  - In the end, the viewer submits the request in an encrypted format.
    1. CloudFront check the request
  - If the object is in the CloudFront edge cache
    - CloudFront encrypts the response and returns it to the viewer, and the viewer decrypts it.
  - If the object is not in the CloudFront cache
    - CloudFront performs SSL/TLS negotiation with your origin
    - when the negotiation is complete, forwards the request to your origin in an encrypted format.
    - Your origin decrypts the request, encrypts the requested object, and returns the object to CloudFront.
    - CloudFront decrypts the response, re-encrypts it, and forwards the object to the viewer.
    - CloudFront also saves the object in the edge cache so that the object is available the next time it’s requested.
      1. The viewer decrypts the response.
      2. The process works similar whether the origin is an S3 bucket, MediaStore, or a custom origin such as an HTTP/S server.

Note To help thwart SSL renegotiation-type attacks, CloudFront does not support renegotiation for viewer and origin requests.

Requiring HTTPS for Communication Between Viewers and CloudFront

configure one or more cache behaviors in the CloudFront distribution
- to require HTTPS for communication between viewers and CloudFront.
- to allow both HTTP and HTTPS
  - so CloudFront requires HTTPS for some objects, but not for others
The configuration steps depend on the domain name using in object URLs
- using the domain name that CloudFront assigned to your distribution
  - like: d111111abcdef8.cloudfront.net
  - change the Viewer Protocol Policy setting for one or more cache behaviors to require HTTPS communication.
  - In that configuration, CloudFront provides the SSL/TLS certificate.
  - change the value of Viewer Protocol Policy
    - by using the CloudFront console
    - use the CloudFront API to change the value of the ViewerProtocolPolicy element
      - UpdateDistribution in the CloudFront API.
- using your own domain name
  - like: example.com
  - need to
    - change several CloudFront settings.
    - use an SSL/TLS certificate provided by AWS Certificate Manager (ACM), or import a certificate from a third-party certificate authority into ACM or the IAM certificate store.

to ensure the objects get from CloudFront were encrypted when CloudFront got them from the origin

always use HTTPS between CloudFront and your origin.

If recently changed from HTTP to HTTPS between CloudFront and the origin

recommend that invalidate objects in CloudFront edge locations.
CloudFront will return an object to a viewer regardless of whether the protocol used by the viewer (HTTP or HTTPS) matches the protocol that CloudFront used to get the object.

To configure CloudFront to require HTTPS between viewers and CloudFront for one or more cache behaviors

AWS Management Console > CloudFront console. https://console.aws.amazon.com/cloudfront/
CloudFront console > the ID for the distribution to update.
Behaviors tab > the cache behavior to update > choose Edit.
Specify one of the following values for Viewer Protocol Policy
- Redirect HTTP to HTTPS
  - Viewers can use both protocols.
  - HTTP GET and HEAD requests are automatically redirected to HTTPS requests.
  - CloudFront returns HTTP status code 301 (Moved Permanently) along with the new HTTPS URL.
  - The viewer then resubmits the request to CloudFront using the HTTPS URL.
    - If you send POST, PUT, DELETE, OPTIONS, or PATCH over HTTP with an HTTP to HTTPS cache behavior and a request protocol version of HTTP
    - protocol version of HTTP 1.1 or above,
      - CloudFront redirects the request to a HTTPS location with a HTTP status code 307 (Temporary Redirect)
      - This guarantees that the request is sent again to the new location using the same method and body payload.
    - protocol version below HTTP 1.1
      - CloudFront returns a HTTP status code 403 (Forbidden)
  - When a viewer makes an HTTP request that is redirected to an HTTPS request, CloudFront charges for both requests.
    - For the HTTP request, the charge is only for the request and for the headers that CloudFront returns to the viewer.
    - For the HTTPS request, the charge is for the request, and for the headers and the object that are returned by your origin.
- HTTPS Only
  - Viewers can access your content only if they’re using HTTPS.
  - If a viewer sends an HTTP request instead of an HTTPS request
    - CloudFront returns HTTP status code 403 (Forbidden) and does not return the object.
Choose Yes, Edit
Repeat steps 3 through 5 for each additional cache behavior that you want to require HTTPS for between viewers and CloudFront.
Confirm the following before you use the updated configuration in a production environment:
- The path pattern in each cache behavior applies only to the requests that you want viewers to use HTTPS for.
- The cache behaviors are listed in the order that you want CloudFront to evaluate them in.
- The cache behaviors are routing requests to the correct origins.

Requiring HTTPS for Communication Between CloudFront and Custom Origin

require HTTPS for communication between CloudFront and your custom origin, the steps depend on
- whether you’re using the domain name that CloudFront assigned to your distribution (d111111abcdef8.cloudfront.net)
- or using your own alternate domain name (example.com)

Note If your custom origin is an S3 bucket that’s configured as a website endpoint, you can’t configure CloudFront to use HTTPS with your origin because S3 doesn’t support HTTPS for website endpoints.

Use the default CloudFront domain name
- use the domain name that CloudFront assigned to the distribution in the URLs for the objects
- (https://d111111abcdef8.cloudfront.net/logo.jpg)
- require HTTPS by following the procedures in this topic to do the following:
  - Change the Origin Protocol Policy setting for specific origins in your distribution
  - Install an SSL/TLS certificate on your custom origin server (this isn’t required when you use an S3 origin)
Use an alternate domain name
- add an alternate domain name that’s easier to work with, like example.com.
- steps and guidance in Using Alternate Domain Names and HTTPS

Changing CloudFront Settings

configure CloudFront to use HTTPS to communicate with an Elastic Load Balancing load balancer, an EC2 instance, or another custom origin.
to use the CloudFront API to update a web distribution, see UpdateDistribution in the CloudFront API Reference.

To configure CloudFront to require HTTPS between CloudFront and your custom origin

AWS Management Console > CloudFront console at https://console.aws.amazon.com/cloudfront/
CloudFront console > choose the ID for the distribution that you want to update.
Origins tab > choose the origin to update > choose Edit.
Update the following settings:
- Origin Protocol Policy
  - Change the Origin Protocol Policy for the applicable origins in your distribution:
    - HTTPS Only
      - CloudFront uses only HTTPS to communicate with your custom origin.
    - Match Viewer
      - CloudFront communicates with your custom origin using HTTP or HTTPS
        depending on the protocol of the viewer request.
      - Example
        choose Match Viewer for Origin Protocol Policy
        the viewer uses HTTPS to request an object from CloudFront,
        CloudFront also uses HTTPS to forward the request to your origin.
      - Choose Match Viewer only if you specify Redirect HTTP to HTTPS or HTTPS Only for Viewer Protocol Policy.
      - CloudFront caches the object only once even if viewers make requests using both HTTP and HTTPS protocols.
- Origin SSL Protocols
  - Choose the Origin SSL Protocols for the applicable origins in your distribution.
  - The SSLv3 protocol is less secure, only if origin doesn’t support TLSv1 or later.
    - The TLSv1 handshake is both backwards and forwards compatible with SSLv3, but TLSv1.1 and TLSv1.2 are not.
    - When you choose SSLv3, CloudFront only sends SSLv3 handshake requests.
Choose Yes, Edit.
Repeat steps 3 through 5 for each additional origin that you want to require HTTPS for between CloudFront and your custom origin.
Confirm the following before you use the updated configuration in a production environment:
- The path pattern in each cache behavior applies only to the requests that you want viewers to use HTTPS for.
- The cache behaviors are listed in the order that you want CloudFront to evaluate them in. For more information, see Path Pattern.
- The cache behaviors are routing requests to the origins that you changed the Origin Protocol Policy for.

Installing an SSL/TLS Certificate on Your Custom Origin Server

use an SSL/TLS certificate from the following sources on your custom origin:

origin is an Elastic Load Balancing load balancer
- use a certificate provided by AWS Certificate Manager (ACM).
- use a certificate that is signed by a trusted third-party certificate authority and imported into ACM.
origins other than ELB load balancers,
- must use a certificate that is signed by a trusted third-party certificate authority (CA)
- for example, Comodo, DigiCert, or Symantec.

When CloudFront uses HTTPS to communicate with your origin

CloudFront verifies that the certificate was issued by a trusted certificate authority.
CloudFront supports the same certificate authorities that Mozilla does.
For the current list, see Mozilla Included CA Certificate List.
You can’t use a self-signed certificate for HTTPS communication between CloudFront and the origin.

Important

If the origin server returns an expired / invalid / self-signed certificate, or returns the certificate chain in the wrong order,
- CloudFront drops the TCP connection, r
- eturns HTTP status code 502 (Bad Gateway),
- and sets the X-Cache header to Error from cloudfront.
Also, if the full chain of certificates, including the intermediate certificate, is not present,
- CloudFront drops the TCP connection.

The certificate returned from the origin

must cover the domain specified for Origin Domain Name for the corresponding origin in your distribution.
In addition, if you configured CloudFront to forward the Host header to your origin, the origin must respond with a certificate matching the domain in the Host header.

About RSA and ECDSA Ciphers

The encryption strength of a communications connection depends on the key size and strength of the algorithm of origin server’s certificate.

The two options that CloudFront supports for connections with a custom origin
- RSA
- Elliptic Curve Digital Signature Algorithm (ECDSA).
For lists of the RSA and ECDSA ciphers supported by CloudFront, see Supported SSL/TLS protocols and ciphers for communication between CloudFront and your origin.

RSA

CloudFront and origin servers typically use RSA 2048-bit asymmetric keys for SSL/TLS termination.
The strength of RSA
- relies on the presumed difficulty of breaking a key that requires factoring the product of two large prime numbers.
  - RSA algorithms use the product of two large prime numbers, with another number added to it to create a public key.
  - The private key is a related number.
- but faster computer calculations have weakened RSA algorithms
- it’s now easier to break the encryption.
to maintain encryption strength while continuing to use RSA
- increase the size of the RSA keys.
- However, this approach isn’t easily scalable because using larger keys increases the compute cost for cryptography.

ECDSA

use an ECDSA certificate.
ECDSA bases its security on more complex mathematical problem than RSA
- takes more computer processing time to break ECDSA encryption.
ECDSA is built on the principle that it is difficult to solve for the discrete logarithm of a random elliptic curve when its base is known, also known as the Elliptic Curve Discrete Logarithm Problem (ECDLP).
so use shorter key lengths to achieve the equivalent security of using RSA with much larger key sizes.
- providing better security
- ECDSA’s smaller keys
- enables faster computing of algorithms, smaller digital certificates, and fewer bits to transmit during the SSL/TLS handshake.
- reduce the time it takes to create and sign digital certificates for SSL/TLS termination on origin servers.
- can increase throughput by reducing the compute cycles needed for cryptography, freeing up server resources to process other work.

Choosing Between RSA and ECDSA Ciphers

Sample tests
- Example,
- 2048-bit RSA to 256-bit ECDSA (nistp256)
- nistp256 option was 95% faster than 2048-bit RSA
- while providing the same security strength as 3072-bit RSA.
CloudFront continues to support RSA for SSL/TLS connections.
- However, for encryption for SSL/TLS authentication for origin servers, ECDSA could be a better option.
stronger encryption, the reduction in computational cost of cryptography while using ECDSA at your origin servers is an added advantage.

Use ECDSA Ciphers for communications between CloudFront and the origin

Generate a private key by using either of the supported curves (prime256v1 or secp384r1).
Generate an ECDSA Digital Certificate in the X.509 PEM format with a trusted certificate authority.
Set up your origin to prefer the ECDSA certificate.
Using ECDSA doesn’t require any settings changes in the CloudFront console or APIs, and there is no additional fee.

Requiring HTTPS for Communication Between CloudFront and S3 Origin

When origin is an S3 bucket, options for using HTTPS for communications with CloudFront depend on how you’re using the bucket.

the S3 bucket is configured as a website endpoint
- no HTTPS when communicate between origin and CloudFront
- S3 doesn’t support HTTPS connections in that configuration.
When your origin is an S3 bucket that supports HTTPS communication
- CloudFront always forwards requests to S3 by using the protocol that viewers used to submit the requests.
- The default setting for the Origin Protocol Policy setting is Match Viewer and can’t be changed.
to require HTTPS for communication between CloudFront and S3
- must change Viewer Protocol Policy to Redirect HTTP to HTTPS or HTTPS Only
- The procedure later in this section explains how to use the CloudFront console to change Viewer Protocol Policy.
- using the CloudFront API to update the ViewerProtocolPolicy element for a web distribution: UpdateDistribution in the CloudFront API

When you use HTTPS with an S3 bucket that supports HTTPS communication, S3 provides the SSL/TLS certificate, so you don’t have to.

To configure CloudFront to require HTTPS to your S3 origin

AWS Management Console > CloudFront console
CloudFront console > choose the ID for the distribution to update.
Behaviors tab > choose the cache behavior to update > choose Edit.
Specify one of the following values for Viewer Protocol Policy
- Redirect HTTP to HTTPS
  - Viewers can use both protocols
  - but HTTP requests are automatically redirected to HTTPS requests.
  - CloudFront returns HTTP status code 301 (Moved Permanently) along with the new HTTPS URL.
  - The viewer then resubmits the request to CloudFront using the HTTPS URL.
  - Important
    - CloudFront doesn’t redirect DELETE, OPTIONS, PATCH, POST, or PUT requests from HTTP to HTTPS.
    - CloudFront responds to HTTP DELETE, OPTIONS, PATCH, POST, or PUT requests for that cache behavior with HTTP status code 403 (Forbidden).
  - When a viewer makes an HTTP request that is redirected to an HTTPS request, CloudFront charges for both requests.
    - For the HTTP request, the charge is only for the request and for the headers that CloudFront returns to the viewer.
    - For the HTTPS request, the charge is for the request, and for the headers and the object returned by your origin.
- HTTPS Only
  - Viewers can access your content only if they’re using HTTPS.
  - If a viewer sends an HTTP request instead of an HTTPS request,
    - CloudFront returns HTTP status code 403 (Forbidden) and does not return the object.
Choose Yes, Edit.
Repeat steps 3 through 5 for each additional cache behavior that you want to require HTTPS for between viewers and CloudFront, and between CloudFront and S3.
Confirm the following before you use the updated configuration in a production environment:
- The path pattern in each cache behavior applies only to the requests that you want viewers to use HTTPS for.
- The cache behaviors are listed in the order that you want CloudFront to evaluate them in. For more information, see Path Pattern.
- The cache behaviors are routing requests to the correct origins.

Using Alternate Domain Names and HTTPS

To use dedicated IP, request permissionfor your AWS account (not necessary for SNI)
- By default, when request permission to use an alternate domain name with HTTPS, we update your account so that you can associate two custom SSL certificates with your CloudFront distributions.
- Typically, you only use the second certificate temporarily, like when have more than one distribution and need to rotate certificates.
- If you need to permanently associate two or more certificates with your distributions, indicate how many certificates you need, and describe your circumstances in your request.
upload your SSL certificate to the IAM certificate store by AWS Certificate Manager (ACM) or AWS CLI.
- ACM (preferred tool): provisioning, managing, and deploying server certificates.
- Certificates that are provided by ACM are free, and automatically renew.
- With ACM, you can
- To request a certificate.
- to deploy an existing ACM or external certificate to AWS resources.
- to manage server certificates from the console or programmatically.
- use IAM as a certificate manager only when must support HTTPS connections in a Region that not supported by ACM.
- IAM securely encrypts your private keys, and itstores the encrypted version in IAM SSL certificate storage.
- IAM supports deploying server certificates in all Regions, but you must obtain your certificate from an external provider for use with AWS. You cannot upload an ACM certificate to IAM.
- When you use the IAM CLI to upload your SSL certificate to the IAM certificate store, you must use the same AWS account that you used to create your CloudFront distribution.
- When you upload your certificate to IAM, the value of the -path parameter, or certificate path, must start with /cloudfront/.
- Examples of the -path parameter include
- /cloudfront/production/
- /cloudfront/test/
- The path also must end with a /.
- to use the CloudFront API to create or update your distribution,
- make sure note the alphanumeric string that AWS CLI returns, such as AS1A2M3P4L5E67SIIXR3J.
- This string is the value that you will specify in the IAMCertificateId element.
- You do not need the IAM Amazon Resource Name—or ARN—which is also returned by the CLI.
You can update your distribution to include your domain names
- so that you can specify which SSL certificate you want to use, specify a dedicated IP address or SNI, and add or update DNS records.
- After you associate your SSL certificate with your CloudFront distribution, do not delete the certificate from the IAM certificate store until you remove the certificate from all distributions, and until the status of the distributions has changed to Deployed.
- To request permission, select the link. https://aws.amazon.com/cloudfront/custom-ssl-domains/

Advanced SSL features support

High security ciphers
- to improve the security of HTTPS connections.
- CloudFront edge servers and clients, such as browsers, automatically agree on a cipher as part of the SSL handshake process.
- The connections can now use ciphers with advanced features, such as Elliptic Curve signatures and key exchanges.
Perfect forward secrecy
- uses a unique random session key to provide additional safe guards against the eavesdropping of encrypted data.
- This feature prevents the decoding of captured data, even if the secret long-term key is compromised.
OCSP stapling
- improves the time taken for individual SSL handshakes.
- It moves the Online Certificate Status Protocol (OSCP) check, which is used to obtain the revocation status of an SSL certificate, from the client to a periodic, secure check by the CloudFront servers.
- With OCSP stapling, the client no longer needs to handle certificate validation, which improves performance.
Session tickets
- speed up the time to restart or resume an SSL session.
- CloudFront encrypts SSL session information and stores it in a ticket.
- The client can use this ticket to resume a secure connection instead of repeating the SSL handshake process

Restricting content with signed URLs and signed cookies

Restricting Access to S3 Content by signed URLs

make content private

restrict access to objects in your S3 bucket.
require that users use signed URLs.
- create CloudFront key pairs for trusted signers
- write the code that generates signed URLs.
- write an application that automatically generates signed URLs
- Or use a web interface to create signed URLs
- add trusted signers to your distribution.
- After you add a trusted signer to your distribution, users must use signed URLs to access the corresponding content.
- A signed URL:
- includes additional information
- such as an expiration date and time,
- gives you more control over access to your content.
- This additional information appears in a policy statement that is based on canned / custom policy:
- canned policy: restrict access to a single object. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-canned-policy.html
- custom policy: restrict access to one or more objects by using pattern matching. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-custom-policy.html

Restricting Access to S3 Content by OAI Origin Access Identity

When your Amazon Cloudfront CDN distributions are using AWS S3 as an origin, the distributions content should be kept private and delivered only via Cloudfront network, using an origin access identity to regulate access.

In general, using an S3 bucket as the origin for a CloudFront distribution

either allow everyone to have access to the files there,
or restrict the access.
- restrict access by CloudFront signed URLs or signed cookies
- to restrict access to view files by the direct S3 URL for the file.
- let them only access the files by the CloudFront URL, so the protections work.

Origin access identity

to restrict access
- restrict access to S3 content by creating an OAI, a special CloudFront user.
- CloudFront OAI gets objects from S3 on behalf of the users.
- Direct access to the objects through S3 URLs will be denied.
Cloudfront distributions can be much more cost effective
- the price for CloudFront data transfer is lower than the price for S3 data transfer.
downloads are faster
- only the CloudFront service is used to deliver the application objects instead of S3
- because the objects are copied to all edge locations within the distribution in order to be stored closer to your users.

Important If you use an S3 bucket configured as a website endpoint
must set it up with CloudFront as a custom origin.
can’t use the origin access identity feature
However, you can restrict access to content on a custom origin by setting up custom headers and configuring your origin to require them.
For more information, see Restricting access to files on custom origins.

create an origin access identity by CloudFront console or the CloudFront API.
- CloudFront console: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html#private-content-creating-oai-console
- CloudFrontAPI: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html#private-content-creating-oai-api
To use this feature to restrict access to content from S3 buckets
- Create a special CloudFront user called an origin access identity (OAI) and associate it with your distribution.
- Configure your S3 bucket permissions
  - change the permissions either on your S3 bucket or the objects in bucket
    - so only the origin access identity has read permission.
  - so CloudFront can use the OAI to access the files in your bucket and serve them to your users.
  - Make sure that users can’t use a direct URL to the S3 bucket to access a file there.
- After these steps, users can only access the files through CloudFront, not directly from the S3 bucket.

Audit

To determine if origin access identity is enabled for your Cloudfront distributions configured with S3 as origin, perform the following:

AWS CLI:

  
aws cloudfront list-distributions \
	--output table \
	--query 'DistributionList.Items[*].Id'
# ---------------------
# | ListDistributions |
# +-------------------+
# |   E7GGTQ8UCFC4G   |
# |   G31A16G5KZMUX   |
# |   D8E6G5KZMPDT0   |
# +-------------------+


# return multiple values using query argument
aws cloudfront list-distributions \
  --output text
  --query "DistributionList.Items[*].Origins.Items[*].{id:Id,name:DomainName}"

aws cloudfront list-distributions \
  --output text
  --query "DistributionList.Items[*].{id:Id, origin:Origins.Items[0].Id}[?origin=='S3-BUCKET_NAME'].id"


# expose the name of the origin access identity set for each S3 origin entry associated with the selected AWS Cloudfront distribution:
aws cloudfront get-distribution-config \
	--id DistributionList.Id \

aws cloudfront get-distribution-config \
	--id E7GGTQ8UCFC4G \
	--query 'DistributionConfig.Origins.Items[*].S3OriginConfig.OriginAccessIdentity'

OAI Setup

When set up an S3 bucket as the origin for a CloudFront distribution

grant everyone permission to read the files in your bucket.
- allows anyone to access your files either through CloudFront or using the S3 URL
- CloudFront doesn’t expose S3 URLs,
- but the users might have those URLs if your application serves any files directly from S3
- or if anyone gives out direct links to specific files in S3.
use CloudFront signed URLs or signed cookies
to restrict access
- but it not prevent users from accessing S3 files by using S3 URLs
- If users access your files directly in S3,
  - they bypass the controls provided by CloudFront signed URLs or signed cookies
    - This includes
    - control over the date and time that a user can no longer access your content,
    - and control over which IP addresses can be used to access content.
  - CloudFront access logs are less useful
    - because they’re incomplete, users access files both through CloudFront and directly by using S3 URLs,

To ensure access by only CloudFront URLs, regardless of whether the URLs are signed, do the following:

Create an origin access identity
- a special CloudFront user
- associate the origin access identity with the distribution.
- associate the origin access identity with origins, so that you can secure all or just some of your S3 content.
- can also create an origin access identity and add it to your distribution when you create the distribution.
Change the permissions either on your S3 bucket or on the files in bucket
- only the origin access identity has read permission (or read and download permission).
- When your users access your S3 files through CloudFront,
  - the CloudFront origin access identity gets the files on behalf of your users.
- If your users request files directly by using S3 URLs, they’re denied access.
- The origin access identity has permission to access files in your S3 bucket, but users don’t.

An AWS account can have up to 100 CloudFront origin access identities (OAIs)

can add an OAI to as many distributions as you want, so one OAI is usually sufficient.

create an OAI and add it to the distribution when created the distribution
create and add one now by either the CloudFront console or the CloudFront API:
- CloudFront console
  - can create an OAI and add it to the distribution at the same time.
- CloudFront API version 2009-09-09 or later.
  - create an OAI, and then you add it to your distribution.

create OAI and update CloudFront distribution

Creating an OAI by CloudFront console

AWS Management Console > CloudFront console > Choose the ID of a distribution that has an S3 origin.
Choose the Origins and Origin Groups tab.
Choose the check box next to an origin, and then choose Edit.
For Restrict Bucket Access, choose Yes.
- If you already have an OAI that you want to use,
  - choose Use an Existing Identity.
  - Then choose the OAI in the Your Identities list.
- to create an OAI, choose Create a New Identity.
  - You can replace the bucket name in the Comment field with a custom description.
If you want CloudFront to automatically give the OAI permission to read the files in the S3 bucket specified in Origin Domain Name, choose Yes, Update Bucket Policy.
- CloudFront updates bucket permissions to grant the specified OAI permission to read files in your bucket.
- However, CloudFront does not remove existing permissions.
- If users currently have permission to access the files in your bucket using S3 URLs, they will still have that permission after CloudFront updates your bucket permissions.
- To view or remove existing bucket permissions, use a method provided by S3.
- If you want to manually update permissions on your S3 bucket, choose No, I Will Update Permissions.
Choose Yes, Edit.
If you have more than one origin, repeat the steps to add an OAI for each one.

Creating an OAI by CloudFront API

create a CloudFront OAI.

POST Origin Access Identity API action.

  
 # creates a CloudFront origin access identity (OAI) by providing the OAI configuration as a command line argument:
 aws cloudfront create-cloud-front-origin-access-identity \
     --cloud-front-origin-access-identity-config \
     CallerReference="cli-example",Comment="Example OAI"

 # providing the OAI configuration in a JSON file:
 aws cloudfront create-cloud-front-origin-access-identity \
     --cloud-front-origin-access-identity-config file://OAI-config.json

 # The file OAI-config.json:
 {
     "CallerReference": "cli-example",
     "Comment": "Example OAI"
 }

 # the output is the same:
 {
     "Location": "https://cloudfront.amazonaws.com/2019-03-26/origin-access-identity/cloudfront/E74FTE3AEXAMPLE",
     "ETag": "E2QWRUHEXAMPLE",
     "CloudFrontOriginAccessIdentity": {
         "Id": "E74FTE3AEXAMPLE",
         # the value used to associate the OAI with your distribution.
         "S3CanonicalUserId": "cd13868f797c227fbea2830611a26fe0a21ba1b826ab4bed9b7771c9aEXAMPLE",
         # the value used when you use S3 object ACLs to give the OAI access to your S3 objects.
         "CloudFrontOriginAccessIdentityConfig": {
             "CallerReference": "cli-example",
             "Comment": "Example OAI"
         }
     }
 }

Adding OAI to Distribution by CloudFront API
- use the CloudFront API to add a CloudFront OAI to an existing distribution or to create a new distribution that includes an OAI.
- In either case, include an OriginAccessIdentity element.
  - This element contains the value of the Id element
- You can add the OriginAccessIdentity element to one or more origins.
- Create a new web distribution
- Update an existing web distribution

  
# Run get-distribution-config command to extract the configuration metadata from the Cloudfront distribution that you want to reconfigure
# returns the configuration details of an AWS Cloudfront CDN distribution identified by the ID E7GGTQ8UCFC4G:
aws cloudfront get-distribution-config \
	--id E7GGTQ8UCFC4G
  --profile yourrole

# output
{
    "ETag": "E1VEIGDP0YISPR",
    "DistributionConfig": {
        "Comment": "",
        "CacheBehaviors": { "Quantity": 0 },
        "IsIPV6Enabled": true,
        "Origins": {
            "Items": [
                {
                    # modify this
                    # "S3OriginConfig": { "OriginAccessIdentity": "" },
                    "S3OriginConfig": {
                        "OriginAccessIdentity": "access-identity-cloudconformity-web-assets.s3.amazonaws.com"
                    },
                    "OriginPath": "/static",
                    "CustomHeaders": { "Quantity": 0 },
                    "Id": "S3-cloudconformity-web-assets",
                    "DomainName": "cloudconformity-web-assets..."
                }
            ],
            "Quantity": 1
        },

       ...

        "CallerReference": "1495036941163",
        "ViewerCertificate": {
            "CloudFrontDefaultCertificate": true,
            "MinimumProtocolVersion": "SSLv3",
            "CertificateSource": "cloudfront"
        },
        "CustomErrorResponses": { "Quantity": 0 },
        "HttpVersion": "http2",
        "Restrictions": {
            "GeoRestriction": {
                "RestrictionType": "none",
                "Quantity": 0
            }
        },
        "Aliases": { "Quantity": 0 }
    }
}

# to enable origin access identity for other Cloudfront CDN distributions
# Run update-distribution to update your AWS Cloudfront distribution in order to enable origin access identity and restrict user access to the S3 bucket used as distribution origin.
# updates an AWS CloudFront CDN web distribution with the ID E7GGTQ8UCFC4G and the ETag E1VEIGDP0YISPR, using the JSON configuration document named cloudfront-distconfig-enable-oai.json, created at the previous step:
aws cloudfront update-distribution \
	--id E7GGTQ8UCFC4G \
	--distribution-config file://cloudfront-distconfig-enable-oai.json \
	--if-match E1VEIGDP0YISPR

Granting the OAI Permission to Read Files in S3 Bucket

When create or update a distribution

add an origin access identity (OAI) and automatically update the S3 bucket policy to give the OAI permission to access your bucket.
or manually create or update the bucket policy
or use object ACLs that control access to individual files in the bucket.

Whichever method, review the permissions to make sure that:

CloudFront OAI can access files
in the bucket on behalf of viewers who are requesting them through CloudFront.
Viewers can’t use S3 URLs
to access your files outside of CloudFront.

Important

If you configure CloudFront to accept and forward all of the HTTP methods that CloudFront supports, make sure you give your CloudFront OAI the desired permissions.
For example,
configure CloudFront to accept and forward requests that use the DELETE method,
configure your bucket policy or object ACLs to handle DELETE requests appropriately so viewers can delete only files that you want them to.

Note the following:

it is easier to use S3 bucket policies than object ACLs
- S3 bucket policies
  - can add files to the bucket without updating permissions.
- object ACLs
  - give more fine-grained control
  - it granting permissions on each individual file.
By default, S3 bucket and all files in it are private.
- Only the AWS account that created the bucket has permission to read or write the files in it.
If another AWS account uploads files to your bucket, that account is the owner of those files.
- Bucket policies only apply to files that the bucket owner owns.
- if another account uploads files to your bucket,
  - the bucket policy that you created for your OAI is not evaluated for those files.
  - In that case, use object ACLs to give permissions to your OAI
If adding an OAI to an existing distribution
- modify the bucket policy or any object ACLs as appropriate
- to ensure that the files are not publicly available outside of CloudFront.
Grant additional permissions to one or more secure administrator accounts
- so you can continue to update the contents of the S3 bucket.
There might be a brief delay between save changes to S3 permissions and when the changes take effect.
- Until the changes take effect, might get “permission denied” errors when try to access files in your bucket.

Using S3 Bucket Policies

give CloudFront OAI access to files in S3 bucket by creating or updating the bucket policy

Using the S3 bucket’s Permissions tab in the S3 console.
Using PutBucketPolicy in the S3 API.
Using the CloudFront console.
- When you add an OAI to your origin settings in the CloudFront console
- choose Yes, Update Bucket Policy to tell CloudFront to update the bucket policy on your behalf.
- If you update the bucket policy manually:
  - Specify the correct OAI as the Principal in the policy.
  - Give the OAI the permissions it needs to access objects on behalf of viewers.

Specify an OAI as the `Principal`

To specify an OAI as the Principal in an S3 bucket policy

use the OAI’s Amazon Resource Name (ARN), which includes the OAI’s ID.
- To find the OAI’s ID
  - use Origin Access Identity page in the CloudFront console
  - use ListCloudFrontOriginAccessIdentities in the CloudFront API.
1 2 3 4 "Principal": { "AWS": "arn:aws:iam::cloudfront:user/EH1HDMB1FH2TC" // CloudFront Origin Access Identity }
or specify an OAI as the Principal by using its S3 canonical ID
- find the OAI’s canonical ID in the same ways that you find its ID.
1 2 3 "Principal": { "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" }

OAI’s ARN:

make it easier to understand the bucket policy.
easier to understand who the bucket policy is granting access to.

S3 canonical IDs:

can refer to different kinds of AWS identities, not just CloudFront OAIs
so difficult to determine which identity a canonical ID refers to.
Also, when use the OAI’s canonical ID in a bucket policy, AWS replaces the canonical ID with the OAI’s ARN.
- When you write a policy that specifies an OAI’s canonical ID and then later view the same policy, the canonical ID has been replaced by the corresponding ARN.

Give Permissions to an OAI

To give the OAI the permissions to access objects in the S3 bucket, use keywords in the policy that relate to specific S3 API operations.

For example, the s3:GetObject permission allows the OAI to read objects in the bucket.
Specifying Permissions in a Policy in the Amazon Simple Storage Service Developer Guide.

S3 Bucket Policy Examples

S3 bucket policies that grant access to a CloudFront OAI.

OAI’s ID: EH1HDMB1FH2TC
S3 bucket: awsexamplebucket

Example S3 bucket policy that gives the OAI read access

allows the OAI to read objects in the specified bucket (s3:GetObject).

  
{
    "Version": "2012-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws:iam::cloudfront:user/EH1HDMB1FH2TC"},
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::awsexamplebucket/*"
        }
    ]
}

Example S3 bucket policy that gives the OAI read and write access

allows the OAI to read and write objects in the specified bucket (s3:GetObject and s3:PutObject).
This allows viewers to upload files to your S3 bucket through CloudFront.

  
{
    "Version": "2012-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws:iam::cloudfront:user/EH1HDMB1FH2TC"},
            "Action": [ "s3:GetObject", "s3:PutObject" ],
            "Resource": "arn:aws:s3:::aws-example-bucket/*"
        }
    ]
}

Updating S3 Object ACLs

give a CloudFront OAI access to files in an S3 bucket by creating or updating the file’s ACL in the following ways:

Using the S3 object’s Permissions tab in the S3 console.
Using PutObjectAcl in the S3 API.

to grant access to an OAI using an ACL

must specify the OAI using its S3 canonical user ID
in CloudFront API, use the value of the S3CanonicalUserId element that was returned when you created the OAI, or call ListCloudFrontOriginAccessIdentities in the CloudFront API.

Using an OAI in S3 Regions that Support Only Signature Version 4 Authentication

Newer S3 Regions require that you use Signature Version 4 for authenticated requests.

when create an origin access identity and add it to a CloudFront distribution,
CloudFront typically uses Signature Version 4 for authentication when it requests files in your S3 bucket.
DELETE, GET, HEAD, OPTIONS, and PATCH requests are supported without qualifications.
to submit PUT requests to CloudFront to upload files to your S3 bucket
- must add an x-amz-content-sha256 header to the request.
- The header value must contain an SHA256 hash of the body of the request.
POST requests are not supported.

01AWS, Balancing

This post is licensed under CC BY 4.0 by the author.

CloudFront

cloudFront

edge locations

Regional Edge caches

Origin Access Identity (OAI)

benefits

enable CloudFront

CloudFront distributions

cache control headers

presigned URLs

Configuring Secure Access and Restricting Access to Content

CloudFront Custom SSL Support

Using HTTPS with CloudFront

Requiring HTTPS for Communication Between Viewers and CloudFront

Requiring HTTPS for Communication Between CloudFront and Custom Origin

Changing CloudFront Settings

Installing an SSL/TLS Certificate on Your Custom Origin Server

About RSA and ECDSA Ciphers

Requiring HTTPS for Communication Between CloudFront and S3 Origin

Using Alternate Domain Names and HTTPS

Restricting content with signed URLs and signed cookies

Restricting Access to S3 Content by signed URLs

Restricting Access to S3 Content by OAI Origin Access Identity

Audit

OAI Setup

create OAI and update CloudFront distribution

Creating an OAI by CloudFront console

Creating an OAI by CloudFront API

Granting the OAI Permission to Read Files in S3 Bucket

Using S3 Bucket Policies

Specify an OAI as the Principal

Give Permissions to an OAI

S3 Bucket Policy Examples

Updating S3 Object ACLs

Using an OAI in S3 Regions that Support Only Signature Version 4 Authentication

Trending Tags

Specify an OAI as the `Principal`