I Passed AWS Cloud Practitioner. Now, Can I Actually Build on AWS?
Passing CLF-C02 gave me a foundation in AWS, but designing a real solution is a different challenge. In this article, we will explore how to choose the right services, think through security and cost, and approach a practical S3 and CloudFront portfolio website project.
After earning my AWS Certified Cloud Practitioner certification, I started thinking about what I should do next.
Preparing for CLF-C02 helped me understand AWS services, cloud concepts, security, pricing, and the shared responsibility model. But I've realised that understanding these concepts and actually applying them to a problem are two different things.
I can learn what a service does and where it is used. But when I'm given a requirement and have to figure out the solution myself, there are a lot more things to consider.
Which service should I choose? Do I really need multiple services for this? How should I handle security? And how do I know whether the solution I've designed is actually a good one?
That's something I want to get better at.
Instead of just learning about services individually, I want to start taking simple problems and figuring out how I would solve them using AWS.
So, let's take one example and work through the thought process.
1. Start With the Problem, Not the Service
Imagine you're asked to build a personal portfolio website where you can showcase your projects, skills, and achievements.
Before opening the AWS Console, I'd want to answer a few questions.
- Is this just a static website, or does it need a backend?
- Do I need a database?
- Will visitors only view the content, or will they submit information?
- Should the website support HTTPS?
- How much traffic do I expect?
- What's the simplest solution I can maintain without adding unnecessary complexity?
These questions might seem basic, but they influence the entire architecture.
For example, if the website only contains HTML, CSS, JavaScript, and images, I might not need a virtual server or a database at all.
That's where choosing the right service becomes important. Instead of starting with a service I already know, I can start with what the project actually requires.
2. Choosing the Right AWS Services
Let's look at some of the services that could be relevant to this project.
| Requirement | AWS service | Why it fits |
|---|---|---|
| Store static website files | Amazon S3 | Stores files as objects without requiring a server |
| Run a custom web server | Amazon EC2 | Provides control over a virtual server and its environment |
| Deliver website content efficiently | Amazon CloudFront | Caches and delivers content through edge locations |
| Manage identities and permissions | AWS IAM | Controls access to AWS resources |
| Monitor metrics and logs | Amazon CloudWatch | Helps track resource usage and application behaviour |
| Estimate and review costs | AWS Pricing Calculator and AWS Budgets | Helps estimate costs and receive spending alerts |
One thing I find useful about this comparison is that it shows why knowing a service's definition isn't enough.
Take EC2 and S3, for example. Both can be part of a website architecture, but they solve different problems.
If I need to run a custom application or manage a web server, EC2 could make sense. If I only need to store and serve static website content, managing an EC2 instance might introduce work that the project doesn't require.
The point isn't to use as many AWS services as possible. It's to choose the services that actually solve the problem.
3. What Would the Architecture Look Like?
For this portfolio website, one possible architecture would be:
Website visitor → Amazon CloudFront → Private Amazon S3 bucket
Here's how the components fit together.
Amazon S3
This is where I'd store the website's HTML, CSS, JavaScript, and image files. I don't need to maintain a virtual server just to keep these files available.
Amazon CloudFront
CloudFront delivers the content to visitors and can cache it at edge locations. With the appropriate configuration, it also supports HTTPS for visitors accessing the website.
Origin Access Control (OAC)
This is the part that makes the architecture more interesting from a security perspective. OAC allows CloudFront to access a private S3 bucket, so I don't have to make the bucket publicly accessible just to deliver the website.
There's an important distinction here: uploading files to S3 and enabling its static website hosting doesn't automatically give me an HTTPS-enabled, private-origin architecture.
S3 static website endpoints don't themselves support HTTPS, and they can't be used as private OAC origins in the same way as regular S3 bucket origins. For this design, I'd configure CloudFront with an S3 bucket origin and OAC.
It's a small project, but it already involves storage, content delivery, permissions, and HTTPS.
That's the kind of connection between services I want to become more comfortable with.
4. Security Is Part of the Design
Getting the website to load successfully doesn't necessarily mean I've configured it properly.
There are a few things I'd want to check before calling the project complete.
- S3 permissions: Can the bucket remain private while CloudFront retrieves the website files?
- IAM: Are the permissions limited to what's actually required?
- HTTPS: Is traffic between visitors and CloudFront encrypted?
- Data protection: Have I accidentally included credentials, private files, or other sensitive information in the website?
- Access testing: Does the website work as expected without unnecessarily exposing the S3 origin?
These are practical applications of concepts covered in CLF-C02.
The shared responsibility model is relevant here, too. AWS secures the underlying cloud infrastructure, but I still need to configure my resources and permissions appropriately.
This is why I think security should be considered while designing the solution, rather than treated as something to check only after deployment.
5. Cost: Even Small Projects Need Some Planning
Another thing I'd want to understand before deploying this architecture is what it might cost.
For this example, potential charges could come from S3 storage and requests, CloudFront requests and data transfer, and any additional resources or features I decide to use.
The actual cost would depend on usage, configuration, applicable free offers, and current AWS pricing.
There are a few tools that can help here:
- AWS Pricing Calculator: Estimate the cost of a planned architecture before deploying it.
- AWS Budgets: Set cost or usage thresholds and receive notifications when configured thresholds are reached.
- AWS Cost Explorer: Review recorded spending and understand where costs are coming from.
One distinction worth remembering is that a budget notification isn't automatically a hard spending limit. Receiving an alert doesn't necessarily stop resources from running.
For a small learning project, I'd keep the architecture simple, understand the possible charges, and clean up resources that I no longer need.
Cost awareness is part of designing a solution, too. It shouldn't be an afterthought.
6. The Mini Challenge: Build It Yourself
Reading about an architecture is useful, but actually implementing it would teach me much more.
Here's a challenge I'd like to work through, and one that other AWS learners can try as well.
Objective: Deploy a static portfolio website using Amazon S3 and Amazon CloudFront.
You don't need an elaborate application. A simple page with your introduction, skills, and project links is enough to get started.
Step 1 — Build the website
Create a basic HTML page and add the CSS, JavaScript, and images you need. Make sure it works locally before moving to AWS.
Step 2 — Plan the architecture
Decide which services you'll use and sketch a simple architecture diagram. Try to explain why you chose each component before creating anything.
Step 3 — Deploy the files
Upload your website files to an S3 bucket. Configure CloudFront to deliver the content using a private S3 bucket origin and Origin Access Control.
Step 4 — Verify the configuration
Check that the website loads over HTTPS, the origin isn't unnecessarily exposed, and the permissions work as intended. Don't stop at seeing the homepage load; understand why the configuration works.
Step 5 — Review and clean up
Review the resources you've created and the charges that could apply. When you're finished experimenting, remove resources you no longer need, following the appropriate cleanup steps.
Before considering the challenge complete, see whether you can answer these questions:
- Why did you choose S3 instead of EC2 for this website?
- What does CloudFront add to the architecture?
- How does OAC help protect the S3 origin?
- What would you change if the website needed user authentication and a database?
- Which resources could generate charges, and how would you monitor them?
You don't need to know every answer before starting. The point is to research, implement, test, and understand the decisions you make along the way.
7. What Comes After the First Project?
A static website is a starting point, not the finish line.
Once I'm comfortable with the basic architecture, there are several directions I could explore next.
- Add a backend API: Use Amazon API Gateway and AWS Lambda if the application needs backend functionality.
- Introduce a database: Explore a suitable database service if the application needs persistent data.
- Improve security and monitoring: Review IAM permissions and use CloudWatch to monitor relevant metrics and logs.
- Explore infrastructure as code: Use AWS CloudFormation to define resources in a repeatable way.
- Review the architecture: Use the AWS Well-Architected Framework to think about security, reliability, performance, cost optimisation, and operational excellence.
Each additional requirement brings new decisions. I'd rather understand why a component is needed before adding another service just because it's available.
That's what makes these projects useful: they encourage you to think about the complete solution, not just individual services.
Final Thoughts
Earning my AWS Certified Cloud Practitioner certification gave me a foundation to build on. Now, I want to get better at applying those concepts to actual problems.
I don't think the next step is learning every AWS service or jumping straight into a complicated project. I'd rather start small, understand the requirements, make sensible decisions, and learn from the things that don't work the first time.
For me, that's how theoretical knowledge starts becoming practical experience.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article