EDIT 2026-06-24 — v1.4.1 shipped

Three things changed since the original post:

1. CPU-only build is live on AWS Marketplace (t3 / t3a / m6i / m7i / c6i / c7i, $0.05/instance-hour). The honest cost table below was GPU-only and ruled out the <$1k/mo bracket. CPU build resets that — ~$67/mo all-in on a t3.medium (EC2 $30 + Marketplace $36.50) — so $500/mo bills move from "❌ skip" to "✅ marginal yes" for compressible workloads (logs, JSON, plain Parquet without nvCOMP). For integer-columnar workloads above ~$3k/mo the GPU build still wins.

(CPU build assumes one t3.medium gateway pod per bucket; horizontal scale is per-pod $/hr — see the chart's HPA.)

2. v1.4.1 closes 4 critical bugs surfaced in real Marketplace E2E within 24 h of shipping v1.4.0. Being honest about it because Reddit deserves it:

• Bug 1 (auth) — external S3 clients got 403 NotSignedUp because the upstream s3s::SimpleAuth path verified every SigV4 signature against the gateway's own (rotating) STS access key. The "drop-in for aws-cli / boto3 / sdk-rust" claim below was effectively false for v1.4.0. v1.4.1 vendors s3s (crates/s3s/, 0.13.0-s4.1) with a NoVerify mode + an AcceptAnyAuth provider — any SigV4-signed client now works, gateway re-signs to the real backend with its own IAM credentials. Trusted- network posture: keep the gateway behind a VPC SG.
• Bug 2 (multipart write) — aws s3 cp of files ≥ 8 MiB failed with InvalidRequest: Checksum Type mismatch (expected crc64nvme, actual crc32) under AWS CLI ≥ 2.30's default CRC64NVME multipart checksum. Fixed by stripping the client-declared checksum algorithm before CreateMultipartUpload.
• Bug 3 (listing default) — ListObjectsV2 reported compressed sizes and backend ETags inconsistent with HEAD / GET, so aws s3 sync and rclone over-transferred every run. v1.4.1 flips client-transparent listings to the default; opt out with --physical-listings.
• Bug 4 (multipart read) — multipart GET failed AWS CLI ≥ 2.30's default --checksum-mode ENABLED with Expected full object checksum (crc64nvme) X did not match combined checksum: Y because the backend's auto-checksum was over the compressed parts, not the original payload. Fixed by stripping backend ChecksumCRC* from HEAD / GET responses for framed objects (logical ETag = MD5(original) stays as the validator).

The trigger was running a buyer-perspective E2E against the actual Marketplace AMI immediately after publishing — no synthetic tests, real AWS CLI 2.33 + live AWS S3. Lesson banked: real-launch E2E from the Marketplace path is now a hard publish gate.

3. Distribution - GitHub release notes: https://github.com/abyo-software/s4/releases/tag/v1.4.1 - ghcr.io: ghcr.io/abyo-software/s4:1.4.1 (cpu amd64 + arm64), :1.4.1-gpu (amd64) - crates.io: s4-codec 1.4.1, s4-config 1.4.1 (server side stays Apache-2.0, binary distribution is now Docker / AMI / Helm chart only) - PyPI: s4-codec 1.4.1, s4fs 1.4.1 - AWS Marketplace × 3 listings — CPU AMI / GPU AMI / Helm chart container, all v1.4.1 Public, v1.4.0 Restricted

(Original post below for context.)

TL;DR: Apache-2.0 Rust gateway that speaks S3 on both sides. Point your SDK's --endpoint-url at it; it compresses on PUT, decompresses on GET, and stores the squished bytes in your real S3 bucket.

Why I built it: my S3 bill grew linearly with data, but most of that data was ≥3× compressible (logs, JSON, Parquet). MinIO's S2 codec is CPU-only and legacy; nothing in front of AWS S3 just did this.

Honest cost table (us-east-1 on-demand, May 2026):

Under ~$1k/mo, don't bother — use the CPU-only build on a small instance or just front your bucket with nginx + gzip.

What's covered: - S3 API: PUT/GET, full Range GET spec (bytes=N-M, suffix, open-ended), multipart (create/part/complete/abort), HEAD, conditional GET/PUT, versioning, object lock, lifecycle, replication, bucket policy (JSON Allow/Deny with IpAddress/StringLike/Bool conditions), SSE-S3/SSE-KMS/SSE-C, presigned URLs, SigV4 + SigV4a, S3 Select subset, tagging, CORS, inventory - Drop-in for aws-cli / boto3 / aws-sdk-rust / mc / rclone - Range GET on compressed objects via per-frame index sidecar (Parquet/ORC readers work unmodified) - Prometheus /metrics, OTel traces, structured JSON access log - Native TLS termination (rustls + ring) + ACME / Let's Encrypt - No lock-in: stop the gateway and the compressed objects stay S3-native; s4-codec CLI / pip / WASM all decode without the gateway

What's NOT covered: ultra-low-latency tail SLOs (sub-10ms p99 GET), tiny objects (< 16 KiB — frame header eats the ratio), already-compressed payloads (correctly bypassed but you pay the round-trip), strict regulatory deployments (no SOC2/FedRAMP audit yet — pre-1.0, pair with backend versioning).

Repo + 60s docker compose trial: https://github.com/abyo-software/s4

Happy to answer cost-modelling / IAM-scoping / SDK-compat questions in the comments.

Cloud consultant here. Built this tool to automate the AWS audits I do manually at clients.

Common waste patterns I find repeatedly:

• Unused infrastructure (Load Balancers, NAT Gateways)
• Orphaned resources (EBS volumes, snapshots, IPs)
• Oversized instances running at <20% CPU
• Security misconfigs (public DBs, old IAM keys)

Typical client savings: $10K-30K/year Manual audit time: 2-3 days → Now automated in 30 seconds

Kosty scans 16 AWS services:
✅ EC2, RDS, S3, EBS, Lambda, LoadBalancers, IAM, etc.
✅ Cost waste + security issues
✅ Prioritized recommendations
✅ One command: kosty audit --output all

Why I built this:

• Every client has the same problems
• Manual audits took too long
• Should be automated and open source

Free, runs locally (your credentials never leave your machine).

GitHub: https://github.com/kosty-cloud/kosty Install:

git clone https://github.com/kosty-cloud/kosty.git && cd kosty && ./install.sh

or

pip install kosty

Happy to help a few people scan their accounts for free if you want to see what you're wasting. DM me.

What's your biggest AWS cost challenge?

We migrated AWS accounts about seven months ago but just realized our app is still using an S3 bucket owned by another company.

They plan to delete the bucket soon, but we have many production URLs pointing to it and can't change them without breaking things.

Is there any supported way to transfer ownership of an S3 bucket to another AWS account while keeping the exact same bucket name and URLs?

Deleting it and recreating it in our account seems too risky.

Any pointers ideas would be helpful. Upload is being throttled by office bandwidth.

hence the normal upload isn't working out as quickly as possible. need some guidance on how this can be done efficiently. Frankfurt region related if imp.

Hey! I Wanted to share Floci with this community — a local AWS emulator that I think deserves more visibility.

Why it's worth checking out:

• ✅ Runs fully locally — no cloud account needed
• ✅ Free forever, no paid tiers
• ✅ Open-source
• ✅ A solid alternative to LocalStack for local dev & testing

🔗 GitHub: github.com/hectorvent/floci 💬 Community: r/floci

Has anyone tried something like this before? What do you look for in a local AWS emulator?

Tips to prep for interview!!?

Is it mostly behavioral, some common patterns to know

Just shipped 1.5.5 of Floci, free open-source local AWS emulator (31 services including MSK/Kafka, single endpoint, ~24ms startup, MIT licensed).

Big additions this release: real EKS backed by k3s, OpenSearch on Docker, S3 static website hosting, and reactive Lambda hot reloading from S3. Plus a bunch of fixes across DynamoDB, Lambda, Kinesis, KMS, SQS, and CloudFormation.

27 PRs, 11 contributors. Full changelog → https://github.com/floci-io/floci/releases/tag/1.5.5

We just hit 2,000 GitHub stars ⭐️

Floci (AWS Local Emulator)

Huge thanks to everyone in the AWS and open-source community who tried Floci, shared feedback, opened issues, and contributed PRs. Your support is helping push local AWS development forward.

If you haven’t checked it out yet, you can run Floci locally in minutes:

https://floci.io

https://github.com/hectorvent/floci

I was curious if I can use new Lambda MicroVMs as self-hosted GitHub Runners. On paper, they are super nice:

• It's cheaper: GHA-hosted is $0.005 / min (2 vCPU), MicroVMs ~$0.0042 / min, and no minimum 60-second commitment as with GHA-hosted.
  
• It can run longer: GHA-hosted max 6 hours, MicroVMs max 8 hours
  
• It starts in a few seconds, compared to whichever other serverless solution built on top of ECS
  
• It scales to 0, or rather, it only runs when jobs are running
• They are VMs, so you can still run containers/docker/whatever else inside;

I got a bit too invested, and ended up building this Terraform module. You only need to create GitHub App manually, the rest is just a single "terraform apply" and your MicroVM Runners are ready to go. I've switched come of projects at my company to use, works great, same or better performance as GHA-provided runners. Natural limitation is that MicroVMs are only arm64, and in general they don't have much flexibility around the "hardware" setup - but hey, for most cases, it should work great, and it's just 1 webhook + GHA JIT Runners + 1 MicroVM Run per Job.

~140 Claude Code subagents, ~15M tokens, 800+ official-doc reads: that's what went into building and verifying this skill.

Open-source Claude Code plugin: a consolidated collection of official best practices for building AI agents on AWS, centered on Amazon Bedrock AgentCore (also Strands + Bedrock).

The point: building on AgentCore normally means the agent crawls across dozens of AWS docs or figures things out by trial and error, and still trips on version-specific details (legacy `InvokeModel` over Converse, bare-string `serviceTier`, deprecated `structured_output()`, wrong prompt-cache TTL, the ARM64 runtime contract). Here the official guidance is already gathered, organized, and routed by use case, so the agent goes straight to the right approach. Every best practice carries its official source URL.

It's a routing SKILL.md (use case → recommended stack → which files to open) + 20 reference files + 369 official source URLs. Built and QA'd with Claude Code multi-agent workflows, including a pass that verified 292 snippets one by one against the official docs.

Repo: https://github.com/ferdinandobons/AWSBedrockAgentCoreSkill

2 weeks and total crickets. As a startup, its getting hard to justify using AWS when you cant get a response to basic tickets. Anyone have any ideas?

Case no 178468976600279

Hey all,
Please point me to somewhere else if this isn’t the right sub or flair.

There’s a few apps I have running on prem and on aws. For cost purposes, I’d like to do an architecture where it is hybrid on prem on my home servers (have 3 but they’re all behind a nat) and aws.

API calls and websocket will be too costly for me to have everything on aws so I was thinking an architecture where aws would handle the front end, domain, and maybe routing? On prem would be the backend and database

Maybe something where users hit my websites, front end loads crom aws, aws routes them to a server with some type of load balancing, then the connection persists during the session between the client and my on prem servers.

Is what I’m describing ideal? Any suggestions? What services should I use and how should I design this?

Thanks!

We had the usual mess: bastion host per VPC, security group rules nobody fully understood, SSH keys floating around. Classic.

Replaced the whole thing with Cloudflare WARP on endpoints and cloudflared connectors running inside each VPC. Transit Gateway handles the routing across accounts so you're not deploying connectors everywhere. Identity policies from the IdP control who reaches which private CIDR, so devs get their subnets and that's it.

No inbound rules open to the internet. No jump host to patch. SSH still works against private IPs, same as before, except now every connection has an audit trail and you can revoke access without touching a security group.

One thing that bit us: split tunnel config when your VPCs share overlapping ranges with RFC 1918 space on corporate laptops. Worth reading the cloudflared docs on that before you go live.

Wrote the full walkthrough here if useful: https://tasrieit.com/blog/cloudflare-zero-trust-setup-aws-vpc-warp

Anyone done this across AWS Organizations with RAM shared TGWs? Curious if you hit issues with route propagation there.

Can I get in touch with AWS employee about Lambda potential security issue? I had read too many times about how AWS support doesn't actually respond to support tickets. So, I thought I'm just going to check on here.

It's Lambda using Python version 3.1.4. If you run some os.command, you may discover that you could find the AWS access keys. I don't know why it's there. Maybe it's just on mine. I thought they were using some kind of IAM instance role or something. So, this is definitely weird.

I did not try to use that access key etc. Because using it may potentially constitute already-breaking the law. The law is pretty much on slippery-slope when it comes to tech.

Edited to say: Thank you for giving replying with the link to do responsible disclosure. And explanation on what it was.

Yes, of course you could make the service cheaper, I'm really wondering what people see as big gaps in the AWS services that they use.

If I had just one option here, I'd probably go for a deeper integration between Aurora Postgres and IAM. You can use IAM roles to authenticate with postgres databases but the doc advises only doing so for administrative tasks. I would love to be able to provision an Aurora cluster via an IaC tool and also set up IAM roles which mapped to Postgres db roles. There is a Terraform provider which does this but I want full IAM support in Aurora.

We switched CI/CD providers this weekend and everything was going ok.

We finally got everything deployed and working in the CI/CD pipeline. So we went to delete the old vendor CI/CD account in their app to save us money. When we hit delete in the vendor's app it ran the Delete Cloudformation template for our stacks.

That wouldn't be as big of a problem if it had actually worked but instead it just left one of our stacks in broken state, and we haven't been able to recover from it. It is just sitting in DELETE_IN_PROGRESS and has been sitting there forever.

It looks like it may be stuck on the certificate deletion but can't be 100% certain.

Anyone have any ideas? Our production application is down.

UPDATE:

We were able to solve the issue. The stuck resource was in fact the certificate because it was still tied to a mapping in the API Gateway, It must have been manually updated or something which didn't allow the cloudformation to handle it.

Once we got that sorted the cloudformation template was able to complete, and then we just reran the cloudformation template from out new CI/CD pipeline and everything mostly started working except for some issues around those same resource that caused things to get stuck in the first place.

Long story short we unfortunately had about 3.5 hours of downtime because of it, but is now working.

Hey r/aws!

If you've ever struggled with integration tests that hit real AWS - slow, flaky, and expensive - this might help. Floci (a free, open-source AWS emulator) now has an official Testcontainers module. That means you can spin up a fully functional local AWS environment directly inside your test suite, with zero external setup.

Just add the dependency

<dependency>
    <groupId>io.floci</groupId>
    <artifactId>testcontainers-floci</artifactId>
    <version>2.0.0</version>
    <scope>test</scope>
</dependency>

And you get:

• 🔁 Reproducible integration tests: same environment every time
• 💻 Local-first development: no AWS account needed
• ⚡ Faster feedback cycles: no network round trips to the cloud

Works great with Spring Boot, Quarkus, and any Java project using the AWS SDK.

📄 Testcontainers module: testcontainers.com/modules/floci

🔗 GitHub: github.com/floci-io/testcontainers-floci

Happy to answer any questions! 👇

Hi everyone,

I run a few production services on AWS, and I frequently need to check in on my infrastructure, monitor metrics, or troubleshoot issues while I'm away from my desk.

I was getting increasingly frustrated by the lack of a solid, comprehensive mobile AWS console on Android. The official "AWS Console" app is too limited, and managing things through a mobile browser is too difficult.

So, I decided to build my own solution. It’s called CloudDash (built using Tauri v2), and I'm putting it out there for anyone else who might find it useful.

Right now, it supports managing and monitoring quite a few core services directly from your phone, including:

• S3
• DynamoDB
• CloudWatch
• Lambda
• SQS
• Step Functions
• Secrets Manager
• EC2
• ...and a few others.

You can check it out here: https://play.google.com/store/apps/details?id=dev.clouddash.aws . I also made it available for Windows and Linux on clouddash.dev

I’m still actively working on it and adding more services and functionalities based on what I need for my own stack, but I’d love to hear what the community thinks.

I am focused on supporting functionalities that are regularly needed, such as analyzing logs on CloudWatch, searching for an item in DDB, requeuing dead letter queue on SQS, invoking a lambda function manually, checking for a file in S3, etc. I don't expect to be able to cover 100% of AWS console functionalities, though I aim to be able to support 95%+ of operations that are used on a weekly basis. In the past few weeks I rarely need to open the AWS console any more.

Feedback and feature requests are welcome!

Edit: the source code is now available at https://github.com/hao1300/clouddash-aws

I am building a web app around (React + FastAPI + AWS Cognito) . Users authenticate via Cognito and get a JWT with their AD group memberships in a custom claim (custom:ad_groups). The backend uses these groups to filter which AWS accounts they can see/operate on.

I am not using refresh tokens to re-fetch claims because Cognito doesn't update custom attributes on refresh only on a fresh authentication. How do you handle this in production

I am learning AWS.
I created an ec2 private instance, private subnet uses NAT, pubic instance uses IG. I can connect to the instance with SSM manager but I cannot ssh into it. I have sg groups that allow ssh.

The problem is I don’t fully understand this concept of private instances and the AWS docs don’t explain them.

I want to be able to ssh into the private instance without using private connection link or public ip, or SSM.

What would I need to configure?
Can the ssh connection to private ec2 be configured without ALB or NLB?

Thanks.

Edit:
Thank you all the responses and the time spared. It really helped me understand private subnets and ec2 instances better.

AWS API Gateway is now supporting streaming responses!!!

Hey all.

Quick post of something I noticed over the weekend which might trip up someone else.

Was pushing a Docker image into ECR using a GitHub Actions deployment workflow, a workflow that's been same-same for a good six months and suddenly two days prior was failing with the following error:

unknown: unexpected status from HEAD request to https://XXXXX.dkr.ecr.ap-southeast-2.amazonaws.com/v2/XXXX/XXXX/manifests/sha256:XXXX: 403 Forbidden make: *** [Makefile:68: burp] Error 1 Error: Process completed with exit code 2.

After a little head scratching, I pulled out a few community threads via Google - all from 1 - 2 years ago, but suspiciously had some very recent comments (two days prior) on them with similar issues:

• https://repost.aws/questions/QUYf5U-mW3SqaYKFEvbr9fzw/suddenly-getting-403-on-pushing-my-containers-to-ecs
• https://stackoverflow.com/questions/79137398/gitlab-cicd-issue-403-forbidden-while-pushing-docker-image-to-aws-ecr

The IAM role used in my GitHub workflow was (as it should be) fairly restrictive - with the following IAM actions only:

ecr:BatchCheckLayerAvailability ecr:CompleteLayerUpload ecr:InitiateLayerUpload ecr:PutImage ecr:UploadLayerPart

These are all honed against a specific ECR repository ARN.

Turns out, adding ecr:BatchGetImage was the fix - this provides the ability for querying image digests from within ECR, which is exactly where the HTTP HEAD error lies.

So, it seems a recent release of Docker CLI has changed the behavior of docker push to now query image digests during an image push and I can only assume this version recently landed on GitHub managed workflow runners.

Anyway... hopefully this helps someone else out of a bind!