A resume doesn’t have to be a static PDF stuck in an email inbox. One developer rebuilt theirs as a live application hosted entirely on AWS, turning a simple document into an interactive experience powered by serverless infrastructure. The project, completed as part of the Cloud Resume Challenge, demonstrates how modern cloud services can transform even the most traditional artifacts into dynamic, scalable systems.
The result is a static website—built with HTML and CSS—hosted in an S3 bucket, accelerated through CloudFront, and served under a custom domain managed by Route 53. No server-side rendering is involved; every request is intercepted and optimized by CloudFront, ensuring fast load times globally while keeping the underlying S3 bucket isolated from direct access. This setup delivers consistent performance regardless of where the visitor is located.
At its core, the resume page is static, but its visitor counter is anything but. As the page loads in a browser, client-side JavaScript immediately triggers an API call to API Gateway. That request invokes an AWS Lambda function, which reads the current visitor count from a DynamoDB table, increments the value, and writes the updated number back. The updated count then flows back through the same path—Lambda, API Gateway, and finally the browser—where it’s displayed in real time.
Every component—from the S3 bucket and CloudFront distribution to the IAM roles, Lambda function, DynamoDB table, and API Gateway—was defined and provisioned using Terraform. No manual configuration was involved. Once the infrastructure was codified, GitHub Actions took over deployment. Every code push triggers automated tests, and passing builds deploy the updates without human intervention.
Simplifying AWS infrastructure with infrastructure as code
Terraform redefined how the developer approached AWS architecture. Instead of relying on the AWS console, every resource—from IAM policies to Lambda functions—was defined in code, versioned, and redeployed from scratch whenever needed. This approach not only improved repeatability but also made it easier to replicate the environment across different stages of development.
During the process, the developer encountered a common Terraform challenge: resource dependencies. Terraform sometimes assumes resources can be created independently, even when one resource clearly depends on another being fully provisioned. That assumption led to deployment failures until depends_on was properly applied, reinforcing the importance of explicit dependency management in infrastructure code.
Choosing the right services for the job
Design decisions mattered more than default configurations. For the visitor counter, DynamoDB was the natural fit over relational databases like Aurora Serverless. The data model required only a single counter value—no complex joins or transactions—so DynamoDB’s schemaless design and on-demand pricing aligned perfectly with the use case. Over-engineering a traditional database would have added unnecessary complexity and cost.
The project also forced a deeper understanding of identity and permissions in AWS. Lambda functions don’t use instance profiles like EC2 instances; instead, they rely on execution roles that define what the function can do. But who can invoke the function is a separate concern, governed by resource-based policies attached to API Gateway. This distinction clarified a common point of confusion: permissions are layered, and each layer must be configured deliberately.
Lessons from failure: the value of automation and least privilege
The most impactful lessons came from failures, not successes. One subtle issue surfaced when local AWS CLI behavior diverged from the GitHub Actions runner. The developer had unknowingly relied on a default region setting that worked locally but failed in CI/CD, where no such fallback existed. This revealed how environment differences can break infrastructure code designed in isolation.
Another failure stemmed from an overly permissive IAM policy. An automation user couldn’t read its own identity information, causing the pipeline to fail when trying to manage a resource it owned. This pattern—a permission gap widening as infrastructure scales—appeared three times during the project, teaching the developer to audit permissions systematically rather than reactively.
Perhaps the most critical realization was about identity hygiene. Storing personal AWS credentials in a CI/CD pipeline, even if technically functional, introduces unacceptable risk. Instead, dedicated IAM users with scoped, minimal permissions were created for each pipeline, ensuring automated systems operate under identities designed for least privilege.
Evolving project structure through iteration
The project began as a single repository, built incrementally through milestones. As the CI/CD requirements grew, the codebase was split into separate frontend and backend repositories, each with its own pipeline. Restructuring a working project taught a valuable lesson: it’s often better to start simple and refactor later than to over-plan from the beginning. The ability to adapt the architecture to real-world needs proved more important than initial perfection.
The Cloud Resume Challenge isn’t just about building a resume—it’s a practical crash course in modern cloud architecture. By turning a static document into a live application, the developer gained hands-on experience with serverless computing, infrastructure as code, and automated deployment. More importantly, they learned that the real value lies not in the end result, but in the failures, iterations, and insights that shape how systems are built for scale and reliability.
AI summary
Statik bir PDF yerine AWS üzerinde canlı bir CV sitesi oluşturmanın adımlarını keşfedin. Sunucusuz mimari, Terraform ve CI/CD ile profesyonel portföyünüzü nasıl hayata geçirebilirsiniz? Detaylar burada.
