This article consists of notes and excerpts I considered relevant from the AWS Cloud for Technical Professionals which consists of AWS training on how to build cloud-native solutions on the AWS platform covering security, access, computation, networking, storage, databases, monitoring and optimization. Thank you Alana Layton for leading this cool project.
Choose the Right AWS Region
. Latency. If your application is sensitive to latency, choose a Region that is close to your user base. This helps prevent long wait times for your customers. Synchronous applications such as gaming, telephony, WebSockets, and IoT are significantly affected by higher latency, but even asynchronous workloads, such as ecommerce applications, can suffer from an impact on user connectivity.
. Price. Due to the local economy and the physical nature of operating data centers, prices may vary from one Region to another. The pricing in a Region can be impacted by internet connectivity, prices of imported pieces of equipment, customs, real estate, and more. Instead of charging a flat rate worldwide, AWS charges based on the financial factors specific to the location.
. Service availability. Some services may not be available in some Regions. The AWS documentation provides a table containing the Regions and the available services within each one.
. Data compliance. Enterprise companies often need to comply with regulations that require customer data to be stored in a specific geographic territory. If applicable, you should choose a Region that meets your compliance requirements.
Navigate the AWS Management Interfaces
Regardless of whether you are using the AWS Management Console or the AWS CLI, you are making API calls to interact with AWS services.
AWS Shared Responsibility Model
AWS classifies services into three different categories.
. Infrastructure services: Compute services, such as Amazon Elastic Compute Cloud (Amazon EC2). AWS manages the infrastructure and foundation services. You control the operating system and application platform, as well as encrypting, protecting, and managing customer data.
. Container services: Services that require less management from the customer, such as Amazon Relational Database Service (Amazon RDS). AWS manages the infrastructure and foundation services, operating system, and application platform. You are responsible for customer data, encrypting that data, and protecting it through network firewalls and backups.
. Abstracted services: Services that require very little management from the customer, such as Amazon Simple Storage Service (Amazon S3). AWS operates the infrastructure layer, operating system, and platforms, as well as server-side encryption and data protection. You are responsible for managing customer data and protecting it through client-side encryption.
Authentication and Authorization
. Authorization – permissions
. Authentication – login
Use Multi Factor Authentication (MFA) on AWS
AWS supports the following mechanisms
. Virtual MFA – A software app that runs on a phone or other device that provides a one-time passcode. Keep in mind that these applications can run on unsecured mobile devices, and because of that, may not provide the same level of security as hardware or U2F devices. Authy, Duo Mobile, LastPass Authenticator, Microsoft Authenticator, Google Authenticator
. Hardware – A hardware device, generally a key fob or display card device that generates a one-time six-digit numeric code. Key fob, display card
. U2F – A hardware device that you plug into a USB port on your computer. YubiKey.
AWS Identity and Access Management
– If I shouldn’t use my AWS root user to build and manage my AWS resources for my application, what identity should I use instead?
– If I have other users, such as developers, security experts, and additional admins, who will be helping me build my application, how can I give them access to my account without sharing credentials?
IAM governs all authentication and authorization processes across an entire AWS account. You can use IAM to solve both of these problems, but you still need specific details on how. In the next unit, you learn how you can solve these issues with IAM users and groups.
. An IAM user represents a person or service that interacts with AWS.
. An IAM group is a collection of users. All users in the group inherit the permissions assigned to the group.
. Instead of the AWS root user, use an IAM user inside an IAM group with admin permissions (meaning they have permission to do everything in your account).
. When you want to add additional users into your account to work on your application, you can create new users and add them into the group that corresponds with their job function.
IAM roles provide temporary credentials to your applications, IAM users, and AWS services. They enable you to maintain least privilege with access control and ease the burden of key rotation.
For instances, in the IAM group of developers, if John is the only one having to deal with Security, then he’ll be linked with a security role.
IAM policies allow you to manage permissions and authorize IAM users, roles, and groups. Keep in mind that the AWS root user is different and cannot be authorized or restricted by IAM policies.
. Lock Down the AWS Root User
. Follow the Principle of Least Privilege (grant only the necessary permissions to do a particular job and nothing more)
. Security is top priority. You must make sure you’re treating it that way as you build your application. Make sure you’re following best practices and choosing the correct identity solution for your needs.
. When managing identities, you have two native identity solutions: IAM and AWS SSO. Though IAM is easier to get started with, navigating IAM identities in multiple AWS accounts can be tricky. On the other hand, AWS SSO enables you to easily administer access across multiple accounts from a central location and serves as a hub for identities, including identities that are replicated from other IdPs.
. If you have only one user in your AWS account and that user is you, getting visibility into what’s happening inside your AWS account is easy.
However, it gets more complicated when you add other users, especially when those users are AWS services, applications, and people authenticating themselves through a role from another AWS account or identity provider.
CloudTrail is an AWS service that tracks all actions taken by a user, role, or AWS service in your AWS account. It records them in an ongoing record of activity. When any API call is made in your AWS account, you can use CloudTrail to view, search, download, and analyze that activity. For example, if your database is deleted within your AWS account, you can view that activity and see information such as who deleted the database, when they deleted it, which database they deleted, and more. When you create an AWS account, CloudTrail is already enabled and begins to track activity within your AWS account, enabling you to govern and audit who is doing what.
AWS Compute
The first building block you need is a place to host and store your website, so that others can access it. Often that place is a Hypertext Transfer Protocol (HTTP) server. It’s a computer, or collection of computers, connected to the internet serving websites to internet users. These servers power your application by providing CPU, memory, and networking capacity to process users’ requests and transform them into responses. Common HTTP servers include:
. Windows options, such as Internet Information Services (IIS).
. Linux options, such as Apache HTTP Web Server, Nginx, and Apache Tomcat.
If you’re responsible for setting up servers on AWS to run your infrastructure, you have many compute options. You need to know which service to use for which use case. At a fundamental level, there are three types of compute options:
. virtual machines (EC2)
. container services
. serverless
EC2
In order to create an EC2 instance, you need to define:
. Hardware specifications, like CPU, memory, network, and storage.
. Logical configurations, like networking location, firewall rules, authentication, and the operating system of your choice.
By default, your EC2 instances are placed in a network called the default Amazon Virtual Private Cloud (VPC).
Architect for High Availability
While EC2 instances are typically reliable, two is better than one, and three is better than two. Specifying the instance size gives you an advantage when designing your architecture because you can use more smaller instances instead of a few larger ones.
If your frontend only has a single instance and that instance fails, your application goes down. On the other hand, if your workload is distributed across 10 instances and one fails, you lose only 10 percent of your fleet and your application availability is hardly affected.
Pricing
One of the ways to reduce costs with Amazon EC2 is to choose the right pricing option for the way your applications run. There are three main purchasing options for EC2 instances:
. on-demand – Billing begins whenever the instance is running, and billing stops when the instance is in a stopped or terminated state
. reserved – You can choose between three payment options: All Upfront, Partial Upfront, or No Upfront. You can select either a 1-year or 3-year term for each of these options. Depending on which option you choose, you are discounted differently. All Upfront offers a higher discount than Partial Upfront instances. Partial Upfront instances offer a higher discount than No Upfront. No Upfront offers a higher discount than On-Demand. On-Demand and No Upfront are similar since both do not require any upfront payment. However, there is a major difference. When you choose an On-Demand instance, you stop paying for the instance when you stop or terminate the instance. When you stop an RI, you still pay for it because you committed to a 1-year or 3-year term.
. spot instances – you set a limit on how much you would like to pay for the instance hour. This is compared against the current Spot price that AWS determines. If the amount you pay is more than the current Spot price and there is capacity, then you will receive an instance. While they are very promising from the billing perspective, there are some architectural considerations you will need to consider in order to use them effectively.
Containers
Containers share the same operating system and kernel as the host they exist on, whereas virtual machines contain their operating system. Since each virtual machine has to maintain a copy of an operating system, there’s a degree of wasted space.
A container is more lightweight. They spin up quicker, almost instantly. This difference in startup time becomes instrumental when designing applications that need to scale quickly during input/output (I/O) bursts.
While containers can provide speed, virtual machines offer you the full strength of an operating system and offer more resources, like package installation, a dedicated kernel, and more.
If you’re trying to manage your compute at a large scale, you need to know:
. How to place your containers on your instances.
. What happens if your container fails.
. What happens if your instance fails.
. How to monitor deployments of your containers.
This coordination is handled by a container orchestration service. AWS offers two container orchestration services:
. Amazon Elastic Container Service (ECS) – Amazon ECS is an end-to-end container orchestration service that allows you to quickly spin up new containers and manage them across a cluster of EC2 instances.
. Amazon Elastic Kubernetes Service (EKS) – Amazon EKS is conceptually similar to Amazon ECS, but there are some differences. An EC2 instance with the ECS Agent installed and configured is called a container instance. In Amazon EKS, it is called a worker node. An ECS Container is called a task. In the Amazon EKS ecosystem, it is called a pod. While Amazon ECS runs on AWS native technology, Amazon EKS runs on top of Kubernetes.
Serverless
If you run your application on Amazon EC2, AWS is responsible for the physical hardware and you are responsible for the logical controls, such as guest operating system, security and patching, networking, security, and scaling.
If you run your application in containers on Amazon ECS and Amazon EKS, AWS is responsible for more of the container management, such as deploying containers across EC2 instances and managing the container cluster. However, when running ECS and EKS on EC2, you are still responsible for maintaining the underlying EC2 instances.
If you want to deploy your workloads and applications without having to manage any EC2 instances, you can do that on AWS with serverless compute.
Every definition of serverless mentions four aspects.
. No servers to provision or manage.
. Scales with usage.
. You never pay for idle resources.
. Availability and fault tolerance are built-in.
AWS has several serverless compute options, including AWS Fargate and AWS Lambda.
AWS Fargate is a purpose-built serverless compute engine for containers. Fargate scales and manages the infrastructure, allowing developers to work on what they do best: application development.
AWS Lambda lets you run code without provisioning or managing servers or containers. You can run code for virtually any type of application or backend service, including data processing, real-time stream processing, machine learning, WebSockets, IoT backends, mobile backends, and web apps!
There are three primary components of a Lambda function: the trigger, code, and configuration.
To summarize:
. If you want to use Amazon EC2, you will have full control over the operating system of your choice. However, this is a less convenient platform when compared to serverless options. This is because there’s still an operating system to maintain, which involves managing software patching, updates, OS patching and configuration, networking, scaling, and more.
. If your application is designed to run in a container, use Amazon EKS, Amazon ECS, or AWS Fargate. These services are designed to remove the burden of maintaining and managing containers on AWS.
. If your application requires little control over the operating system and you want to inherit scaling and resilience out of the box, use AWS Lambda.
Networking
In order to properly route your messages to a location, you need an address. Just like each home has a mail address, each computer has an IP address. However, instead of using the combination of street, city, state, zip code, and country, the IP address uses a combination of bits, 0s and 1s.
Typically, you don’t see an IP address in this binary format. Instead, it’s converted into decimal format and noted as an Ipv4 address. The higher the number after the /, the smaller the number of IP addresses in your network. For example, a range of 192.168.1.0/24 is smaller than 192.168.1.0/16.
When working with networks in the AWS Cloud, you choose your network size by using CIDR notation. In AWS, the smallest CIDR range you can have is /28, which provides you 16 IP addresses. The largest CIDR range you can have is a /16, which provides you with 65,536 IP addresses.
If you want to build your own secure network for your application in AWS, you use Amazon Virtual Private Cloud (Amazon VPC). A VPC is an isolated network you create in the AWS cloud, similar to a traditional network in a data center. When you create a VPC, you need to choose three main things.
1. The name of your VPC.
2 A Region for your VPC to live in. Each VPC spans multiple Availability Zones within the Region you choose.
3. A CIDR range for your VPC. This determines the size of your network. Each VPC can have up to four /16 CIDR ranges.
After you create your VPC, you need to create subnets inside of this network. Think of subnets as smaller networks inside your base network—or virtual area networks (VLANs) in a traditional, on-premises network. In an on-premises network, the typical use case for subnets is to isolate or optimize network traffic. In AWS, subnets are used for high availability and providing different connectivity options for your resources.
When you create a subnet, you need to choose three settings.
1. The VPC you want your subnet to live in, in this case VPC (10.0.0.0/16).
2 The Availability Zone you want your subnet to live in, in this case AZ1.
3 A CIDR block for your subnet, which must be a subset of the VPC CIDR block, in this case 10.0.0.0/24.
When you launch an EC2 instance, you launch it inside a subnet, which will be located inside the Availability Zone you choose. When you create your subnets, keep high availability in mind. In order to maintain redundancy and fault tolerance, create at least two subnets configured in two different Availability Zones.
As you learned earlier in the trail, it’s important to consider that “everything fails all the time.” In this case, if one of these AZs fail, you still have your resources in another AZ available as backup.
When you place a resource, such as an EC2 instance, inside a subnet in your new VPC, it can be protected from being exposed to the internet by default.
Wrap up:
. The default route table that is created when you create your VPC that allows for local traffic.
. A public route table that allows for connectivity from your resources to the internet, and vice versa using an internet gateway.
. A private route table only allows for connectivity from your resources to the internet, but does not allow the internet to connect to your resources, using a NAT gateway.
Think of a network ACL as a firewall at the subnet level. A network ACL enables you to control what kind of traffic is allowed to enter or leave your subnet. You can configure this by setting up rules that define what you want to filter.
There are many examples of network designs you can build in AWS. These are just some of the fundamentals you need to know to confidently build and design an Amazon VPC. You can use network ACLs and security groups as powerful tools to filter network-wide traffic for a single instance or subnet’s traffic.
Storage
Amazon EBS is a block-level storage device that you can attach to an Amazon EC2 instance. These storage devices are called Amazon EBS volumes. EBS volumes are essentially drives of a user-configured size attached to an EC2 instance, similar to how you might attach an external drive to your laptop.
Amazon EBS is useful when you need to retrieve data quickly and have data persist long-term. Volumes are commonly used in the following scenarios.
. Operating systems: Boot/root volumes to store an operating system. The root device for an instance launched from an Amazon Machine Image (AMI) is typically an Amazon EBS volume. These are commonly referred to as EBS-backed AMIs, as mentioned in AWS Compute.
. Databases: A storage layer for databases running on Amazon EC2 that rely on transactional reads and writes.
. Enterprise applications: Amazon EBS provides reliable block storage to run business-critical applications.
. Throughput-intensive applications: Applications that perform long, continuous reads and writes.
Errors happen. One of those errors is not backing up data, and then, inevitably losing that data. To prevent this from happening to you, you should back up your data—even in AWS. Since your EBS volumes consist of the data from your Amazon EC2 instance, you’ll want to take backups of these volumes, called snapshots.
Unlike Amazon EBS, Amazon S3 is a standalone storage solution that isn’t tied to compute. It enables you to retrieve your data from anywhere on the web. If you’ve ever used an online storage service to back up the data from your local machine, then you most likely have used a service similar to Amazon S3.
Amazon S3 is an object storage service. As mentioned in the first unit, object storage stores data in a flat structure, using unique identifiers to look up objects when requested. In that unit, you also learned that an object is simply a file combined with metadata and that you can store as many of these objects as you’d like. All of these characteristics of object storage are also characteristics of Amazon S3.
The most common ways you can use Amazon S3:
. Backup and storage: S3 is a natural place to back up files because it is highly redundant. As mentioned in the last unit, AWS stores your EBS snapshots in S3 to take advantage of its high availability.
. Media hosting: Because you can store unlimited objects, and each individual object can be up to 5 TBs, S3 is an ideal location to host video, photo, or music uploads.
. Software delivery: You can use S3 to host your software applications that customers can download.
. Data lakes: S3 is an optimal foundation for a data lake because of its virtually unlimited scalability. You can increase storage from gigabytes to petabytes of content, paying only for what you use.
. Static websites: You can configure your bucket to host a static website of HTML, CSS, and client-side scripts.
Everything in Amazon S3 is private by default. This means that all S3 resources, such as buckets, folders, and objects can only be viewed by the user or AWS account that created that resource. Amazon S3 resources are all private and protected to begin with.
Databases
There are many benefits to using a relational database. A few of them are listed here.
. Joins: You can join tables, enabling you to better understand relationships between your data.
. Reduced redundancy: You can store data in one table and reference it from other tables instead of saving the same data in different places.
. Familiarity: Relational databases have been a popular choice since the 1970s. Due to this popularity, technical professionals often have familiarity and experience with this type of database.
. Accuracy: Relational databases ensure that your data is persisted with high integrity and adheres to the ACID (atomicity, consistency, isolation, durability) principle.
Much of the world runs on relational databases. In fact, they’re at the core of many mission-critical applications, some of which you may use in your day to day life. Here are some common use cases for relational databases.
+ Applications that have a solid schema that doesn’t change often, such as:
.. Lift and shift applications that lifts an app from on-premises and shifts it to the cloud, with little or no modifications.
+ Applications that need persistent storage that follows the ACID principle, such as:
.. Enterprise Resource Planning (ERP) applications
.. Customer Relationship Management (CRM) applications
.. Commerce and financial applications
Modern data requirements can be challenging. Scaling for millions of users, maintaining accessibility across the globe, and ensuring a millisecond response time for a strong customer experience are just a few of the things you have to consider. You have more choices of databases that go beyond relational, such as key-pair, graph, document, and ledger databases.
Monitoring
Monitoring gives you visibility into your resources, but the question now is, “Why is that important?” The following are some of the benefits of monitoring.
. Respond to operational issues proactively before your end users are aware of them. It’s a bad practice to wait for end users to let you know your application is experiencing an outage. Through monitoring, you can keep tabs on metrics like error response rate or request latency, over time, that help signal that an outage is going to occur. This enables you to automatically or manually perform actions to prevent the outage from happening—fixing the problem before your end users are aware of it.
. Improve the performance and reliability of your resources. Monitoring the different resources that comprise your application provides you with a full picture of how your solution behaves as a system. Monitoring, if done well, can illuminate bottlenecks and inefficient architectures. This enables you to drive performance and reliability improvement processes.
. Recognize security threats and events. When you monitor resources, events, and systems over time, you create what is called a baseline. A baseline defines what activity is normal. Using a baseline, you can spot anomalies like unusual traffic spikes or unusual IP addresses accessing your resources. When an anomaly occurs, an alert can be sent out or an action can be taken to investigate the event.
. Make data-driven decisions for your business. Monitoring is not only to keep an eye on IT operational health. It also helps drive business decisions. For example, let’s say you launched a new feature for your cat photo app, and want to know whether it’s being used. You can collect application-level metrics and view the number of users who use the new feature. With your findings, you decide whether to invest more time into improving the new feature.
. Create more cost-effective solutions. Through monitoring, you can view resources that are being underutilized and rightsize your resources to your usage. This helps you optimize cost and make sure you aren’t spending more money than necessary.
Amazon CloudWatch is a service that allows you to monitor and collect data from your AWS and IT resources in one centralized location, making it easy for you to have visibility into your solutions. Think of Amazon CloudWatch as a central repository for metrics. When data points, or metrics, are monitored over a specific amount of time, they become statistics, and you can use these statistics to analyze and manage your AWS resources.
Optimization
In Monitoring on AWS, you answered the following questions with Amazon CloudWatch using metrics and dashboards.
. How will I know if the application is having performance or availability issues?
. What happens if my Amazon Elastic Compute Cloud (EC2) instance runs out of capacity?
. Will I be alerted if my application goes down?
There’s one more question you need to answer: What should you do to prevent these availability, capacity, and reachability issues?
There are different solutions to these problems.
Here are some primary features of Application Load Balancer (ALB).
. ALB routes traffic based on request data. It makes routing decisions based on the HTTP protocol like the URL path (/upload) and host, HTTP headers and method, as well as the source IP address of the client. This enables granular routing to the target groups.
. Send responses directly to the client. ALB has the ability to reply directly to the client with a fixed response like a custom HTML page. It also has the ability to send a redirect to the client which is useful when you need to redirect to a specific website or to redirect the request from HTTP to HTTPS, removing that work from your backend servers.
. ALB supports TLS offloading. Speaking of HTTPS and saving work from backend servers, ALB understands HTTPS traffic. To be able to pass HTTPS traffic through ALB, an SSL certificate is provided by either importing a certificate via Identity and Access Management (IAM) or AWS Certificate Manager (ACM) services, or by creating one for free using ACM. This ensures the traffic between the client and ALB is encrypted.
. Authenticate users. On the topic of security, ALB has the ability to authenticate the users before they are allowed to pass through the load balancer. ALB uses the OpenID Connect protocol and integrates with other AWS services to support more protocols like SAML, LDAP, Microsoft AD, and more.
. Secure traffic. To prevent traffic from reaching the load balancer, you configure a security group to specify the supported IP address ranges.
. ALB uses the round-robin routing algorithm. ALB ensures each server receives the same number of requests in general. This type of routing works for most applications.
. ALB uses the least outstanding request routing algorithm. If the requests to the backend vary in complexity where one request may need a lot more CPU time than another, then the least outstanding request algorithm is more appropriate. It’s also the right routing algorithm to use if the targets vary in processing capabilities. An outstanding request is when a request is sent to the backend server and a response hasn’t been received yet.
For example, if the EC2 instances in a target group aren’t the same size, one server’s CPU utilization will be higher than the other if the same number of requests are sent to each server using the round-robin routing algorithm. That same server will have more outstanding requests as well. Using the least outstanding request routing algorithm would ensure an equal usage across targets.
. ALB has sticky sessions. In the case where requests need to be sent to the same backend server because the application is stateful, then use the sticky session feature. This feature uses an HTTP cookie to remember across connections which server to send the traffic to.
Finally, ALB is specifically for HTTP and HTTPS traffic. If your application uses a different protocol, then consider the Network Load Balancer (NLB). Here are some primary features of Network Load Balancer (NLB).
. Network Load Balancer supports TCP, UDP, and TLS protocols. HTTPS uses TCP and TLS as protocol. However, NLB operates at the connection layer, so it doesn’t understand what a HTTPS request is. That means all features discussed above that are required to understand the HTTP and HTTPS protocol, like routing rules based on that protocol, authentication, and least outstanding request routing algorithm, are not available with NLB.
. NLB uses a flow hash routing algorithm. The algorithm is based on:
..The protocol
..The source IP address and source port
..The destination IP address and destination port
..The TCP sequence number
If all of these parameters are the same, then the packets are sent to the exact same target. If any of them are different in the next packets, then the request may be sent to a different target.
. NLB has sticky sessions. Different from ALB, these sessions are based on the source IP address of the client instead of a cookie.
. NLB supports TLS offloading. NLB understands the TLS protocol. It can also offload TLS from the backend servers similar to how ALB works.
. NLB handles millions of requests per second. While ALB can also support this number of requests, it needs to scale to reach that number. This takes time. NLB can instantly handle this amount of requests.
. NLB supports static and elastic IP addresses. There are some situations where the application client needs to send requests directly to the load balancer IP address instead of using DNS. For example, this is useful if your application can’t use DNS or if the connecting clients require firewall rules based on IP addresses. In this case, NLB is the right type of load balancer to use.
. NLP preserves source IP address. NLB preserves the source IP address of the client when sending the traffic to the backend. With ALB, if you look at the source IP address of the requests, you will find the IP address of the load balancer. While with NLB, you would see the real IP address of the client, which is required by the backend application in some cases.