CloudFront ForwardedValues ambiguous documentation - amazon-web-services

I'm configuring my CloudFront using CloudFormation, and on the AWS documentation page for the ForwardedValues property, we can see the following statement:
If you specify true for QueryString and you don't specify any values for QueryStringCacheKeys, CloudFront forwards all query string parameters to the origin and caches based on all query string parameters.
The word in bold (caches) are causing some confusion, as the meaning of this sentence is completely dependent on caches being a verb or caches being a noun:
Verb: CloudFormation will cache the queryparameter
Noun: CloudFormation will forward the queryparameter to the cache, but it will not cache the queryparameters
If I don't specify the QueryStringCacheKeys, what is the behaviour of CloudFront?

I fixed it by specifying CachePolicyId
as in https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-managed-cache-policies.html
Type: "AWS::CloudFront::Distribution"
Properties:
DistributionConfig:
DefaultCacheBehavior:
# Name: Managed-CachingOptimized
# need either this parameter or 'ForwardedValues'
CachePolicyId: 658327ea-f89d-4fab-a63d-7e88639e58f6

If you don't specify the QueryStringCacheKeys, but only this:
ForwardedValues:
QueryString: true
CloudFront will Forward all, cache based on all, which means that the request will be cached based on url+querystring and that the querystring is forwarded to the underlying system.
You can read more on this in the AWS documentation here.

Related

GCP load balancers - query params or custom method

I was trying to set up a load balancer to cache requests only when a query param is present in the request or a custom method on the API is called.
Either something like:
BASE_URL/api/v1/asset/UUID?static_only=true
or something like
BASE_URL/api/v1/asset/UUID:static
I've set up 2 NEG linked to the same cloud run service. One of them has the CDN active so that it can cache responses.
Since this API has some content that can require other calls to other services that are subject to change, I want to give the option to cache the request when the query param is present.
I tried to set up a url-map with the following configuration:
defaultService: DEFAULT_BACKEND
name: path-matcher-1
routeRules:
- matchRules:
- queryParameterMatches:
- exactMatch: 'true'
name: static_only
prefixMatch: /api/v1/asset/*
priority: 1
service: BACKEND-2
I couldn't find examples on the custom method, but the tries I had with the query param didn't work. Is my approach wrong?
I guess there are two parts on this question.
How do I configure the URL map to accept a path that ends with a dynamic value? (in this case the UUID of the resource) The * doesn't seem to work.
Is it possible to configure the URL map to use custom methods (AIP-136)?

AWS CloudFront will only invalidate entire cache

I want to invalidate the CloudFront cache entry for a specific path, say /api/dict/bob/article/1, but it has no effect. I've experimented with different wildcards, for instance:
/*/1
/api/dict/bob/article/*
/api/dict/bob/*
/api/dict/*
But in the end, the only invalidation that actually removes the object from the cache is the catch-all /*
The path's origin is custom (API Gateway)
Cache policy:
Minimum TTL: 60,
Maximum TTL:28800,
Default TTL: 10800
Cache key:
query-strings all
cookies: all
headers: whitelist (one param)
Update: I managed to invalidate an svg-file from an s3 origin. The api origin requires an x-api-key http-header. Could that make a difference?
I think * can be only in the end. Are you sure it is not a client caching and you waited for the invalidation to finish? It is a slow process, not instant for sure. You can track its progress either on the UI or using the CLI.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html
To invalidate files, you can specify either the path for individual
files or a path that ends with the * wildcard, which might apply to
one file or to many, as shown in the following examples:
/images/image1.jpg
/images/image*
/images/*

How to update Athena output location using Cloudformation

Can someone help me write a Cloud formation script to update output location of Athena primary workgroup. When i run below code, getting error message "Invalid request provided: primary workGroup could not be created (Service: Athena, Status Code: 400, Request ID: 9945209c-6999-4e8b-bd3d-a3af13b4ac4f)"
Resources:
MyAthenaWorkGroup:
Type: AWS::Athena::WorkGroup
Properties:
Name: primary
Description: My WorkGroup Updated
State: DISABLED
WorkGroupConfigurationUpdates:
BytesScannedCutoffPerQuery: 10000000
EnforceWorkGroupConfiguration: true
PublishCloudWatchMetricsEnabled: true
RequesterPaysEnabled: false
ResultConfigurationUpdates:
EncryptionConfiguration:
EncryptionOption: SSE_S3
OutputLocation: s3://test/
you need to "create a change set to import an existing resource into a new or existing stack.", because the 'primary' workgroup was created outside your stack.
So you need to use the option: "Create stack with existing resources":
You also need to add DeletionPolicy/UpdateReplacePolicy.
An complete working example is:
Resources:
AthenaPrimaryWorkGroup:
Type: AWS::Athena::WorkGroup
Properties:
Name: primary
State: ENABLED
WorkGroupConfigurationUpdates:
BytesScannedCutoffPerQuery: 1000000000
EnforceWorkGroupConfiguration: true
PublishCloudWatchMetricsEnabled: true
RequesterPaysEnabled: false
ResultConfigurationUpdates:
OutputLocation: s3://MY-Athena-results
DeletionPolicy: Retain
UpdateReplacePolicy: Retain
More detail at: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import.html
Why not name the workgroup in your cloudformation stack something other than "primary", and let the stack manage the workgroup resource completely? Then, depending on how the rest of the system is set up, it may work out to use this new workgroup instead of the primary one. Even if you do get it working to alter the primary workgroup output location in CF, I think it's clear that's going upstream against CF's most natural usage patterns.

AWS MSK Cloud Formation Tags problems

When creating AWS::MSK::Cluster with Cloud Formation I am not able to set Tags in the usual way:
Tags:
- Key: Name
Value: !Ref Identifier
Because of this error:
Property validation failure: [Value of property {/Tags} does not match type {Map}]
As of the time of writing, the documentation states that, instead of the usual Type: List of Tag, I should use: Type: Json.
Also the same documentation states that:
You can specify tags in JSON or in YAML, depending on which format you use for your template
After further investigation (and AWS support help), the working (only on creation) example looks like this:
Tags:
Name: !Ref Identifier
Additionally, tags cannot be modified (the docs actually state that tags change require replacement), when tried a slightly confusing error shows up:
CloudFormation cannot update a stack when a custom-named resource requires replacing. Rename kafka-eu-west-1-dev and update the stack again.

Serverless Framework S3 Event Rule

I am creating a s3 listener using serverless framework. A user has requested a specific file format, for the s3 trigger for the event.
I currently have
functions:
LambdaTrigger:
name: ${self:service}-${self:custom.environment}
description: lambda_trigger
handler: handler.lambda_handler
tags:
project: ""
owner: ""
environment: ${self:custom.environment}
events:
- existingS3:
bucket: ${self:custom.listener_bucket_name}
event: s3:ObjectCreated:*
rules:
- prefix: ${self:custom.listener_prefix}
- suffix: ${self:custom.listener_suffix}
my user is requesting that lambda only be triggered when file is of
/ID1_ID2_ID3.tar
I have handled the prefix and the suffix condition in the above function, but I am wondering how or even if it is possible to construct a new rule to only be triggered when file has the format of ID1_ID2_ID3 where each id N integers.
According to the docs, an earlier question and my own experience in the matter, prefix and suffix parameters cannot be wildcard or regular expressions, so I'm affraid that unless you find some clever way to circunvent the restriction it's not possible to do what you want.