grants access to authenticated operators.
Because everything in AWS is accessed through APIs, IAM becomes a comprehensive tool for controlling all permissions to AWS services and resources.
For established enterprise customers, IAM can be integrated with existing directory systems via AWS Directory Service.
Security is integral to every part of the AWS platform. This means that security is part of each piece of the architecture.
Monitoring of critical systems is provided by Amazon CloudWatch, which provides visibility into metrics that happen on the Customer side of the shared responsibility model. Thousands of metrics across more than 90 services keep track of everything from CPU consumption to latency, queue depths, and so on.
AWS CloudTrail records every API call in the AWS system, including:
■ Who made the API call
■ When the API call was performed
■ Where the API call originated
■ The result of the API call
These records and other log files are processed through Amazon CloudWatch Logs, which analyze text data for patterns that trigger alerts and corresponding actions.
Automated deployment methods ensure that human error does not disrupt rollouts or updates to production or sandbox environments. AWS CloudFormation turns infrastructure plans into code, allowing your operations team to build and tear down entire systems in a single action. Refer to Chapter 8, “Application Deployment and Management,” for more details.
As described above, the three-tier architecture consists of a web front end, an application layer, and database layer. In addition to the compute, storage, and database resources, additional AWS infrastructure may need to be deployed. Refer to Table 1.1 for a list of key products.
TABLE 1.1 Key products: three-tier architecture
It may seem like a daunting list, but this represents the core services (the toolset) that all AWS systems operators need to understand fully. As with any craft, it is important to use the right tool for the right job. You could use a torque wrench to smooth wet concrete, but of course there are much more appropriate tools for that task. Knowing the wide variety of AWS tools available to you is just as important.
As application design continues to evolve, individual instances are replaced with container services. Container services eventually are replaced by the final abstraction: serverless architectures.
There are many variations of serverless architectures. Rather than assume a generic use case, let’s look at a specific scenario that might be used by your operations team.
Serverless Architectures
The Challenge
In this scenario, we want to find a better way to track the number of outstanding security updates on our production fleet. A serverless solution would be ideal, because we would not be adding any servers to maintain and we would only be paying for the compute time of the AWS Lambda functions.
The Solution
Python code executing in AWS Lambda on a regular schedule will use the Secure Shell (SSH) protocol to query for outstanding security updates on production instances. Python code (running anywhere) can use the AWS Boto Software Development Kit (SDK) to query Amazon EC2 for a list of specially tagged instances. The Python code establishes an SSH connection to the instances, and it executes a small script to find the number of required security updates. After you have this information, you can present it to the systems operations team as a tag on the instances, again using the AWS Boto SDK.
The AWS Lambda functions run in their own Amazon VPC. We establish Amazon VPC peering between the two Amazon VPCs to allow network connections between the AWS Lambda function and the production Amazon EC2 instances. This requires the creation of routing tables to direct the traffic between the two Amazon VPCs.
The AWS Lambda function must authenticate at two different levels: when the function queries the Amazon EC2 APIs via the Boto SDK and when the function establishes an SSH connection to the operating system on the production instances. AWS Lambda functions are configured with an IAM role and policy, which grants access to query the Amazon EC2 APIs. SSH authentication uses a Rivest-Shamir-Adleman (RSA) public/private key authentication. The AWS Lambda function has the private portion on the key. The Linux operating system on the production instances is configured with the public portion of the key. The operating system uses the public key to authenticate the SSH connection being initiated from the AWS Lambda function (see Figure 1.1).
FIGURE 1.1 Lambda function interacting with the Amazon EC2 API and EC2 instances
Let’s take an extra step to secure the private portion of the SSH key. This key is used by the AWS Lambda function to prove that it is allowed to SSH into the production instances and execute a script – so it is very important to keep secrets secret! The secret key is encrypted using the AWS Key Management Service (AWS KMS) and stored in Amazon S3. For the AWS Lambda function to retrieve the key from Amazon S3 and decrypt with AWS KMS, you must update the IAM policy associated with the AWS Lambda function. More information on cryptography is provided in Chapter 3. (See Figure 1.2.)
FIGURE 1.2 AWS KMS operations with Lambda
Who is allowed to access the encrypted private key in Amazon
