Forem: Anton Poriadin

Cross-Account CodeCommit Access from EC2

Anton Poriadin — Tue, 07 Nov 2023 05:26:42 +0000

Introduction
Cross-Account CodeCommit Access from EC2
- Step 1: Create an IAM role in Account A
- Step 2: Create a policy in Account B
- Step 3: Create an IAM role in Account B
- Step 4: Create a CodeCommit repository in Account A
- Step 5: Create an EC2 instance in Account B
- Step 6: Connect to the instance and checkout files
Lessons learned

Introduction

In this two-part series, I will guide you on how to access an AWS CodeCommit repository using git-remote-codecommit. This tutorial will specifically focus on accessing a repository from a different account. In contrast, the first part of this series explains how to access a repository from the same account.

While working on a project, I came across a situation where a client was using SSH keys to interact with CodeCommit on their EC2 server. In my opinion, this approach is not secure, as there is a risk of the key being leaked, and it is difficult to keep track of who has access to it. I believe a more secure and transparent approach should be adopted to ensure better security.

My client might be one of many using this method to interact with CodeCommit. Therefore, I wrote a tutorial to help others secure their repository interactions.

While I suggest going through the tutorial to consolidate your knowledge, you can also see the entire process through the numerous screenshots I have provided to make the tutorial more straightforward.

Cross-Account CodeCommit Access from EC2

To complete this tutorial, we need to create certain resources in two AWS accounts. In Account A, we need to create an IAM role and a CodeCommit repository. In Account B, we need to create an IAM policy, an IAM role, and an EC2 instance.

Additionally, after completing the tutorial, it's recommended to delete these resources to avoid unnecessary AWS charges.

Step 1: Create an IAM role in Account A

Let's start by creating the first role. Go to the console and search for Identity and Access Management. Then, select Roles from the left-hand menu and click Create Role. This time, we will allow a different account to use our role from Account A. Therefore, we will choose AWS Account as the use case. In the section below, select Another AWS Account and provide the account ID.

Afterward, click Next and attach the AWSCodeCommitReadOnly permission. This will ensure that the other account can't push any changes to our repository.

Finally, name the role account_a_cross_account_role. Scroll down and click Create Role.

Congratulations! You have successfully created a role for cross-account access. Let's move on to the next step.

Step 2: Create a policy in Account B

It's time to switch to Account B. To proceed, let's create a policy first. Go to the console and search for Identity and Access Management. From the left-hand menu, select Policies, then create a policy.

Select STS from the service dropdown. In the actions section, we need to configure granular access. To do this, expand options under the Write access level and select the AssumeRole option.

Next, let's specify a resource under the resource section. Choose the specific option and click on Add ARNs. Set the ARN of the role that we created in the previous step, which should look like arn:aws:iam:123456789012:role/account_a_cross_account_role.

Navigate to the next screen and name the policy account_b_cross_account_access_policy.

Click Create.

Step 3: Create an IAM role in Account B

It's time to create a classic EC2 role and attach the policy we previously created. From the left-hand menu, select Roles and then create a role. Ensure that AWS service is selected. Next, select EC2 under Common Use Cases and click Next.

Next, we will add the managed policy we previously created to our role. Search for account_b_cross_account_access_policy and press "Enter". You will find the managed policy that provides the necessary permissions to assume the role from Account A on your EC2 instance. Select the policy and click Next.

We will name our role account_b_ec2_role, and then scroll down to click the Create Role button.

Step 4: Create a CodeCommit repository in Account A

If you've completed the previous tutorial and haven't deleted the repo, you can skip this step. Otherwise, let's create a new repository. For this demo, I have created a repository named repository.

Once you have created the repository, you'll see a screen with different connection options. We will use the recommended HTTPS (GRC) method to support connections made with federated access, identity providers, and temporary credentials.

To add content to the repository, we need to create a simple text file. Firstly, scroll down to the section that says "empty repository" and click on the center button that says Create File.

Next, put "Hello World!" as the content and "file.txt" as the file name to match the file created in the previous tutorial. You also must put your author name and email, and then click on Commit Changes to complete the process.

That's all for this step. You can move on to the next one.

Step 5: Create an EC2 instance in Account B

Let's move forward to the next step. We need to create an EC2 instance and name it account_b_instance. We'll use Amazon Linux 2023, which is the perfect fit for our needs.

Regarding hardware, we'll select the latest toys and choose an arm-based image. For our demo, t4g.nano is more than enough. This time, we'll proceed without a keypair.

Now, expand the Advanced details tab and select the IAM instance profile we created earlier.

To ensure that we have all the necessary tools, we will install them with the User Data script. Here is the script we will use:

#!/bin/bash
dnf install git -y
curl -O https://bootstrap.pypa.io/get-pip.py
python3 get-pip.py
pip install git-remote-codecommit

Let me explain what we'll do here:

First, we'll install git as we can't interact with our repository without it.
We need to download PIP, which is a package manager for Python packages.
After downloading, we'll install PIP.
Finally, we'll install git-remote-codecommit using pip.

Here is a screenshot that shows how the field appears in the console.

That's all we need to do. Let's wait for a moment while AWS creates an instance for us.

Step 6: Connect to the instance and checkout files

Once the instance is ready, let's proceed with the next steps. To connect through the console, switch to the EC2 console, where you will see a page similar to the screenshot below.

Select the instance and click the Connect button at the top right corner. Then, click Connect again on the next screen.

After logging in, we can start with the necessary actions. The first step is to set up a profile based on the assumed role from account A. You will need to replace the ARN of the role with your own ARN in the first line.

aws configure set role_arn arn:aws:iam::123456789012:role/account_a_cross_account_role --profile CodeAccess
aws configure set credential_source Ec2InstanceMetadata --profile CodeAccess
aws configure set role_session_name "code_access" --profile CodeAccess

By following these commands, you will create a profile. There should be no output.

You have created a profile, but tools like the CLI can't predict whether to use the default profile or any named profile you created, so you need to specify it if you don't want to use default. Let's try to list repositories. First, we will use a simple AWS CLI command without the profile parameter:

aws codecommit list-repositories

Since we do not have permissions with the default role, this call will result in an error. However, we can specify the profile we created with the --profile parameter, and the command will return our repository from account A. So let's try that:

aws codecommit list-repositories --profile CodeAccess

You can see the result in the screenshot below if you don't want to follow along in your console.

We have confirmed that we have access to the repository in Account A, and now it's time to check it out. To do this, we need to specify the profile for git-remote-codecommit. You can find the documentation for this process here. Let's attempt to run the following command:

git clone codecommit::us-east-1://CodeAccess@repository

We have successfully checked out the repository. Now, let's test our read-only permissions. We will attempt to modify the file and push the changes. These are the steps we need to follow:

cd repository/
nano file.txt
git add file.txt
git commit -m "Second release of Hello World!"
git push

Let me explain the commands above in detail. Firstly, go to the "repository" directory. Once you're there, use a text editor such as Nano or any other editor you prefer to make changes to the file. After making the changes, add the modified file to Git. Then, create a new commit and push the changes to the repository.

However, we encountered a 403 error due to our limited read-only permissions.

If you need to push changes from a different account, you can jump to Account A and replace the AWSCodeCommitReadOnly policy with AWSCodeCommitFullAccess for the account_a_cross_account_role role to grant full access.

And push the changes after that without any errors.

Lessons learned

I hope you found the article about accessing a CodeCommit repository from a different account using git-remote-codecommit helpful. Perhaps you even learned something new!

To summarize, you now have the skills to securely access a CodeCommit repository from a different account using the recommended approach. Additionally, you have learned how to create roles for cross-account access, which is quite useful.

I hope you enjoyed reading the article and gained valuable insights from it. If you found it helpful, please feel free to share, ask questions, or share your thoughts. Let's continue the conversation. Until next time, happy coding!

CodeCommit Access from EC2

Anton Poriadin — Mon, 23 Oct 2023 20:10:31 +0000

Introduction
CodeCommit Access from EC2
- Step 1: Create an IAM role
- Step 2: Create a CodeCommit repository
- Step 3: Create an EC2 instance
- Step 4: Connect to the instance and commit a file
- Step 5: Check the file in the CodeCommit console
Lessons learned

Introduction

In this two-part series, I will show you how to access an AWS CodeCommit repository using git-remote-codecommit. The first part focuses on accessing a repository from the same account, while the second covers accessing a repository from a different account.

My client might be one of many using this method to interact with CodeCommit. Therefore, I wrote a tutorial to help others secure their repository interactions.

CodeCommit Access from EC2

In order to complete this tutorial, we will need to create a few resources: an IAM role, a CodeCommit repository, and an EC2 instance. It's important to note that these resources should all be created within the same AWS account. Additionally, after completing the tutorial, it's recommended to delete these resources to avoid unnecessary AWS charges.

Step 1: Create an IAM role

To get started, we need to create a role. Go to IAM Roles and click Create role. Under the Trusted entity type section, select AWS Service. Since we'll be using EC2, select it as a use case.

The next screen will require us to add a policy. We need to select AWSCodeCommitFullAccess for demo purposes as we want to commit a file. However, on a real server, choosing AWSCodeCommitReadonly or even a stricter role is recommended to stick to the principle of least privilege.

To keep things simple, name the role account_a_ec2_role. Scroll down and click Create Role.

Perfect! This is all we need for this role. Now, let's move on to the next step.

Step 2: Create a CodeCommit repository

To keep things simple for the demo, I have created a repository named repository, which perfectly describes its purpose.

After creating the repository, you'll see a screen with various connection options. We will be using the third option, which is HTTPS (GRC). According to AWS, this is the recommended method for supporting connections made with federated access, identity providers, and temporary credentials.

That's all for this step. We can move on to the next one.

Step 3: Create an EC2 instance

Let's move on to the next step, which is the most interesting one. We need to create an EC2 instance and name it account_a_instance. We just want to keep the naming simple. We'll go with Amazon Linux 2023, which works great for us.

Regarding hardware, we'll select the latest toys and choose an arm-based image. For our demo, t4g.nano is more than enough. This time, we'll proceed without a keypair.

Now, let's expand the advanced details tab and select the IAM instance profile we created earlier.

To make sure we have all the necessary tools, we'll install them with the User Data script. Here is the script we'll use:

#!/bin/bash
dnf install git -y
curl -O https://bootstrap.pypa.io/get-pip.py
python3 get-pip.py
pip install git-remote-codecommit

Let me explain what we'll do here:

First, we'll install git as we can't interact with our repository without it.
We need to download PIP, which is a package manager for Python packages.
After downloading, we'll install PIP.
Finally, we'll install "git-remote-codecommit" using pip.

That's all we need to do. Let's wait for a moment while AWS creates an instance for us.

Step 4: Connect to the instance and commit a file

When the instance is ready, let's continue. To connect through the console, switch to the EC2 console, where you see something like the image below.

Select the instance and click the Connect button located at the top right section with buttons. Then click Connect again on the next screen.

You will see something like the image below once you have successfully connected to the instance.

As the first step, let's check out the repository. Open the tab with the repository if it's still open, or go to CodeCommit and select our repository. You basically need to copy a command from the bottom of the HTTPS (GRC) tab.

An example command from my console would look like this:

git clone codecommit::us-east-1://repository

Run this command on the instance. The output will say

Cloning into 'repository'...
warning: You appear to have cloned an empty repository.

Which is perfectly fine since it's an empty repository, and we will commit our first file in a few steps.

Now, let's type a few more commands.

cd repository/
echo 'Hello World!' > file.txt
git add file.txt
git commit -m "First release of Hello World!"
git push

First, we need to go to the directory with our repository. Then, we want to create a file that contains the string "Hello World!" Next, we add the file to git, create a commit and push the changes. If everything runs successfully, you will see output that looks like the image below.

This way we created a file and committed it to the repo. Let's jump to the final step of this quick demo.

Step 5: Check the file in the CodeCommit console

Open the tab with our repository where you found the connection instructions earlier and refresh the page.

You will see the file we created on our EC2 instance. This indicates that we can access our repository without using long-term personal credentials.

Lessons learned

I hope you found the article on accessing a CodeCommit repository using git-remote-codecommit helpful. Perhaps you even learned something new.

To sum up, you now have the skills to enable secure access to CodeCommit from your computing resources. In my experience, I haven't come across a project where using personal or long-term credentials was advantageous.

I hope you enjoyed reading this article and gained valuable insights from it. Feel free to share it, ask questions, or share your thoughts if you found it helpful. Let's continue the conversation. Until next time, happy coding!

The Magical City Behind the NAT Gateway: An AWS Adventure

Anton Poriadin — Wed, 12 Jul 2023 22:39:42 +0000

This article is inspired by a brilliant article I came across a few years ago. Since then, it has become a cornerstone of my recommendations, as it beautifully illustrates the core AWS Virtual Private Cloud (VPC) concepts.

Each project's infrastructure functions like a living organism — constantly evolving, expanding, and adapting to accommodate distinct needs throughout its lifecycle. This dynamic character of project infrastructure represents a reality we often overlook.

This post delves into a Network Address Translation (NAT) gateway and attempts to illustrate various infrastructure configurations across projects of varying scales. To help illustrate this concept, we will use a whimsical analogy of a magical city.

What is a NAT gateway?

In simple terms, a NAT gateway is a service that helps your resources in a private subnet of your VPC communicate with the internet.

When you create a VPC in AWS, you can have both public and private subnets. The public subnets can directly access the internet, but the private subnets are isolated and can't directly connect to the internet. This is where the NAT Gateway comes into play.

The City

Imagine a vast, bustling, and magical city. This city is akin to your private subnets in AWS. This city's buildings, parks, and roads represent your EC2 instances, database services, application services, and other resources you're running within your subnet. Each distinct area in the city is like a different availability zone. Some zones may be residential, some commercial, some industrial, and others purely magical – in AWS, these could represent different application tiers or functions like web servers, application servers, and databases.

For sure, we want to protect our magical city from unwanted visitors - those from the outer world who may mean harm or disruption. This is where the castle walls with magical portals to the external world or the NAT gateway come into the picture. These walls and portals prevent strangers (unsolicited inbound traffic) from entering the city directly while allowing the residents (private subnet resources) to go outside and return safely (outbound internet access). It ensures only authorized entities can get in, like knights returning from a quest.

Certainly, as our city's architects and overseers, predicting its growth and expansion will be an enthralling journey. Like a living, breathing entity, the city will evolve, with new districts emerging, the city walls expanding, and the population growing. We'll face unexpected challenges. Let's gear up for this adventure, because with every sunrise, our magical city holds a promise of novel experiences and learning opportunities. I bet it's going to be an exciting ride, don't you?

Village (Single NAT Gateway)

The whole city is surrounded by a wall and there is only one magical portal to the outside world. All the traffic from the different districts has to pass through this portal to reach the world beyond.

Using a single portal for your magical city can have its advantages:

Cost Saving: Maintaining one portal is less expensive than having multiple ones. After all, each portal requires its own magic (or in real terms, more resources) to function and keep it safe, right?
Simplicity: One portal, one spell. It's easier to manage and less complicated to maintain.
Security and Control: A single point of entry and exit allows the city's guardians to effectively monitor, filter, and control what comes in and out of the city.

However, this one magical portal also carries potential risks:

A single point of failure: What if the magic fails or the guardians are distracted by a dragon attack? Well, then nobody can get in or out of the city.
Bottleneck: If your city grows and more people need to use the portal, it could lead to delays and frustrated citizens.

This setup is ideal for new projects. It's essential to be aware of potential risks, but remember, this is likely the most cost-effective arrangement in the initial stages.

Town (One NAT Gateway per availability zone)

Our city is flourishing and growing larger. We need to account for its ability to manage challenges like increased traffic or potential disruptions in any of the districts. Currently, each district has its own portal for reaching the outside world. This allows traffic from each area to flow easily through its specific gateway and access what lies beyond.

Here's why this might be a good idea:

Improved Redundancy and Resilience: If one portal is under a troll attack, the other portals aren't affected and can keep functioning. This reduces the risk of the whole city getting cut off from the outside world.
High Availability: With each district having its own portal, there's no worry if one portal goes down due to a curse or magical mishap. The other districts remain unaffected, and the citizens can continue their journey to and from the outside world.
Better Scalability: With multiple portals, you effectively spread out the traffic, preventing any one portal from getting overcrowded. This helps avoid traffic jams and keeps everything moving smoothly.

However, just as with everything in magic and technology, there are trade-offs:

Increased Cost: More portals mean more magic, and more magic means more cost. You'll need to factor this into your city's treasury.
Management Complexity: Each portal needs its own team of wizards for maintenance and its own set of security spells, which means more things to manage and keep track of.
Security Challenges: Having multiple access points requires diligent monitoring and security measures to prevent any dark forces from entering the city.

This stage effectively addresses the issues highlighted in the previous setup. Most projects maintain this arrangement for their entire lifespan. Although there's an additional cost involved, it successfully resolves all fundamental challenges. Therefore, it's a worthwhile stage for handling production workloads.

City (One NAT Gateway per subnet)

Here's the twist: every neighborhood has its own portal. That means all the traffic from such neighborhood can independently zip through its own portal to reach the world beyond.

Here's why having one NAT Gateway per subnet could be beneficial:

Performance: Each neighborhood managing its own traffic through a dedicated portal can help prevent congestion and ensure smooth data flow.
Scalability: As your city grows, new neighborhoods with their own portals can be added. This means your city's capacity to handle traffic can increase as needed.
Efficiency: Each portal only handles the traffic for its neighborhood, which can increase efficiency as traffic patterns can be more predictable.

Yet, we're faced with similar trade-offs, but they bear even more significance now.

This stage could be particularly relevant for projects with heavy loads. It does offer performance enhancement. Here, your project is already up and running, and your primary goal is to ensure it operates as smoothly as possible. Your chief concern should be the quality of your service.

Lessons Learned

To wrap things up, let's think back to our magic city, a city that, like our project, started small and had a single protective wall and one magical portal. But as the city grew, it needed more protective barriers and magical gateways. This is much like the evolution of a project's infrastructure, beginning with one NAT gateway and eventually scaling up to have individual NAT gateways for high-loaded subnets.

Our small, charming city once had only one wall and a magic portal that met everyone's needs. It's just like when a project is new; one NAT gateway can manage all the internet traffic for private subnets. But as our city got bigger and more people and areas needed to use the magic door, it became clear that one door just wouldn't be enough. This is where the idea of staying strong, or resilience, becomes important.

Imagine if the only magical portal in the city was blocked or failed for some reason. The whole city would be stuck, unable to move in or out. It's the same with a project. If the only NAT gateway in a project breaks down, it could cause big problems. So, having more magic doors, like having multiple NAT gateways, helps manage the increased flow of people and adds a layer of resilience. If one portal fails, there are other doors people can use. This is key to maintaining smooth operations and protecting the city, or project, from unexpected problems.

As city planners carefully choose where to put extra walls and doors, we must also be wise about our project setup. It might be easy to follow a simple guide and use one NAT gateway for the whole project. But, we should always make sure our infrastructure fits our current needs and consider possible risks.

I hope you enjoyed this journey with me. Feel free to share it, leave your thoughts, or ask questions if you found it helpful. Let's keep the conversation going. Until next time, happy coding!

How to Host a Secure Static Website using AWS S3 and CloudFront

Anton Poriadin — Sun, 09 Jul 2023 19:11:32 +0000

Introduction
How to host a static website in a secure way
- Step 1: Create static website
- Step 2: Create S3 bucket
- Step 3: Upload our website to S3
- Step 4: Create CloudFront Distribution
- Step 5: Update bucket policy
- Step 6: Let’s check our site
- Step 7: Create custom error documents
- Step 8: Get real 404
Lessons Learned

Introduction

In this easy-to-follow guide, I will show you how to put your static website on the internet using Amazon's S3 and CloudFront. We'll keep things secure, sticking to a blend of best practices and AWS recommendations. We'll cover the basics and also get into some of the details, making it simple for you to host your website. Let's dive in!

How to host a static website in a secure way

In order to finish this tutorial, we need to create an S3 bucket and a CloudFront distribution. We will also explore the bucket policies and Origin Access Control (OAC). Once you're done with the tutorial, deleting these resources is a good idea to avoid unnecessary AWS charges.

Step 1: Create static website

To host a static website, we need to do a few things before we can get started. We must create it first. Don't worry. Creating a static site can be complicated, but we'll keep things simple.

To begin, we'll start with some basic HTML. We don't want to go into too much detail at this point. Let's focus on just a few files that are essential for now.

index.html

<!DOCTYPE html>
<html lang=en>
  <head>
    <meta charset=utf-8>
    <title>index</title>
  </head>
  <body>
    <h1>Hello World!</h1>
  </body>
</html>

403.html

<!DOCTYPE html>
<html lang=en>
  <head>
    <meta charset=utf-8>
    <title>403</title>
  </head>
  <body>
    <h1>403</h1>
  </body>
</html>

404.html

<!DOCTYPE html>
<html lang=en>
  <head>
    <meta charset=utf-8>
    <title>404</title>
  </head>
  <body>
    <h1>404</h1>
  </body>
</html>

Step 2: Create S3 bucket

Let's begin by navigating to the AWS Management Console. Take advantage of the search box positioned at the top of the screen for a faster route. By typing in "S3", you can quickly locate the S3 service amidst the numerous services AWS offers.

Before we delve into creating a new S3 bucket, it's essential to remember a couple of crucial points:

Each S3 bucket must be created in a specific geographical region. This region can be chosen based on factors such as data governance requirements, proximity to the majority of your users, or cost.
Each bucket name must be globally unique across all existing bucket names in Amazon S3. This is because the bucket namespace is shared by all AWS accounts worldwide. Therefore, it's a good idea to devise a unique name that relates to its purpose.

In this walkthrough, I've opted for the name "one-more-secure-website". This name encapsulates the purpose of our bucket - to hold assets for a secure website - and also adheres to the requirement of global uniqueness. Now, we're ready to create our S3 bucket using this name.

You can now adjust various settings, including versioning, server-side encryption, and access permissions. However, you can leave these settings at their default values for this tutorial. Remember, these configurations can be modified later if required.

Once you're satisfied with the settings, finalize the process by clicking on the "Create bucket" button at the bottom of the page. Your new bucket should now be successfully created in your designated AWS region.

Step 3: Upload our website to S3

We need to move some files to a place called an S3 bucket. You can do this two ways: using the AWS Management Console or running commands from your computer using CLI or Command-Line Interface.

If you're okay with typing commands, it's pretty easy. Keep in mind that you need to install the AWS CLI in order to use it. For example, if you have a file called "index.html" and you want to put it in your bucket, you'd type something like this:

aws s3 cp index.html s3://{bucket}/index.html

Step 4: Create CloudFront Distribution

This is the most exciting part. You might have noticed that we haven't made any changes to the S3 settings, yet we still want to host a static website. The reason is that CloudFront has all the necessary features to accomplish that.

Open up the AWS console, the control panel for all Amazon's tools. Type "CloudFront" in the search box on top. It'll take you right to the CloudFront tool.

There's a button that says "Create a CloudFront distribution". Click it. This will start the process of setting up how your website data gets sent out.

You'll be asked to select your "origin domain". That's where your website data is coming from - in our case, it's our S3 bucket, the storage space we mentioned earlier.

Look for the "Origin access control settings" area. Go for the "Origin access control settings (recommended)" option and click "Create control setting". It's okay to stick with what's already there, no need to change anything. Then click "Create".

Next, we have to sort out the "Default cache behavior". This is how CloudFront stores and sends your website data. Make sure you change "Viewer protocol policy" to "Redirect HTTP to HTTPS". That's just a fancy way of saying it makes sure anyone visiting your site has a secure connection. Leave everything else as it is.

You'll see a "Web Application Firewall (WAF)" section. We're going to skip it, so select "Do not enable security protections".

Almost there! In the "Settings" part at the bottom, make sure the "Default root object" says "index.html". That's just telling CloudFront what to show when someone visits your website.

To finish off, scroll down and click "Create distribution". And there you go! You've set up how your website gets sent to viewers with CloudFront.

Step 5: Update bucket policy

After setting things up, you'll get two messages from AWS. The first one basically says, "Good job! You've created the distribution successfully!" The second one suggests you update your S3 bucket policy, which is like a set of rules for your S3 bucket. This update is needed so CloudFront can read what's in your S3 bucket.

Here's how to do that:

Look for and click on the "Copy Policy" button, then click on the "Go to S3 bucket permissions to update policy" button. When you click this, it'll take you directly to your S3 bucket's permissions tab.
Find the "Bucket Policy" section and click "Edit". You'll see a field where you can paste the policy you got earlier.
After inserting the policy, hit "Save changes" to lock in these new rules.

Once that's done, you'll have to wait a bit. The CloudFront distribution is getting ready, which is like preparing your content for delivery. You've created a strong base for hosting a safe, static site.

Step 6: Let’s check our site

To check out the site we've set up, copy the distribution domain we've given and put it into browser's address bar. Upon opening it, you should see our index page.

You can also try typing in the address without the "https://" part at the beginning, just using "http://" instead. If you do this, don't worry, CloudFront will automatically guide you to the secure version of the site (the one starting with "https://"). You might notice a message saying "301 Moved Permanently", that just means CloudFront moved you to the secure page, which is a good thing!

Step 7: Create custom error documents

Imagine you've got a bucket and it only contains three files: an index, a "403" item, and a "404" item. Now, pretend you're looking for something that isn't there, like a document called "another.html". You'd probably expect to be told, "Sorry, can't find that" – or in internet language, you'd expect a '404 error'. Let's check if that's what actually happens.

Oops! Instead of a simple "can't find that" message, we get a weird XML document and a 403 error. A bit strange, huh? You'd think we'd get a 404 error for something missing, not a 403 error. But let's not worry about that right now. Let's focus on making this whole thing less confusing for our users.

First, click on the tab that says "Error Pages". Then select the option that says "Create custom error response", and fill in the information for the 403 error. Hit the Save button when you're done.

Now, try to open "another.html" again. This time, you should see our custom error page instead of that strange XML. Much better, right?

Step 8: Get real 404

Ever wondered why you sometimes get a 403 error from S3 when a file isn't found? It's because of security reasons.

Amazon S3 gives you an "AccessDenied" error when you ask for a file that doesn't exist, and you don't have the permission to see all the files in that bucket. It's a neat way of keeping things private, as it doesn't let anyone know if the file you're looking for actually exists or not.

So, what if we allow CloudFront to have the "s3:ListBucket" permission? This lets it see all the files in the bucket. Here's how you do it:

Go to the permissions tab of the S3 bucket.
Find the statement that you pasted previously and copy it.
Please make a copy of that statement, but change it slightly. First, change the action to allow "s3:ListBucket". Then, make sure you remove "/*" from the end of the resource name. This new permission should be given to the bucket itself, not its contents.

Original policy:

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::one-more-secure-website/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::{account_number}:distribution/E3QFHDB3Z8A00A"
                }
            }
        }
    ]
}

Modified version:

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::one-more-secure-website/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::{account_number}:distribution/E3QFHDB3Z8A00A"
                }
            }
        }, {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::one-more-secure-website",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::{account_number}:distribution/E3QFHDB3Z8A00A"
                }
            }
        }
    ]
}

Once you've done that and refresh the page, you'll see a different error message - "NoSuchKey". This means that CloudFront can now tell us when the file we're looking for isn't in our bucket.

To finish things off, let's add another custom error page for when a 404 error occurs. Once you've done that and refresh the page, you'll see our custom HTML message instead of the standard error message.

Lessons Learned

I hope you've found this article about hosting a static website using S3 and CloudFront helpful and perhaps even learned something extra. Let's sum it all up:

You now have the skills to host a website securely without leaning on the S3 static website feature and making a bucket public.
Every architectural choice has its pros and cons. Navigating through the world of AWS, you might find many paths leading to the same destination. The obvious path isn't always the wisest.
In this tutorial, we've crafted a simple infrastructure. While it doesn't cover all the aspects of a real-world project, like versioning, logs, or complex topics such as CORS, it gives you a solid foundation to build upon.

I hope you enjoyed this journey with me. Feel free to share it, leave your thoughts, or ask questions if you found it helpful. Let's keep the conversation going. Until next time, happy coding!

Forem: Anton Poriadin

Cross-Account CodeCommit Access from EC2

Table of contents

Introduction

Cross-Account CodeCommit Access from EC2

Step 1: Create an IAM role in Account A

Step 2: Create a policy in Account B

Step 3: Create an IAM role in Account B

Step 4: Create a CodeCommit repository in Account A

Step 5: Create an EC2 instance in Account B

Step 6: Connect to the instance and checkout files

Lessons learned

CodeCommit Access from EC2

Table of contents

Introduction

CodeCommit Access from EC2

Step 1: Create an IAM role

Step 2: Create a CodeCommit repository

Step 3: Create an EC2 instance

Step 4: Connect to the instance and commit a file

Step 5: Check the file in the CodeCommit console

Lessons learned

The Magical City Behind the NAT Gateway: An AWS Adventure

What is a NAT gateway?

The City

Village (Single NAT Gateway)

Town (One NAT Gateway per availability zone)

City (One NAT Gateway per subnet)

Lessons Learned

How to Host a Secure Static Website using AWS S3 and CloudFront

Table of contents

Introduction

How to host a static website in a secure way

Step 1: Create static website

Step 2: Create S3 bucket

Step 3: Upload our website to S3

Step 4: Create CloudFront Distribution

Step 5: Update bucket policy

Step 6: Let’s check our site

Step 7: Create custom error documents

Step 8: Get real 404

Lessons Learned