Three-Tier Architecture

       The Challenge

      An application runs an order management system for a global company. The application will manage inventory, customer records, and orders in an integrated system.

      Some of the system requirements include flexibility to adjust to changing needs. It must be scalable to handle variable customer loads. It must have separate front-end and processing layers to allow User Interface (UI) development to be isolated from business logic programming.

      It must be cost effective. In addition to scalable web and application instances, it should leverage native, cost-effective services such as elastic load balancing and Amazon S3.

      The environment must be secure. Steps should be taken to ensure that all traffic is properly protected in transit and at rest. All access must be controlled and monitored at all times. All critical data must be stored in durable, highly-available systems, protected against node failure.

       The Solution

      

      As we examine the pieces of the solution, we start by breaking down the components of the architecture. Then we focus on how systems operators interact with the individual pieces and begin thinking about how those pieces fit into the certification exam.

      Architectures live inside AWS Regions; in this scenario, in us-west-2 (Oregon, United States). Regions are made up of multiple Availability Zones, which provide the foundation for highly available architectures. Although this is a systems operation exam, it is critical to understand the nature of AWS Regions and Availability Zones.

      Networking components start inside the AWS Region with Amazon Virtual Private Cloud (Amazon VPC). Amazon VPC is a private network in the AWS Region that isolates all traffic from the millions of other applications running in AWS. A deep dive into Amazon VPC (and the rest of its components) is found in Chapter 5.

      Amazon VPC is divided into subnets; all assets running in your Amazon VPC are assigned to a subnet. Unlike on-premises subnetting decisions that can affect latency between servers, Amazon VPC subnets only affect access. Access between subnets is controlled through network Access Control Lists (nACLs), and access in and out of Amazon VPC is controlled through attached gateways. In this scenario, the only gateway is the Internet Gateway (IGW), and it allows traffic to and from external (public IP) sources.

      By granting route table access to the gateway only to specific subnets, ingress and egress can be tightly controlled. In this scenario, public subnets indicate IGW access. Without IGW access, the subnets become private; that is, they are accessible only to private IP networks.

      Security groups are often part of the networking discussion. They provide stateful firewalls that operate at the hypervisor levels for all individualAmazon Elastic Compute Cloud (Amazon EC2) instances and other Amazon VPC objects. In this scenario, we potentially have seven different security groups:

      Public Elastic Load Balancing The only security group that allows full public access

      Web Tier Amazon EC2 This accepts traffic only from public Elastic Load Balancing.

      Private Elastic Load Balancing This accepts traffic only from Web Tier Amazon EC2.

      Application Tier Amazon EC2 This accepts traffic only from private Elastic Load Balancing.

      Amazon ElastiCache This accepts traffic only from Application Tier Amazon EC2.

      Amazon Relational Database Service (Amazon RDS) This accepts traffic only from Application Tier Amazon EC2.

      Network Address Translation (NAT) This is used only for internally initiated outbound traffic.

      By specifically stacking security groups in this manner, you can provide layers of network security that surround the database portion of the three-tier design.

      In this scenario, you use traditional compute methods, such as Linux servers running on Amazon EC2. Amazon EC2 comes in many sizes (how many CPUs, how much memory, how much network capacity, and so on), known as instances. Based on the Amazon Machine Image (AMI), each Amazon EC2 instance can run a wide range of Linux- or Windows-based operating systems as well as preinstalled software packages. Amazon EC2 instances also support runtime configuration as required.

      The requirements for the scenario include scalable solutions. AWS provides Auto Scaling as an engine that can take predefined launch configurations and dynamically add or remove instances from the web or the Application Tier based on metrics.

      Amazon RDS runs in your Amazon VPC on Amazon EC2. You select the database engine and version (MySQL, Oracle, Postgres, and so forth) and the configuration (the size of the Amazon EC2 instance, which subnets to use, how often to take backups, and so on). Amazon RDS takes care of the infrastructure of the instances and the engine; your database administrator (DBA) takes care of the database schema and data.

      This scenario also includes Amazon DynamoDB, a native NoSQL engine optimized for consistent low latency, high availability, and strongly consistent reads and writes. Unlike Amazon RDS (or do-it-yourself databases running on Amazon EC2), Amazon DynamoDB operates at the regional level through API access only.

      This scenario looks at storage in three different areas: the block storage used by the Amazon EC2 instances, the object storage keeping all of the media as well as backups and AMIs, and the caching storage used by Amazon CloudFront.

      Amazon EBS is durable, persistent block storage used by most Amazon EC2 and Amazon RDS instances. It provides drive space for boot volumes and data volumes. Additionally, AWS provides ephemeral storage for many Amazon EC2 instance types through instance