TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities and articles.
Top engineers at Anthropic and OpenAI say AI now writes 100% of their code.
If you're not using AI, you're spending 40 hours doing what they do in 4.
These 100+ Claude Code hacks fix that and help you ship 10x faster.
Sign up for The Code and get:
100+ Claude Code hacks used by top engineers — free
The Code newsletter — learn the latest AI tools, tips, and skills to code faster with AI in 5 minutes a day
IN TODAY'S EDITION
🧠 Use Case
How AWS Signed URLs Works Internally
👀 Remote Jobs
VRChat is hiring a Senior/Staff Platform Engineer
Remote Location: Worldwide
Wikimedia is hiring a Senior Site Reliability Engineer
Remote Location: Worldwide
Powered by: Jobsurface.com
📚 Resources
If you’re not a subscriber, here’s what you missed last week.
To receive all the full articles and support TechOps Examples, consider subscribing:
🛠 TOOL OF THE DAY
semgrep - A fast, open-source, static analysis tool that searches code, finds bugs, and enforces secure guardrails and coding standards.
Supports 30+ languages and can run in an IDE, as a pre-commit check, and as part of CI/CD workflows.
🧠 USE CASE
How AWS Signed URLs Works Internally
S3 buckets holding private content and CloudFront distributions serving restricted media both face the same problem. You need to give a specific user temporary access to a specific file without making the file public.
You cannot share the S3 URL directly. If the bucket is private, the request will be denied.
You cannot open the bucket to the public that exposes everything to everyone.
The solution in both cases is a signed URL: a time limited, cryptographically verified URL that grants access to exactly one resource for exactly as long as you specify.
AWS offers two different signed URL mechanisms.
S3 Pre-Signed URLs are generated and verified entirely within S3.
CloudFront Signed URLs are generated by your application and verified by CloudFront at its edge locations.
How the Signing Works Cryptographically
A signed URL is a regular URL with additional query parameters appended to it. Those parameters encode who is making the request, what resource they are accessing, and when the permission expires. The URL also carries a signature, a cryptographic hash generated using a secret key that only AWS and your application know.
When the signed URL is presented to AWS, the service recomputes the expected signature from the request parameters using the same key. If the computed signature matches the one in the URL, the request is valid. If the URL has been tampered with the expiry extended, the resource path changed or the signature no longer matches and the request is rejected. The client cannot forge or modify a signed URL without access to the signing key, because any change to the URL invalidates the signature.
S3 Pre-Signed URLs
An S3 Pre-Signed URL grants temporary access to a private S3 object. It is generated by your application using AWS credentials that have permission to access that object. The URL itself encodes the bucket, object key, HTTP method, expiry timestamp, and a signature computed using HMAC-SHA256 against those parameters with your AWS secret key.
When the client presents the pre-signed URL to S3, S3 recomputes the signature using the same parameters and the credentials associated with the access key ID embedded in the URL. If they match and the expiry has not passed, S3 serves the object directly to the client. The client never needs AWS credentials of their own. The signing happens server-side before the URL is handed to the client.
In the flow shown, Lambda handles the URL generation step. The application receives the client's request for file access, calls Lambda, Lambda uses its IAM role to call the S3 SDK's presign operation, S3 returns the pre-signed URL to Lambda, and Lambda passes it back through the chain to the client. The client then uses that URL to fetch the object from S3 directly. The application server is out of the content delivery path entirely, the client talks to S3 without routing through the application.
Pre-signed URLs can be generated for GET requests to download objects, PUT requests to upload directly to S3, and other S3 operations. The method is baked into the signature, so a URL generated for GET cannot be used for PUT. Expiry is set at generation time and is typically between a few minutes and several hours depending on the use case. There is no way to revoke a pre-signed URL before it expires except by deleting the object or rotating the signing credentials.
CloudFront Signed URLs
A CloudFront Signed URL controls access to content served through a CloudFront distribution, not directly through S3. The content source behind CloudFront can be S3, an EC2 origin, a load balancer, or any other HTTP origin. The signing mechanism does not care about the origin type.
CloudFront Signed URLs are signed using RSA-SHA1 with a CloudFront key pair. The key pair is created in the AWS console and associated with a trusted signer, either your root account or a CloudFront key group. Your application holds the private key and uses it to sign the URL. CloudFront holds the corresponding public key at its edge locations and uses it to verify the signature when the client presents the URL.
In the flow shown, the client requests content from the application, the application constructs a signed URL pointing to the CloudFront distribution domain, and returns it to the client. The client uses the signed URL to request the content from CloudFront. CloudFront's edge location verifies the signature using the public key it holds, checks the expiry, and if both checks pass, serves the content from its cache or fetches it from the EC2 origin. The content flows from the edge location directly to the client.
CloudFront Signed URLs also support a more expressive access control mechanism called a custom policy, which allows you to restrict access by IP address range in addition to expiry. A canned policy restricts by expiry only. A custom policy can additionally limit which IP addresses the URL is valid for, which is useful for enterprise scenarios where you know the client's network.
In Short..
Use S3 Pre-Signed URLs when clients need direct access to S3 objects without CloudFront, and when you need upload support via presigned PUT requests.
Use CloudFront Signed URLs when content is served through CloudFront and you need per user, time limited access with edge level validation and CDN caching benefits.
THE CODE - Learn how to code faster with AI in 5 mins a day. Loved by 300k+ devs, engineers at Meta, Google, OpenAI, and more.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Looking to promote your company, product, service, or event to 49,000+ DevOps and Cloud Professionals? Let's work together.
