Merikanto

一簫一劍平生意，負盡狂名十五年

AWS - 09 ElastiCache & CloudFront

Veröffentlicht am in
Symbole im Artikel gezählt: 5.8k Wörter Lesezeit ≈ 7 min

In the ninth post of the AWS series, we’re going to talk about 2 services:

  • ElastiCache (Memcached & Redis)
  • CloudFront (Cloud CDN)

ElastiCache

Only ElastiCache & RDS have read replicas.

DynamoDB & CloudFront DO NOT have read replicas.

  • Distributed in-memory cache, supports Redis & Memcached
  • Can be used for storing session states
  • Monitor events with ElastiCache Events
  • Redis is more HA than Memcached

For Redis

  • Existing applications that use Redis can use ElastiCache with almost no modification
  • Automatic detection and recovery from cache node failures
  • For improved fault tolerance, have at least two nodes in a Redis cluster and enabling Multi-AZ with automatic failover

  • Supports data partition up to 250 shards
  • Data encryption in transit & at rest
  • Persistent data, can be used as data store
  • Single-threaded

Cache data if:

  • It is slow or expensive to acquire when compared to cache retrieval
  • It is accessed with sufficient frequency
  • It is relatively static, or if rapidly changing, staleness is not a significant issue

  • 🧡 Redis publish / subscribe: recipients of the messages subscribe to the publisher
  • Redis hashes map string names to string values

Nodes, shards & clusters

  • A node is a fixed-size chunk of secure, network-attached RAM. A node can exist in isolation / relation to other nodes

  • Every node within a cluster is the same instance type and runs the same cache engine. Each cache node has its own DNS name and port

    Replica nodes use asynchronous replication to keep synchronized with the primary node


  • Shard: A grouping of 1- 6 related nodes

    • Cluster mode off: A Redis cluster always has one shard
    • Cluster mode on: A Redis cluster can have 1–90 shards

  • If there is more than one node in a shard, the shard supports replication with one node being the read/write primary node and the others read-only replica nodes.

  • Cluster: a logical grouping of one or more ElastiCache for Redis Shards. Data is partitioned across the shards in a Redis cluster (cluster mode on).


Parameter groups

Parameters are used to control memory usage, eviction policies, item sizes, and more.


Security

Redis AUTH: Improve data security by requiring the user to enter a password before they are granted permission to execute Redis commands on a password-protected Redis server (--auth-token)


Caching

ElastiCache Auto Discovery only available for Memcached (identify all nodes in a cache cluster)


Caching Strategy

By adding TTL to each write, we have advantages of each strategy, and largely avoid cluttering up the cache with too many data

If there are no cache records to begin with, then use write through first.


1. Lazy loading (for GET, read-heavy)

  • Loads data into cache only when necessary
  • Only requested data is cached
  • Cons: cache miss, stale data

2. Write through (for CUD)

  • Adds / updates data in the cache whenever data is written to the database
  • Cache data is never stale
  • Each write involves 2: write to cache & write to DB (add / update)
  • Cons: data miss, cache churn

CloudFront

Cannot directly upload files to CloudFront. Must have origin servers, e.g. S3, EC2.

  • Delivers content through a worldwide network of data centers (= edge locations)
  • When a user requests content that you’re serving with CloudFront, the user is routed to the edge location that provides the lowest latency, so that content is delivered with the best possible performance

Deliver Content

  • You specify origin servers, like an S3 bucket / EC2 / your own HTTP server, from which CloudFront gets your files which will then be distributed from CloudFront edge locations all over the world.
  • Upload files (objects), cached for 24h by default
  • Create CloudFront Distribution

  • CloudFront supports WebSocket protocol & HTTP protocol

  • Use Lambda@Edge & CloudFront enables a variety of ways to customize the content that CloudFront delivers

    It can help you configure your CloudFront distribution to serve private content from your own custom origin, as an option to using signed URLs or signed cookies

  • CloudFront can cache different versions of your content based on the values of query string parameters


Other

HA

  • CloudFront allows you to set up multiple origins to enable redundancy with Origin Failover (a distribution with >= 2 origins)

HTTPS

  • Between viewers & CloudFront, and between CloudFront & origins

Monitoring

  • Cloud Front own reports: Cache Statistics / Viewers / Usage etc.
  • AWS Config to record configuration changes for CloudFront distribution settings changes
  • Integrates with CW metrics
  • CloudTrail to capture API requests (only logging, not analyze)

Security

  • CloudFront & Shield & WAF & Route 53 (layered security protection)
  • Origin Access Identity (OAI): Restrict access to an S3 bucket to only be accessible from CloudFront
  • Field-level encryption: Securely upload user-submitted data (e.g. credit card numbers) to your origin servers

Notice

Many companies that distribute content over the Internet want to restrict access to documents, business data, media streams, or content that is intended for selected users, for example, users who have paid a fee. To securely serve this private content by using CloudFront, you can do the following:

  • Require that your users access your private content by using special CloudFront signed URLs or signed cookies 🧡
  • Require that your users access your Amazon S3 content by using CloudFront URLs, not Amazon S3 URLs. Requiring CloudFront URLs isn’t necessary, but it is recommended to prevent users from bypassing the restrictions that you specify in signed URLs or signed cookies.

All objects and buckets by default are private. The presigned URLs are useful if you want your user/customer to be able to upload a specific object to your bucket, but you don’t require them to have AWS security credentials or permissions. You can generate a presigned URL programmatically using the AWS SDK. Anyone who receives a valid presigned URL can then programmatically upload an object.


Signed cookies feature is primarily used if you want to provide access to multiple restricted files.

For example, all of the files for a video in HLS format or all of the files in the subscribers’ area of website. In addition, this solution is not complete since the users can bypass the restrictions by simply using the direct S3 URLs.


Origin Access Identity (OAI) will require your client to access the files only by using the CloudFront URL and not through a direct S3 URL. This can be a possible solution if it mentions the use of Signed URL or Signed Cookies.

  • 正确做法： Use S3 pre-signed URLs to ensure that only their client can access the files. Remove permission to use Amazon S3 URLs to read the files for anyone else.
  • 另一种： OAI + Signed URL / Signed cookies

Provide best user experience (for pushing updates to clients):

  • Store the update file on an S3 bucket. Configure CloudFront to use the bucket as the origin to cache the update file to edge locations

Upload once to S3, CloudFront cache to edge locations worldwide