Two constraints that platform teams had designed around for a decade disappeared in the week of 13 July. S3 dropped the 30-day wait before an object may move from S3 Standard to Standard-IA or One Zone-IA, and Lambda stopped copying your deployment package into its own storage, which removes the code storage quota and shortens activation after a deploy. A third change is smaller but matters to anyone consolidating identity: Cognito can now import users with their existing password hashes, so a migration from another identity provider no longer forces a password reset on every user. On the AI side, OpenAI's GPT-5.6 Sol, Terra, and Luna went GA on Bedrock.

No migration or modernization launch landed in this window beyond the Cognito change, so the post is shorter than last week's. It is still a week with a theme: AWS removed limits that existed for AWS's convenience rather than yours.

S3: Infrequent Access on day zero

Until 16 July a lifecycle rule could not transition an object to S3 Standard-IA or One Zone-IA until it had sat in S3 Standard for 30 days. Now the rule can say 0 days, and the transition happens as soon as the day the object is created. AWS pitches it for backups, log analytics, and compliance data that go cold within hours, and the storage rate for the IA classes is up to 40% below S3 Standard with the same millisecond access.

Read the transition considerations before you change every rule to zero, because the things that made IA expensive for the wrong workload are untouched. Objects under 128 KB do not transition by default, and you pay a transition request per object either way, so a bucket of small log fragments gets more expensive, not less. The IA classes keep their minimum storage duration charge, so an object you write, tier on day zero, and delete on day three is billed as if it stayed. And IA charges per GB retrieved, which is what turns "cold" data into a surprise when a reprocessing job reads it all back. A concrete rule for a backup prefix looks like this:

{
  "Rules": [{
    "ID": "backups-to-ia-day-zero",
    "Status": "Enabled",
    "Filter": { "Prefix": "backups/" },
    "Transitions": [{ "Days": 0, "StorageClass": "STANDARD_IA" }]
  }]
}

The right workload is data that is written once, read rarely, and kept past the minimum duration. Backups and compliance archives qualify. Application logs you tail for a week do not, and S3 Intelligent-Tiering already handled the "I do not know" case without the retrieval fee.

Lambda: your bucket is the source of truth

Lambda used to copy every deployment package into Lambda-managed storage when you created or updated a function or layer. That copy was what the 75 GB per-Region code storage quota counted, and it was a step in the critical path of every deploy. From 15 July you can set S3ObjectStorageMode to REFERENCE on a function or layer and Lambda reads the code from your bucket instead. Referenced code does not count against the quota, the managed quota itself rose from 75 GB to 300 GB for everyone else, there is no added Lambda charge, and you pay S3 storage plus cross-Region transfer where it applies. The Lambda service principal needs s3:GetObject and s3:GetObjectVersion on the bucket.

The trade-off is that you now own an availability dependency you did not have. If the bucket's object is deleted, overwritten, or its policy breaks, that is a Lambda incident. Versioning on the bucket stops being optional, the deployment pipeline must write new keys rather than overwrite, and the bucket policy needs the same change-control as the function's IAM role. Teams with hundreds of functions and layers, where the 75 GB quota meant a support ticket every quarter, get the most from this. A team with twenty functions should ask whether the faster activation is worth another thing that can be misconfigured.

Cognito: the migration that no longer resets passwords

Moving a user base into Cognito via CSV import has always had one ugly moment: every imported user had to reset their password on first sign-in, because Cognito could not accept hashes from the source system. From 15 July the CSV can carry the hashes, you declare the algorithm, and Cognito verifies the user's password against the imported hash at first sign-in, then re-protects it. Supported: bcrypt, scrypt, Argon2id, and PBKDF2 with SHA-256, in every Region where Cognito runs.

This is the kind of change that decides whether a consolidation project happens. The forced reset was the reason many teams kept a legacy IdP alive in parallel for a year, with the migration trigger on first login. Now the cutover can be a single import. The failure mode is the hash export itself: the source system has to give you the algorithm parameters exactly, and a mismatch does not fail loudly, it fails as "wrong password" for the whole user base at once. Test with a sample that includes users on every historical hashing configuration the old system ever used.

Also this week

The throughline

The 30-day S3 rule and the Lambda code copy were both artifacts of how AWS built the service, not of what customers needed. Both were worked around with tooling: Intelligent-Tiering for the first, layer-pruning scripts and quota tickets for the second. Removing them is good, and it is also a reminder of what the workaround was hiding. Day-zero IA exposes the retrieval and minimum-duration pricing that the 30-day wait kept most people from hitting. Referenced code exposes your bucket as a runtime dependency. Cognito's hash import removes the forced reset and exposes the quality of your old IdP's export. In each case AWS handed back a decision it used to make for you.

Read this next

For the AI and agent reading of the same weeks, the field notes live at ercan.ai. Consulting on AWS, cloud, CI/CD pipelines, Linux, GitHub/GitLab, and more runs through ercanermis.com.

References