I took a different approach. I built projects that forced me to understand the services deeply, not just what they do, but why you’d choose them, what breaks under load, and how the pieces connect. I passed the SAA-C03 and could talk confidently in interviews about real implementations. Here are the 5 projects I recommend.

Sponsored by Salesforce

Cross-Platform Consistency with Agentforce AXL

If you’ve ever tried to maintain brand and logic parity for an AI agent across Slack, web, and mobile, you know the pain. Enter the Agentforce Experience Layer (AXL). This new abstraction layer allows you to define agent logic and UI components once and have them render natively across any surface—including third-party platforms like Microsoft Teams.

Stream the AXL Orchestration Session

Watch the developer conference of the year. On demand on Salesforce+

Agentic AI is changing the game and Agentforce is leading the way. Watch TDX on demand to explore dozens of sessions covering the latest innovations across Agentforce, Data 360, the core platform, vibe coding, Slack, and more. All free on Salesforce+.

Watch TDX on Salesforce+ to:

• Get roadmap insights from the leaders shaping what’s next

• Access broadcast-only moments and exclusive interviews

It all starts with the main keynote, where you’ll experience the future of software and learn how to build it. Watch it now and catch every moment at your own pace.

👉 Watch Now

Let’s now go back to our article and see the 5 projects.

Project 1: Three-Tier Web Application

What you build: A custom VPC with public and private subnets, an Application Load Balancer, an Auto Scaling Group, and an RDS database.

Why it matters: This is the foundational architecture pattern behind almost every production web workload on AWS. The exam tests it constantly, and so does every technical interview.

The critical insight here is traffic flow. Your ALB lives in the public subnet and accepts inbound traffic on port 443. Your EC2 instances sit in private subnets and only accept traffic from the ALB’s security group, not from the internet. Your RDS instance sits in a separate private subnet and only accepts traffic from the EC2 security group. Nothing in the data tier is ever directly reachable.

When you build this yourself, you stop memorizing “databases should be private” and start understanding why: defense in depth, blast radius reduction, and compliance requirements that mandate network isolation. You also learn where Auto Scaling actually helps, horizontal scaling behind the ALB, and where it doesn’t, like a single-AZ RDS instance that becomes your bottleneck at 500 concurrent connections.

What the exam will ask: Multi-AZ RDS failover behavior, ALB vs. NLB selection criteria, and how security group rules differ from NACLs. Build this project and those questions answer themselves.

Project 2: Serverless Image Processing Pipeline

What you build: An S3 upload triggers Lambda, which resizes the image, stores metadata in DynamoDB, and sends an SNS notification.

Why it matters: Event-driven architecture is the dominant pattern in modern cloud systems. This project teaches you how AWS services communicate asynchronously, and what happens when they don’t.

The flow looks simple: S3 event → Lambda → DynamoDB write + SNS publish. But building it forces you to confront real decisions. What’s your Lambda timeout? If image processing takes 8 seconds and you set 5, you’ll see silent failures. What’s your DynamoDB write capacity? If you’re processing 200 images per minute and your table is provisioned for 50 WCU, you’ll hit throttling. What happens to the SNS notification if the DynamoDB write fails? You’ll need to think about idempotency and partial failure handling.

What the exam will ask: S3 event notification targets, Lambda concurrency limits, DynamoDB capacity modes, and SNS delivery guarantees. This project covers all of them.

Project 3: Disaster Recovery Solution

What you build: Cross-region S3 replication, automated RDS backups, and Route 53 failover routing.

Why it matters: DR is one of the most heavily tested domains on the SAA-C03, and it’s also one of the most misunderstood in practice. Most candidates can recite the four DR strategies. Few can explain the trade-offs that determine which one you’d actually choose.

Building this project forces you to internalize the RTO/RPO trade-off with real numbers. Cross-region S3 replication gives you near-zero RPO for object storage, replication typically completes in under 15 minutes for objects under 5GB. But your RDS automated backup has an RPO of up to 24 hours unless you’re using read replicas or Aurora Global Database. Route 53 health checks with failover routing can redirect traffic in under 60 seconds, but only if your secondary environment is already running (warm standby) or fully active (multi-site active-active).

The exam distinguishes between backup/restore (hours of RTO, lowest cost), pilot light (minutes of RTO, minimal running infrastructure), warm standby (seconds to minutes, scaled-down but live), and multi-site active-active (near-zero RTO, highest cost). Build this project and you’ll understand why a financial services company chooses multi-site active-active at $40,000/month while a content platform chooses backup/restore at $200/month.

What the exam will ask: S3 replication configuration, RDS backup retention, Route 53 routing policies, and how to calculate RTO/RPO for each DR tier.

Project 4: Hybrid Storage Solution

What you build: AWS Storage Gateway connected to on-premises systems, S3 lifecycle policies moving data through storage tiers, and IAM policies controlling access.

Why it matters: Most cloud engineers underestimate how much enterprise workload still runs on-premises. Storage Gateway is the bridge, and understanding it makes you sound experienced in interviews because it signals you’ve thought about migration, not just greenfield architecture.

Storage Gateway has three modes: File Gateway (NFS/SMB access to S3), Volume Gateway (iSCSI block storage backed by S3), and Tape Gateway (virtual tape library for backup software). The exam tests which mode fits which scenario. Build a File Gateway and you’ll understand why a media company with 200TB of on-premises video assets uses it to extend their NAS to S3 without rewriting their editing workflows.

S3 lifecycle policies complete the picture. Moving objects from S3 Standard to S3 Standard-IA after 30 days saves roughly 46% on storage costs. Moving to S3 Glacier Instant Retrieval after 90 days saves another 68%. For a workload storing 10TB of infrequently accessed data, that’s the difference between $230/month and $40/month. The exam will ask you to design the right lifecycle policy for a given access pattern, build this project and you’ll answer from experience, not memorization.

What the exam will ask: Storage Gateway modes, S3 storage class trade-offs, lifecycle policy configuration, and IAM policy structure for cross-account S3 access.

Project 5: Containerized Microservices Application

What you build: Two services deployed on ECS with Fargate, task definitions with resource limits, ALB path-based routing to each service, and CloudWatch Container Insights for logging and metrics.

Why it matters: Containers are now a core SAA-C03 domain, and ECS with Fargate is the AWS-native answer to “I want containers without managing servers.” Building this project teaches you the ECS mental model, clusters, services, task definitions, and tasks, and how they map to the infrastructure underneath.

The ALB routing piece is where most candidates get confused. Path-based routing lets you send /api/orders/* to your orders service and /api/inventory/* to your inventory service, both running as separate ECS services behind a single ALB. Each service has its own target group, its own task definition with CPU and memory limits, and its own auto-scaling policy based on CPU utilization or request count. When you build this, you understand why a task definition with 256 CPU units and 512MB memory will throttle under load before it scales, and how to set the right CloudWatch alarm threshold to trigger scaling before users notice.

CloudWatch Container Insights gives you container-level CPU, memory, network, and disk metrics without any instrumentation. You’ll see exactly which task is consuming resources and correlate it with application logs in the same console. That operational visibility is what separates a working prototype from a production-ready deployment.

What the exam will ask: ECS vs. EKS selection criteria, Fargate vs. EC2 launch type trade-offs, ALB target group configuration, and CloudWatch metrics for container workloads.

Conclusion

Watching videos teaches you what AWS services do. Building projects teaches you what they cost, where they fail, and why you’d choose one over another. Every question on the SAA-C03 is ultimately asking: given these constraints, what’s the right architecture decision?

These five projects give you the intuition to answer that question, not just on the exam, but in the room when a customer asks why their database is the bottleneck, why their DR plan won’t meet their RTO, or why their serverless pipeline is costing more than expected.

Build the projects. Pass the exam. Show up to the interview ready to talk about real systems.

Sponsored by Salesforce

Salesforce goes Headless 360

The biggest news out of SF last week wasn’t a new UI, it was the decoupling of it. Salesforce is officially pivoting to an API-first “Headless 360” architecture. For those of us tired of the walled garden constraints, this is a massive shift. By separating core CRM logic and data from the standard UI, we can now treat Salesforce as a backend engine for any custom frontend or external application stack.

Click the link here and let me know what you think!

Explore the biggest announcements, launches, and innovations from TDX 2026.

Agentic AI is changing the game and Agentforce is leading the way. Watch TDX on demand to explore dozens of sessions covering the latest innovations across Agentforce, Data 360, the core platform, vibe coding, Slack, and more. All free on Salesforce+.

Watch TDX on Salesforce+ to:

• Get roadmap insights from the leaders shaping what’s next

• Access broadcast-only moments and exclusive interviews

It all starts with the main keynote, where you’ll experience the future of software and learn how to build it. Watch it now and catch every moment at your own pace.

👉 Watch Now

The Requirements

Let’s now go back to our article. We needed security that addressed four critical concerns:

Application-layer protection against SQL injection, XSS, and other OWASP Top 10 attacks that target business logic rather than infrastructure.

DDoS mitigation at both network and application layers without manual intervention. When attacks happen at 3 AM, automated response is non-negotiable.

Rate limiting and throttling that works across a global user base. Simple IP-based limiting breaks with legitimate users behind corporate NATs or mobile carriers.

Performance constraints of sub-200ms API response times even with all security layers active. Security cannot become the bottleneck.

We also needed complete observability into every attack attempt with real-time alerting when patterns emerge. The solution had to scale automatically, security couldn’t become the constraint during traffic spikes.

The AWS Services

API Gateway serves as the entry point, handling authentication, request validation, and throttling before requests reach backend functions. It’s the first line of defense that rejects malformed requests immediately.

AWS WAF sits in front of API Gateway, inspecting every HTTP request against managed rule sets and custom rules. It blocks attacks at the edge before they consume API Gateway capacity or cost Lambda invocations.

AWS Shield Standard comes automatically with API Gateway, providing DDoS protection against common network and transport layer attacks. Shield Advanced is available for scenarios requiring dedicated DDoS response team support.

The Flow

When a request hits our API, it reaches the regional API Gateway with WAF rules applied at the edge. If the request matches a block rule, suspicious patterns, known bad IPs, rate limit exceeded, it’s rejected with a 403 before reaching API Gateway.

For legitimate requests that pass WAF inspection, API Gateway applies its own throttling limits, validates the request structure, checks API keys or JWT tokens, and only then invokes backend functions. If anything fails validation, the request is rejected without consuming compute capacity.

This layered approach means attacks get stopped at the cheapest point possible. WAF blocks cost nothing beyond the WAF inspection fee. API Gateway rejections cost nothing beyond the API call. Only legitimate requests that pass all checks consume Lambda invocations.

Deep Dive: WAF Rule Strategy

We started with AWS Managed Rules, they catch 90% of common attacks immediately. But we hit false positives on legitimate API calls that included JSON payloads with special characters.

Our custom rules operate with three priorities:

IP reputation list blocks known malicious IPs. We integrated threat intelligence feeds that update hourly. This stops repeat offenders before they even attempt an attack.

Rate-based rules block IPs making more than 2,000 requests in five minutes. This catches credential stuffing attempts targeting our login endpoints. We observed attackers cycling through stolen credentials at exactly this rate, fast enough to test thousands of accounts but slow enough to avoid obvious detection.

Geo-blocking rules target countries with no legitimate users but high attack traffic. This was controversial internally, but the data was clear: 95% of attacks came from regions with zero paying customers.

The critical decision: we set WAF to count mode initially, not block. We observed traffic patterns for two weeks, identified false positives, tuned rules, then switched to block mode. This prevented accidentally blocking legitimate users during the learning phase.

Deep Dive: API Gateway Security Features

API Gateway provides multiple security layers beyond basic routing.

Request validation happens before Lambda invocation, rejecting requests with malformed JSON, missing required parameters, or invalid data types. This prevents malicious payloads from reaching backend code. We defined JSON schemas for every endpoint, verbose to maintain, but it stops entire classes of attacks.

Authentication integrates with multiple mechanisms. We use API keys for simple use cases, Lambda authorizers for custom logic, and Cognito user pools for OAuth 2.0 flows. Each request is validated before consuming any compute resources.

Resource policies add another control layer. We restricted our internal APIs to specific VPCs, preventing public internet access entirely while maintaining the benefits of API Gateway’s managed service.

Deep Dive: Throttling Strategy

API Gateway’s throttling operates at multiple levels, and understanding each is critical.

Account-level limits serve as a safety net, but real control comes from usage plans. Each usage plan has both rate limits (steady-state) and burst capacity. Burst capacity matters during traffic spikes when clients temporarily exceed their rate limit using burst tokens. We set burst to 2x the rate limit, this handles legitimate spikes without triggering false positives.

Custom throttling in WAF for specific endpoints adds another layer. Our login endpoints get rate-limited to 10 requests per minute per IP, far more restrictive than general API limits. This stops brute force attacks without impacting normal API usage.

Method-level throttling provides even finer control. Read operations (GET) can have higher limits than write operations (POST, PUT, DELETE), reflecting their different resource consumption and risk profiles. We observed that 80% of attacks targeted write endpoints, so we throttled them more aggressively.

Deep Dive: Shield Protection

Shield Standard provides automatic protection against common DDoS attacks at the network and transport layers. It detects and mitigates SYN floods, UDP reflection attacks, and other volumetric attacks without any configuration.

The protection operates inline with minimal latency impact. Shield’s detection algorithms analyze traffic patterns in real-time, distinguishing legitimate traffic spikes from attack patterns. When attacks are detected, mitigation happens automatically within seconds.

For our API, Shield Advanced wasn’t initially necessary. The decision point: Shield Advanced makes sense when API downtime costs exceed $3,000/month or when regulatory requirements mandate dedicated security response. We added it after a competitor suffered a multi-day DDoS attack that made headlines.

Monitoring and Observability

WAF logs every blocked request to CloudWatch Logs. We stream these to S3 for long-term analysis. Analyzing these logs reveals attack patterns, identifies false positives, and guides rule tuning. We set up CloudWatch alarms for blocked request spikes, when blocks exceed 1,000 per minute, we get paged.

API Gateway metrics expose throttling events, 4xx/5xx error rates, and latency distributions. We correlate WAF blocks with API Gateway metrics to see the full security picture, which attacks reached API Gateway versus which were blocked at WAF.

X-Ray tracing adds end-to-end visibility, showing exactly where requests spend time and where failures occur. This proved essential when debugging whether performance issues stemmed from security layers, backend code, or downstream services.

Cost Breakdown

WAF costs run approximately $5/month base fee plus $1 per million requests plus $1 per rule per month. With 10 custom rules and 100 million requests monthly, that’s $115/month.

API Gateway costs are $3.50 per million requests for REST APIs. At 100 million requests monthly, that’s $350/month. Caching can reduce backend invocations significantly.

Shield Standard is included at no additional cost. Shield Advanced costs $3,000/month plus data transfer fees, only justified for high-value APIs where downtime is extremely costly.

Lambda invocations saved by blocking malicious requests represent the hidden cost savings. We block approximately 5 million malicious requests monthly that would have cost $1 in Lambda invocations plus potential data breach costs.

Total monthly cost for our security stack: approximately $465 for WAF and API Gateway, blocking attacks that would cost far more in compute resources and potential breaches.

Key Takeaways

This architecture stops millions of malicious requests monthly, requests that would cost money and potentially compromise systems. The layered approach proves essential: WAF catches obvious attacks, API Gateway enforces business logic throttling and authentication, and Shield protects against network-layer DDoS. No single layer would be sufficient.

Sponsored by Salesforce

The shift toward Agentic AI isn’t just another buzzword—it’s redefining how we design, architect, and build modern systems.

That’s exactly why I’ll be tuning into TDX on Salesforce+ to explore how Agentforce is shaping the next generation of the developer roadmap.

If you’re serious about staying ahead of the curve, I highly recommend grabbing a free spot and joining the sessions.

Plus, when you register, you’ll be automatically entered for a chance to win one of 20 AI exam vouchers (valued at $200)—available to legal residents of the U.S., Canada, New Zealand, and the U.K.

Stream the developer conference of the year. Live on Salesforce+.

Agentic AI is changing the game and Agentforce is leading the way. Stream TDX to join dozens of sessions and virtual hands-on trainings that explore the latest innovations across Agentforce, Data 360, the core platform, vibe coding, Slack, and more. All free on Salesforce+.

Tune in to TDX on Salesforce+ to:

• Build hands-on skills with virtual trainings and live demos

• Get roadmap insights from the leaders shaping what’s next

• Access broadcast-only moments and exclusive interviews

It all kicks off with the main keynote, where you’ll experience the future of software and learn how to build it. Add it to your calendar so you don’t miss a moment.

👉 Register for free

Why Tracing Matters in Serverless

Serverless applications are inherently distributed. A single user request might trigger an API Gateway endpoint, invoke multiple Lambda functions, write to DynamoDB, publish messages to SNS, and queue tasks in SQS. When something goes wrong, or even when you’re optimizing performance, pinpointing the bottleneck becomes challenging without proper tracing.

X-Ray solves this by creating a complete map of your request journey, showing you exactly where time is spent, where errors occur, and how services interact with each other. It’s the difference between guessing and knowing.

Understanding the Service Map

The service map is X-Ray’s visual representation of your application architecture. It automatically discovers and displays all the services your application uses, showing the relationships between them. Each node represents a service, and the connections show how requests flow between them.

What makes this powerful is the real-time health indicators. You can immediately spot services with high error rates or elevated latency. The color coding provides instant visual feedback, green for healthy, yellow for warnings, and red for errors. This bird’s-eye view helps you understand your system’s behavior at a glance.

Traces and Segments: The Building Blocks

Every request that flows through your application creates a trace. Within each trace, individual services create segments that represent the work they perform. For Lambda functions, a segment captures the entire function execution. For downstream calls to DynamoDB or other services, subsegments provide granular detail.

The trace timeline shows you exactly how long each segment took, helping you identify slow operations. You can drill down into specific traces to see the complete request path, including all the metadata, annotations, and errors associated with each segment.

Practical Tips for Effective Tracing

Start with sampling strategies wisely. X-Ray uses sampling to balance cost and visibility. The default sampling rule captures the first request each second and 5% of additional requests. For production environments, this is usually sufficient. However, for critical workflows or during troubleshooting, consider creating custom sampling rules to capture 100% of specific API paths or error conditions.

Use annotations for filtering and grouping. Annotations are indexed key-value pairs that you can use to filter traces in the X-Ray console. Add annotations for user IDs, transaction types, or feature flags. This makes it easy to analyze specific user journeys or compare performance across different code paths.

Leverage metadata for context. Unlike annotations, metadata isn’t indexed but provides rich contextual information when viewing individual traces. Include relevant business context, configuration values, or debugging information that helps you understand what was happening during the request.

Monitor cold starts separately. Lambda cold starts can significantly impact performance. Use X-Ray annotations to tag cold start invocations, allowing you to analyze their frequency and impact separately from warm starts. This helps you make informed decisions about provisioned concurrency.

Set up alarms on key metrics. X-Ray integrates with CloudWatch, allowing you to create alarms based on error rates, latency percentiles, or fault rates. Don’t wait to discover problems, let X-Ray notify you when thresholds are breached.

Trace asynchronous workflows. For event-driven architectures using SNS, SQS, or EventBridge, ensure you’re propagating trace context through message attributes. This maintains the trace continuity across asynchronous boundaries, giving you end-to-end visibility even in complex event chains.

Use trace groups for organization. As your application grows, create trace groups to organize and filter traces by environment, application component, or team ownership. This keeps your X-Ray console manageable and helps teams focus on their specific services.

The Bottom Line

AWS X-Ray transforms serverless observability from reactive debugging to proactive optimization. By providing clear visibility into request flows, performance characteristics, and error patterns, it empowers you to build more reliable and efficient serverless applications.

The key is to integrate X-Ray early in your development process, not as an afterthought when problems arise. With proper instrumentation and thoughtful use of annotations and sampling, X-Ray becomes an invaluable tool for understanding and improving your serverless architecture.

Sponsored by Salesforce

Stream the developer conference of the year. Live on Salesforce+.

Agentic AI is changing the game and Agentforce is leading the way. Stream TDX to join dozens of sessions and virtual hands-on trainings that explore the latest innovations across Agentforce, Data 360, the core platform, vibe coding, Slack, and more. All free on Salesforce+.

Tune in to TDX on Salesforce+ to:

• Build hands-on skills with virtual trainings and live demos

• Get roadmap insights from the leaders shaping what’s next

• Access broadcast-only moments and exclusive interviews

It all kicks off with the main keynote, where you’ll experience the future of software and learn how to build it. Add it to your calendar so you don’t miss a moment.

👉 Register for free

What Are Canary Deployments?

A canary deployment is a progressive rollout strategy where you route a small percentage of production traffic to a new version of your application while the majority continues using the stable version. The term comes from the historical practice of using canaries in coal mines as early warning systems, if something goes wrong with the new version, only a small subset of users are affected.

In API Gateway, canary deployments work at the stage level. When you create a canary, you’re essentially splitting traffic between two versions of your API: the base deployment and the canary deployment. Each can point to different Lambda function versions or aliases, allowing you to test new code with real production traffic.

How Canary Deployments Work with Lambda

The integration between API Gateway canary deployments and Lambda is straightforward but powerful. When you deploy a canary in API Gateway, you specify a percentage of traffic to route to the canary version, typically starting with 5-10%. The remaining traffic continues flowing to your stable base deployment.

API Gateway uses a weighted random distribution to split traffic. This means if you set a 10% canary weight, approximately 10% of requests will hit your canary Lambda function version, while 90% go to the base version. The distribution happens at the request level, not the user level, so individual users might experience both versions during a canary deployment.

The key is that both deployments exist simultaneously in the same stage. Your base deployment might point to Lambda alias “production” running version 5, while your canary points to alias “canary” running version 6. This allows you to validate new functionality with real traffic patterns before committing to a full rollout.

Practical Tips for Success

Start Small and Increase Gradually: Begin with 5-10% traffic to your canary. Monitor metrics closely for 15-30 minutes before increasing. A common progression is 10% → 25% → 50% → 100%, with monitoring periods between each increase.

Use Lambda Aliases, Not Versions Directly: Always point your API Gateway integrations to Lambda aliases rather than specific versions. This gives you flexibility to update what version an alias points to without redeploying your API. Use one alias for production traffic and another for canary testing.

Monitor the Right Metrics: Focus on error rates, latency percentiles (especially p99), and business-specific metrics. Don’t just watch averages, a 1% error rate on your canary means 1 in 100 of your customers are having problems. Set up CloudWatch alarms that compare canary metrics against baseline metrics.

Implement Proper Logging: Ensure your Lambda functions log which version they are. Include version information in structured logs so you can quickly filter and compare behavior between canary and base deployments during troubleshooting.

Have a Rollback Plan: Know how to quickly promote your canary to 100% if it’s successful, or delete it entirely if problems arise. Practice these operations in non-production environments. The API Gateway console and CLI both support these operations, but automation through CI/CD pipelines is ideal.

Consider Stage Variables: Use API Gateway stage variables to pass configuration to your Lambda functions. This allows the same Lambda code to behave differently based on whether it’s handling base or canary traffic, useful for feature flags or environment-specific settings.

Test with Realistic Load: Canary deployments are most valuable when they experience real production traffic patterns. Avoid deploying canaries during low-traffic periods if possible, you want enough requests to generate statistically significant results.

Don’t Rush the Process: The entire point of canary deployments is risk reduction. If you promote a canary to 100% within minutes, you’re not giving yourself time to detect issues. Plan for canary periods of at least several hours for critical APIs.

When to Use Canaries

Canary deployments shine when rolling out significant changes: new business logic, performance optimizations, dependency updates, or architectural changes. They’re less critical for minor bug fixes or configuration changes, though the safety they provide is always valuable.

The overhead of managing canaries is minimal compared to the protection they offer. For production APIs serving real customers, canary deployments should be your default deployment strategy, not an exception.

Sponsored by Salesforce

Stream the developer conference of the year. Live on Salesforce+.

Agentic AI is changing the game and Agentforce is leading the way. Stream TDX to join dozens of sessions and virtual hands-on trainings that explore the latest innovations across Agentforce, Data 360, the core platform, vibe coding, Slack, and more. All free on Salesforce+.

Tune in to TDX on Salesforce+ to:

• Build hands-on skills with virtual trainings and live demos

• Get roadmap insights from the leaders shaping what’s next

• Access broadcast-only moments and exclusive interviews

It all kicks off with the main keynote, where you’ll experience the future of software and learn how to build it. Add it to your calendar so you don’t miss a moment.

👉 Register for free

Architecture Overview

Our multi-region architecture consists of four key components working together:

• Route 53: Provides intelligent DNS routing to direct users to the nearest regional endpoint

• API Gateway: Regional REST or HTTP APIs that serve as entry points in each region

• Lambda: Compute layer that processes requests with minimal latency

• DynamoDB Global Tables: Multi-region, fully replicated database with automatic conflict resolution

This architecture provides active-active deployment across multiple AWS regions, ensuring that if one region experiences issues, traffic automatically fails over to healthy regions.

The Architecture Flow

At the heart of a multi-region serverless architecture lies a carefully orchestrated chain of AWS services working together to deliver a seamless global experience.

Route 53: The Global Traffic Director

Amazon Route 53 serves as the entry point for all user requests. Using health checks and routing policies like latency-based or geoproximity routing, Route 53 intelligently directs users to the nearest healthy regional endpoint. This ensures that a user in Tokyo connects to the Asia Pacific region while a user in Frankfurt connects to Europe, minimizing latency and improving user experience.

API Gateway: Regional Entry Points

Each region hosts its own API Gateway endpoint, acting as the front door for that region’s serverless infrastructure. API Gateway handles request validation, throttling, and authentication before passing requests to the compute layer. With features like request/response transformation and built-in AWS WAF integration, it provides a robust security perimeter for your application.

Lambda: Distributed Compute

Behind each regional API Gateway sits AWS Lambda functions that execute your business logic. These functions are deployed identically across all regions, ensuring consistent behavior regardless of where the request originates. Lambda’s automatic scaling handles traffic spikes in each region independently, while its pay-per-use model keeps costs optimized even with a multi-region footprint.

DynamoDB Global Tables: The Data Layer

The foundation of this architecture is DynamoDB Global Tables, which provides fully managed, multi-region, multi-active database replication. When a Lambda function writes data in one region, DynamoDB automatically replicates that data to all other configured regions, typically within seconds. This means users can read and write data from their nearest region while maintaining global consistency.

Key Architectural Considerations

Conflict Resolution: DynamoDB Global Tables uses a last-writer-wins reconciliation strategy. Your application design should account for this, potentially using timestamps or version numbers to handle concurrent updates across regions.

Replication Lag: While DynamoDB replication is fast, there’s still a brief window where data might not be consistent across all regions. Design your application to handle eventual consistency gracefully.

Regional Failover: Route 53 health checks continuously monitor your regional endpoints. If a region becomes unhealthy, traffic automatically routes to the next best region, providing transparent failover without user intervention.

Cost Implications: Running infrastructure in multiple regions increases costs through data transfer charges and duplicated resources. Balance the number of regions against your actual user distribution and availability requirements.

The Benefits

This architecture delivers several compelling advantages. Users experience lower latency by connecting to nearby infrastructure. Your application remains available even if an entire AWS region experiences an outage. Data is protected through geographic redundancy. And perhaps most importantly, you can scale globally without redesigning your architecture.

When to Use This Pattern

Multi-region architectures make sense for applications with a global user base, strict availability requirements, or regulatory needs for data residency. However, they add complexity and cost, so evaluate whether your application truly needs global distribution or if a single-region deployment with good disaster recovery would suffice.

Conclusion

Building a multi-region serverless architecture with Route 53, API Gateway, Lambda, and DynamoDB Global Tables provides a robust foundation for globally distributed applications. This architecture delivers low-latency responses to users worldwide while maintaining high availability and disaster recovery capabilities.

The key to success is embracing eventual consistency, implementing comprehensive monitoring, and regularly testing your failover mechanisms. While the initial setup requires careful planning, the operational benefits of automatic scaling, reduced latency, and improved reliability make it worthwhile for applications serving a global user base.

The Serverless Testing Challenge

Serverless architectures introduce complexity that makes testing more nuanced than traditional applications. Lambda functions don’t run in isolation, they interact with API Gateway, DynamoDB, S3, SQS, SNS, EventBridge, and numerous other AWS services. The pay-per-invocation model means you can’t simply spin up a test environment and leave it running. Additionally, the distributed nature of serverless systems means that failures can cascade across multiple services in ways that are difficult to predict and reproduce.

The testing pyramid for serverless applications looks different from traditional applications. While you still want a solid foundation of unit tests, the integration layer becomes significantly more important because so much of your application’s behavior depends on how services interact with each other.

Unit Testing Lambda Functions

Unit testing Lambda functions focuses on testing your business logic in isolation from AWS services. The key principle is to separate your core logic from the Lambda handler and AWS SDK calls. This separation allows you to test your business logic without needing to mock AWS services or make actual API calls.

Testing Frameworks: Use Jest or Mocha for Node.js Lambda functions, pytest for Python, JUnit for Java, or Go’s built-in testing package for Go-based functions. These frameworks provide the foundation for writing and running your unit tests with features like test discovery, assertions, and test reporting.

Your Lambda handler should be thin, primarily responsible for parsing events, calling your business logic, and formatting responses. The actual business logic should live in separate modules that can be tested independently. This architectural pattern makes your code more testable and maintainable.

When unit testing, focus on testing edge cases, error conditions, and business rule validation. Test how your code handles malformed input, missing required fields, and unexpected data types. These tests should run quickly and require no external dependencies, making them ideal for rapid feedback during development.

Mocking Tools: Mock external dependencies at the boundaries of your application using tools like aws-sdk-mock for JavaScript, or moto for Python. Rather than mocking the entire AWS SDK, create abstraction layers or interfaces that represent the operations your code needs to perform. This approach makes your tests more resilient to changes in the AWS SDK and keeps your business logic decoupled from infrastructure concerns.

Integration Testing Strategies

Integration testing for serverless applications verifies that your Lambda functions work correctly with actual AWS services. This is where you test the contracts between your code and services like DynamoDB, S3, SQS, and API Gateway. Integration tests are more expensive and slower than unit tests, but they catch issues that unit tests cannot.

Integration Testing Tools: Leverage AWS SAM CLI for local testing and deployment, Serverless Framework’s invoke local command, or LocalStack for comprehensive AWS service emulation. For end-to-end testing, consider Postman or Newman for API testing, and aws-testing-library for programmatic integration tests.

There are several approaches to integration testing in serverless environments. One strategy involves deploying to a dedicated testing environment in AWS and running tests against real services using AWS CDK or Terraform for infrastructure provisioning. This approach provides the highest confidence that your application will work in production, but it’s also the slowest and most expensive option.

Another approach uses local emulation tools like LocalStack, SAM Local, or Serverless Offline that simulate AWS services on your development machine. These tools provide a faster feedback loop than deploying to AWS, but they may not perfectly replicate the behavior of actual AWS services. They’re best used for rapid iteration during development, with periodic validation against real AWS services.

Contract Testing: Consider implementing contract testing using Pact or Spring Cloud Contract for your Lambda functions. Contract tests verify that your functions correctly handle the event formats they receive from triggers like API Gateway, EventBridge, or SQS. They also verify that your functions produce output in the format expected by downstream services. This approach helps catch breaking changes early.

Integration tests should cover the critical paths through your application, the workflows that represent your core business value. Test how your functions handle retries, how they behave under throttling conditions, and how they recover from transient failures using tools like Chaos Toolkit or AWS Fault Injection Simulator for chaos engineering experiments. These scenarios are difficult to test with unit tests alone.

Local Development Strategies

Effective local development for serverless applications requires tools and workflows that provide rapid feedback without requiring constant deployment to AWS. The goal is to enable developers to iterate quickly while maintaining confidence that their code will work when deployed.

Local Development Tools: Use AWS SAM CLI with sam local start-api and sam local invoke commands, Serverless Framework with the serverless-offline plugin, or LocalStack for comprehensive local AWS service emulation. Docker is essential for containerizing your development environment to match Lambda’s execution environment.

Local development environments should replicate the Lambda execution environment as closely as possible using Docker images based on AWS Lambda base images. This includes matching the runtime version, environment variables, memory configuration, and timeout settings. Discrepancies between local and deployed environments are a common source of bugs that only appear in production.

Consider using Docker Compose to orchestrate containerized development environments that mirror the Lambda runtime. This approach ensures consistency across your development team and reduces “works on my machine” issues. Containers can include all necessary dependencies, tools, and configurations, making onboarding new developers faster and more reliable.

Debugging Tools: Local development should support debugging with breakpoints and step-through execution using VS Code’s built-in debugger, AWS Toolkit for VS Code, IntelliJ IDEA with AWS Toolkit, or PyCharm’s remote debugging. The ability to pause execution, inspect variables, and step through code line by line is invaluable for understanding complex issues. This capability is especially important when working with asynchronous operations and event-driven workflows.

Conclusion

Testing serverless applications requires a comprehensive strategy that spans unit testing, integration testing, local development, and production monitoring. The distributed nature of serverless architectures and the tight integration with managed services make testing more complex than traditional applications, but the right tools and approach can provide confidence in your application’s reliability and correctness.

In this article, we'll cover what they are, when you should use them, and how they compare with AWS Step Functions to help you choose the right orchestration tool for your serverless applications.

What Are Lambda Durable Functions?

Lambda Durable Functions are regular Lambda functions enhanced with stateful execution capabilities. They allow you to write complex, long-running workflows directly in your application code using familiar programming languages, rather than defining workflows in a separate orchestration language.

The key innovation lies in automatic checkpointing. As your function executes, AWS Lambda automatically saves progress at strategic points. If your workflow needs to wait for an external event, such as a webhook callback, a manual approval, or a scheduled delay, the function pauses without consuming compute resources. When the awaited event occurs, execution resumes from the last checkpoint with full context preserved.

This approach embeds orchestration logic directly into your Lambda code, eliminating the need to manage state manually or architect separate state management systems. The result is a serverless-first approach that reduces operational overhead while maintaining the scalability and pay-per-use economics that make serverless attractive.

When to Use Durable Functions

Lambda Durable Functions excel in specific scenarios where application logic naturally involves multiple steps with waiting periods:

AI and Machine Learning Workflows - Orchestrating multi-stage AI pipelines where each step might involve model inference, data transformation, or human review. The ability to pause between stages without incurring costs makes this particularly economical for batch processing scenarios.

Order Processing and E-commerce - Managing order fulfillment workflows that span inventory checks, payment processing, shipping coordination, and customer notifications. These workflows often involve waiting for external system responses or scheduled delivery windows.

Approval and Human-in-the-Loop Processes - Building loan applications, expense approvals, or content moderation systems where workflows must pause for human decisions before proceeding. The year-long execution window accommodates even the most extended approval cycles.

Event-Driven Application Logic - Coordinating complex business processes that respond to multiple events over time, such as customer onboarding journeys, subscription lifecycle management, or multi-step data processing pipelines.

Application-Centric Orchestration - When your workflow logic is tightly coupled with your application code and benefits from being expressed in the same programming language as the rest of your business logic.

How Durable Functions Compare with Step Functions

Both Lambda Durable Functions and AWS Step Functions solve the problem of orchestrating multi-step workflows, but they approach it from fundamentally different philosophical and architectural standpoints.

Architectural Philosophy

Step Functions is built for infrastructure orchestration. It excels at coordinating disparate AWS services, providing a visual workflow designer, and offering a declarative approach using Amazon States Language (ASL). The workflow definition lives separately from your application code, making it ideal for workflows that need to be understood and modified by operations teams or non-technical stakeholders.

Durable Functions, by contrast, are optimized for application orchestration. The workflow logic lives within your Lambda function code, written in your preferred programming language. This code-first approach makes it natural for developers who want to keep orchestration logic alongside business logic, use familiar debugging tools, and leverage existing programming constructs like loops, conditionals, and error handling.

Developer Experience

With Step Functions, you define workflows in ASL—a JSON-based state machine definition language. While powerful and expressive, this requires learning a new syntax and switching contexts between your application code and workflow definitions. Local testing typically involves additional tooling or mocking frameworks.

Durable Functions let you write workflows as regular code. If you know how to write a Lambda function, you already know how to write a durable function. The workflow logic uses standard programming constructs, making it more intuitive for developers and easier to test locally using familiar development tools.

Visibility and Monitoring

Step Functions provides superior visual representation of workflows. The built-in graphical interface shows execution flow, making it easy for stakeholders to understand complex processes at a glance. This visualization is particularly valuable for compliance, auditing, and operational monitoring.

Durable Functions trade some of this visual clarity for code simplicity. While you can still monitor executions through CloudWatch and Lambda insights, the workflow structure isn’t as immediately apparent to non-technical observers.

Use Case Alignment

Choose Step Functions when you need to:

• Orchestrate multiple AWS services (Lambda, ECS, Glue, etc.)

• Provide workflow visibility to non-technical stakeholders

• Build workflows that benefit from visual design and monitoring

• Implement complex branching, parallel execution, or error handling patterns that benefit from declarative definition

• Maintain clear separation between orchestration and business logic

Choose Durable Functions when you need to:

• Keep workflow logic tightly integrated with application code

• Leverage existing programming language features and libraries

• Simplify development by avoiding context switching between code and ASL

• Build workflows where the orchestration is primarily application logic rather than service coordination

• Optimize for developer velocity and code maintainability within Lambda

Cost Considerations

Both services charge only for active execution time, not idle waiting periods. However, the pricing models differ slightly. Step Functions charges per state transition, while Durable Functions follow Lambda’s standard pricing model with additional charges for state persistence. For workflows with many state transitions, Durable Functions may offer cost advantages. For workflows coordinating many AWS services, Step Functions’ integration capabilities may provide better value.

Conclusion

Lambda Durable Functions and Step Functions aren’t competitors—they’re complementary tools in your serverless toolkit. Durable Functions shine when you want to write workflow logic as code within your Lambda functions, keeping orchestration close to your application logic. Step Functions excel when you need to coordinate multiple AWS services with clear visual representation and operational oversight.

The choice ultimately depends on your team’s preferences, the nature of your workflows, and whether you value code-centric development or service-centric orchestration. Many organizations will find themselves using both, selecting the right tool for each specific use case.

That’s exactly the problem Kiro is designed to solve.

What Is Kiro?

Kiro is an AI-powered IDE built for developers who work with cloud infrastructure. It’s not just a code editor with a chatbot bolted on, it’s a development environment that understands your infrastructure context and actively helps you build, validate, and troubleshoot it.

One of Kiro’s most compelling features is its Powers system. Powers are purpose-built AI capabilities that you can install directly into your IDE, each one tailored to a specific domain or technology. Think of them as expert co-pilots for different parts of your stack.

And for AWS engineers, there’s one Power that deserves your full attention.

The “Build AWS Infrastructure with CDK and CloudFormation” Power

Available at kiro.dev/powers, this Power is built specifically for AWS infrastructure development. Its description is straightforward but the implications are significant:

“Build well-architected AWS infrastructure with CDK using latest documentation, best practices, and code samples. Validate CloudFormation templates, check resource configuration security compliance, and troubleshoot deployments.”

This isn’t a generic AI assistant that happens to know some AWS. This is a focused, infrastructure-aware capability that integrates directly into your development workflow.

What This Power Actually Does

Under the hood, this Kiro Power is backed by the AWS Infrastructure as Code (IaC) MCP Server, a tool built on the Model Context Protocol (MCP) that connects AI assistants to your local AWS development environment.

The Power gives Kiro access to a set of specialized tools organized into two categories:

Documentation and Knowledge Tools

• Search CDK documentation and best practices

• Read specific CDK documentation pages

• Search CDK samples and constructs

• Search CloudFormation documentation

Validation and Troubleshooting Tools

• Validate CloudFormation templates before deployment

• Check resource configuration for security compliance

• Get pre-deployment validation instructions

• Troubleshoot CloudFormation deployment failures

Together, these capabilities cover the full lifecycle of infrastructure development, from the moment you start designing a stack to the moment you’re debugging a failed deployment.

Why This Changes Your CDK and CloudFormation Workflow

You Stop Guessing at Best Practices

One of the most common pain points with CDK is knowing how to use it correctly, not just that you can use it. Should you use a Construct or an L2 Construct? What’s the right pattern for a serverless API? What are the security defaults you should always set?

With this Power active, Kiro can answer these questions in context, pulling from the latest AWS documentation and surfacing the right patterns for your specific use case. You’re not getting generic advice; you’re getting guidance grounded in current AWS best practices.

You Catch Errors Before They Reach AWS

CloudFormation template errors are notoriously painful to debug. You deploy, wait several minutes, and then get a cryptic rollback message. With Kiro’s validation tools, you can catch configuration issues and security compliance gaps before you ever run cdk deploy or submit a stack.

This alone can save significant time in any infrastructure development cycle.

You Troubleshoot Deployments Faster

When deployments do fail, Kiro can help you understand why. Rather than manually cross-referencing CloudTrail logs and CloudFormation events, you can ask Kiro directly, and it will surface the relevant error context and suggest a fix. For example, if CloudTrail shows an AccessDenied error for a specific API call, Kiro can identify the missing permission and tell you exactly what needs to change in your deployment role.

You Learn While You Build

If you’re newer to CDK or expanding into unfamiliar AWS services, this Power doubles as a learning accelerator. You can ask Kiro to show you how to build a specific architecture pattern, and it will search CDK constructs and samples to give you multiple implementation approaches, not just one answer, but a range of options with context.

Security and Local Execution

A reasonable concern with any AI-assisted development tool is: where does my code go?

The IaC MCP Server that powers this Kiro capability runs entirely on your local machine. Your CloudFormation templates and CDK code are not sent to external services. The only external calls made are for documentation searches. AWS credentials are used from your existing local configuration, the same way the AWS CLI works, and communication between the server and Kiro happens over standard input/output with no network ports opened.

For teams working in regulated environments or with sensitive infrastructure, this local execution model is a meaningful architectural choice.

Getting Started

Installing the Power is straightforward from within the Kiro IDE. Navigate to the Powers panel in the sidebar, find “Build AWS infrastructure with CDK and CloudFormation” under the Recommended section, and install it. Once active, Kiro gains access to all the CDK and CloudFormation tools described above.

The Bigger Picture

CDK and CloudFormation are not going away. If anything, infrastructure as code is becoming more central to how teams build and operate on AWS, not less. The question isn’t whether you’ll use these tools; it’s how efficiently you’ll use them.

Kiro’s CDK and CloudFormation Power represents a meaningful shift in that equation. It brings documentation, validation, compliance checking, and troubleshooting directly into your development environment, reducing the context-switching that slows down infrastructure work and helping you build well-architected systems faster.

If you’re serious about AWS infrastructure development, this is worth adding to your workflow.

But here’s the thing: serverless is not a silver bullet.

After years of building on AWS, I’ve seen teams adopt serverless for everything — and sometimes pay the price in performance, cost, complexity, or all three. The best architects don’t just know when to use a tool. They know when not to.

In this article, I’ll walk you through five real-world use cases where going serverless is the wrong choice, and what you should consider instead.

1. Long-Running, Compute-Heavy Workloads

The Problem

AWS Lambda has a hard timeout of 15 minutes. If your workload takes longer than that, Lambda simply isn’t an option. But even workloads that fit within 15 minutes can be a poor match.

Think about:

• Video transcoding or rendering

• Large-scale data transformations (ETL)

• Machine learning model training

• Complex PDF generation from massive datasets

These tasks are CPU-intensive and often run for extended periods. Shoehorning them into Lambda means you’ll spend your time fighting the platform instead of leveraging it.

Why Serverless Fails Here

• 15-minute max execution time is a hard ceiling you can’t negotiate.

• CPU is allocated proportionally to memory in Lambda. To get meaningful compute power, you might need to allocate 4–10 GB of memory — even if you only need 512 MB of RAM. You’re paying for memory you don’t use just to get CPU.

• No GPU access. If your workload benefits from GPU acceleration, Lambda is out of the question.

• Orchestrating many short Lambda functions to chunk the work adds significant complexity and potential failure points.

What to Use Instead

• AWS Fargate (ECS) — Containerized long-running tasks without managing servers

• EC2 Spot Instances — Cost-effective heavy compute (batch jobs, rendering)

• AWS Batch — Managed batch processing at scale

• SageMaker — ML model training specifically

• Step Functions + Fargate — Orchestrated pipelines with long-running steps

A Practical Example

Let’s say you’re processing uploaded video files. Instead of Lambda:

S3 Upload Event → EventBridge → Fargate Task (ECS)

Fargate gives you configurable vCPU and memory, no time limits, and you only pay for the duration of the task. You still get the “no servers to manage” benefit without Lambda’s constraints.

2. High-Throughput, Latency-Sensitive Applications

The Problem

You’re building an application that needs to handle thousands of requests per second with consistent, single-digit millisecond response times. Think:

• Real-time bidding platforms

• High-frequency trading APIs

• Multiplayer game backends

• Real-time fraud detection at the edge

Why Serverless Fails Here

The biggest villain here is the cold start.

When Lambda spins up a new execution environment, there’s an initialization delay.

• Python, Node.js: 100–300 ms

• Java, .NET: 500 ms – 2+ seconds

For most applications, cold starts are a minor nuisance. For latency-critical systems, they’re a dealbreaker.

Yes, Provisioned Concurrency exists, and SnapStart helps with Java. But:

• Provisioned Concurrency is essentially pre-warming containers — which defeats the core serverless value proposition. You’re paying for idle compute.

• You still can’t guarantee tail latency (p99/p99.9) the way you can with a warm, long-running process.

• At high throughput, the API Gateway overhead (typically 10–30 ms) adds up and is hard to eliminate.

What to Use Instead

• ECS/EKS on Fargate or EC2 — Long-running containers with persistent connections and predictable latency.

• EC2 with Auto Scaling — Maximum control over the runtime, networking, and performance tuning.

• ElastiCache (Redis) — Pair with containers for ultra-low-latency data access.

The Key Takeaway

If your SLA says “p99 latency under 10 ms”, serverless will make that extremely difficult and expensive to achieve. Use always-on compute with connection pooling and warm caches.

3. Applications with Complex or Stateful Workflows (That Need Persistent Connections)

The Problem

Serverless functions are stateless and ephemeral by design. Each invocation is independent. There’s no shared memory, no local disk that persists, and no guarantee that the same instance handles consecutive requests.

This becomes painful when you need:

• WebSocket connections with complex server-side state

• Long-lived database connection pools

• In-memory caching across requests

• Sticky sessions

Why Serverless Fails Here

Database connections are the classic pain point. Every Lambda invocation may open a new connection to your relational database. Under load, you can easily exhaust your database’s connection limit.

100 concurrent Lambda invocations = 100 database connections
1,000 concurrent invocations = 💥 database connection limit exceeded

RDS Proxy helps by pooling connections, but it:

• Adds cost

• Adds latency (~5–15 ms per query overhead)

• Is another component to configure and monitor

• Doesn’t eliminate the fundamental mismatch — it just papers over it

In-memory state is another problem. If your application logic depends on keeping data in memory across requests (e.g., a game server tracking player positions, a collaborative editing backend), Lambda can’t help you. You’d have to externalize all state to DynamoDB, ElastiCache, or S3 — adding latency and complexity for every operation.

What to Use Instead

• ECS/Fargate with long-running containers that maintain connection pools and in-memory state.

• EC2 for maximum control over memory, connections, and runtime behavior.

• ElastiCache if you need shared in-memory state across instances.

• AppSync for managed GraphQL with real-time subscriptions (a serverless option that does handle WebSockets well, but for a specific use case).

When It’s a Judgment Call

If you’re building a standard REST API with a relational database, serverless can work — especially with RDS Proxy and moderate traffic. But if your application is connection-heavy or state-heavy, you’ll spend more time fighting the architecture than building features.

4. Predictable, Always-On, Steady-State Workloads

The Problem

Serverless pricing is brilliant for spiky, unpredictable, or low-traffic workloads. You pay per invocation, per millisecond of compute. When traffic is zero, your bill is zero.

But what about workloads that run 24/7 at a consistent, high volume?

• A backend API serving millions of requests per day, evenly distributed

• A stream processor consuming from Kinesis around the clock

• A WebSocket server with thousands of persistent connections

Why Serverless Fails Here

Let’s do some back-of-the-envelope math.

Scenario: An API handling 50 million requests/month, average execution time of 200 ms, with 512 MB memory allocated.

Lambda Cost:

Compute: 50M × 0.2s × 0.5 GB = 5,000,000 GB-seconds
Cost:    5,000,000 × $0.0000166667 = ~$83.33
Requests: 50M × $0.20/million     = ~$10.00
API Gateway: 50M × $1.00/million  = ~$50.00
                                    --------
Total:                              ~$143/month

Fargate Equivalent (2 tasks, 0.5 vCPU, 1 GB each):

vCPU:   2 × 0.5 × $0.04048/hr × 730 hrs = ~$29.55
Memory: 2 × 1 GB × $0.004445/hr × 730 hrs = ~$6.49
ALB:    ~$16.20 + LCU charges (~$5-10)     = ~$25.00
                                              --------
Total:                                       ~$61/month

That’s a ~57% cost reduction with Fargate — and the gap widens as traffic increases.

The Rule of Thumb

Ask yourself:

“Will my compute utilization be consistently above 20-30%?”

If yes, reserved/always-on compute (Fargate, EC2 Reserved Instances, or Savings Plans) will almost always be cheaper.

What to Use Instead

• Fargate with Auto Scaling — Steady containerized workloads with occasional spikes

• EC2 Reserved Instances / Savings Plans — Predictable, long-term workloads at the best price

• EKS — When you need Kubernetes orchestration at scale

The Hybrid Approach

The best architectures often mix serverless and containers:

• Use Lambda for event-driven, asynchronous tasks (S3 triggers, SNS handlers, cron jobs).

• Use Fargate/EC2 for the high-throughput, steady-state API layer.

You get the best of both worlds.

5. Complex Local Development and Debugging Requirements

The Problem

This one is less about production and more about developer experience — which matters more than many teams admit.

Serverless applications are inherently distributed. A single user action might involve:

API Gateway → Lambda → DynamoDB → DynamoDB Stream → Lambda → SNS → Lambda → SQS → Lambda

Try debugging that locally.

Why Serverless Fails Here

• Local emulation is imperfect. Tools like SAM CLI and LocalStack are helpful but don’t perfectly replicate IAM permissions, event source mappings, service integrations, or edge cases.

• “Console log” debugging is still the primary debugging strategy for many Lambda developers. Attaching a real debugger with breakpoints is possible but cumbersome.

• Integration testing is hard. You often need a deployed AWS environment to truly test your application, which slows down the feedback loop.

• Distributed tracing adds overhead. You’ll need X-Ray or third-party tools to understand request flows across services.

• Each developer needs their own cloud sandbox. Unlike a containerized app where you can docker-compose up and have a full environment locally, serverless often requires deploying to AWS — leading to shared-environment conflicts or the cost of per-developer AWS accounts.

When This Matters Most

• Large teams where developer productivity at scale is critical

• Complex, multi-service architectures with many interconnected functions

• Regulated industries where you need to reproduce and debug production issues quickly

• Teams new to serverless with existing expertise in containers or traditional architectures

What to Use Instead

If developer experience is a priority and your team is more productive with containers:

• Docker Compose + ECS/Fargate — Develop locally with Docker, deploy to Fargate. Nearly identical environments.

• EKS with Skaffold or Telepresence — Hot-reload Kubernetes development.

A Balanced View

To be fair, the serverless developer experience is improving rapidly. Tools like SST (Serverless Stack), AWS SAM Accelerate, and Lambda Powertools have made development significantly better. If you’re starting a greenfield project with a small team, serverless DX is often good enough.

But for large, complex systems — especially if your team has deep container expertise — forcing a serverless-first approach can meaningfully slow development velocity.

So... When SHOULD You Go Serverless?

After all that, let’s end on a positive note. Serverless is the right choice when:

1. Your traffic is spiky, unpredictable, or low-volume

2. You want to minimize operational overhead (no patching, no capacity planning)

3. You’re building event-driven architectures (S3 triggers, message processing, webhooks)

4. You need to ship fast with a small team

5. Your workloads are short-lived (seconds, not minutes)

6. You want automatic scaling from zero to massive without configuration

7. You’re building microservices, APIs, or background jobs with moderate latency requirements

The Bottom Line

The best cloud architects aren’t loyal to any single paradigm. They pick the right tool for the job.

Serverless is incredible — I use it extensively and recommend it often. But blindly applying it to every problem leads to over-engineered, expensive, and frustrating architectures.

Before going serverless, ask yourself:

1. Does my workload fit within Lambda’s execution limits?

2. Can I tolerate cold start latency?

3. Is my application fundamentally stateless?

4. Is my traffic pattern spiky or variable?

5. Can my team debug and develop effectively in a serverless model?

If the answer to any of these is “no”, consider containers, EC2, or a hybrid approach. There’s no shame in using a server. After all, serverless still runs on them.

The good news? You can dramatically reduce your risk by following a clear set of steps in the first 24 hours. This article is that checklist.

Let’s get started.

Why the First 24 Hours Matter

New AWS accounts are often in their most vulnerable state right after creation. Default settings are permissive, there’s no monitoring in place, and credentials are frequently mishandled. Automated bots constantly scan for exposed keys and misconfigured resources. Stories of developers waking up to five-figure AWS bills after accidentally committing credentials to GitHub are not myths, they happen regularly.

Treating security as a “day one” priority is not paranoia. It’s engineering discipline.

Phase 1: Protect the Root Account

The root account is the single most powerful identity in your AWS environment. It has unrestricted access to everything, and it cannot be limited by IAM policies. Your first actions should be to lock it down.

1. Set a Strong, Unique Password for the Root User

The password you chose during sign-up might have been rushed. Go to the account settings and make sure the root password is long, random, and stored in a reputable password manager. Do not reuse a password from another service.

2. Enable Multi-Factor Authentication (MFA) on the Root Account

This is the single most important step on this entire list. Go to the IAM console, select the root user, and enable MFA. A hardware security key (such as a YubiKey) is the strongest option. A virtual MFA app like Google Authenticator or Authy is a solid alternative. Avoid SMS-based MFA if possible, as it is vulnerable to SIM-swapping attacks.

3. Do Not Generate Access Keys for the Root Account

The root user should never have programmatic access keys. If keys already exist for the root account, delete them immediately. There is no legitimate operational reason to use root access keys.

4. Store Root Credentials Securely and Rarely Use Them

After setting up the root account, you should almost never log into it again. Store the credentials and MFA recovery codes in a secure vault (a physical safe or an encrypted password manager with restricted access). The root account should only be used for the handful of tasks that specifically require it, such as changing the account’s support plan or closing the account.

Phase 2: Set Up Proper IAM Identity Management

Now that root is locked away, you need a secure way for humans and services to interact with the account.

5. Create an IAM Admin User or Use AWS IAM Identity Center

Create a dedicated IAM user (or, even better, use IAM Identity Center if you’re working within AWS Organizations) with administrative permissions. This is the identity you’ll use for day-to-day management — not root.

If you’re managing a single account, an IAM user in the “Administrators” group is sufficient. If you’re managing multiple accounts, invest the time to set up IAM Identity Center (formerly AWS SSO) from the start. It will save you enormous headaches later.

6. Enable MFA for All Human IAM Users

Every person who can log into the AWS console should have MFA enabled. No exceptions. Consider creating an IAM policy that denies all actions until MFA is activated, which encourages users to set it up immediately upon first login.

7. Apply the Principle of Least Privilege

Resist the temptation to give every user or role full admin access. Start with the minimum permissions required for each person or service, and expand only when there is a justified need. Use AWS managed policies as a starting point, but review what they allow. The “PowerUserAccess” policy, for example, is far more permissive than most people realize.

8. Create an IAM Password Policy

Configure a strong password policy for IAM users in your account. Enforce minimum length (at least 14 characters), require a mix of character types, and enable password expiration if your organization requires it. This is found under IAM > Account settings.

Phase 3: Enable Logging and Monitoring

You can’t protect what you can’t see. Visibility into account activity is non-negotiable.

9. Enable AWS CloudTrail in All Regions

CloudTrail records every API call made in your account. It’s your audit trail, your forensic evidence, and your early warning system. Create a trail that applies to all regions and logs to a dedicated S3 bucket. Enable log file validation so you can verify that logs haven’t been tampered with.

This is one of those services that costs very little but provides enormous value. Do not skip it.

10. Enable CloudTrail Log File Integrity Validation

When you set up CloudTrail, enable digest file delivery. This allows you to later verify that no log files were modified or deleted after delivery. In the event of a security incident, you need to trust your logs.

11. Turn On AWS Config

AWS Config continuously monitors and records your resource configurations and evaluates them against rules. Enable it in all regions. It answers questions like: “When did this security group change?” and “Is this S3 bucket publicly accessible?”

You can start with the AWS Config conformance packs, which provide pre-built rule sets for common compliance frameworks.

12. Enable Amazon GuardDuty

GuardDuty is a threat detection service that analyzes CloudTrail logs, VPC flow logs, and DNS logs to identify malicious activity. It can detect things like cryptocurrency mining, compromised credentials, and unusual API calls. Enabling it takes about 30 seconds, and it starts working immediately.

There is a 30-day free trial, and the ongoing cost is typically very reasonable relative to the protection it provides.

13. Set Up Billing Alerts and Anomaly Detection

Security incidents often show up as billing anomalies first. Go to the Billing and Cost Management console and enable the following:

• AWS Budgets: Create a monthly budget with a threshold alert. Even a simple “notify me if my spend exceeds $50” can save you from a surprise bill.

• Cost Anomaly Detection: This service uses machine learning to detect unusual spending patterns and alert you automatically.

An unexpected spike in EC2 or Lambda charges could be the first sign that someone is using your account for unauthorized purposes.

Phase 4: Secure Your Network Defaults

Every new AWS account comes with default networking resources that are more permissive than you might want.

14. Review and Restrict Default Security Groups

Every VPC comes with a default security group that allows all outbound traffic and allows all inbound traffic from resources assigned to the same security group. While this isn’t publicly open, it’s more permissive than most workloads need. Adopt the practice of creating custom, purpose-specific security groups and never attaching the default security group to resources.

15. Delete or Ignore the Default VPC (Use Custom VPCs Instead)

The default VPC in each region comes with public subnets and an internet gateway already attached. It’s designed for convenience, not security. For any real workload, create a custom VPC with a deliberate network design — private subnets for backend services, public subnets only where necessary, and proper route table configuration.

You don’t necessarily need to delete the default VPC (some AWS services expect it to exist), but make a rule to never deploy production workloads into it.

16. Block Public Access to S3 at the Account Level

One of the most common AWS security headlines involves publicly exposed S3 buckets. AWS now provides an account-level setting called “S3 Block Public Access.” Enable all four options at the account level. If a specific bucket later needs public access (for static website hosting, for example), you can override it deliberately for that one bucket. The default should be locked down.

Phase 5: Establish Account-Level Protections

These steps create safety nets that protect you across the entire account.

17. Enable EBS Default Encryption

Navigate to the EC2 console and enable default EBS encryption for each region you plan to use. This ensures that every new EBS volume is encrypted automatically, without requiring the person launching the instance to remember to check a box. You can use the AWS-managed key or specify a customer-managed KMS key.

18. Configure Account-Level Contacts

Under Account Settings, make sure the security, billing, and operations contact fields are filled in with valid email addresses. AWS uses these contacts to reach you in the event of abuse notifications or security issues. If these emails go to an unmonitored inbox, you might miss a critical warning.

19. Enable AWS Security Hub (Optional but Recommended)

Security Hub aggregates findings from GuardDuty, Config, IAM Access Analyzer, and other services into a single dashboard. It also runs automated security checks against industry benchmarks like CIS AWS Foundations. If you’ve already enabled the services listed above, Security Hub ties everything together and gives you a centralized security posture score.

20. Enable IAM Access Analyzer

IAM Access Analyzer helps you identify resources in your account that are shared with an external entity — for example, an S3 bucket policy that grants access to another AWS account, or an IAM role that can be assumed externally. Enable it in each region. It runs continuously and alerts you when it finds unintended external access.

Phase 6: Plan for the Worst

Security isn’t just about prevention. You also need to prepare for the possibility that something goes wrong.

21. Document Your Incident Response Plan

Even a simple one-page document is better than nothing. Answer these questions in advance:

• Who is responsible for responding to a security alert?

• How do we revoke compromised credentials?

• Where are our logs stored and how do we access them?

• Who do we contact at AWS for support?

Under pressure during an incident is the worst time to figure out these answers.

22. Know How to Contact AWS Support

If your account is compromised, you may need to contact AWS quickly. Make sure you know how to open a support case, and consider whether your current support plan (Basic, Developer, Business, or Enterprise) provides the response time you’d need in an emergency. Business-level support or above gives you 24/7 access to Cloud Support Engineers.

23. Create an Emergency “Break Glass” Procedure for Root Access

Since you’ve locked down root access (as described in Phase 1), document the procedure for accessing it in an emergency. Who has access to the password vault? Where is the MFA device stored? What approvals are needed? This should be written down, tested, and reviewed periodically.

Final Thoughts

None of these steps are difficult. Most take less than five minutes. But together, they form a security foundation that will protect you from the vast majority of common AWS threats.

The most expensive security incident is the one you could have prevented with ten minutes of configuration on day one. Don’t learn that lesson the hard way.

Bookmark this checklist. Share it with your team. Run through it every time a new account is created. Your future self will thank you.

In this article, we’ll break down the differences between SQL and NoSQL databases on AWS, explore the main services available, and give you a practical decision framework so you can choose with confidence.

Understanding the Fundamentals

Before diving into AWS services, let’s make sure we’re on the same page about what sets these two paradigms apart.

SQL (Relational Databases)

Relational databases store data in tables with predefined schemas made up of rows and columns. They use Structured Query Language (SQL) to query and manipulate data and enforce relationships between tables through foreign keys and joins.

Key characteristics:

• Structured schema: You define your tables, columns, and data types upfront.

• ACID compliance: Transactions are Atomic, Consistent, Isolated, and Durable.

• Strong consistency: Reads always return the most recent write.

• Vertical scaling: Traditionally scaled by adding more power (CPU, RAM) to a single server.

• Complex queries: Excellent support for JOINs, aggregations, and ad-hoc queries.

NoSQL (Non-Relational Databases)

NoSQL databases break away from the rigid tabular model. They come in several flavors, document, key-value, wide-column, and graph, each optimized for different access patterns.

Key characteristics:

• Flexible schema: Fields can vary from record to record.

• BASE model: Basically Available, Soft state, Eventually consistent.

• Horizontal scaling: Designed to scale out across many nodes.

• High throughput: Optimized for massive read/write workloads.

• Simple queries: Best suited for known access patterns rather than ad-hoc queries.

SQL Databases on AWS

Amazon RDS (Relational Database Service)

Amazon RDS is a managed service that supports six popular relational engines:

• MySQL

• PostgreSQL

• MariaDB

• Oracle

• SQL Server

• Amazon Aurora (MySQL & PostgreSQL compatible)

When to use RDS:

• Your data is highly relational with complex relationships.

• You need ACID-compliant transactions (e.g., financial systems).

• Your team is experienced with SQL.

• You want a managed service but with a traditional relational model.

Example use cases: E-commerce order management, HR systems, CMS platforms, ERP systems.

Amazon Aurora

Aurora deserves special attention. It’s AWS’s cloud-native relational database, compatible with MySQL and PostgreSQL but re-engineered for the cloud.

Why Aurora stands out:

• 5x throughput of standard MySQL, 3x of standard PostgreSQL.

• Storage auto-scales up to 128 TB.

• 6-way replication across 3 Availability Zones.

• Supports up to 15 read replicas with minimal lag.

• Aurora Serverless v2 scales capacity automatically based on demand.

When to use Aurora over standard RDS:

• You need higher performance and availability.

• Your workload has unpredictable traffic (Aurora Serverless).

• You want automatic storage scaling.

NoSQL Databases on AWS

Amazon DynamoDB

DynamoDB is AWS’s flagship fully managed key-value and document database. It’s designed for applications that need consistent, single-digit millisecond latency at any scale.

Key features:

• Serverless: No servers to manage, patch, or provision.

• Auto-scaling: Throughput adjusts to traffic automatically (on-demand mode).

• Global Tables: Multi-region, multi-active replication.

• DAX (DynamoDB Accelerator): In-memory caching for microsecond reads.

• Streams: Capture item-level changes for event-driven architectures.

When to use DynamoDB:

• You need extreme scale and low latency.

• Your access patterns are well-defined and predictable.

• You’re building serverless applications (Lambda + API Gateway + DynamoDB).

• You need a simple key-value or document store.

Example use cases: Gaming leaderboards, IoT telemetry, session management, shopping carts, real-time bidding.

Amazon DocumentDB (MongoDB Compatible)

If your team already uses MongoDB, DocumentDB provides a managed, MongoDB-compatible document database.

When to use DocumentDB:

• You’re migrating from MongoDB.

• You need flexible JSON document storage with rich query capabilities.

• You want managed infrastructure without running your own MongoDB clusters.

Amazon ElastiCache (Redis & Memcached)

ElastiCache provides in-memory key-value stores for caching and real-time workloads.

When to use ElastiCache:

• You need sub-millisecond response times.

• You’re caching frequently accessed data from another database.

• You need real-time features like session stores, pub/sub messaging, or leaderboards.

Amazon Neptune

Neptune is a graph database for highly connected datasets.

When to use Neptune:

• Social networks, recommendation engines, fraud detection.

• Your queries involve traversing complex relationships between entities.

Head-to-Head Comparison

Decision Framework: 7 Questions to Ask Yourself

Use these questions to guide your choice:

1. How relational is your data?

Highly relational (many joins, foreign keys, normalized tables) → SQL
Loosely structured or denormalized → NoSQL

2. How complex are your queries?

Need ad-hoc queries, complex reporting, aggregations → SQL
Known, simple access patterns (get by key, query by index) → NoSQL

3. What’s your scale?

Moderate, predictable traffic → SQL (RDS/Aurora) handles this well
Massive, spiky, or unpredictable traffic → NoSQL (DynamoDB) scales seamlessly

4. What are your latency requirements?

Single-digit millisecond → Both work
Microsecond → DynamoDB + DAX or ElastiCache

5. Do you need ACID transactions?

Complex multi-table transactions → SQL
Simple transactions → DynamoDB Transactions may be sufficient

6. Are you building serverless?

DynamoDB integrates natively with Lambda, API Gateway, and EventBridge.
RDS in serverless architectures can be problematic (connection limits), though Aurora Serverless v2 and RDS Proxy help.

7. What’s your budget model preference?

Predictable monthly cost → RDS (reserved instances)
Pay-per-use → DynamoDB on-demand mode

Real-World Scenarios

Scenario 1: E-Commerce Platform

Requirements: Product catalog, orders, inventory, payments.

Recommendation: Aurora PostgreSQL + DynamoDB (hybrid)

• Use Aurora for orders and payments (ACID transactions, complex queries).

• Use DynamoDB for the product catalog and shopping cart (high read throughput, flexible attributes).

• Use ElastiCache Redis for session management and caching.

Scenario 2: Real-Time Gaming Backend

Requirements: Leaderboards, player profiles, matchmaking, millions of concurrent users.

Recommendation: DynamoDB

• Scales horizontally to handle millions of players.

• Single-digit millisecond latency for leaderboard reads/writes.

• Global Tables for multi-region play.

Scenario 3: Financial Reporting System

Requirements: Complex queries, regulatory compliance, audit trails, historical analysis.

Recommendation: Aurora PostgreSQL

• Full ACID compliance for transaction integrity.

• Complex SQL queries for financial reporting.

• Point-in-time recovery for audit requirements.

Scenario 4: IoT Data Platform

Requirements: Millions of devices sending telemetry every second.

Recommendation: DynamoDB + Amazon Timestream

• DynamoDB for device state and metadata.

• Timestream (purpose-built time-series DB) for telemetry data.

The Hybrid Approach: Why Not Both?

In practice, many production systems on AWS use both SQL and NoSQL databases. This is called polyglot persistence, using the best database for each specific job.

┌──────────────┐     ┌──────────────────┐     ┌──────────────┐
│   Frontend   │────▶│   API Gateway +  │────▶│  DynamoDB    │
│   (React)    │     │   Lambda         │     │  (Catalog,   │
└──────────────┘     └──────┬───────────┘     │   Sessions)  │
                            │                 └──────────────┘
                            │
                            ▼
                     ┌──────────────────┐     ┌──────────────┐
                     │   ECS / EKS      │────▶│  Aurora       │
                     │   (Order Service)│     │  (Orders,    │
                     └──────────────────┘     │   Payments)  │
                                              └──────────────┘

Tips for a hybrid approach:

• Use DynamoDB for high-throughput, simple-access workloads.

• Use Aurora for transactional and reporting workloads.

• Use ElastiCache as a caching layer in front of either.

• Use Amazon EventBridge or DynamoDB Streams to sync data between databases when needed.

Final Thoughts

There’s no universal “best” database, only the best database for your specific use case. The most important thing is to start with your access patterns and requirements, not with the technology.

Ask yourself:

• What does my data look like?

• How will I query it?

• How much will it scale?

• What consistency guarantees do I need?

Let the answers guide you to the right choice. And remember, on AWS, you’re never locked into one paradigm. Embrace polyglot persistence and use the right tool for each job.

Here’s the truth: VPCs are simpler than they seem. Once you understand the core concepts and how they fit together, everything else clicks into place. The terminology can feel overwhelming at first, CIDR blocks, route tables, gateways, but each of these is just a small, logical piece of a bigger puzzle. This guide will walk you through VPCs step-by-step, with visual explanations that make sense. By the end, you won’t just understand VPCs, you’ll understand why they’re designed the way they are.

What Is a VPC, Really?

Think of a VPC as your own private section of the AWS cloud. It’s like having your own data center, but virtual. Inside this space, you can launch AWS resources (like EC2 instances, databases, and Lambda functions) and control exactly how they communicate with each other and the outside world.

To make this even more concrete, imagine you’re renting an entire floor in a massive office building. The building is AWS’s cloud infrastructure, shared among millions of tenants. But your floor? That’s entirely yours. You decide how to partition the rooms, who gets access to what, which doors lead outside, and which rooms are locked away from public view. Other tenants can’t wander into your space, and you can’t wander into theirs, unless you both explicitly agree to connect your floors together.

Every AWS account comes with a default VPC in each region, pre-configured so you can start launching resources immediately. However, for production workloads, you’ll almost always want to create a custom VPC where you have full control over the network design. The default VPC is convenient for experimentation, but it makes assumptions about your architecture that may not align with your security or organizational needs.

The key benefit: Complete control over your network environment, IP addresses, subnets, route tables, and network gateways. You decide what’s exposed, what’s hidden, and how every piece communicates.

The Building Blocks

Let’s break down the essential components you need to understand:

1. VPC (Virtual Private Cloud)

What it is: The container for your entire network. It’s the foundational layer upon which everything else is built.

Key details:

• You define an IP address range using CIDR notation (e.g., 10.0.0.0/16). CIDR stands for Classless Inter-Domain Routing, and it’s simply a compact way of expressing a range of IP addresses. The /16 part is called the prefix length and determines how many IP addresses are available within the range. A smaller number after the slash means a larger network, /16 gives you 65,536 addresses, while /24 gives you only 256.

• Choosing your CIDR block is one of the most important early decisions because you cannot change it after creation (though you can add secondary CIDR blocks later). If you choose a range that’s too small, you’ll run out of IP addresses as your infrastructure grows. If you choose one that overlaps with another VPC or your on-premises network, you’ll run into conflicts when you try to connect them later.

• Each VPC is isolated from other VPCs by default. This is a fundamental security property. Even if two VPCs use the exact same CIDR block, they cannot communicate unless you explicitly set up a connection between them (using VPC Peering or a Transit Gateway). This isolation means a misconfiguration in one VPC won’t accidentally leak traffic into another.

• A VPC exists within a single AWS Region but spans all of that region’s Availability Zones. This is important: your VPC isn’t confined to a single data center. It’s a regional construct that gives you the ability to distribute resources across multiple physically separated facilities.

Visual concept:

┌───────────────────────────────────┐
│         VPC (10.0.0.0/16)         │
│                                   │
│  [Your AWS resources live here]   │
│                                   │
└───────────────────────────────────┘

2. Subnets

What they are: Subdivisions of your VPC’s IP address range. If the VPC is your floor in the office building, subnets are the individual rooms you create within it.

Why you need them: To organize resources and control access to the internet. Subnets give you the ability to apply different network rules and routing behaviors to different groups of resources. Without subnets, every resource in your VPC would have to follow the same networking rules, and that’s not practical when some resources need public exposure and others need to stay hidden.

Two types:

• Public subnets: Resources here can communicate directly with the internet. These are for things that need to be reachable by users or external systems, web servers, load balancers, bastion hosts, and similar front-facing infrastructure.

• Private subnets: Resources here cannot directly access the internet and, crucially, cannot be directly reached from the internet. This makes them far more secure. These are ideal for databases, application servers, internal microservices, caches, and anything that doesn’t need a public-facing presence.

It’s important to understand that there’s nothing inherently “public” or “private” about a subnet itself. What makes a subnet public or private is its route table configuration, specifically, whether its route table includes a route to an Internet Gateway. This is a common source of confusion for beginners who think the distinction is set at creation time.

Each subnet lives within a single Availability Zone and cannot span multiple AZs. This is by design, it allows AWS to provide strong isolation guarantees. If one AZ experiences issues, subnets in other AZs remain unaffected. This is why best practice dictates creating matching subnets across multiple Availability Zones, so your application can survive the loss of an entire data center.

Each subnet also has a small number of reserved IP addresses that AWS uses for internal purposes. In every subnet, the first four IP addresses and the last IP address are reserved. For a /24 subnet (256 addresses), that means 251 are actually usable. This is a small detail, but it matters when you’re planning tightly-sized subnets.

Visual concept:

┌──────────────────────────────────────────────┐
│              VPC (10.0.0.0/16)               │
│                                              │
│  ┌──────────────────┐  ┌──────────────────┐  │
│  │  Public Subnet   │  │  Private Subnet  │  │
│  │  10.0.1.0/24     │  │  10.0.2.0/24     │  │
│  │                  │  │                  │  │
│  │  [Web Servers]   │  │  [Databases]     │  │
│  └──────────────────┘  └──────────────────┘  │
│                                              │
└──────────────────────────────────────────────┘

Best practice: Create subnets in multiple Availability Zones for high availability. A common pattern is to have at least two public subnets and two private subnets, each pair spread across two different AZs. Some organizations go further and use three AZs for even greater resilience.

3. Internet Gateway (IGW)

What it is: The door between your VPC and the public internet. It’s a horizontally scaled, redundant, and highly available component managed entirely by AWS.

What it does: Allows resources in public subnets to communicate with the internet, both sending requests out and receiving requests in. Without an Internet Gateway, your VPC is a completely sealed-off network with no path to the outside world.

The Internet Gateway serves two critical functions. First, it acts as a target in your route table for internet-bound traffic, giving your resources a path to follow when they need to reach an external address. Second, it performs Network Address Translation (NAT) for instances that have been assigned a public IPv4 address. When traffic leaves your instance, the IGW replaces the private IP with the public IP; when responses come back, it reverses the translation. This is why simply attaching an IGW isn’t enough, your instances also need public IP addresses (or Elastic IPs) and the correct route table entries to actually use it.

Visual concept:

                    Internet
                       ↕
              ┌────────────────┐
              │ Internet       │
              │ Gateway (IGW)  │
              └────────────────┘
                       ↕
┌────────────────────────────────────┐
│           VPC (10.0.0.0/16)        │
│                                    │
│  ┌────────────────┐                │
│  │ Public Subnet  │                │
│  │ 10.0.1.0/24    │                │
│  │                │                │
│  │ [Web Server]   │                │
│  └────────────────┘                │
└────────────────────────────────────┘

Key point: You attach one IGW per VPC. You cannot attach multiple Internet Gateways to the same VPC, and you cannot share an IGW across VPCs. It’s a one-to-one relationship. Without it, nothing in your VPC can reach the internet, and nothing on the internet can reach your VPC. It’s also worth noting that the IGW itself doesn’t impose bandwidth limits or become a bottleneck, AWS manages its scaling transparently.

4. Route Tables

What they are: Sets of rules (called routes) that determine where network traffic is directed. Every single packet of data that moves through your VPC is guided by a route table.

How they work: Each subnet is associated with exactly one route table, and that route table tells traffic where to go based on its destination. When a resource in your subnet sends a packet, the VPC examines the destination IP address, looks it up in the route table, and forwards the packet to the matching target. If there are multiple matching routes, the most specific route (the one with the longest prefix) wins.

Every VPC comes with a main route table automatically. Any subnet that isn’t explicitly associated with a custom route table will use the main route table by default. This is a subtle but important point, it means newly created subnets silently inherit the main route table’s behavior. For this reason, many practitioners recommend keeping the main route table restrictive (private) and explicitly assigning custom route tables with internet access only to the subnets that need it. This way, if someone creates a new subnet and forgets to assign a route table, it defaults to private rather than accidentally becoming public.

Example routes:

• 10.0.0.0/16 → local : Traffic destined for any IP within the VPC stays inside the VPC. This route is automatically present in every route table and cannot be removed. It’s what allows your resources to communicate with each other across subnets.

• 0.0.0.0/0 → igw-xxxxx : All other traffic (anything not matching a more specific route) goes to the Internet Gateway. This is the route that makes a subnet “public.” The 0.0.0.0/0 destination is a catch-all, often called the default route.

Visual concept:

Public Subnet Route Table:
┌─────────────────┬──────────────┐
│ Destination     │ Target       │
├─────────────────┼──────────────┤
│ 10.0.0.0/16     │ local        │
│ 0.0.0.0/0       │ igw-xxxxx    │
└─────────────────┴──────────────┘

Private Subnet Route Table:
┌─────────────────┬──────────────┐
│ Destination     │ Target       │
├─────────────────┼──────────────┤
│ 10.0.0.0/16     │ local        │
└─────────────────┴──────────────┘

The difference: Public subnets have a route to the IGW; private subnets don’t. That single route entry is literally the only thing that separates a “public” subnet from a “private” one. Route tables can also contain routes pointing to other targets like NAT Gateways, VPC Peering connections, Transit Gateways, VPN connections, and VPC endpoints, which is how more complex architectures are built.

5. NAT Gateway

What it is: A managed service that allows resources in private subnets to initiate outbound connections to the internet (for software updates, API calls, downloading patches, etc.) without exposing them to inbound internet traffic. It performs Network Address Translation, replacing the private IP address of the originating resource with its own public IP address before forwarding the request to the internet.

Why you need it: Your database in a private subnet needs to download security patches, your application server needs to call a third-party API, or your Lambda function in a private subnet needs to reach an external webhook. But you don’t want any of these resources to be directly reachable from the internet. The NAT Gateway solves this by acting as a one-way intermediary, it allows traffic out but blocks unsolicited traffic in.

Visual concept:

                    Internet
                       ↕
              ┌────────────────┐
              │ Internet       │
              │ Gateway (IGW)  │
              └────────────────┘
                       ↕
┌──────────────────────────────────────────────┐
│              VPC (10.0.0.0/16)               │
│                                              │
│  ┌────────────────┐    ┌─────────────────┐   │
│  │ Public Subnet  │    │ Private Subnet  │   │
│  │ 10.0.1.0/24    │    │ 10.0.2.0/24     │   │
│  │                │    │                 │   │
│  │ [NAT Gateway]  │←───│ [Database]      │   │
│  └────────────────┘    └─────────────────┘   │
│                                              │
└──────────────────────────────────────────────┘

How it works:

1. The database initiates an outbound connection (e.g., to download a security patch).

2. The private subnet’s route table sends internet-bound traffic (0.0.0.0/0) to the NAT Gateway in the public subnet.

3. The NAT Gateway replaces the database’s private IP address with its own public Elastic IP address and forwards the traffic to the Internet Gateway.

4. The IGW sends the request out to the internet.

5. The response comes back through the same path in reverse, IGW to NAT Gateway, which translates the address back and forwards the response to the database.

The key security property here is that while the database can reach out to the internet, no one on the internet can initiate a connection to the database. The NAT Gateway will simply drop any unsolicited inbound traffic.

Important architectural consideration: A NAT Gateway is deployed into a specific subnet within a specific Availability Zone. If that AZ goes down, resources in private subnets in other AZs that depend on that NAT Gateway will lose their internet access. This is why production architectures deploy a NAT Gateway in each AZ and configure each private subnet to route through the NAT Gateway in its own AZ. This adds cost but ensures that an AZ failure doesn’t cascade into a networking failure for your private resources.

Cost note: NAT Gateways cost approximately $0.045/hour (about $32/month) plus data processing charges of $0.045 per GB. In a multi-AZ setup with two NAT Gateways, that’s roughly $64/month before any data transfer. For learning environments or development workloads, you can use a NAT Instance (a regular EC2 instance configured to perform NAT) to save money, though it won’t offer the same availability, bandwidth, or managed maintenance that a NAT Gateway provides. Some teams also explore VPC endpoints as a way to avoid NAT Gateway costs entirely for traffic destined to supported AWS services like S3 or DynamoDB.

6. Security Groups

What they are: Virtual firewalls that control inbound and outbound traffic at the instance level (more precisely, at the network interface level). Every EC2 instance, RDS database, Lambda function in a VPC, and many other AWS resources are associated with one or more Security Groups.

How they work: You define rules that allow specific traffic. This is an important distinction: Security Groups are allow-only. You cannot write a rule that explicitly denies traffic. If traffic doesn’t match any allow rule, it is implicitly denied. This makes Security Groups relatively straightforward to reason about, if it’s not explicitly permitted, it’s blocked.

Example rules:

Web Server Security Group:
Inbound:
- Allow HTTP (port 80) from 0.0.0.0/0 (anywhere)
- Allow HTTPS (port 443) from 0.0.0.0/0
- Allow SSH (port 22) from your IP only

Outbound:
- Allow all traffic (default)

Database Security Group:
Inbound:
- Allow MySQL (port 3306) from Web Server Security Group only

Outbound:
- Allow all traffic

One of the most powerful features of Security Groups is the ability to reference other Security Groups as sources or destinations in your rules. In the example above, the database Security Group doesn’t allow MySQL traffic from a specific IP address, it allows it from any resource associated with the Web Server Security Group. This means if you add a new web server and attach the same Security Group, it automatically gains database access without any rule changes. This creates a dynamic, self-maintaining security model that scales with your infrastructure.

Key concept: Security Groups are stateful, if you allow inbound traffic on a port, the corresponding response traffic is automatically allowed outbound, regardless of the outbound rules. Likewise, if an instance initiates an outbound connection, the response is automatically allowed inbound. This means you don’t need to worry about creating matching rules for both directions of a conversation, which significantly reduces the complexity of your firewall configuration.

Another important behavior: Security Groups evaluate all rules before making a decision. Unlike NACLs (which process rules in order and stop at the first match), Security Groups aggregate all rules and allow traffic if any rule permits it. This means you never have to worry about rule ordering within a Security Group.

7. Network ACLs (NACLs)

What they are: An additional layer of security that operates at the subnet level. While Security Groups wrap around individual resources, NACLs wrap around entire subnets, filtering traffic as it enters and exits the subnet boundary.

Difference from Security Groups:

• NACLs are stateless, you must explicitly write rules for both inbound and outbound traffic. If you allow inbound HTTP traffic on port 80, you must also create an outbound rule allowing the response traffic (which typically uses an ephemeral port in the range 1024–65535). Forgetting the outbound rule is one of the most common NACL mistakes, and it results in traffic appearing to be silently dropped.

• NACLs support both allow and deny rules, unlike Security Groups which only support allow rules. This makes NACLs useful for explicitly blocking specific IP addresses or ranges, for example, blocking a known malicious IP that’s attempting to probe your infrastructure.

• NACLs process rules in order, starting from the lowest numbered rule and stopping at the first match. This means rule ordering matters significantly. A common pattern is to use low-numbered rules (like 100, 200, 300) for your specific allow/deny rules, leaving gaps so you can insert new rules later without renumbering everything.

• NACLs apply to all resources within a subnet automatically. You don’t attach a NACL to an individual instance, every resource in the subnet is subject to the NACL’s rules, with no exceptions.

• Each subnet must be associated with exactly one NACL. If you don’t explicitly assign one, the subnet uses the VPC’s default NACL, which allows all inbound and outbound traffic. Custom NACLs, by contrast, deny all traffic by default until you add rules, another common gotcha for beginners.

Think of NACLs and Security Groups as two concentric walls of defense. Traffic entering a subnet first passes through the NACL. If the NACL allows it, the traffic then reaches the Security Group attached to the target resource. Both must permit the traffic for it to get through. This is an example of defense in depth, even if one layer is misconfigured, the other layer can still provide protection.

When to use them: Most beginners can stick with Security Groups for day-to-day access control. NACLs are most useful when you need subnet-wide rules, when you need to explicitly deny traffic from specific sources, or when your organization’s compliance requirements mandate multiple layers of network filtering. In many production environments, NACLs are kept relatively permissive while Security Groups do the heavy lifting of fine-grained access control.

Putting It All Together: A Complete VPC Architecture

Here’s a production-ready VPC setup:

                         Internet
                            ↕
                   ┌────────────────┐
                   │ Internet       │
                   │ Gateway (IGW)  │
                   └────────────────┘
                            ↕
┌─────────────────────────────────────────────────────┐
│                  VPC (10.0.0.0/16)                  │
│                                                     │
│  Availability Zone A          Availability Zone B   │
│  ┌──────────────────┐        ┌──────────────────┐   │
│  │ Public Subnet    │        │ Public Subnet    │   │
│  │ 10.0.1.0/24      │        │ 10.0.3.0/24      │   │
│  │                  │        │                  │   │
│  │ [Web Server A]   │        │ [Web Server B]   │   │
│  │ [NAT Gateway A]  │        │ [NAT Gateway B]  │   │
│  └──────────────────┘        └──────────────────┘   │
│          ↕                           ↕              │
│  ┌──────────────────┐        ┌──────────────────┐   │
│  │ Private Subnet   │        │ Private Subnet   │   │
│  │ 10.0.2.0/24      │        │ 10.0.4.0/24      │   │
│  │                  │        │                  │   │
│  │ [Database A]     │        │ [Database B]     │   │
│  └──────────────────┘        └──────────────────┘   │
│                                                     │
└─────────────────────────────────────────────────────┘

Why this architecture works:

• High availability: Resources are distributed across multiple Availability Zones. If AZ-A experiences a hardware failure, a power outage, or a network issue, AZ-B continues to serve traffic. Your application stays online because it doesn’t depend on any single physical location.

• Security: Databases sit in private subnets with no direct internet access. The only way to reach them is through the web servers (controlled by Security Groups) or via internal networking. This dramatically reduces the attack surface for your most sensitive data.

• Internet access: NAT Gateways in each AZ ensure that private resources can still reach the internet for necessary outbound tasks, operating system patches, third-party API calls, package downloads, without compromising their isolation from inbound internet traffic. Each private subnet routes through the NAT Gateway in its own AZ, so an AZ failure doesn’t cut off internet access for the other AZ’s private resources.

• Scalability: An Application Load Balancer (which would sit in the public subnets) distributes incoming user traffic across web servers in both AZs. As demand grows, you can add more instances behind the load balancer, or use Auto Scaling Groups to add and remove them automatically based on metrics like CPU utilization or request count.

This architecture is often extended with additional subnet tiers. Many organizations add a third tier, sometimes called an “isolated” or “data” tier, for resources that should have no internet access at all, not even outbound. You might also see dedicated subnets for things like Elasticache clusters, internal load balancers, or container orchestration infrastructure. The pattern stays the same; you’re just adding more rooms to the floor plan.

Conclusion

VPCs don’t have to be intimidating. At their core, they’re built from a handful of straightforward concepts: a VPC gives you an isolated network, subnets help you organize and secure your resources, an Internet Gateway connects you to the outside world, route tables direct traffic, NAT Gateways let private resources reach the internet safely, and Security Groups and NACLs act as your gatekeepers.

Once you understand how these pieces snap together, you’re not just following tutorials, you’re making informed decisions about how your infrastructure should work. You’ll understand why a database should live in a private subnet, why a route table needs a specific entry, and why Security Groups reference each other instead of hard-coded IP addresses.

Here’s what I’d recommend as your next steps:

• Get hands-on. Create a VPC from scratch in the AWS Console (not the default one). Set up a public subnet, a private subnet, an Internet Gateway, and a route table. Launch an EC2 instance in the public subnet and verify you can SSH into it. Then launch one in the private subnet and observe that you can’t. Break things on purpose, remove the route to the IGW and see what happens. Remove the Security Group rule for SSH and watch the connection fail. These small experiments will teach you more than reading ever could.

• Start simple. You don’t need multi-AZ NAT Gateways on day one. Build the basic architecture first, one public subnet, one private subnet, one AZ. Get comfortable with how traffic flows. Then layer in high availability by duplicating the setup across a second AZ. Add a load balancer. Add a NAT Gateway. Each addition will make more sense because you understand the foundation it’s building on.

• Explore Infrastructure as Code. Once you’re comfortable building VPCs manually, try recreating the same setup with CloudFormation or Terraform. Defining your VPC in code forces you to understand every dependency and every relationship between components, you can’t click “next” and let the console fill in defaults. It’ll solidify your understanding and make your infrastructure repeatable, version-controlled, and shareable with your team.

• Learn about VPC connectivity options. Once your single-VPC architecture is solid, start exploring how VPCs connect to each other and to the outside world. VPC Peering lets two VPCs communicate directly. Transit Gateway simplifies networking when you have many VPCs. VPN connections and AWS Direct Connect link your VPC to on-premises data centers. VPC Endpoints let your private resources access AWS services like S3 and DynamoDB without traversing the internet at all. Each of these builds directly on the concepts you’ve learned here.

The production-ready architecture we walked through above isn’t just a diagram, it’s the foundation that most real-world AWS applications are built on. Every load balancer, container cluster, and serverless application you’ll work with in the future sits inside a VPC. By understanding these fundamentals now, you’re setting yourself up to build cloud infrastructure that’s secure, scalable, and resilient from the start.

This article walks you through the complete flow of deploying a containerized application using Amazon ECS with Fargate. No servers to manage. No cluster capacity to worry about. Just your application running in containers.

By the end, you will understand each component and how they connect together.

What Are ECS and Fargate?

Amazon ECS

Elastic Container Service (ECS) is a container orchestration platform from AWS. It handles the scheduling, deployment, and management of your containers. Think of it as the brain that decides where and how your containers run.

AWS Fargate

Fargate is a serverless compute engine for containers. Instead of provisioning EC2 instances and managing their capacity, you simply tell AWS how much CPU and memory your container needs. Fargate handles the underlying infrastructure.

When you combine ECS with Fargate, you get container orchestration without server management.

Architecture Overview

Before diving into the steps, let us look at the components involved.

The Complete Flow

Step 1: Prepare Your Application for Containerization

Start with your application. Whether it is a web API, a backend service, or a worker process, you need to package it into a container image.

Create a Dockerfile in your project root. This file contains instructions for building your container image. Define the base image, copy your application files, install dependencies, and specify the command to run your application.

Keep images small. Use multi-stage builds if needed. Smaller images mean faster deployments and lower costs.

Step 2: Create an ECR Repository

Amazon Elastic Container Registry stores your container images. Before pushing images, you need a repository.

Navigate to the ECR console and create a new private repository. Choose a meaningful name that reflects your application. Enable image scanning to automatically check for vulnerabilities when images are pushed.

Configure lifecycle policies to automatically clean up old images. This prevents storage costs from growing indefinitely.

Step 3: Build and Push Your Image

Build your container image locally using Docker. Tag the image with your ECR repository URI. The tag should include a version identifier such as a git commit hash or semantic version number.

Authenticate Docker with ECR using the AWS CLI. This generates temporary credentials that allow Docker to push images.

Push the tagged image to your ECR repository. Verify the push succeeded by checking the repository in the console.

Step 4: Set Up the Network Infrastructure

Your containers need a network to run in. Create a VPC or use an existing one.

Design your subnets carefully. Place your Fargate tasks in private subnets. They do not need direct internet access. Place the Application Load Balancer in public subnets so it can receive traffic from the internet.

Create a NAT Gateway in a public subnet. Your tasks in private subnets need this to pull images from ECR and access other AWS services.

Configure security groups. Create one for the load balancer that allows inbound traffic on your application port. Create another for the Fargate tasks that only allows traffic from the load balancer security group.

Step 5: Create IAM Roles

ECS requires two types of IAM roles.

The task execution role allows ECS to pull images from ECR, send logs to CloudWatch, and retrieve secrets from Secrets Manager or Parameter Store. AWS provides a managed policy called AmazonECSTaskExecutionRolePolicy that covers most use cases.

The task role is what your application uses at runtime. Attach policies based on what AWS services your application needs to access. If your app reads from S3, add S3 read permissions. If it writes to DynamoDB, add those permissions. Follow the principle of least privilege.

Step 6: Create an ECS Cluster

The cluster is a logical grouping for your services and tasks. Navigate to the ECS console and create a new cluster.

Give it a descriptive name. Enable Container Insights if you want detailed metrics and logs. This adds cost but provides valuable observability.

With Fargate, the cluster is essentially just a namespace. There are no EC2 instances to manage.

Step 7: Define Your Task Definition

The task definition is a blueprint for your container. It describes how your container should run.

Specify the following:

Family name: A unique identifier for your task definition. New revisions will share this name.

Launch type: Select Fargate.

CPU and memory: Choose appropriate values based on your application requirements. Fargate has specific combinations available.

Container definition: Provide the ECR image URI, container port mappings, environment variables, and log configuration.

Networking mode: Use awsvpc mode. This is required for Fargate and gives each task its own elastic network interface.

Log configuration: Send logs to CloudWatch Logs. Create a log group beforehand or let ECS create one automatically.

Step 8: Create an Application Load Balancer

The load balancer distributes traffic across your tasks and provides a stable endpoint.

Create an Application Load Balancer in your public subnets. Configure listeners for HTTP on port 80 or HTTPS on port 443. For production, always use HTTPS with an ACM certificate.

Create a target group with the target type set to IP. This is required for Fargate. Configure health checks to verify your application is responding correctly.

Set the health check path to an endpoint your application exposes. Configure appropriate thresholds and intervals based on how quickly your application starts.

Step 9: Create the ECS Service

The service maintains the desired number of tasks and integrates with the load balancer.

Navigate to your cluster and create a new service. Select the task definition you created earlier.

Configure the following:

Launch type: Fargate.

Desired count: The number of tasks you want running. Start with two for high availability.

Deployment configuration: Use rolling updates. Set minimum healthy percent to 100 and maximum percent to 200. This ensures zero downtime during deployments.

Network configuration: Select your VPC, private subnets, and the security group for tasks. Enable auto-assign public IP only if tasks are in public subnets.

Load balancing: Select the Application Load Balancer and target group you created.

Service discovery: Optionally enable Cloud Map integration for internal service-to-service communication.

Step 10: Configure Auto Scaling

Your application should scale based on demand. ECS Service Auto Scaling adjusts the desired count automatically.

Configure target tracking scaling policies. Common metrics include:

CPU utilization: Scale when average CPU across tasks exceeds a threshold.

Memory utilization: Scale when memory usage grows.

Request count per target: Scale based on how many requests each task handles.

Set minimum and maximum task counts. The minimum ensures you always have capacity. The maximum prevents runaway scaling and unexpected costs.

Step 11: Set Up Logging and Monitoring

Observability is critical for production workloads.

Your tasks should already send logs to CloudWatch Logs based on the task definition configuration. Create CloudWatch alarms for key metrics such as CPU utilization, memory utilization, and running task count.

Enable Container Insights on your cluster for enhanced metrics. This provides task-level and container-level visibility.

Set up CloudWatch dashboards to visualize your application health at a glance.

Step 12: Verify the Deployment

Once the service is running, verify everything works correctly.

Check the ECS console. Your service should show the desired number of running tasks. If tasks are failing, check the stopped tasks for error messages.

Check the target group health. All registered targets should be healthy. If not, verify security group rules and health check configuration.

Access your application through the load balancer DNS name. Verify it responds as expected.

Deployment Flow for Updates

Once your initial deployment is complete, updating your application follows this flow:

1. Make changes to your application code

2. Build a new container image with a new tag

3. Push the image to ECR

4. Create a new task definition revision pointing to the new image

5. Update the ECS service to use the new task definition

6. ECS performs a rolling deployment automatically

7. Old tasks drain connections and stop

8. New tasks start and register with the load balancer

This process can be automated with CI/CD pipelines using services like CodePipeline, GitHub Actions, or GitLab CI.

Best Practices

Keep Images Lean

Smaller images deploy faster. Use minimal base images. Remove unnecessary files and dependencies.

Use Specific Image Tags

Never use the latest tag in production. Always use specific versions so deployments are predictable and rollbacks are possible.

Implement Health Checks

Define health checks at both the container level and load balancer level. This ensures traffic only routes to healthy tasks.

Store Secrets Securely

Never bake secrets into container images. Use Secrets Manager or Parameter Store. Reference them in your task definition and inject them as environment variables at runtime.

Plan for Failure

Run tasks across multiple availability zones. Set appropriate desired counts. Configure auto scaling to handle load spikes.

Monitor Costs

Fargate pricing is based on CPU and memory. Right-size your task definitions. Use Spot capacity for fault-tolerant workloads to reduce costs significantly.

Common Pitfalls to Avoid

Incorrect security group rules: Tasks cannot pull images or register with load balancers if security groups block traffic.

Missing NAT Gateway: Tasks in private subnets cannot reach ECR or other AWS services without a NAT Gateway or VPC endpoints.

Health check misconfiguration: If the health check path returns errors or times out, tasks will be marked unhealthy and constantly replaced.

Insufficient task role permissions: Your application will fail to access AWS services if the task role lacks required permissions.

Forgetting to update the service: Creating a new task definition revision does not automatically deploy it. You must update the service.

Conclusion

Deploying containers on ECS with Fargate removes the burden of managing servers while giving you full control over your application. The initial setup involves several components, but each serves a clear purpose.

Start with a simple deployment. Get it working end to end. Then iterate by adding auto scaling, improving monitoring, and building CI/CD pipelines.

The serverless nature of Fargate lets you focus on your application rather than infrastructure. You pay only for the resources your containers use, and scaling happens automatically based on your policies.

Now you have a clear roadmap. Pick your application and start building.

Introduction

Building a serverless platform often starts with just a few AWS Lambda functions. Over time, however, as new features are added and the platform evolves, that number can quickly grow into the hundreds. At that scale, managing, deploying, and maintaining Lambda functions becomes increasingly complex.

This is a common challenge organizations face as they scale serverless architectures. As the number of Lambda functions increases, so does the operational overhead. One of the most frequent questions we hear from customers is:

“How should we properly structure and organize a large number of Lambda functions?”

In this article, we present three practical architectural patterns that help teams organize Lambda functions at scale, enabling them to grow serverless applications while keeping complexity under control.

The Starting Point: Single-Purpose Lambda Functions

When organizations first adopt AWS Lambda, they typically follow a straightforward approach: one function per responsibility. We refer to these as single-purpose Lambda functions.

Consider a typical e-commerce architecture:

• GetProduct – Retrieve product details

• AddCart – Add items to a shopping cart

• RemoveCart – Remove items from the cart

• GetCart – View the cart

• SubmitOrder – Submit an order

• ReserveInventory – Reserve inventory

• ProcessPayment – Process payment

• FulfilOrder – Complete the order

Amazon API Gateway acts as the front door, exposing HTTP endpoints and routing requests to the appropriate Lambda functions. Each function persists its data in a dedicated DynamoDB table.

This approach is perfectly valid and widely used. However, as organizations add features and scale their platforms, they often end up with hundreds or even thousands of Lambda functions in a single repository.

At scale, this typically results in:

• A large, monolithic repository

• A single, complex CI/CD pipeline

• High deployment risk, where a failure impacts the entire system

To address these challenges, let’s explore three organizational patterns.

Pattern 1: Microservices

When all Lambda functions reside in a single repository backed by one AWS SAM template, complexity escalates quickly. Deployments become slow and risky, and ownership becomes unclear.

The solution is to apply microservices principles and bounded contexts to your serverless architecture.

Consider the cart-related functions: AddCart, RemoveCart, and GetCart. These functions:

• Operate on the same domain (shopping cart)

• Share the same data model and DynamoDB table

• Are typically owned by the same team

These functions clearly belong together. Instead of managing them independently, group them into a dedicated service, such as a cart-service.

Repeat this process for other domains, including product, order, inventory, and payment. Each domain becomes its own service with:

• A dedicated repository

• Its own AWS SAM template

• An independent CI/CD pipeline

In a true microservices architecture, services expose functionality through APIs rather than sharing infrastructure resources directly. As a result, SAM templates are typically self-contained and do not reference resources across services.

Benefits

This approach enables:

• Independent development and deployment – Teams can ship changes without impacting unrelated services

• Clear ownership – Each service has a well-defined boundary and responsible team

• Reduced coupling – Services only include the dependencies they require

This is the foundation for scaling serverless systems both technically and organizationally.

Pattern 2: Lambda Web Adapter

Even with improved organization, teams may still manage a large number of Lambda functions. In many cases, these functions can be consolidated.

This is where the Lambda Web Adapter pattern becomes valuable. Instead of creating one Lambda function per HTTP endpoint, you run a traditional web framework inside a single Lambda function and handle routing internally.

For example, AddCart and RemoveCart both update the same DynamoDB table and operate within the same domain. These can be combined into a single manage_cart function.

Inside that function, you can use familiar frameworks such Express.js, Next.js, Flask, Django, Spring Boot, ASP.NET, Laravel, and so on. The Lambda Web Adapter makes this possible.

Benefits

This pattern offers several advantages:

• Fewer cold starts – A single function replaces multiple endpoints

• Shared initialization – SDK clients and database connections are initialized once

• Familiar development model – Teams can use established web frameworks

• Simpler testing – Routing and logic can be tested locally without mocking Lambda events

A Word of Caution

Consolidation should be applied carefully. Overuse can result in a monolithic Lambda function that negates the benefits of serverless design.

Keep functions aligned to a bounded context, and continuously monitor:

• Function size

• Memory usage

• Execution time

Remember that a failure in a consolidated function can impact multiple operations.

When to Consolidate Functions

Consolidation is appropriate when functions:

• Share common dependencies or downstream services

• Have similar memory and performance requirements

• Share IAM permissions

• Have comparable initialization costs

If these factors align, consolidation is often beneficial.

Pattern 3: API Gateway Direct Integration

A common anti-pattern in serverless architectures is the use of Lambda functions that simply proxy requests to downstream services without applying any business logic.

For example, the GetCart function that retrieves an item from DynamoDB and returns it without transformation adds little value.

In such cases, the Lambda function can be removed entirely and replaced with an API Gateway direct integration.

With direct integrations, API Gateway communicates directly with AWS services such as DynamoDB or Step Functions, and others, eliminating the need for an intermediate Lambda function.

Benefits

This pattern provides:

• Lower cost – No Lambda invocation charges

• Lower latency – One less hop in the request path

• No cold starts – API Gateway is always available

• Reduced operational overhead – Fewer functions to manage

When to Use This Pattern

Use direct integrations when:

• Performing simple CRUD operations

• No business logic or complex validation is required

• The goal is to minimize Lambda usage

Avoid this pattern when:

• Complex transformations are needed

• Business logic or orchestration is involved

• Advanced error handling is required

Recap

To organize Lambda functions effectively at scale, consider the following patterns:

1. Microservices Organization – Group related functions by domain into independent services and repositories

2. Lambda Web Adapter – Consolidate related functions inside a single Lambda function

3. API Gateway Direct Integration – Eliminate unnecessary Lambda functions for simple operations

Applying these patterns allows teams to move from:

• A single repository with scattered Lambda functions

• To a domain-driven, multi-repository architecture

• To fewer, more meaningful Lambda functions

• And, where appropriate, to no Lambda functions at all

Conclusion

Organizing Lambda functions at scale does not need to be overwhelming. By grouping functions by domain, consolidating where appropriate, and leveraging API Gateway direct integrations, you can transform an unmanageable serverless environment into a clean, scalable, and maintainable architecture.

Start by reviewing your existing Lambda landscape. Identify shared domains, look for consolidation opportunities, and evaluate where direct integrations can reduce unnecessary compute. These incremental changes can significantly improve both developer productivity and operational efficiency.

A contact form seems straightforward until you remember that static sites have no server to process form submissions. You need somewhere to receive the data, validate it, and do something useful with it.

This article walks through building a serverless contact form backend using AWS services. By the end, you will have a solution that receives form submissions, sends email notifications, and costs nearly nothing to operate.

Architecture Overview

The serverless contact form backend uses three core AWS services working together.

Amazon API Gateway provides an HTTPS endpoint that your frontend form can call. It receives the POST request containing the form data and passes it along for processing.

AWS Lambda runs your backend logic. It receives the form data from API Gateway, validates the input, formats an email, and triggers the email delivery. You pay only when the function executes.

Amazon Simple Email Service (SES) handles email delivery. Lambda tells SES what to send and where, and SES manages the actual delivery, retries, and bounce handling.

The flow works like this. A visitor fills out your contact form and clicks submit. JavaScript on your static site sends a POST request to your API Gateway endpoint. API Gateway triggers your Lambda function with the form data. Lambda validates the input and calls SES to send an email. SES delivers the email to your inbox. Lambda returns a success response through API Gateway to your frontend. Your static site displays a thank you message.

This entire process typically completes in under one second and costs a fraction of a cent.

Setting Up Amazon SES

Start with SES because email delivery requires verification before you can use it.

Understanding the SES Sandbox

New AWS accounts start with SES in sandbox mode. This is a restricted environment that prevents abuse. In sandbox mode, you can only send emails to verified email addresses. This is fine for testing but not for production.

To exit sandbox mode, you submit a request through the AWS console. AWS reviews your use case and typically approves legitimate requests within 24 hours. You do not need production access to build and test your contact form, but you will need it before going live.

Verifying Your Email Address

Navigate to SES in the AWS console and go to verified identities. Add the email address where you want to receive contact form submissions. AWS sends a verification email with a link you must click.

For sending emails, you have two options. You can verify a specific email address that will appear in the From field. Alternatively, you can verify an entire domain, which allows sending from any address at that domain.

Domain verification requires adding DNS records to prove ownership. If you manage your domain through Route 53, AWS can add these records automatically. For external DNS providers, you manually add the TXT records AWS provides.

Choosing a Region

SES is not available in all AWS regions. Check which regions support SES and choose one close to your users or in the same region as your other resources. Common choices include us-east-1, us-west-2, and eu-west-1.

Remember that your Lambda function must call SES in the region where you verified your email addresses.

Creating the AWS Lambda Function

The Lambda function is the brain of your contact form backend. It receives form submissions, validates them, and orchestrates email delivery.

Function Design

Keep the function focused on a single responsibility. It should accept form data, validate required fields exist and contain reasonable values, format a readable email, call SES to send it, and return an appropriate response.

Resist the temptation to add features like database storage or complex analytics in this initial version. Start simple and extend later if needed.

Input Validation

Never trust user input. Your function should verify that required fields are present before processing. Check that email addresses look roughly valid. Enforce reasonable length limits on message content. Strip or escape any potentially dangerous content.

Validation protects you from malformed requests and reduces the chance of processing garbage data or abuse attempts.

Email Formatting

Consider what information you want in the notification email. Typically you include the sender name, their email address for replies, the message content, and a timestamp. You might also include metadata like which page the form was submitted from.

Format the email so it is easy to scan. A wall of text is harder to process than clearly labeled sections.

Error Handling

Your function should handle failures gracefully. SES might be temporarily unavailable. The input might be malformed. Network issues happen.

Return clear error responses that help your frontend display appropriate messages. Log errors with enough detail to debug problems later. Avoid exposing internal error details to users as this can reveal information useful to attackers.

IAM Permissions

Your Lambda function needs permission to call SES. Create an IAM role with the minimum required permissions. The function needs ses:SendEmail for the specific verified identities you are using. It does not need full SES access.

Follow the principle of least privilege. Grant only what the function needs to operate.

Configuring Amazon API Gateway

API Gateway creates the public endpoint that your frontend calls.

Choosing an API Type

API Gateway offers two main options for this use case.

REST APIs are the traditional option with more features and configuration options. They work well and have extensive documentation.

HTTP APIs are newer, cheaper, and faster. They have fewer features but everything you need for a simple contact form. For most contact form backends, HTTP APIs are the better choice.

Creating the Endpoint

Create a new API and add a single route. You need a POST method at a path like /contact or /submit. Connect this route to your Lambda function.

Configure the integration so API Gateway passes the request body to Lambda. The default settings usually work fine for JSON payloads.

Enabling CORS

Cross-Origin Resource Sharing is essential when your frontend and backend are on different domains. Your static site at yourdomain.com needs permission to call your API at some-id.execute-api.region.amazonaws.com.

Configure CORS on your API Gateway to allow requests from your static site domain. Specify the allowed origin, allowed methods (POST and OPTIONS), and allowed headers (Content-Type at minimum).

Without proper CORS configuration, browsers block the request and your form silently fails.

Deploying the API

API Gateway requires deployment to a stage before your endpoint becomes accessible. Create a stage named prod or live. After deployment, you receive an invoke URL that your frontend uses.

Save this URL. You configure your frontend form to send submissions here.

Connecting Your Frontend

With the backend complete, update your static site to use it.

Form Structure

Your HTML form needs fields for whatever information you want to collect. Common fields include name, email, and message. Add any other fields relevant to your use case.

The form does not need an action attribute or traditional submit behavior. JavaScript handles the submission.

JavaScript Submission

Write JavaScript that intercepts the form submission, prevents the default browser behavior, collects the form field values, and sends them to your API endpoint as a JSON POST request.

Handle the response appropriately. On success, show a thank you message and clear the form. On failure, display an error message asking the user to try again or contact you directly.

User Experience Considerations

Disable the submit button while the request is processing to prevent duplicate submissions. Show a loading indicator so users know something is happening. Provide clear feedback on both success and failure.

Consider what happens if JavaScript fails to load or the user has it disabled. Progressive enhancement with a fallback email link improves accessibility.

Security Considerations

A public form endpoint attracts abuse. Plan for it.

Rate Limiting

Configure throttling on your API Gateway to limit requests per second. This prevents a single source from overwhelming your backend or running up your AWS bill.

Start with conservative limits. A legitimate contact form rarely receives more than a few submissions per minute. You can always increase limits if needed.

Spam Prevention

Bots constantly scan the internet for forms to abuse. Several techniques help reduce spam.

Honeypot fields are hidden form fields that humans never see or fill out. Bots often fill every field they find. If the honeypot field contains data, reject the submission.

Time-based validation rejects submissions that happen too quickly. A human takes at least several seconds to fill out a form. A bot submits instantly. Record when the page loaded and reject submissions that arrive suspiciously fast.

CAPTCHA services like reCAPTCHA add a challenge that bots struggle to complete. They add friction for users but dramatically reduce automated spam.

Consider implementing at least one of these techniques from the start. Cleaning up after a spam attack is more work than preventing it.

Input Sanitization

Sanitize all input before including it in emails. This prevents injection attacks and ensures your emails render correctly. Be especially careful with HTML content if you send HTML-formatted emails.

Cost Analysis

Serverless pricing aligns well with contact form usage patterns.

Expected Costs

API Gateway HTTP APIs cost one dollar per million requests. Lambda charges based on execution time and memory, with a generous free tier of one million requests per month. SES costs ten cents per thousand emails.

For a typical small business website receiving a few hundred contact form submissions monthly, the entire backend costs pennies. Many sites stay within free tier limits indefinitely.

Cost Controls

Set up billing alerts to notify you of unexpected charges. A sudden spike in requests could indicate abuse or a misconfigured frontend.

The rate limiting configured earlier also protects your budget. Even if someone attempts to abuse your endpoint, throttling limits how many requests actually process.

Testing Your Setup

Test thoroughly before announcing your new contact form.

Manual Testing

Submit test entries through your actual form. Verify emails arrive with correct formatting. Test with various input lengths and special characters. Confirm error cases display appropriate messages.

Edge Cases

Test what happens with empty required fields. Submit extremely long messages. Include special characters and emoji. Try submitting while offline. Each test might reveal handling you need to improve.

Monitoring

After launch, monitor your Lambda function logs for errors. Watch SES for bounces or complaints. Set up CloudWatch alarms to alert you if error rates spike.

Going Further

Once your basic contact form works, consider enhancements.

Store submissions in DynamoDB for a searchable archive. Add SNS to send notifications through multiple channels. Implement different notification routing based on form fields. Build an admin dashboard to view and manage submissions.

Each enhancement adds complexity. Add them only when you have a clear need.

Conclusion

A serverless contact form backend solves a real problem elegantly. You get reliable form processing without maintaining servers, pay only for actual usage, and keep full control over your data.

The combination of API Gateway, Lambda, and SES provides a robust foundation that scales from zero to thousands of submissions without configuration changes. For most static sites, this backend costs nothing or nearly nothing to operate.

Build it once, deploy it, and focus on the rest of your site knowing that contact form submissions will reliably reach your inbox.

Today, I work with cloud infrastructure daily. I’ve built serverless applications, designed architectures for production workloads, and helped others navigate the same confusion I once felt.

Looking back, I realize the technical skills were the easy part. The harder lessons were about mindset, consistency, and understanding how careers actually work. The things nobody tells you when you’re starting out.

If I could sit down with my past self on Day 1, here’s what I’d say.

1. Stop Waiting to Feel Ready

You will never feel ready.

I spent months telling myself I needed to finish one more course before I could start building. I needed to understand networking better before I touched AWS. I needed to be more comfortable with Linux before I could deploy anything.

This is a trap. Readiness is a feeling that comes after you start, not before.

The first time I tried to deploy a simple web application to EC2, I had no idea what I was doing. I didn’t understand security groups. I couldn’t figure out why my instance wasn’t reachable. I spent an entire weekend troubleshooting something that should have taken an hour.

But here’s what happened: by Monday, I understood security groups. Not because I read about them, but because I had broken something and needed to fix it.

Your first project will confuse you. Your second will frustrate you. Your third will still have problems. But by your fifth project, something shifts. You start recognizing patterns. Error messages that once looked like gibberish begin making sense. You develop instincts.

That confidence you’re waiting for? It’s on the other side of starting.

The course you’re watching right now is valuable. But it becomes ten times more valuable when you pause it, open your AWS console, and try to build what you just learned. Understanding and doing are completely different skills. You need both, and you can only get the second one by starting before you’re ready.

2. Projects Matter More Than Everything Else

Let me be direct: not one certification, not one course, not one bootcamp did more for my career than building real projects.

I’m not saying certifications are worthless. They have their place. They give you structured learning paths, validate your knowledge to employers who use them as filters, and force you to learn topics you might otherwise skip.

But here’s what certifications can’t do: they can’t teach you what happens when things break in unexpected ways. They can’t give you the experience of debugging a problem for three hours only to discover it was a typo in an environment variable. They can’t simulate the feeling of deploying something to production and watching real users interact with it.

Projects give you stories to tell in interviews. When someone asks about a challenging problem you solved, you need a real answer. “I studied this topic in a course” doesn’t compare to “I built an application that processed user uploads, and when it started failing at scale, I had to redesign the architecture to handle the load.”

Here’s my framework for learning through projects:

Build something. It doesn’t need to be original or impressive. Clone an existing idea. Build a to-do app, a URL shortener, a simple API. The goal isn’t to create something the world has never seen, it’s to learn by doing.

Break it. Intentionally push your project to its limits. What happens when you send a thousand requests at once? What happens when the database goes down? What happens when you feed it unexpected input? Breaking things teaches you how they work.

Fix it. This is where the real learning happens. Debugging forces you to understand systems at a deeper level than building ever does. Every error you resolve adds to your mental library of solutions.

Repeat. Each project should be slightly more ambitious than the last. Add a new service you haven’t used. Implement a pattern you read about. Increase the complexity gradually.

Document everything as you go. Take screenshots. Write notes about what you tried and what worked. This documentation becomes portfolio material, blog content, and interview preparation all at once.

3. Your Future Network Matters More Than Your Current Skills

When I started in tech, I thought success was purely about technical ability. Learn enough skills, pass enough certifications, and opportunities would appear.

I was wrong.

The opportunities that changed my career came through people. A former colleague mentioned my name when their company was hiring. Someone I’d interacted with on LinkedIn sent me a message about a role they thought I’d be perfect for. A connection I’d helped with a technical question months earlier returned the favor with an introduction.

Your network isn’t just about who you know, it’s about who knows what you’re capable of.

This doesn’t mean you need to become a networking expert or attend every meetup in your city. It means being visible and helpful in small, consistent ways.

Comment on posts. When someone shares something interesting, add a thoughtful comment. Not “Great post!” but something that shows you actually read and thought about it. Ask a follow-up question. Share a related experience. This puts you on people’s radar.

Post your progress. You don’t need to be an expert to share what you’re learning. “Today I finally understood how IAM policies work” is valuable content. Someone else is struggling with the same thing and will appreciate your explanation. Someone more experienced might offer additional insights. Both outcomes benefit you.

Ask questions publicly. Many people are afraid to ask questions because they don’t want to look uninformed. But asking good questions demonstrates curiosity and engagement. It also invites helpful people into your orbit.

Help others. Answer questions when you can. Share resources you’ve found useful. Celebrate other people’s wins. Generosity in professional communities compounds over time in ways that are hard to predict but impossible to ignore.

The cloud community is remarkably welcoming to beginners. People remember what it was like to start out and genuinely want to help. But they can only help you if they know you exist.

4. LinkedIn Isn’t Optional

I resisted LinkedIn for years. It felt performative. Self-promotional. Uncomfortable.

Then I realized something: LinkedIn isn’t social media in the traditional sense. It’s infrastructure for your career.

Think about what LinkedIn actually is. It’s your resume, but dynamic and always accessible. It’s your portfolio, where you can showcase projects and share your work. It’s your reputation, built through your posts, comments, and endorsements. It’s your discoverability, where recruiters and hiring managers search for candidates.

When a recruiter searches for “Cloud Engineer,” they’re not searching your personal website. They’re searching LinkedIn. When a hiring manager wants to learn more about you before an interview, they’re checking LinkedIn. When someone you met at a conference wants to stay in touch, they’re connecting on LinkedIn.

You don’t need to become a LinkedIn influencer. You don’t need to post every day or chase viral content. But you do need to:

Complete your profile. A professional photo, a headline that describes what you do, and a summary that tells your story. List your projects, certifications, and relevant experience. Make it easy for people to understand who you are and what you’re looking for.

Show your work. When you complete a project, write about it. When you pass a certification, share what you learned. When you solve an interesting problem, explain your approach. These posts serve as evidence of your capabilities.

Engage consistently. Even ten minutes a day makes a difference. Comment on a few posts. Congratulate people on their achievements. Share an article you found valuable. Consistency matters more than volume.

People can’t help you if they can’t see you. LinkedIn makes you visible.

5. Momentum Beats Perfection

You’re going to overthink your first GitHub repository. You’ll worry the code isn’t clean enough, the documentation isn’t thorough enough, the project isn’t impressive enough.

You’re going to overthink your first LinkedIn post. You’ll rewrite it five times, wonder if anyone will care, and debate whether you should even hit publish.

You’re going to overthink your first job application. You’ll convince yourself you’re not qualified, that you’ll embarrass yourself in the interview, that you should wait until you’re more prepared.

Here’s what I wish someone had told me: done is better than perfect, and published is better than polished.

The first version of anything is supposed to be rough. That’s not a flaw, it’s the process. You can’t edit something that doesn’t exist. You can’t improve a project you never built. You can’t get feedback on a post you never published.

Every expert you admire has a graveyard of mediocre first attempts. The difference between them and people who never made it isn’t talent, it’s that they kept going.

Momentum has a compounding effect. Your first repository teaches you how Git works. Your second teaches you about documentation. Your third teaches you about code organization. Each iteration improves because you’re learning by doing, not waiting to learn everything before you start.

The same applies to content. Your first LinkedIn post might get three likes. Your tenth will be better because you’ve learned what resonates with your audience. Your fiftieth will feel natural because you’ve developed your voice through practice.

Perfection is a form of procrastination. It feels productive because you’re “working on” something, but nothing is actually shipping. Momentum gets you results.

Still hit publish. Still apply. Still show up.

6. Interviews Aren’t Exams - They’re Conversations

I failed my first cloud interview badly. I treated it like a certification exam, trying to recall memorized facts about AWS services. When the interviewer asked about my experience with a service I’d never used, I froze. I didn’t know the “right answer.”

Here’s what I didn’t understand: interviews aren’t about having all the answers. They’re about demonstrating how you think.

Hiring managers know you won’t have experience with every service. They know you’ll encounter problems you’ve never seen before. What they want to know is how you’ll handle those situations.

When you don’t know something, the worst response is pretending you do. The best response is showing your thought process: “I haven’t used that service directly, but based on what I know about similar services, I’d approach it by...”

Interviewers are evaluating several things at once:

How you think. Can you break down complex problems? Do you ask clarifying questions? Can you reason through unfamiliar territory?

How you communicate. Can you explain technical concepts clearly? Do you listen to questions carefully? Can you admit when you don’t know something?

How you solve problems. What’s your approach when you’re stuck? How do you prioritize when there are multiple possible solutions? How do you validate that your solution actually works?

How you’d be to work with. Are you collaborative? Do you seem coachable? Would the team enjoy having you in meetings and Slack channels?

Prepare for interviews by practicing how you talk about your experience, not just what you know. Use the STAR method (Situation, Task, Action, Result) to structure stories about projects you’ve worked on. Practice explaining technical decisions you’ve made and why you made them.

The interview is a conversation about whether you and the company are a good fit for each other. You’re evaluating them just as much as they’re evaluating you. That mindset shift alone will make you more relaxed and more authentic.

7. The Cloud Isn’t Hard - It’s Unfamiliar

When I first opened the AWS console, I was genuinely intimidated. There were over two hundred services. The documentation was dense. Every tutorial seemed to assume knowledge I didn’t have.

I thought the problem was that cloud computing was inherently difficult and maybe I wasn’t cut out for it.

I was wrong. The problem wasn’t difficulty, it was unfamiliarity.

There’s an enormous difference between hard and unfamiliar. Hard means something is objectively complex, requiring exceptional intelligence or talent to understand. Unfamiliar just means you haven’t been exposed to it yet.

Most of cloud computing is unfamiliar, not hard.

When you first learn about VPCs, subnets, and routing tables, it feels overwhelming. Six months later, you set them up without thinking. The concepts didn’t get easier, you got familiar with them.

When you first deploy a Lambda function, you don’t understand cold starts, execution environments, or IAM roles. After you’ve deployed fifty functions, these concepts are second nature.

This reframe matters because it changes your emotional response to confusion. If you believe cloud is hard and you’re confused, you might conclude you’re not smart enough. If you believe cloud is unfamiliar and you’re confused, you know you just need more exposure.

Give yourself thirty days of consistent learning and building. Not passive learning where you watch videos and nod along, but active learning where you’re hands-on in the console, making mistakes, and fixing them.

What feels impossible today becomes your new normal tomorrow. Every expert you admire went through the same process of confusion becoming clarity. The only difference is they stuck with it long enough.

8. The Fastest Way to Stand Out Is Going Deep

When you’re starting out, it’s tempting to learn a little bit of everything. You want to be well-rounded. You want to have an answer for any question that might come up in an interview.

This is a mistake.

The market doesn’t reward generalists who are mediocre at everything. It rewards specialists who are exceptional at something.

Think about it from a hiring manager’s perspective. They have a specific problem to solve. Maybe they need someone to build serverless applications. Maybe they need someone to secure their AWS environment. Maybe they need someone to build CI/CD pipelines.

When they’re hiring, they want someone who has gone deep in that specific area. Someone who has encountered the edge cases, understands the tradeoffs, and can hit the ground running.

“I have experience with Lambda, EC2, S3, RDS, DynamoDB, CloudFront, Route 53, IAM, VPC, ECS, EKS, and Step Functions” sounds impressive but says nothing about your actual expertise.

“I specialize in serverless architectures. I’ve built event-driven systems with Lambda, designed APIs with API Gateway, and optimized costs for high-throughput workloads” tells a story. It positions you as the go-to person for a specific type of problem.

Pick a lane:

Serverless if you’re drawn to event-driven architectures and want to minimize operational overhead.

Security if you’re detail-oriented and interested in protecting systems from threats.

DevOps/Platform Engineering if you enjoy building tools and processes that help other developers move faster.

Data Engineering if you’re interested in building pipelines that move and transform large amounts of data.

Networking if you want to understand the foundational infrastructure that everything else runs on.

You can always expand later. But early in your career, depth beats breadth. Master one lane first, then broaden from a position of strength.

9. You Don’t Need to Be the Smartest - Just the One Who Doesn’t Quit

I’ve watched people who were more naturally talented than me quit because they got frustrated. I’ve watched people who started after me give up because they weren’t seeing results fast enough.

The people who succeed in cloud aren’t necessarily the smartest or most talented. They’re the ones who keep showing up.

This career path has a high dropout rate because the early stages are uncomfortable. You feel confused constantly. Progress seems slow. Imposter syndrome tells you everyone else is figuring this out faster than you are.

What you don’t see is that everyone else feels the same way. The difference between those who make it and those who don’t isn’t intelligence, it’s persistence.

Some practical strategies for not quitting:

Set small, achievable goals. “Become a cloud engineer” is overwhelming. “Complete one hands-on tutorial this week” is manageable. Stack enough small wins and you’ll look up to find you’ve made massive progress.

Track your progress visibly. Keep a learning journal. Save screenshots of things you’ve built. Document problems you’ve solved. When you’re feeling discouraged, look back at where you started. You’ve come further than you think.

Find a community. Learning alone is hard. Find a Discord server, a study group, or even one other person who’s on the same journey. Accountability and encouragement make a huge difference.

Expect plateaus. Progress isn’t linear. You’ll have weeks where everything clicks and weeks where nothing makes sense. The plateaus are normal. Keep going through them.

Remember your why. On the hard days, reconnect with the reason you started. Financial security for your family. A more fulfilling career. The ability to build things that matter. Whatever it is, keep it visible.

The cloud industry is full of people who aren’t geniuses. They’re just people who refused to quit.

10. Your Life Can Look Completely Different in 6-12 Months

This isn’t motivational fluff. I’ve seen it happen repeatedly.

I’ve seen people go from help desk to cloud engineer in eight months. I’ve seen people with no technical background land their first AWS role in a year. I’ve seen people double their salaries by gaining cloud skills and changing companies.

Six to twelve months is not a long time. But it’s enough time to completely transform your career if you’re consistent.

Think about where you were a year ago. Think about what you’ve learned since then, even without focused effort. Now imagine what would happen if you spent the next year intentionally building cloud skills, creating projects, growing your network, and positioning yourself for opportunities.

The compound effect of daily effort is staggering. One hour a day for a year is 365 hours, more than many college courses. Fifteen minutes a day engaging on LinkedIn builds a network of hundreds of relevant connections. One project a month gives you a portfolio of twelve things you’ve built.

Most people overestimate what they can do in a week and underestimate what they can do in a year.

Your future self will thank you or blame you for the decisions you make today. A year from now, you’ll have either made progress or made excuses. The time will pass regardless.

It starts with one decision: committing to this.

Not “I’ll try to learn cloud when I have time.” Not “I’ll start seriously studying after this busy period.” Not “I’ll build projects once I feel more confident.”

A real commitment. A non-negotiable decision that you’re going to do this, that you’re going to keep showing up even when it’s hard, and that you’re going to trust the process even when progress feels slow.

Make that decision today.

The Journey Ahead

Starting in cloud is challenging. You’ll face confusion, frustration, and self-doubt. There will be days when you question whether you’re on the right path.

But you’re also starting at the best possible time. Cloud adoption is accelerating. The demand for cloud skills continues to grow. Companies are struggling to find qualified people. The opportunity is real and it’s not going away.

The only question is whether you’ll position yourself to capture it.

Everything I’ve shared in this article comes down to a few core principles: start before you’re ready, learn by building, make yourself visible, choose depth over breadth, and don’t quit.

None of this requires exceptional talent. It requires consistency, patience, and the willingness to be uncomfortable while you’re learning.

You have everything you need to start. The resources are available. The community is welcoming. The opportunity is waiting.

Now it’s on you.

The cloud engineering landscape is transforming rapidly. As we enter 2026, technical skills alone won’t cut it anymore. The engineers who thrive are those who embody a holistic set of traits that go far beyond knowing how to configure an EC2 instance or write a CloudFormation template.

Here are the five essential traits every Cloud Engineer must master:

1. Cultivate Relentless Curiosity

“We are not what we know, but what we are willing to learn.”

The cloud landscape doesn’t just evolve—it transforms at breakneck speed. New services launch quarterly, best practices shift, and yesterday’s cutting-edge architecture becomes today’s legacy system. Curiosity isn’t optional; it’s your competitive advantage.

The curious engineer doesn’t wait for formal training. They experiment with new services in sandbox environments, read whitepapers during lunch breaks, and ask “why” when everyone else accepts “that’s how we’ve always done it.” This trait keeps you ahead of the curve and ensures you’re solving problems with the best tools available, not just the familiar ones.

2. Think in Systems, Not Services

Building resilient cloud infrastructure requires seeing the forest, not just the trees. It’s tempting to focus on individual components—optimizing that Lambda function, tuning that database, securing that API gateway. But true cloud engineering mastery comes from understanding how everything interconnects.

Systems thinking means considering:

• How does this service failure cascade through the architecture?

• What are the upstream and downstream dependencies?

• How does this design decision impact scalability, cost, and reliability simultaneously?

• What are the feedback loops in our system?

When you think in systems, you design for resilience, anticipate bottlenecks before they occur, and create architectures that scale gracefully under pressure.

3. Communicate with Clarity

Here’s an uncomfortable truth: unclear communication causes more production incidents than bad code.

Whether you’re documenting architecture decisions, explaining technical trade-offs to non-technical stakeholders, or writing runbooks for on-call engineers, communication is non-negotiable. The best technical solution means nothing if your team can’t understand it, maintain it, or build upon it.

Strong communicators:

• Write documentation that their future selves will thank them for

• Translate complex technical concepts into business value

• Create architecture diagrams that tell a story

• Ask clarifying questions before making assumptions

• Give and receive feedback constructively

Remember: every line of code you write is communication with future developers. Every architecture decision you make needs to be communicated to stakeholders. Master this skill, and you’ll reduce mistakes, accelerate onboarding, and build better systems.

4. Embrace True Ownership

“You build it, you own it.”

This Amazon principle has become a cornerstone of modern cloud engineering, and for good reason. Ownership transforms how you approach every aspect of your work.

When you truly own a system, you don’t just write code and throw it over the wall. You:

• Design with operational excellence in mind from day one

• Implement comprehensive monitoring and alerting

• Write runbooks and disaster recovery procedures

• Respond to incidents with urgency and accountability

• Continuously improve based on lessons learned

Ownership creates a virtuous cycle: better design leads to fewer incidents, which leads to more time for improvement, which leads to even better systems. The best cloud engineers I’ve worked with take pride in their systems’ reliability and performance because they know they’re accountable for the outcomes.

5. Become a Polymath

The T-shaped engineer concept isn’t new, but it’s more critical than ever in cloud engineering. You need deep expertise in at least one area—whether that’s serverless architectures, security, networking, or data engineering—combined with broad knowledge across the entire cloud ecosystem.

Why? Because modern cloud solutions rarely fit neatly into a single domain. A serverless application still needs proper networking, security controls, database design, and observability. If you only understand Lambda functions but not VPCs, IAM policies, or DynamoDB partition keys, you’ll build fragile systems with hidden vulnerabilities.

Broaden your “T” by:

• Learning adjacent technologies to your specialty

• Understanding the fundamentals of compute, storage, networking, and databases

• Exploring how different AWS services integrate and complement each other

• Studying architecture patterns across different domains

• Contributing to projects outside your comfort zone

The polymath engineer brings versatility that modern cloud environments demand. They can architect end-to-end solutions, spot cross-domain optimization opportunities, and adapt quickly when requirements change.

The Complete Cloud Engineer

The best cloud engineers I’ve worked with embody all five traits. They’re not just technically proficient, they’re well-rounded professionals who drive real business impact. They ask insightful questions, design holistic solutions, communicate effectively with diverse audiences, take ownership of outcomes, and bring versatile expertise to every challenge.

As we move into 2026, the gap between engineers who master these traits and those who don’t will only widen. The good news? Unlike innate talent, these are all learnable skills. Start with one trait, practice deliberately, and build from there.

The Renaissance Developer that Werner Vogels described isn’t a distant ideal, it’s the Cloud Engineer the industry needs right now.

The results after 12 months? 50 posts published, 3,200 subscribers, and over 60,000 views across all content.

A special thanks to every one of you who subscribed, read, and engaged—your support means everything.

In this final article of 2025, I’m looking back on the year and sharing the top 10 articles based on views and 5 low-view articles worth reading. Make sure to check them out!

Top 10 Most-Viewed Articles

1. 5 AWS Projects To Get You Hired | FREE PDF Guide

2. How to Nail Your Cloud Engineering Interview with the STAR Method

3. From Beginner to AWS Certified: A Roadmap for the Solutions Architect Associate Exam

4. AWS Budgets for Beginners: How to Monitor Your Cloud Spending and Avoid Overages

5. Building Your First Event-driven Application on AWS

6. How Much Do Cloud Engineers Really Make? A Breakdown by Role and Experience

7. Idempotency Patterns for Serverless Applications

8. Secure File Uploads to Amazon S3 Using Presigned URLs

9. Building a 3-Tier Architecture with Serverless on AWS

10. RTO vs RPO: Designing Practical DR Strategies on AWS

Low-View Articles Worth Reading

1. How to Ace the AWS Cloud Practitioner Certification: A Practical Roadmap

2. Building Your Personal Brand in the Cloud: Creating an AWS-Powered Resume

3. Build a Personal Blog with WordPress on AWS: A Comprehensive Guide

4. Why AWS Step Functions is My Favourite Orchestration Service for Microservices

5. Creating AWS Architecture Diagrams with Amazon Q CLI and Exporting to Draw.io

Conclusion

Wishing you all a very productive 2026 filled with growth and new opportunities. My goal for the coming year is simple: write more, share more, and build a thriving community of cloud engineers.

Let's level up together!

Here are the five most expensive mistakes I see repeatedly—and how to fix them.

Mistake #1: Using the Default 128MB Memory

This is the most common mistake, and it’s counterintuitive: allocating more memory can actually lower your bill.

Many teams deploy Lambda functions with the default 128MB memory allocation, thinking they’re being cost-conscious. The problem is that Lambda allocates CPU power proportionally to memory. At 128MB, your function gets a tiny slice of CPU, which means slower execution times.

Lambda pricing is calculated by multiplying the memory allocated by the execution time by the price per GB-second. If doubling your memory cuts execution time by more than half, you save money.

The Fix

Use AWS Lambda Power Tuning, an open-source tool that tests your function across memory configurations and shows you the cost-performance tradeoff. You can deploy it directly from the AWS Serverless Application Repository by searching for “aws-lambda-power-tuning.”

Run it against your production functions quarterly. Memory requirements change as your code and data evolve.

Mistake #2: Synchronous Chains of Lambda Functions

I’ve seen architectures where Lambda A calls Lambda B, which calls Lambda C, all synchronously. While the request waterfall completes, you’re paying for all three functions simultaneously.

Picture this flow: API Gateway triggers Lambda A, which invokes Lambda B and waits three seconds for a response, which in turn invokes Lambda C and waits two seconds, which finally does one second of actual work. The total billed Lambda execution time is ten seconds, but the actual compute work being done might only be two seconds. You’re paying for wait time, not compute time.

The Fix

Break synchronous chains with asynchronous patterns using SQS, SNS, or EventBridge.

Instead of having Lambda A invoke Lambda B directly and wait for a response, have Lambda A send a message to an SQS queue and return immediately to the caller with a 202 Accepted status. Lambda B then processes messages from the queue independently.

This approach means each function only runs for the time it needs to do its own work. No function sits idle waiting for another.

If you need orchestration with waiting, branching logic, or error handling across multiple steps, use Step Functions. You pay for state transitions rather than idle Lambda time, and you get built-in retry logic and visualization of your workflows.

Mistake #3: Logging Everything to CloudWatch

CloudWatch Logs ingestion costs $0.50 per GB. That sounds cheap until you realize how much your Lambdas are logging.

I audited one team’s account and found a single function generating 50GB of logs per month—$25/month for one function’s logs. They were logging full request and response bodies for debugging purposes during development and forgot to remove it before going to production.

The Fix

Use log levels properly. Configure your log level via environment variables so you can set DEBUG in development and INFO or WARN in production without changing code. Only log full payloads at the DEBUG level so they don’t appear in production logs.

Set CloudWatch Logs retention policies. The default retention is “never expire,” which means you’re storing and paying for logs forever. In your infrastructure templates, set retention to 14 or 30 days for most functions. You can always set longer retention for audit-critical functions.

Sample logs in high-throughput functions. If a function processes thousands of requests per minute, you don’t need detailed logs for every single one. Implement sampling where you only log full details for 10% of requests. This gives you enough data to debug issues while cutting log volume by 90%.

Audit what you’re logging. Search your codebase for log statements that include full event objects, request bodies, or response payloads. Each of these can add kilobytes per invocation that compound quickly at scale.

Mistake #4: Using Lambda for Long-Running Workloads

Lambda charges per millisecond of execution. For quick, bursty workloads, it’s incredibly cost-effective. For long-running processes, it becomes expensive fast.

I worked with a team running data transformation jobs that took 10-14 minutes per execution. They hit Lambda’s 15-minute timeout regularly and were paying a premium for what was essentially a batch job.

The Math

For a job running 12 minutes at 2048MB memory, executed 100 times per day:

Lambda cost: approximately $72 per month

Fargate cost (equivalently sized, running only when needed): approximately $5.40 per month

That’s a 13x difference.

The Fix

For workloads that exceed a one-minute runtime, consider evaluating AWS Fargate.

For workloads that can be parallelized, consider breaking them into smaller Lambda functions coordinated by Step Functions. You might process data faster and cheaper than a single long-running container by fanning out work across many concurrent short-lived functions.

Mistake #5: Provisioned Concurrency “Just in Case”

Provisioned Concurrency eliminates cold starts by keeping initialized execution environments ready. It’s great for latency-sensitive workloads. It’s terrible for your bill if misconfigured.

Provisioned Concurrency charges you whether the capacity is used or not. I’ve seen teams provision 100 concurrent executions “to be safe” for functions that peak at 20.

At 1024MB memory, keeping 100 provisioned instances running 24/7 for a month costs approximately $1,203—for capacity that sits mostly idle.

The Fix

Check your actual concurrency patterns in CloudWatch before deciding on provisioned concurrency. Look at the ConcurrentExecutions metric with the Maximum statistic over the past 30 days. You might find your function rarely exceeds 10 concurrent executions, making 100 provisioned instances wildly excessive.

Conclusion

Lambda cost optimization isn’t about using less serverless—it’s about using it more intelligently. The teams I see with the lowest bills per transaction aren’t the ones avoiding Lambda. They’re the ones who understand the pricing model and architect accordingly.

Start with Mistake #1. Run Lambda Power Tuning on your most-invoked functions this week. It takes 10 minutes and often pays for itself immediately.

Understanding the Cloud Engineering Landscape

Before diving into specific roles, it’s important to note that cloud engineering salaries vary significantly based on several factors:

• Location: San Francisco and New York typically offer 20-40% higher salaries than mid-tier cities

• Company size: FAANG and enterprise companies generally pay more than startups

• Experience level: Years of experience dramatically impact compensation

• Certifications: AWS certifications can add $10,000-$20,000 to base salary

• Specialization: Niche skills like security or FinOps command premium rates

All salary ranges mentioned below are for the United States market and include base salary (not total compensation with stock/bonuses), current as of 2025.

Entry-Level Roles

1. Cloud Support Engineer

Salary Range: $60,000 - $85,000

Cloud Support Engineers are typically the first line of technical support for cloud infrastructure issues. They troubleshoot basic cloud service problems, assist with resource provisioning, and escalate complex issues.

Key Responsibilities:

• Responding to support tickets

• Basic troubleshooting of EC2, S3, RDS issues

• Documentation of solutions

• Monitoring cloud resources

Required Skills:

• Basic understanding of AWS services

• Fundamental networking knowledge

• Good communication skills

• AWS Cloud Practitioner certification (recommended)

2. Junior Cloud Engineer

Salary Range: $70,000 - $95,000

Junior Cloud Engineers work under senior engineers to build and maintain cloud infrastructure. This is an excellent entry point for those with some technical background.

Key Responsibilities:

• Assisting with infrastructure deployment

• Writing basic Infrastructure as Code (IaC)

• Implementing monitoring and alerts

• Maintaining documentation

Required Skills:

• Basic scripting (Python, Bash)

• Understanding of Linux/Windows systems

• Familiarity with CI/CD concepts

• AWS Solutions Architect Associate certification (preferred)

Mid-Level Roles

3. Cloud Engineer

Salary Range: $95,000 - $140,000

The standard Cloud Engineer role involves designing, implementing, and maintaining cloud infrastructure with moderate autonomy.

Key Responsibilities:

• Designing scalable cloud architectures

• Implementing IaC with Terraform or CloudFormation

• Automating deployment pipelines

• Cost optimization initiatives

• Security best practices implementation

Required Skills:

• 3-5 years of experience

• Proficiency in IaC tools

• Strong AWS services knowledge (EC2, VPC, IAM, S3, Lambda, ECS/EKS)

• Scripting/programming skills

• CI/CD pipeline experience

4. DevOps Engineer (Cloud Focus)

Salary Range: $100,000 - $145,000

DevOps Engineers bridge the gap between development and operations, with heavy focus on automation and CI/CD pipelines in cloud environments.

Key Responsibilities:

• Building and maintaining CI/CD pipelines

• Container orchestration (Kubernetes, ECS)

• Infrastructure automation

• Application deployment strategies

• Monitoring and observability implementation

Required Skills:

• Strong scripting/programming abilities

• Container technologies (Docker, Kubernetes)

• CI/CD tools (Jenkins, GitLab CI, GitHub Actions)

• Configuration management (Ansible, Chef, Puppet)

• Cloud platform expertise

5. Cloud Security Engineer

Salary Range: $110,000 - $155,000

With security being paramount, Cloud Security Engineers focus specifically on securing cloud infrastructure and ensuring compliance.

Key Responsibilities:

• Implementing security controls and guardrails

• Compliance monitoring and remediation

• Security audits and assessments

• Incident response

• Identity and Access Management (IAM) policies

Required Skills:

• Deep understanding of cloud security best practices

• Experience with security tools (GuardDuty, Security Hub, AWS Config)

• Compliance frameworks (SOC2, HIPAA, PCI-DSS)

• Security certifications (AWS Security Specialty, CISSP)

Senior-Level Roles

6. Senior Cloud Engineer

Salary Range: $130,000 - $180,000

Senior Cloud Engineers are technical leaders who design complex systems and mentor junior team members.

Key Responsibilities:

• Architecting enterprise-scale solutions

• Technical leadership and mentoring

• Establishing cloud best practices

• Multi-account/multi-region strategies

• Disaster recovery planning

Required Skills:

• 5-8+ years of experience

• Deep expertise in multiple AWS services

• Strong architectural knowledge

• Leadership and communication skills

• Multiple AWS certifications

7. Cloud Architect

Salary Range: $140,000 - $200,000

Cloud Architects design comprehensive cloud solutions aligned with business objectives, focusing on scalability, reliability, and cost-efficiency.

Key Responsibilities:

• Designing end-to-end cloud solutions

• Technology evaluation and selection

• Stakeholder communication

• Technical documentation and standards

• Cross-team collaboration

Required Skills:

• 7-10+ years of experience

• Broad and deep AWS knowledge

• Business acumen

• Excellent communication skills

• AWS Solutions Architect Professional certification

8. Site Reliability Engineer (SRE)

Salary Range: $135,000 - $190,000

SREs apply software engineering principles to infrastructure and operations problems, focusing on system reliability and performance.

Key Responsibilities:

• Ensuring system reliability and uptime

• Implementing SLOs/SLIs/SLAs

• Incident management and postmortems

• Performance optimization

• Capacity planning

Required Skills:

• Strong programming skills

• Deep understanding of distributed systems

• Observability tools (Prometheus, Grafana, Datadog)

• On-call experience

• Automation expertise

Specialized Roles

9. Cloud FinOps Engineer

Salary Range: $115,000 - $165,000

A relatively new but increasingly important role, FinOps Engineers focus on cloud cost optimization and financial accountability.

Key Responsibilities:

• Cloud cost analysis and optimization

• Implementing tagging strategies

• Chargeback/showback models

• Reserved Instance and Savings Plan management

• Cost anomaly detection and alerting

Required Skills:

• Strong analytical skills

• Deep understanding of AWS pricing models

• Experience with cost management tools

• Business communication skills

• FinOps certification (FinOps Foundation)

10. Cloud Data Engineer

Salary Range: $120,000 - $175,000

Cloud Data Engineers build and maintain data infrastructure in the cloud, focusing on data pipelines, warehouses, and analytics platforms.

Key Responsibilities:

• Designing data architectures

• Building ETL/ELT pipelines

• Managing data warehouses (Redshift, Snowflake)

• Data lake implementation

• Data governance and quality

Required Skills:

• Strong SQL and Python skills

• Experience with AWS data services (S3, Glue, Athena, Redshift, Kinesis)

• Data modeling expertise

• Big data technologies (Spark, Kafka)

Leadership Roles

11. Lead Cloud Engineer / Engineering Manager

Salary Range: $150,000 - $210,000

These roles combine technical expertise with people management, overseeing cloud engineering teams.

Key Responsibilities:

• Team management and development

• Technical strategy and roadmap

• Budget management

• Cross-functional collaboration

• Hiring and performance management

Required Skills:

• 8-12+ years of experience

• Proven leadership experience

• Strong technical background

• Project management skills

• Strategic thinking

12. Principal Cloud Architect

Salary Range: $170,000 - $250,000+

Principal-level architects are technical authorities who influence technology decisions across entire organizations.

Key Responsibilities:

• Enterprise-wide architectural decisions

• Technology vision and strategy

• Standards and governance

• Executive stakeholder management

• Industry thought leadership

Required Skills:

• 12-15+ years of experience

• Exceptional technical depth and breadth

• Proven track record of large-scale implementations

• Strong business acumen

• Excellent communication and influence skills

13. Director of Cloud Engineering

Salary Range: $180,000 - $280,000+

Directors oversee multiple teams and are responsible for the overall cloud strategy and execution within an organization.

Key Responsibilities:

• Departmental strategy and vision

• Budget planning and management

• Organizational structure and hiring

• Executive reporting

• Vendor relationships

Required Skills:

• 12-15+ years of experience

• Extensive leadership experience

• Strategic planning abilities

• Business and financial acumen

• Strong executive presence

Tips for Maximizing Your Cloud Engineering Salary

1. Build a Portfolio

Create public repositories showcasing your IaC templates, automation scripts, and projects. Contribute to open-source projects.

2. Specialize

While breadth is valuable, developing deep expertise in areas like security, FinOps, or Kubernetes can significantly boost your value.

3. Stay Current

Cloud services evolve rapidly. Regularly learn new services and best practices. Follow AWS announcements and implement new services in side projects.

4. Invest in Certifications

Start with AWS Solutions Architect Associate and progress to Professional level certifications. They provide both knowledge and market value.

5. Develop Soft Skills

Technical skills get you in the door, but communication, leadership, and business acumen accelerate your career.

6. Network

Attend cloud conferences, join cloud communities, engage on LinkedIn, and contribute to technical discussions.

7. Negotiate

Many candidates leave money on the table by not negotiating. Research market rates and don’t be afraid to counter-offer.

Conclusion

Cloud engineering offers excellent compensation across all experience levels, with clear paths for advancement. Whether you’re just starting out or looking to move into more specialized or leadership roles, understanding the landscape helps you make informed career decisions.

Remember that salary is just one component of compensation. Consider factors like:

• Learning opportunities

• Work-life balance

• Company culture

• Benefits and equity

• Remote work flexibility

• Career growth potential

The cloud engineering field is dynamic and rewarding, both intellectually and financially. By continuously learning, building expertise, and developing both technical and soft skills, you can position yourself for a lucrative and fulfilling career in cloud engineering.