Letra Chica — What changed in the fine print

[Fixed] [AWS] CloudTrail creates the organization trail in member accounts even if the bucket or key validation fails

2026-10-24T00:00:00Z

CloudTrail creates the organization trail in member accounts even if a resource validation fails; the documentation gives an incorrect bucket policy and insufficient permissions to encrypt with a KMS key as examples. A successful apply doesn't prove there is delivery. Check get-trail-status: if there is a problem with the bucket, the LatestDeliveryError field shows the S3 error (it only appears for problems with the destination bucket, not for requests that time out). Fix it with the bucket policy, or by creating another bucket and calling update-trail.

[Fixed] [AWS] In the official example, an organization trail's bucket policy needs its own statement and the logs are accessible only to management

2026-10-24T00:00:00Z

Scope of the source: the official example is a bucket owned by the organization's management account; the documentation doesn't cover a bucket in another account (such as this module's log archive account), so test it in a non-production environment. The bucket of an organization trail needs a policy that lets CloudTrail write the organization's logs: the official example has three statements (GetBucketAcl, PutObject on the management account prefix and PutObject on the AWSLogs/o-<organization id>/ prefix). The aws:SourceArn must be the ARN of a trail owned by the management account, using that account's ID. That policy doesn't give access to users in member accounts: by default, the organization's log files are accessible only to the management account. List explicitly who you want to grant read access to and don't assume member accounts can read.

[Fixed] [AWS] If a multi-Region trail's home Region is opt-in, only accounts that enabled that Region send activity

2026-10-24T00:00:00Z

If the organization trail is multi-Region and its home Region is an opt-in Region, member accounts don't send activity to the trail unless they opt into that Region; the documentation's example is Europe (Spain): only accounts that enabled it send their activity. Organization trails created in the console are multi-Region. Choose a Region that is enabled by default as the home Region, or verify that each account enabled the Region; if an account doesn't show up in the bucket, check this point.

[Fixed] [AWS] A misconfigured trail retries delivery for 30 days and those attempts are charged

2026-10-24T00:00:00Z

If the trail is misconfigured (for example, the bucket is unreachable), CloudTrail attempts to redeliver the log files to the bucket for 30 days, and those delivery attempts are subject to standard CloudTrail charges. To avoid charges on a misconfigured trail you need to delete it. Fix the bucket policy and the key policy before creating the trail (in Terraform, with a depends_on of the trail on both) and check get-trail-status afterwards.

[Fixed] [AWS] Test SCPs and RCPs in an OU or test accounts before moving up to the root; removing FullAWSAccess without a replacement cuts all actions

2026-10-24T00:00:00Z

AWS strongly recommends not attaching an SCP to the root without testing its impact on the accounts: create an OU and move accounts into it one at a time, or in small groups, so you don't lock anyone out of key services. For RCPs it recommends starting with test accounts, moving up through the OUs and reviewing CloudTrail for Access Denied errors. Also, don't remove the FullAWSAccess policy without modifying it or replacing it with another that has the allowed actions: otherwise all AWS actions from member accounts fail. For an S3 policy, after each change check the effective policy of representative accounts with DescribeEffectivePolicy.

[Fixed] [Azure] With Private Link to storage, a container without anonymous access requires authorized requests, for example with SAS

2026-10-24T00:00:00Z

Front Door's guide for a Storage origin says that if the blob or container doesn't permit anonymous access, requests against it must be authorized, for example with shared access signatures, and lists as a common mistake not using SAS against an account that doesn't allow anonymous access. According to the same guide, public internet access to the account is disabled once the private endpoint is enabled. ~~So you have to choose:~~If athe container ~~with anonymous~~doesn't ~~blob~~permit ~~read,~~anonymous ~~reachable~~access, ~~only~~don't ~~through~~connect the ~~private endpoint, or SAS on requests. Decide explicitly and~~origin ~~don't~~without ~~leave~~authorizing the ~~container private without SAS.~~requests.

[Fixed] [GCP] If the bucket stays public, signed URLs don't protect the content

2026-10-24T00:00:00Z

For signed URLs to protect the content, the origin must not grant public access: the documentation says to remove the allUsers (and allAuthenticatedUsers, if applicable) read permissions from the bucket, which is commonly left public during testing. Even without public access, anyone who already has permission on the bucket, such as OWNER, can access Cloud Storage without a signed URL. And a signed URL gives time-limited access to anyone who holds it, whether or not they have a Google Account. The same page warns that Cloud CDN doesn't block requests without a Signature query parameter or Cloud-CDN-Cookie cookie (it rejects those with invalid parameters) and that the origin must validate signatures and accept or reject unsigned requests. Check that the bucket has neither allUsers nor allAuthenticatedUsers before calling the entry closed, and sign only HTTPS URLs.

[New] [Azure] The Activity Log is deleted after 90 days; to keep it longer you have to export it with a diagnostic setting

2026-10-24T00:00:00Z

Azure Monitor collects the Activity Log with no configuration, but it retains events for 90 days and then deletes them. To keep them longer you have to create a diagnostic setting that sends them to another destination (a Log Analytics workspace, a storage account or Event Hubs). It matters for one specific reason: the Activity Log is the only place that stores who created a resource. If you were already exporting with log profiles (the legacy method), disable that configuration when you create the diagnostic setting.