Get your Portfolio from Local to Global
Pushing a portfolio site live on AWS using Amazon S3, CloudFront, and the AWS CLI, drafted for anyone who built something locally but has never deployed to the cloud before.
I had a portfolio site sitting on localhost for about three weeks before I actually put it online. Not because deploying is hard, but because I assumed it would cost money, and I genuinely didn't know I already had credit sitting unused in my AWS account from the day I signed up. Turns out that credit alone covers this project many times over. Follow this and your site is hosted easily on AWS.
The approach, explained before we touch anything
- Amazon S3 is where your actual files live. Think of it as a very reliable folder in the cloud. On its own, S3 can serve files, but it doesn't give you HTTPS or a clean way to add a custom domain.
- CloudFront sits in front of that S3 bucket. It caches your site at locations closer to wherever your visitors are, which makes it load faster, and it's what actually provides the HTTPS padlock in the browser. Keeping your S3 bucket private and routing everyone through CloudFront instead is the current recommended setup, rather than making the bucket itself public.
- AWS Certificate Manager, or ACM, issues the free SSL certificate that CloudFront uses for HTTPS. Route 53 is optional and only comes into play if you want a custom domain instead of the default CloudFront web address.
1. Get your Site Ready on Local Environment
Before touching AWS at all, make sure your project is in its final, built form. If you wrote plain HTML, CSS, and JS, that's already ready. If you used something like React or Vue, run your project's build command first, which usually produces a folder named build or dist. containing the actual static files you'll be uploading. Confirm there's an index.html file sitting at the top level of that folder, since that's what gets served first.
2. Install and Setup the AWS CLI on your system
Install the AWS CLI following AWS's official instructions for your operating system. Once it's installed, create an IAM user for yourself instead of using your root account for this, give it programmatic access, and generate an access key for it. Then run this once in your terminal and paste in your key when prompted.
1
aws configureThis step connects your local terminal to your AWS account, which is what makes pushing files from your laptop actually possible.
3. Create the S3 bucket
In the S3 console, create a new bucket and give it a unique name. Leave Block Public Access turned on, which is the default and the safer choice, since CloudFront will be the one reaching into this bucket rather than the public internet reaching it directly.
4. Push your files from your local environment
This is the actual deployment moment. From inside your built portfolio folder, run:
1
aws s3 sync . s3://your-bucket-nameThis command uploads everything in your current local folder straight into the bucket, and if you run it again later after making changes, it only uploads what's actually different, which makes future updates fast.
5. Set up CloudFront in front of the bucket
Create a CloudFront distribution and point its origin at the S3 bucket you just filled. When prompted, choose to use Origin Access Control, which lets CloudFront read from your still private bucket without you having to open it to the public. CloudFront will generate a signed policy you attach to the bucket, and the console walks you through that part directly.
If you want HTTPS working cleanly on a custom domain later, request a certificate through ACM in the us-east-1 region specifically, since that's a requirement for certificates used with CloudFront, regardless of which region your bucket itself lives in.
Once the distribution finishes deploying, which usually takes several minutes, you'll get a CloudFront web address that already serves your site over HTTPS.
6. Point a custom domain at it, if you want one
This step is entirely optional. If you register a domain through Route 53, or already own one elsewhere and point its nameservers at Route 53, you create an alias record pointing your domain at the CloudFront distribution instead of at an IP address. Once that record propagates, your custom domain and your CloudFront distribution become the same thing from a visitor's perspective.
Updating your site later
When you make changes locally, rerun the same sync command, then let CloudFront know the cached version is outdated:
1
aws cloudfront create-invalidation --distribution-id YOUR_ID --paths "/*"Without this last step, CloudFront will keep serving the old cached version for a while even after your new files are uploaded, which trips up a lot of people the first time they update their site and wonder why nothing changed.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article