It was 9:47 AM on a Tuesday when our VP of Sales walked into the engineering room with that look. You know the one. The "we have a problem" look mixed with "and you're going to fix it" energy. "Enterprise deal. $2.3 million ARR. They need SOC 2. We have six weeks." I remember staring at my coffee, watching the steam rise, thinking about all the traditional compliance projects I'd seen drag on for six, nine, twelve months. Consultants billing $400 an hour to tell you what you already know. Endless documentation. Security theater. But here's the thing – we'd been building our entire platform on serverless from day one, and I had this nagging suspicion that maybe, just maybe, we could use that to our advantage. Spoiler: We did. And it changed how I think about security architecture forever. The "Oh Shit" Moment That Led to Zero Trust Three days into our SOC 2 preparation, our security consultant (Amy, a brilliant woman, zero patience for bullshit) asked us a simple question during our initial assessment: Amy: "Walk me through how your Lambda functions authenticate with each other." Amy: Me: "Well, we have this shared API key in Secrets Manager that—" Me: Amy: "Stop. Just... stop." Amy: She pulled up her laptop and showed me the SOC 2 control requirements around access management. Then she showed me our current architecture diagram. Then she just looked at me. That silence lasted maybe five seconds, but it felt like an hour. Because I knew she was right. We'd built a distributed system where every service trusted every other service. One compromised Lambda function meant potential access to everything. Classic castle-and-moat security thinking, dressed up in serverless clothes. That night, I couldn't sleep. I kept thinking about what real zero trust would look like in a serverless world. No shared secrets. No implicit trust. Every request is authenticated and authorized, even between our own services. By 3 AM, I had the basic architecture sketched out on my iPad. By 6 AM, I was in the office testing the first prototype. The Architecture: Trust Nothing, Verify Everything Here's what we built, and I'm going to be honest about what worked and what was harder than I expected. Core Principle 1: No Shared Secrets, Ever Every Lambda function has its own IAM role. Not one role for "backend services" – I mean every single function. Our user authentication function? Its own role. The function that processes payments? Separate role. The one that sends emails? You guessed it. At first, this felt like overkill. We went from 4 IAM roles to 37 in the first week. But here's what happened: when the auditors asked, "What can your payment processing function access?" I could pull up exactly one IAM policy and show them. Not a shared policy with asterisks and conditions. Not "well, technically it has access to X, but we don't use it." Just the three specific resources that function needed. The auditor literally said, "Oh. That's... actually perfect." Core Principle 2: SigV4 for Everything This was the part that took me the longest to wrap my head around, but once I got it, everything clicked. AWS Signature Version 4 (SigV4) is how the AWS SDK signs requests to AWS services. Every API call to DynamoDB, S3, Lambda – they all use SigV4. So we said: if it's good enough for AWS's internal authentication, why not use it for our service-to-service communication? When Lambda A needs to call Lambda B, it doesn't send an API key. It signs the request using SigV4, just like it would if it were calling DynamoDB. Lambda B validates that signature using IAM, checks the caller's identity, and either allows or denies the request based on the IAM policy. Zero secrets to rotate. Zero keys to leak. Zero "oh shit, that key was committed to GitHub" moments. // Lambda B - Validation Handler 
const AWS = require('aws-sdk');
exports.handler = async (event) => {
    // Extract caller ARN from Lambda context 
    const callerArn = event.requestContext.identity.userArn;
    // Policy: Only lambda-a-role can invoke this 
    const allowedRoles = ['arn:aws:iam::ACCOUNT:role/lambda-a-role'];
    if (!allowedRoles.includes(callerArn)) {
        return {
            statusCode: 403,
            body: JSON.stringify({
                error: 'Unauthorized caller',
                caller: callerArn
            })
        };
    }
    // Proceed with actual logic 
    return processRequest(event);
}; // Lambda B - Validation Handler 
const AWS = require('aws-sdk');
exports.handler = async (event) => {
    // Extract caller ARN from Lambda context 
    const callerArn = event.requestContext.identity.userArn;
    // Policy: Only lambda-a-role can invoke this 
    const allowedRoles = ['arn:aws:iam::ACCOUNT:role/lambda-a-role'];
    if (!allowedRoles.includes(callerArn)) {
        return {
            statusCode: 403,
            body: JSON.stringify({
                error: 'Unauthorized caller',
                caller: callerArn
            })
        };
    }
    // Proceed with actual logic 
    return processRequest(event);
}; Core Principle 3: VPC Endpoints for Data Services This one surprised me with how much the auditors cared about it. We set up VPC endpoints for every AWS service our Lambdas touched: DynamoDB, S3, KMS, Secrets Manager (for the few actual secrets we had, like third-party API keys). Traffic never left the AWS network. No internet gateway. No NAT gateway. Cost impact? $23/month for all endpoints combined. Security impact? Massive. The auditors spent maybe five minutes on this section because it was so straightforward. What The Auditors Actually Asked Us Let me share the real questions from our SOC 2 audit, because this is the stuff nobody talks about. These aren't theoretical security theater questions – these are what actual auditors care about. Real Audit Questions & Our Answers Q: "How do you prevent lateral movement if one Lambda is compromised?" Q: "How do you prevent lateral movement if one Lambda is compromised?" A: Pulled up Lambda A's IAM policy. It can invoke exactly two other Lambdas. That's it. Can't touch S3, can't touch DynamoDB, can't invoke any other functions. We showed them the IAM policy simulator results. Q: "Show me your secrets rotation process." Q: "Show me your secrets rotation process." A: "We don't have one. We don't have secrets to rotate." That stopped the conversation. We explained SigV4, showed them the code, and demonstrated a function call. They tested it themselves by trying to invoke a function without proper IAM credentials. Instant 403. Q: "How do you audit inter-service communication?" Q: "How do you audit inter-service communication?" A: CloudTrail logs every Lambda invocation with the caller's ARN. We built a simple Lambda that queries CloudTrail and generates a graph of which services talk to which. Real-time service dependency mapping, basically free. The Timeline: 6 Weeks, Broken Down People always ask "how did you really do it in 6 weeks?" Here's the honest timeline, including the parts that sucked. Week 1: Architecture redesign & initial implementation Week 1: Architecture redesign & initial implementation Threw away shared API keys, rebuilt IAM role structure, implemented SigV4 auth between services. Broke everything twice. Fixed it once. Learned that Lambda-to-Lambda IAM permissions are weird. 73 hours of work, mostly nights. Week 2: VPC migration & endpoint configuration Week 2: VPC migration & endpoint configuration Moved all Lambdas into VPC. Set up VPC endpoints. Discovered that cold starts in VPC suck. Optimized with provisioned concurrency for critical functions. Cost went from $412/month to $847/month (worth it). Had a mini panic attack about the cold start latency. Week 3: CloudTrail & monitoring setup Week 3: CloudTrail & monitoring setup Configured CloudTrail for everything. Set up EventBridge rules for suspicious patterns. Built automated alerts for weird IAM activity. Tested by intentionally creating violations. Got woken up at 2 AM by our own alerts. Success? Week 4: Documentation & policy writing Week 4: Documentation & policy writing The boring part. Access control policies, incident response procedures, change management docs. Amy (our consultant) reviewed everything, found 12 gaps, we fixed them. This week felt like it lasted a month. Week 5: Pre-audit testing & mock scenarios Week 5: Pre-audit testing & mock scenarios Amy ran mock audit sessions. We failed the first two. Fixed the issues. Passed the third. Built automated tests for critical controls. Realized we'd forgotten about change management for IAM policies. Scrambled to fix that. Week 6: Actual SOC 2 audit Week 6: Actual SOC 2 audit Three days of intensive questioning. Two auditors, 47 controls tested. We passed 45 on the first try. The two failures were documentation issues (missing dates on two policies), not architecture problems. Fixed in 3 hours. Final report: zero technical findings. The Numbers That Made My Vice President Happy Compare that to what we quoted for a traditional approach: 4-6 months timeline, $120K+ in consulting fees, another $3-4K/month in infrastructure for separate security zones and bastions. The serverless zero-trust architecture wasn't just faster – it was 76% cheaper upfront and 82% cheaper to maintain. What Actually Sucked (Being Honest Here) Let's talk about the problems, because if I only share the wins, this becomes worthless marketing material instead of something useful. VPC Cold Starts: Moving Lambdas into VPC killed our cold start times. Went from 200ms to 8-12 seconds. We fixed it with provisioned concurrency for our hot path functions, but that added $280/month to our bill. Still worth it, but painful. VPC Cold Starts: IAM Policy Hell: Managing 37+ IAM roles is not fun. We built a Python script that generates policies from a YAML config file, but even that gets messy. If I were doing this again, I'd invest in proper infrastructure-as-code from day one. We ended up using Terraform later, which helped. IAM Policy Hell: Testing SigV4 Auth: Unit testing Lambda-to-Lambda calls with SigV4 was harder than expected. We ended up building a small test harness that could mock IAM credentials, but the first three weeks we just... didn't test it well. Found bugs in production. Not proud of that. Testing SigV4 Auth: The Learning Curve: None of our junior engineers had worked with SigV4 before. Training took time. Writing good documentation took more time. Six months later, we're still finding edge cases. The Learning Curve: Would I Do It Again? Absolutely. Without hesitation. We closed that $2.3M deal. Then we closed three more enterprise deals in the next quarter, all because we had SOC 2 ready to go. The ROI on those six weeks was ridiculous. But more than that, I sleep better now. I'm not worried about some developer accidentally committing an API key to GitHub. I'm not stressed about rotating secrets across 30+ services. I don't have recurring nightmares about lateral movement attacks. The architecture just... works. It's elegant in a way that most security solutions aren't. It's serverless done right – not just "we use Lambda" but "we've rethought security for an event-driven, ephemeral world." Two months ago, we had a security researcher reach out through our bug bounty program. They'd found a theoretical vulnerability in one of our public APIs. We fixed it in 4 hours by updating a single IAM policy. No code changes. No deployment. Just tightened the permissions on one Lambda role. That's when I knew we'd built something special. Key Takeaways If you're building on serverless and thinking about compliance, here's what I'd tell my past self: Start with zero trust from day one. It's so much harder to retrofit security than to build it in. We got lucky that we were still small enough to refactor everything in a week. Start with zero trust from day one. IAM roles are free, use them. The mental overhead of managing multiple roles is real, but it's nothing compared to the security and audit benefits. Plus, tools like Terraform make it manageable. IAM roles are free, use them. SigV4 is your friend. Yes, it's AWS-specific. Yes, it locks you into AWS a bit more. But if you're already all-in on Lambda, the security and simplicity benefits are worth it. SigV4 is your friend. VPC endpoints are cheap insurance. $23/month to never worry about data exfiltration over the internet? Take that deal every time. VPC endpoints are cheap insurance. Document as you build. We saved so much time in week 4 because we'd been documenting our decisions and architecture all along. Future you will thank present you. Document as you build. And most importantly: SOC 2 doesn't have to take forever. If you have the right architecture and you're willing to hustle, six weeks is totally doable. We proved it. SOC 2 doesn't have to take forever. Now if you'll excuse me, I have a $3.1M renewal to celebrate. Zero-trust serverless for the win.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Terra

A $2.3M Deal, a Six-Week Deadline, and the Serverless Architecture That Saved Us

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Building an Active-Active AWS Architecture for $47 a Month

10 Things in Engineering We Don't Spend Enough Time On

254 Stories To Learn About Amazon

193 Stories To Learn About AWS Lambda

17 of the Best Amazon Web Services (AWS) for Web Developers to Learn

3 Min Hack for Locally building a Native Extension

Building an Active-Active AWS Architecture for $47 a Month

10 Things in Engineering We Don't Spend Enough Time On

254 Stories To Learn About Amazon

193 Stories To Learn About AWS Lambda

17 of the Best Amazon Web Services (AWS) for Web Developers to Learn

3 Min Hack for Locally building a Native Extension

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps