Building three-tier architectures with security groups

Update 2 (27 Oct 2017): This post is no longer current. I would recommend that you start by reading the Network and Security documentation and read about Web Application Hosting in the AWS Cloud. You should also take a look at the Web Hosting Best Practices white paper.

Update 1 (17 June 2010): I’ve changed the command-line examples to reflect current capabilities of our SOAP and Query APIs. They do, in fact, allow specifying a protocol and port range when you’re using another security group as the traffic origin. Our Management Console will support this functionality at a later date.

During a recent webcast an attendee asked a question about building multi-tier architectures on AWS. Unlike with traditional on-premise physical deployments, AWS’s virtualization of compute, storage, and network elements requires that you think differently about how to build network segregation into your projects. There are no distinct physical networks, no VLANs, and no DMZs. So how can you construct the equivalent of traditional three-tier architectures?

Our security whitepaper alludes to the possibility (pp. 5-6, November 2009 edition). In my security presentations I show this diagram to illustrate conceptually how a three-tier architecture can be built:

Security groups: a quick review

Before we explore how to define the architecture, let’s take a moment to review some critical details about how security groups work.

A security group is a semi-stateful firewall (more on this in a moment) that contains one or more rules defining which traffic is permitted into an instance. Rules contain the following elements:

• The permitted protocol (TCP or UDP)
• The permitted destination port range (more on this in a moment, too)
• The permitted source IP address range or originating security group

Now there are three particular aspects I’d like to call your attention to. First: security groups are semi-stateful because changes made to their rules don’t apply to any in-progress connections. Say that you currently have a rule permitting inbound traffic to port 3579/tcp, and that there are right now five inbound connections to this port. If you delete the rule from the group, the group blocks any new inbound requests to port 3579/tcp but doesn’t terminate the existing five connections. This behavior is intentional; I want to ensure everyone understands this. In all other respects, security groups behave like traditional stateful firewalls.

The second aspect is our terminology for port ranges. This often confuses people new to AWS. The traditional usage of the words “from” and “to” in security-speak describes traffic direction: “from” indicates the source and “to” indicates the destination. This isn’t the case when defining rules for security groups. Instead, security group rules concern themselves only with destination ports; that is, the ports on your instances listening for incoming connections. The “from port” and “to port” in a security group rule indicate the starting and ending port numbers for occasions when you need to define a range of listening ports. In most cases you need to allow only a single port, so the values for “from port” and “to port” will be the same.

This leads to the third aspect I’d like to discuss: how to define traffic sources. The most common method is to specify a protocol along with an individual source IP address, a range of IP addresses using CIDR notation, or the entire Internet (using 0.0.0.0/0). The other way to define a traffic source is to supply the name of some other security group you’ve already created. Here’s the magic jewel for creating three-tier architectures; it’s this capability that answered the person’s question on the webcast.

Defining the security groups for a three-tier architecture

If you’re an API aficionado, you can use these eight simple calls to create the three required security groups to implement this architecture:

ec2-authorize WebSG -P tcp -p 80 -s 0.0.0.0/0
ec2-authorize WebSG -P tcp -p 443 -s 0.0.0.0/0
ec2-authorize WebSG -P tcp -p 22|3389 -s CorpNet

ec2-authorize AppSG -P tcp|udp -p AppPort|AppPort-Range -o WebSG
ec2-authorize AppSG -P tcp -p 22|3389 -s CorpNet

ec2-authorize DBSG -P tcp|udp -p DBPort|DBPort-Range -o AppSG
ec2-authorize DBSG -P tcp -p 22|3389 -s CorpNet
ec2-authorize DBSG -P tcp -p 22|3389 -s VendorNet

Note here the interesting distinction in the parameters used with the commands. If the rule permits a source IP address or range, the parameter is “-s” which indicates source. If the rule permits some other security group, the parameter is “-o” which indicates origin. Neat, huh?

The color coding in the rule list helps you visualize how the rules relate to each other:

• The first three statements define WebSG, the security group for the web tier. The first two rules in the group permit inbound traffic to destination ports 80/tcp and 443/tcp from any node on the Internet. The third rule in the group permits inbound traffic to management ports (22/tcp for SSH, 3389/tcp for RDP) from the IP address range of your internal corporate network — this is optional, but probably a good idea if you ever need to administer your instances :)

• The second two statements define AppSG, the security group for the application tier. The second rule in the group permits inbound traffic to management ports from your corpnet. The first rule in the group permits inbound traffic from WebSG — the origin — to the application’s listening port(s).

• The final three statements define DBSG, the security group for the database tier. The second and third rules in the group permit inbound traffic to management ports from your corpnet and from your database vendors network (required for certain third-party database products). The first rule in the group permits inbound traffic from AppSG — the origin — to the database’s listening port(s).

Of course, not everyone’s a programmer (your humble author included), so here are some screen shots showing how to define these security groups using the AWS Management Console. Please be aware that using the Console produces different results, which I’ll describe in a moment.

WebSG permitting HTTP from the Internet, HTTPS from the Internet, and RDP from our sample corpnet address range:

AppSG permitting connections from instances in WebSG and RDP from our sample corpnet address range:

DBSG permitting connections from instances in AppSG and RDP from our sample corpnet and vendor address ranges:

Important. The AWS APIs and the Management Console behave differently when defining security groups as origins:

• Management console: When you define a rule using the name of a security group in the “Source (IP or group)” column, you can’t define specific protocols or ports. The console automatically expands your single rule into the three you see: one for all ICMP, one for all TCP, and one for all UDP. If you remove one of them, the console will remove the other two. If you wish to further limit inbound traffic on those instances, feel free to use a software firewall such as iptables or the Windows Firewall.

• SOAP and Query APIs: With the APIs, rules containing security group origins can include protocol and port specifications. The result is only the rules you define, not the three broad automatic rules like the console creates. This provides you with greater control and reduces potential exposure, so I’d recommend using the APIs rather than the Console. As of now, while the Console correctly displays whatever rules you define with the APIs, please don’t modify API-created rules because the Console’s behavior will override your changes. We’re working to make the Console support the same functionality as the APIs.

More information

The latest API documentation provides details and examples of how to configure rules in security groups. To learn more, please see:

• Network security concepts (from the Amazon EC2 User Guide)
• Using security groups (from the Amazon EC2 User Guide)
• SOAP and Query API examples (from the Amazon EC2 Developer Guide)
• SOAP API syntax (from the Amazon EC2 API Reference)
• Query API syntax (from the Amazon EC2 API Reference)

I hope this short tutorial has been useful for you and provides information you can use as you plan migrations to or new implementations in AWS. Over time, I’d like to write more short security and privacy related guides which I’ll post here and in our Security Center. If you have comments or suggestions about content you’d like to see, please let us know. We’re here to make sure you succeed!

>Steve <

Modified 1/25/2021 – In an effort to ensure a great experience, expired links in this post have been updated or removed from the original post.