A first cloud project should be small enough to understand and substantial enough to test. A static website is a useful starting point: you can explain where its files live, how visitors reach them, who can change them and what happens when a request fails.
This proposed lab uses Amazon S3 for files and CloudFront to deliver them. It does not require a virtual server or a database. It is a learning project, not a claim of production availability or a promise that running it will be free. Review current AWS pricing and your account's offers before creating resources.
Define the architecture and its limits
The intended request path is browser, then CloudFront, then a private S3 bucket. The website itself is public; the bucket is not anonymously readable. CloudFront receives restricted permission to retrieve the objects it serves. The distinction matters: a private origin does not make the published website private.
Use a simple page and a small stylesheet that you created yourself. Keep account information, credentials and personal data out of both the files and the repository. Add a README describing the request path, deployment steps, expected costs and cleanup checklist.
Prepare access and a spending boundary
Use an approved learning account with suitable permissions. Follow AWS IAM guidance on temporary credentials, least privilege and multi-factor authentication. Do not put access keys in page code or screenshots. Ask the account owner before using a shared account.
Create an appropriate cost budget and notification route before the lab. AWS Budgets documentation explains that billing information is updated periodically. A budget alert is not an instant spending cap. Choose a spending allowance you can accept and check actual usage as well as notifications.
List the billable components you intend to create. Storage, requests, data transfer and optional features can contribute to the bill. A custom domain adds separate considerations, so the CloudFront distribution address is sufficient for this first exercise. Do not assume a free offer applies to your account or covers every component.
Connect CloudFront to the private bucket
- Create a dedicated S3 bucket for the lab and retain Block Public Access. Upload only the files intended for the public website.
- Create a CloudFront distribution with the regular S3 bucket origin. Do not select the S3 website endpoint for this design.
- Configure origin access control and the restricted bucket policy for that distribution, following the current AWS instructions.
- Choose request signing as recommended by AWS and configure the viewer behaviour to use HTTPS.
- Set
index.htmlas the default root object and wait for distribution changes to finish deploying.
AWS's origin access control documentation distinguishes regular S3 origins from website endpoints: the latter cannot use this OAC setup. Its policy examples also show how access can be limited to the intended distribution. Read those instructions instead of making the bucket public when a request fails.
Verify behaviour, not just the homepage
Open the distribution address over HTTPS and confirm that the expected page and stylesheet load. Check the root address separately from /index.html. AWS explains the default-root behaviour in its default root object guide; it is not automatic index-file handling for every nested directory.
Test an anonymous request to a direct S3 object address using a client without signed credentials. It should be denied. A successful CloudFront response and a denied direct-origin response together provide evidence about this access path. Neither check is a complete security assessment.
Run a controlled failure exercise
Use only your dedicated lab. Do not remove production permissions or disrupt a shared distribution. Start with a harmless request for an object that does not exist, then record the response and investigate the relevant configuration.
| Check | What to learn |
|---|---|
| Request a missing file | The S3 GetObject reference explains why a missing object can return access denied instead of not found; inspect the cause. |
| Upload a changed stylesheet | An edge cache may keep an older version until its cache policy allows refresh. |
| Try the root URL | A default root object connects the root request to the intended file. |
| Request the S3 object anonymously | The origin should remain protected even while CloudFront serves the page. |
For a cache exercise, use a new asset filename and update the page reference, or study invalidation behaviour before using it. Note the settings and wait for changes to propagate. This is a test of request and deployment behaviour, not a demonstration of server failover: this design has no virtual server to stop.
Make cleanup part of the deliverable
When the exercise ends, remove the resources you no longer need following AWS's cleanup instructions. CloudFront distributions must be disabled before deletion. A bucket must be emptied before deletion; if versioning was enabled, include old versions and delete markers. Remove lab-only access policies and any optional logging resources you created.
Record what was removed and what remains intentionally. Check the billing view again after its reporting delay. Saving a screenshot of the homepage is not a cleanup record, and closing the browser does not stop cloud charges.
Explain the project in your README
Include a simple architecture diagram, the access boundary, deployment instructions, the checks you ran and their actual results. List a remaining limitation, such as an untested custom-domain setup or a missing automated deployment. Keep screenshots free of sensitive account details. A clear explanation of a small tested project is more useful than a long list of services you cannot explain.
Common questions
Is this an always-free website?
No cost promise is made. Check current prices, offers and account eligibility, monitor usage and remove resources when finished.
Does a private S3 bucket mean visitors must sign in?
No. In this design CloudFront serves the public content. The bucket restriction controls origin access, not visitor authentication.
Is this enough to claim production reliability?
No. It demonstrates a specific architecture and a few checks. Production requirements need a separate review of security, monitoring, recovery, cost and operational ownership.
Explore AWS training or the Cloud Project Lab. The lab describes a selective pathway with separate terms for any actual assignment. Ask for counselling to discuss your starting skills and a suitable project.