Building out a VPC Part 2

Following on from my previous post, we’ll now continue building out our VPC and perform some tests to prove all is as it should be (and as secure as it should be).

Security Groups

Security Groups are our firewalls in the AWS cloud, they allow us to permit/deny protocol and port access level.

We’re going to create two new Security Groups, one to permit the outside world across the www into our public facing instance – a web server as an example.

Our second SG will be permitting our EC2/public facing resources to talk to our backend – perhaps we have our database tier in the private addressing space.

Navigate to your VPC Dashboard and select “Security Groups” from the left hand pane.

Create a new Security Group. Give it a useful name, description and associate it with your VPC. Hit “Create”.

Select your newly created SG and add your required rules. This is our web facing instance in our public subnet, therefore for this web server we’re going to allow SSH and HTTP access from the internet.

Here you can see I have added two rules into the “Inbound Rules” tab within the SG. The top rule allows me to SSH into my instances sharing the same Security Group, and the second allows clients to come in over TCP/80 – HTTP.

To prove this SG we’ll spin up an EC2 instance and check two things:

  • If we can SSH into the instance
  • If the instance can get out to the internet.

There are a few details we need to make sure are correct on the “Configure Instance Details” screen, these are:

  • Network – You want the instance provisioned into your VPC
  • Subnet – You want the instance in the correct public subnet we created earlier
  • Auto-assign Public IP – As this is going to be a public facing instance/server, we want a public IP address to be automatically configured for us.

Before we try to SSH to our newly created instance we need to assign it to the Security Group we created earlier for our public facing instances.

Navigate to “Actions > Networking > Change Security Groups”.

Deselect the wizard SG, as that was created when we spun up the instance and select the appropriate SG that was created earlier to permit SSH and HTTP. This step could have been set during instance creation, but I find it easier to do it post as I get a better feel for what the new instance can and can’t do.

SSH

Attempt to SSH into the instance via PuTTy. If you’ve not done this before I suggest reading this article as the process if different for MAC and Windows.

Grab your instances public IP address – right hand side of the “Description” tab and head over to PuTTy.

Populate your hostname and save the session for future use if required. Then navigate down the left pane to SSH > Auth and browse for your PPK file which will authenticate you and permit you into the instance.

Head back to the Session window and hit Open, if successful you’ll receive the below screen. If this fails it’s likely to be a PuTTy issue with the ppk file, an Security Group issue or a issue with your instance being in the wrong subnet.

Hit Yes here.

We’ve now successfully SSH’d into our AWS EC2 instance, which resides in our configured subnet, inside our VPC.

Increase your privileges using the command “Sudo Su” – this is a Linux VM we’ve created.

Let’s see if our instance in the public subnet can get out to the internet to Yum repositories for example, to update. We know we can get in, but can it get out?

Looks good.

Web Server

We know we can SSH into our instance, as we’ve just done that, but how can we tell if port 80 (HTTP) is open. To test that we’re going to install Apache onto the instance and create a little web page for us to target.


This command will install Apache onto our instance and turn it into a web server.

Now change directory to /var/www/html and create an index.html file, which will be the file our web server will present when we try and access it over the web!

Type a message, or add some ascii art 😉 and exit and save via a CTRL+x and Return.

As you can see, our newly created index.html file now sits in the /var/www/html directory for us to hit when we browse to our server – all going well.

The final thing to do before testing is to start the httpd service, which will make our web server listen for incoming request on port 80.

We can confirm the server is now listening by looking at it’s open ports


The acid test is bringing up the webpage (index.html) in a browser so let’s try that.

And there we are, we’re now serving web pages to anyone on the internet from our EC2 web server. This sits in our defined subnet, inside our VPC, and is restricted by our Security Groups.

That was another long one, so in part 3 we’ll:

  • Spin up a backend server and drop it into our Private Subnet
  • Secure the backend, so only the instances in our public subnet can talk to it – not anyone on the internet!
  • Create a NAT Gateway, so our instances in the private subnet can get secure internet access.

I.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Powered by WordPress.com.

Up ↑

%d bloggers like this: