# Broken Code Notebook All things development (and then some) # Architecture and Design "Don't try to find the best design in software architecture; instead, strive for the least worst combination of trade-offs" (Software Architecture: The Hard Parts by Niel Ford et al) # Architectural Decision Records excerpt from "Software Architecture: The Hard Parts" One of the most effective ways of documenting architecture decisions is through Architectural Decision Records (ADRs). {% embed url="" %} An ADR consists of a short text file (usually one or two pages long) describing a specific architecture decision. While ADRs can be writen in plain text, they are usually written in some sort of document format, like Markdown. ADR format: {% hint style="info" %} **ADR**: A short noun phrase containing the architecture decision **Context** In this section of the ADR we will add a short one- or two-sentence description of the problem. **Decision** In this section we will state the architecture decision and provide a detailed justification of the decision. **Consequences** In this section of the ADR we will describe any consequences after the decision is applied, and also discuss the trade-offs that were considered. {% endhint %} # Trade-off Analysis "Software Architecture" is the stuff you can't Google answers for. * Find what parts are entangled together * Analyze how they are coupled with one another * Assess trade-offs by determining the impact of change to independent systems # Data Decomposition Drivers Breaking apart a monolytic database can be a daunting task, and as such it is important to understand if (and when) a database should be decomposed. Architects can justify a data decomposition effort by understanding and analyzing data disintegrators (drivers that justify breaking apart data) and data integrators (drivers that justify keeping the data together). Striving for a balance between these two forces and analysing the trade-offs of each is the key to getting the data granularity right. #### Data Disintegrators Data disintegration drivers provide answers and justifications for the question "when should I consider breaking apart my data?". The main drivers area as follows: {% hint style="info" %} * **Change control**: How many services are impacted by a database change? * **Connection management**: Can my database handle the connection needed from multiple distributed services? * **Scalability**: Can the database scale to meet the demands of the services accessing it? * **Fault tolerance**: How many services are impacted by a database crash or maintenance downtime? * **Architectural quanta**: Is a single shared database forcing me into an undesirable single architecture quantum? * **Database type optimization**: Can I optimize my data by using multiple database types? {% endhint %} #### Data Integrators Data integrators do the opposite of the data disintegrators. These drivers provide answers and justifications for the question: "when should I consider putting data back together". Along with data disintegrators, they provide the balance and trade-offs for analyzing when to break apart data and when not to. The two main integration drivers for putting data back together are the following: {% hint style="info" %} * **Data relationship**: Are there foreign keys, triggers, or views that form a close relationship between the tables? * **Database transactions**: Is a single transactional unit of work necessary to ensure data integrity and consistency? {% endhint %} # Selecting a Database Type **Key points when selecting databases** * Ease-of-learning curve * Ease of data modeling * Scalability/throughput * Availability/partitioning tolerance * Consistency * Programming language support, product maturity, SQL support, and community * Read/write priority (does the database prioritizes reads over writes, or the other way around) **Database types (with examples)** * Relational - PostgreSQL, Oracle, Microsoft SQL * Key-value - Riak KV, Amazon DynamoDB, Redis * Document - MongoDB, Couchbase, Amazon DocumentDB * Columnar - Cassandra, Scylla, Amazon SimpleDB * Graph - Neo4j, Infinite Graph, Tiger Graph * NewSQL - VoltDB, ClustrixDB, SimpleStore (aka MemSQL) * Cloud-native - Snowflake, Datomic, Redshift * Time-series - InfluxDB, kdb+, Amazon Timestream # Service Granularity #### Granularity Disintegrators Granularity disintegrators provide guidance and justification for when to break a service into smaller parts. While the justification for breaking up service may involve only a single driver, in most cases the justification will be based on multiple drivers. {% hint style="info" %} * **Service scope and function**: is the service doing too many unrelated things? * **Code volatility**: Are changes isolated to only one part of the service? * **Scalability and throughput**: Do parts of the service need to scale differently? * **Fault tolerance**: Are there errors that cause critical functions to fail within the service? * **Security**: Do some parts of the service need higher security levels than others? * **Extensibility**: Is the service always expanding to add new contexts? {% endhint %} #### Granularity integrators {% hint style="info" %} * **Database transactions**: Is an ACID transaction required between separate services? * **Workflow and choreography**: Do services need to talk to one another? * **Shared code**: Do services need to share code among one another? * **Database relationship**: Although service can be broken apart, can the data it uses be broken apart as well? {% endhint %} # Consumer-driven Contracts A common problem in microservices architectures is the seemingly contradictory goals of loose coupling yet contract fidelity. One innovative approach that utilizes advances in software architecture and development is a consumer-driven contract. In many architecture integration scenarios, a service decides what information to emit to other integration partners (a push model - the service provider pushes a contract to consumers). The concept of consumer-driven contract inverses that relationship into a pull model; here the consumer puts together a contract for the items they need from the provider, and passes the contract to the provider, who includes it in their build and keeps the contract test green at all times. Advantages: * Allow loose contract coupling between services * Allow variability in strictness * Evolvable Disadvantages: * Require engineering maturity * Two interlocking mechanisms than one # AWS # Resources ## AWS Links * [Whitepapers](https://aws.amazon.com/whitepapers) * [AWS Documentation](https://docs.aws.amazon.com/) * [Github - AWS Samples](https://github.com/aws-samples) * [Policy Generator](https://awspolicygen.s3.amazonaws.com/policygen.html) * ## Certification * [AWS Certification](https://aws.amazon.com/certification/) * [AWS Training and Certification Portal](https://www.aws.training/Certification) * [AWS Training - Learning Library](https://www.aws.training/LearningLibrary) * [Tutorials Dojo](https://tutorialsdojo.com/) * [Jayendra's Blog](https://jayendrapatil.com/) * [Github - A curated list of AWS resources to prepare for the AWS Certifications](https://gist.github.com/leonardofed/bbf6459ad154ad5215d354f3825435dc) * # Compute # EC2 Elastic Compute Cloud ### Pricing Models * On-demand * Reserved * Spot * Dedicated hosts #### On-Demand * Users that want the low cost and flexibility of EC2 without any up-front payment of long-term commitments. * Applications with short term, spiky, or unpredictable workloads that can not be interrupted. * Applications being developed or tested on EC2 for the first time. #### Reserved * Applications with steady state or predictable usage * Applications that require reserved capacity * Users able to make upfront payments to reduce their total computing costs even further * Standard RI (up to 75% off On-Demand) * Convertible RI (up to 54% off On-Demand), capability to change the attributes of the RI as long as the exchange results in the creation of Reserved Instances of equal or greater value. * Scheduled RI's available to launch within the time windows you reserve. This option allows you to match your capacity reservation to a predictable recurring schedule that only requires a fraction of a day, a week or a month. #### Spot * Application that has flexible start and end times. * Application that is only feasible at very low compute prices. * Users with urgent computing needs for large amounts of additional capacity. #### Dedicated Hosts * Useful for regulatory requirements that may not support multi-tenant virtualization. * Greate for licensing which does not support multi-tenancy or cloud deployments. * Can be purchased On-Demand (hourly). * Can be purchased as a Reservation for up to 70% off the On-Demand price. #### Dedicated Instances vs. Dedicated Hosts * Both dedicated instances and dedicated hosts have dedicated hardware. * Dedicated instances are charged by the instance, dedicated hosts are charged by the host. * If you have specific regulatory requirements or licensing conditions, choose dedicated hosts. * Dedicated instances may share the same hardware with other AWS instances from the same account that are not dedicated. * Dedicated hosts give you much better visibility into things like sockets, cores, and host ID. ### Instance types | FAMILY | SPECIALITY | USE CASE | | ---------- | -------------------------------- | ------------------------------------ | | **F1** | FPGA | Genomics, financial, video, big data | | **I3** | High-speed storage | NoSQL DB, data warehousing | | **G3** | Graphics intensive | Video encoding, 3D | | **H1** | High disk throughput | MapReduce, HDFS | | **T3** | Low cost, general | Web servers, small DBs | | **D2** | Dense storage | File server, Hadoop | | **R5** | Memory optimized | Memory-intensive apps | | **M5** | General purpose | App servers | | **C5** | Compute optimized | CPU intensive apps | | **P3** | Graphics, general purpose | ML, cryptocurrency | | **X1** | Memory optimized | SAP HANA, Spark | | **Z1D** | High compute capacity and memory | Analytics, certain databases | | **A1** | ARM-based workloads | Scale-out workloads | | **U-6tb1** | Bare metal | No virtualization overhead | ### Instance metadata * curl * curl ### Launch errors * **InstanceLimitExceeded** error - you have exceeded the default limit for number of instances you can launch in a region * **InsufficientInstanceCapacity** error - AWS does not currently have enough available On-Demand capacity to service your request ### Troubleshooting * Instances not launching into Autoscaling group * associated key pair does not exist * security group does not exist * autoscaling config is not working correctly * autoscaling group not found * instance type specified is not supported in AZ * AZ is no longer supported * invalid EBS device mapping * autoscaling service is not enabled in your account * attempting to attach EBS block device to an instance store AMI ## AMI - Amazon Machine Image ### Converting unencrypted AMI to encrypted AMI * Create snapshot of the unencrypted root device volume. * Create a copy of the snapshot, select the encryption option * Create an AMI from the encrypted snapshot * Use that AMI to launch new encrypted instance #### Sharing AMIs * AMIs can be shared and copied between user accounts * Restrictions * Encrypted AMIs * Copy the underlying snapshot, re-encrypt using your own key and create a new AMI from the snapshot * AMIs with associated `billingProducts` code (e.g. Windows AMIs, RedHat, AWS Marketplace AMIs) * Launch an EC2 instance using the shared AMI and create an AMI from that instance. ## Placement Groups When you launch a new EC2 instance, EC2 service attempts to place an instance in such a way that all of your instances are spread out across underlying hardware to minimize the correlated failures. You can use placement groups to influence the placement of a group of independent instances to meet the needs of your workload. Depending of the type of your workloads, you can create a placement group using one of the following placement strategies: * **Cluster** - packs instances close together inside the AZ. This strategy enables workloads to achieve low-latency network performance for tightly-coupled node-to-node communication that is typical of HPC (high-performance compute) applications. * **Partition** - spreads your instances across logical partitions such that group of instances in one partition do not share the underlying hardware with group of instances in different partitions.This strategy is typically used by large distributed and replicated workloads, such as Hadoop, Cassandra and Kafka. * **Spread** - strictly places a small group of instances across distinct underlying hardware to reduce correlated failure.
* A clustered placement group can't span multiple AZs. A spread and partitioned placement group can. * The name you specify for placement group must be unique within your AWS account. * Only certain types of instances can be launched in a placement group (compute optimized, GPU, memory optimized, storage optimized). * AWS recommends homogeneous instances within the clustered placement group. * You can not merge placement groups. * You can not move an existing instance into a placement group. You can create an AMI from your existing instance, and then launch a new instance from the AMI into a placement group. * A spread placement group supports a maximum of 7 running instances per AZ. ## ENI vs ENA vs EFA * **ENI - Elastic Network Interface** - essentially a virtual network card. * It allows: * A primary private IPv4 address from the IPv4 address range of your VPC. * One or more secondary private IPv4 addresses from the IPv4 address range of your VPC. * One Elastic IP address (IPv4) per private IPv4. * One public IPv4 address. * One or more IPv6 addresses * One or more security groups * A MAC address * A source / destination check flag * A description * Scenarios for ENIs: * Create a managed network * Use network and security appliances in your VPC * Create a dual-homed instances with workloads/roles on distinct subnets * Create a low budget, high-availability solution * **EN - Enhanced Networking**. * Uses single root I/O virtualization (SR-IOV) to provide high-performance networking capabilities on supported instance types. * What is `Enhanced Networking` * It uses single root I/O virtualization (SR-IOV) to provide high-performance networking capabilities on supported instance types. SR-IOV is a method of device virtualization that provides higher I/O performance and lower CPU utilization when compared to traditional virtualized network interfaces. * Enhanced networking provides higher bandwidth, higher packet per second (PPS) performance and consistently lower inter-instance latencies. There is no additional charge for using enhanced networking. * Use where you want good network performance. * Depending on your instance type, enhanced networking can be enabled using: * **Elastic Network Adapter (ENA)**, which supports network speeds of up to **100 Gbps** for supported instance types * Intel 82599 **Virtual Function (VF)** interface, which supports network speeds of up to **10Gbps** for supported instance types. * In most cases you probably what ENA over VF. * **EFA - Elastic Fabric Adapter.** * A network device that you can attach to your Amazon EC2 instance to accelerate High Performance Computing (HPC) and machine learning applications. * EFA provides lower and more consistent latency and higher throughput than the TCP transport traditionally used in cloud-based HPC systems. * EFA can use OS bypass. OS bypass enables HPC and machine learning applications to bypass the operating system kernel and to communicate directly with the EFA device. It makes it a lot faster with a lot lower latency. Not supported with Windows currently, only Linux. # Batch * Enables you to run batch computing workloads on AWS * It's a regional service that simplifies running batch jobs across multiple AZs within a region. ### Features * Batch manages compute environments and job queues, allowing you to easily run thousands of jobs of any scale using EC2 and EC2 Spot. * Batch chooses where to run the jobs, launching additional capacity if needed. * Batch carefully monitors the progress of your jobs. When capacity no longer needed it will be removed. * Batch provides the ability to submit jobs that are part of pipeline or workflow, enabling you to express any interdependency(ies) that exist between them as you submit jobs. ### Components * Jobs * Job definitions * Job queues * Compute environment ### Jobs * A unit of work (such as shell script, a Linux executable or a Docker container image) that you submit to Batch. * Jobs can reference other jobs by name of by ID, and can be dependent on the successful completion of other jobs. * Job types: * single * array (between 2 and 10000) * An array job shares common job parameters, such as job definition, vCPUs, and memory. It runs as a collection of related, yet separate, basic jobs that can be distributed across multiple hosts and may run concurrently. * Multi-node parallel jobs enable you to run single, large-scale, tightly-coupled and distributed GPU model training jobs that span multiple EC2 instances. * Batch lets you specify up to 5 distinct node groups for each job. Each group can have its own container images, commands, environment variables, and so on. * Each multi-node parallel jobs contain a main node, which is launched first. After the main node is up, the child nodes are launched. If the main node exists, the job is considered finished, and the child nodes are stopped. * Not supported on environments that use Spot instances. ### Dependencies * A job may have up to 20 dependencies. * For `job depends on` enter the job ID for any jobs that must finish before this job starts. * (array only) For N-to-N job dependencies, specify one or more job IDs for any array jobs for which each child job index of this job should depend on the corresponding child index job of the dependency. * (array only) Run children sequentially creates a sequential dependency for the current array job. This ensures that each child index job waits for its earlier sibling to finish. ### States * **SUBMITTED** - a job that has been submitted to the queue, and has not been evaluated by the scheduler. * **PENDING** - a job that resides in the queue and is not yet able to run due to a dependency on another job or resource. * **RUNNABLE** - a job that resides in the queue, has no outstanding dependencies, and is therefore ready to be scheduled to a host. Jobs in this state are started as soon as sufficient resources are available in one of the compute environments that are mapped to it's jobs queue. * **RUNNING** - the job is running as a container job on an ECS container instance within a compute environment. When the job's container exists, the process exit code determines whether the job succeeded or failed. An exit code of 0 indicates success, and any non-zero exit code indicates failure. * **SUCCEEDED** - the job has successfully completed with an exit code of 0. The job state for succeeded jobs is persisted for 24 hours. * You can apply a retry strategy to your jobs and job definitions that allow failed jobs to be automatically retried. * You can configure a timeout duration for your jobs so that if a job runs longer than that, Batch terminates the job. If a job terminated for exceeding the timeout, it is not retried. If it fails on its own, then it can retry, if retries are enabled, and the timeout coundown is started over for the new attempt. ### Job definitions * Specifies how jobs are to be run. * The definition can contain: * An IAM role to provide programmatic access to other AWS resources. * Memory and CPU requirements for the job. * Controls for container properties, environment variables, and mount points for persistent storage. ### Job Queues * This is where job resides until it is scheduled onto a compute environment. * You can associate one or more compute environments with a job queue. * You can assign priority values for the compute environments and even across the job queues themselves. * The Batch Scheduler evaluates when, where and how to run jobs that have been submitted to a job queue. Jobs run in approximately the order in which they are submitted as long as all dependencies on other jobs have been met. ### Compute environment * A set of managed or unmanaged (such as EC2 instances) that are used to run the jobs. * Compute environments contain the ECS container instances that are used to run containerized batch jobs. * A given compute environment can be mapped to one or more job queues. #### Managed compute environment * Batch manages the capacity and instance types of the compute resources within the environment, based on the compute resource specification that you define when you create the compute environment. * You can choose to use EC2 on-demand or spot instances in your compute environment. * ECS container instances are launched into the VPC and subnets that you specify when you create the compute environment. #### Unmanaged compute environment * You manage your own compute resources in this environment. * After you have created your unmanaged compute environment, use `DescribeComputeEnvironments` API operation to view compute environment details and find the ECS cluster that is associated with the environment and manually launch container instances into the cluster. ### Security * By default, IAM users don't have permissions to create or modify Batch resources, or perform tasks using Batch API. * Take advantage of IAM policies, roles and permissions. ### Monitoring * You can use AWS Batch event stream for CloudWatch to receive near real-time notifications regarding the current state of jobs that have been submitted to your job queue. * Events from Batch event stream are ensured to be delivered at least once. * CloudTrail captures all API calls for AWS Batch as events. ### Pricing * There is no additional cost for Batch. You pay for resources you create to store and run your application. # ECS & ECR Elastic Container Service & Elastic Container Registry ## ECS - Amazon Elastic Container Service * A container service to run and and manage Docker container on a cluster. * ECS can be used to create a consistent deployment and build experience, manage and scale batch and ELT workloads, and build sophisticated application architectures on a microservice model. * ECS is a regional service. ### Features * You can create ECS clusters within a new or existing VPC. * After the cluster is up and running, you can define task definitions and services that specify which Docker container images to run across your clusters. * AWS SLA guarantees a monthly uptime percentage of at least 99.99% for ECS. ### Components * **Containers and images** * Your application components must be architected to run in containers - containing everything that your application needs to run: code, runtime, system tools, libraries, etc. * Containers are created from a read-only template called an image. * Images are typically build from a Dockerfile, a plaintext file that specifies all of the components that are included in the container. These images are then stored in the registry, from which they can be downloaded and run on your cluster. * When you launch a container instance, you have the option of passing the user data to the instance. The data can be used to perform common automated configuration tasks and even run scripts when the instance boots. * **Task definitions** * Task definitions specify various parameters for your application. It's a text file, in JSON format, that describes one or more containers, up to a maximum of 10, that form your application. * Task definitions are split into separate parts: * **Task family** - the name of the task and each family can have multiple revisions. * **IAM task role** - specifies the permissions that containers in tasks should have. * **Network mode** - determines how the networking is configured for your containers. * **Container definitions** - specify which image to use, how much CPU and memory the containers are allocated, and many more options. * **Volumes** - allow you to share data between containers and even persist the data on the container instance when the containers are no longer running. * **Task placement constraints** - lets you customize how your tasks are placed within the infrastructure. * **Launch types** - determines which infrastructure your tasks use. ### Task definitions * **Fargate launch type** * Fargate task definitions require that network mode is set to `awsvpc`. The `awsvpc` provides each task with its own ENI (Elastic Network Interface). * Fargate task definitions require that you specify CPU and memory at the task level. * Fargate task definitions only support `awslogs` log driver for the log configuration. This configures your Fargate tasks to send log information to CloudWatch Logs. * Task storage is ephemeral. After Fargate task stops, the storage is deleted. * Put multiple containers in the same task definition if: * Containers share a common lifecycle. * Containers are required to be run on the same underlying host. * You want your containers to share resources. * Your containers share data volumes. * Otherwise, define your containers in separate task definitions so that you can scale, provision and deprovision them separately. * **EC2 launch type** * Create task definitions that group the containers that are used for a common purpose, and separate the different components into multiple type definitions. * After you have your task definitions, you can create services from them to maintain the availability of your desired tasks. * For EC2 tasks, the following are the types of data volumes that can be used: * Docker volumes * Bind mounts * Private repositories are only supported by the EC2 launch type. ### Tasks and scheduling * A tasks is the instantiation of a task definition within a cluster. After you have created a task definition for your application, you can specify the number of tasks that will run on your cluster. * Each task that uses the Fargate launch type has its own isolation boundary and does not share the underlying kernel, CPU resources, memory resources or ENI with another task. * The task scheduler is responsible for placing tasks within your cluster. There are several scheduling options available: * **REPLICA** - places and maintains the desired number of tasks across your cluster. By default, the service scheduler spreads tasks across the Availability Zones.You can use task placement strategies and constraints to customize task placement decision. * **DAEMON** - deploys exactly one task on each active container instance that meets all of the task placement constraints that you specify in your cluster. When using this strategy, there's no need to specify a desired number of tasks, a task placement strategy or use Service Auto Scaling policy. * You can upload a new version of your application task definition, and the ECS scheduler automatically starts new containers using the updated image and stop containers running the previous version. ### Clusters * When you run tasks using ECS, you place them in a cluster, which is a logical grouping of resources. * Clusters are region-specific. * Clusters can contain tasks using both the Fargate and EC2 launch types. * When using the Fargate launch type with tasks within your cluster, ECS manages your resources. * When using EC2 launch type, then your clusters are a group of container instances you manage. These clusters can contain multiple container instance types, but each container instance may only be part of one cluster at a time. * Before you can delete a cluster, you must delete all services and deregister the container instances inside that cluster. ### Services * ECS allows you to run and maintain a specified number of a task definitions simultaneously in a cluster. * In addition to maintaining the desired count of tasks in your service, you can optionally run your service behind a load balancer. * There are two deployment strategies in ECS: * **Rolling update** * This involves the service scheduler replacing the current running version of the container with the latest version. * The number of tasks ECS adds or removes from the service during the rolling update is controlled by the deployment configuration, which consists of minimum and maximum number of tasks allowed during a service deployment. * **Blue/green deployment** * This deployment type allows you to verify a new deployment of a service before sending production traffic to it. * The service must be configured to use either Application Load Balancer or Network Load Balancer. ### Container Agent * The Container Agent runs on each infrastructure resource within an ECS cluster. * It sends information about the resource's current running tasks and resource utilization to ECS, and starts and stops tasks whenever it receives the request from ECS. * Container agent is only supported on EC2 instances. ### Task Placement Strategies * A task placement strategy is an algorithm for selecting instances for task placement or tasks for termination. When the tasks that uses the EC2 launch type is launched, ECS must determine where to place the task based on the requirements specified in the task definition, such as CPU and memory. Similarly, when you scale down the task count, ECS must determine which tasks to terminate. * A task placement constraint is a rule that is considered during task placement. * You can use constraints to place tasks based on AZ or instance type. * You can also associate attributes, which are name-value pairs, and then use a constraint to place tasks based on attribute. * Task placement strategy types: * **Binpack** - place tasks based on the least available CPU and memory. This minimizes the number of instances in use and allow you to be cost-efficient. * **Random** - place tasks randomly. You use this strategy when task placement or termination does not matter. * **Spread** - place tasks evenly based on the specified value. Accepted values are attribute key-value pairs, instance ID or host. Spread is typically used to achieve high availability by making sure that multiple copies of task are scheduled across multiple AZs in the default placement strategy used for services. * You can combine different strategy types to suit your application needs. * Task placement strategies are best effort. * By default, Fargate tasks are spread across availability zones. * By default ECS uses following placement strategies: * When you run tasks with the `RunTask` action, tasks are placed randomly in the cluster. * When you launch and terminate tasks with the `CreateService` API action, the service scheduler spreads the tasks across the AZs (and the instances within the zones) in the cluster. ### Cluster queries Cluster queries are expressions that enable you to group objects. For example, you can group container instances by attributes such as AZs, instance types or custom metadata. You can add custom metadata to your container instances, known as attributes. Each attribute has a name and optional string value. You can use the built-in attributes provided by ECS or define custom attributes. After you have defined a group of container instances, you can customize ECS to place tasks on container instances based on group. Running tasks manually is ideal in certain situations. For example, suppose that you're developing a task but you're not ready to deploy this task with the service scheduler. Perhaps your task is a one-time or periodic batch job that does not make sense to keep running or restart when finishes. ### Secrets ECS enables you to inject sensitive data into your containers by storing your sensitive data in either Secrets Manager or Systems Manager Parameter Store parameters and then referencing them in your container definition. This feature is supported by tasks using both the EC2 and Fargate launch types. Secrets can be exposed to containers in the following way: * as environment variables, use the `secrets` container definition parameter. * in the log configuration of a container, use the `secretOptions` container definition parameter. ### Fargate * You can use Fargate with ECS to run containers without having to manage servers or clusters of EC2 instances. * You no longer have to provision, configure or scale clusters of virtual machines to run containers. * Fargate only supports images hosted on ECR or Docker Hub. ### Monitoring * You can configure your container instances to send log information to the CloudWatch Logs from your container instances in one convenient location. * With CloudWatch Alarms, watch a single metric over time period that you specify, and perform one or more actions based on the value of the metric relative to a give threshold over the number of time periods. * Share a log files between accounts, monitor CloudTrail log files in real time by sending them to CloudWatch Logs. ### ECS and X-Ray * The AWS X-Ray SDK does not trace data directly to the AWS X-Ray. To avoid calling the service every time your application serves the request, the SDK sends the trace data to a daemon, which collects segments for a multiple requests and uploads them in batches. * Use a script to run a daemon alongside your application. * To properly instrument your applications in ECS, you have to create a Docker image that runs X-Ray daemon, upload it to an image repository, and then deploy it to your ECS cluster. You can use port mappings and network mode settings in your task definition file to allow your application to communicate with the daemon container. * The X-Ray daemon is an application that listens for the traffic on UDP port 2000, gathers raw segment data and relays it to the X-Ray API. The daemon works in conjunction with X-Ray SDK and must be running so that data sent by the SDK can reach the X-Ray service. ### Tagging * ECS resources, including task definitions, clusters, tasks, services and container instances, are assigned an ARN and a unique resource ID. These resources can be tagged with values that you define, to help you organize and identify them. ### Pricing * With Fargate, you pay for the amount of vCPU and memory resources that your containerized application requests. vCPU and memory resources are calculated from the time your container images are pulled until the ECS task terminates. * There is no additional charge for EC2 launch type. You pay for the AWS resources you create to store and run your application. ### Limits | Description | Value | | ------------------------------------------------------------------------------------------------------- | ----- | | Number of clusters, per region, per account | 1000 | | Number of container instances per cluster | 1000 | | Number of services per cluster | 500 | | Number of tasks using EC2 launch type per service (the desired count) | 1000 | | Number of tasks using Fargate launch type, per region | 50 | | Number of load balancers per service | 1 | | Number of tasks launched (count) per run-task | 10 | | Number of container instances per start-task | 10 | | Task definition max containers | 10 | | Maximum layer size of an image used by a task, Fargate launch type | 4GB | | Maximum size of a shared volume used by multiple containers within a task using the Fargate launch type | 4GB | | Maximum container storage for tasks using the Fargate launch type | 10 GB | ## ECR - Elastic Container Registry ### Features * ECR supports Docker registry API v2 allowing you to use Docker CLI commands or your preferred Docker tools in maintaining your existing development workflow. * ECR stores both the containers you create and any container software you buy through AWS marketplace. * ECR stores your images in S3. * ECR support the ability to define and organize repositories in your registry using namespaces. * You can transfer your container images to and from ECR via HTTPS. ### Components * **Registry** * A registry is provided to each AWS account; you can create image repositories in your registry and store the images in them. * The URL for your default registry is `https://aws.{account_id}.dkr.ecr.{region}.amazonaws.com` * You must be authenticated before you can use your registry. * **Authorization Token** * Your Docker client needs to authenticate to ECR repositories as an AWS user before it can push and pull images. The AWS CLI `get-login` command provides you with authentication credentials to pass to Docker. * **Repository** * An image repository contains your Docker images * ECR uses resource-based permissions to let you specify who has access to a repository and what actions they can perform on it. * ECR lifecycle policies enable enable you to specify the lifecycle management in a repository. * **Repository policy** * You can control access to your repositories and the images within them with repository policy. * **Image** * You can push and pull images to your repositories. You can use these images locally on your development system, or you can use them in your task definitions. ### Security * By default, IAM users don't have permissions to create or modify ECR resources, or perform tasks using the ECR API. * Use IAM policies to grant or deny permissions to use ECR resources and operations. * ECR partially supports resource-level permissions. ### Pricing * You pay only for the amount of data you store in your repositories and data transferred to the internet. ### Limits | Description | Limit | | ------------------------------------------ | ----- | | Maximum number of repositories per account | 1000 | | Maximum number of images per repository | 1000 | # Elastic Beanstalk Allows you to quickly deploy and manage applications in AWS Cloud without worrying about the infrastructure that runs these applications. * Automatically handles the details of capacity provisioning, load balancing, scaling and health monitoring. * It is platform-as-a-service (PaaS). * Support Go, Java, .NET, NodeJS, PHP, Python, Ruby. * Supports following web containers: Tomcat, Passenger, Puma. * Supports Docker containers. * Your application domain: `{subdomain}.{region}.elasticbeanstalk.com` ### Environment pages * **Configuration page** shows the resources provisioned for this environment. This page also lets you configure some of the provisioned resources. * **Health page** shows the status and detailed health information about the EC2 instances running your application. * **Monitoring page** shows the statistics for the environment, such as the average latency and CPU utilization. You also use this page to create alarms for the metrics that you're monitoring. * **Event page** shows any informational or error messages from services that this environment is using. * **Tags page** shows tags. ### Concepts * **Application** - a logical collection of Beanstalk components, including environments, versions, and environment configurations. It's conceptually similar to a folder. * **Version** - refers to a specific, labeled iteration of deployable code for a web application. An application version points to an S3 object that contains the deployable code. Applications can have many versions and each application version is unique. There is a limit to the number of application versions you can have.You can avoid hitting the limit by applying the application version policy to your applications to tell Beanstalk to delete application versions that are old, or to delete versions when the total number of versions for an application exceeds a specific number. * **Environment** - a version that is deployed to AWS resources. Each environment runs only a single application version at a time, however you can run the same version or different version in many environments at the same time. * **Environment Tier** - determines whether Beanstalk provisions resources to support an application that handles HTTP requests or an application that pulls tasks from a queue. An application that serves HTTP requests runs in a web server environment. An application that pulls events from an SQS queue runs in a worker environment. * **Environment Configuration** - identifies the collection of parameters and settings that define how an environment and its associated resources behave. * **Configuration Template** - a starting point for creating unique environment configuration. ### Environment Types * **Load balancing, auto-scaling environment** - automatically starts additional instances to accommodate increasing load on your application. * **Single instance environments** - contains one EC2 instance with Elastic IP address. ### Environment Configurations * Your EC2 VMs configured to run web applications on the platform that you choose. * An auto-scaling group that ensures that there is always one instance running in a single-instance environment, and allows configuration of the group with a range of instances to run in a load-balanced environment. * When you enable load-balancing, Beanstalk will create ELB to distribute traffic among your environment instances. * Beanstalk provides integration with RDS to help you add a database instance to your environment. When you add a database instance to your environment, Beanstalk provides connection information to your application by setting environment properties for the database: hostname, port, user name, password, and a database name. * You can use environment variables to pass secrets, endpoints, debug settings and other information to your application. Environment properties help you run your application in multiple environments for different purposes, such as dev, qa, prod, etc. * You can configure your environment to use SNS to notify you of important events that affect your application. * Your environment is available to users at a subdomain of `elasticbeanstalk.com`. When you create an environment, you can choose a unique subdomain that represent your application. ### Monitoring * Beanstalk monitoring console displays you environment status and application health at a glance. * Beanstalk reports a health of a web server environment depending of how the application running in it responds to a health check. * Enhanced health reporting is a feature that you can enable on your environment to allow Beanstalk to gather additional information about resources in your environment.Beanstalk analyses the information gathered to provide a better picture of overall environment health and aid in the identification of issues that can cause your application to become unavailable. * You can create alarms for metrics to help you monitor changes to your environment so you can easily identify and mitigate problems before they occur. * EC2 instances in your environment generate logs that you can view to troubleshoot issues with your application or configuration files. ### Security * When you create an environment, Beanstalk prompts you to provide two IAM roles: service role and an instance profile role: * **service role** - assumed by Beanstalk to use other AWS services on your behalf. * **instance profile** - applied to the instances in your environment and allows them to retrieve application versions from S3, upload logs to S3 and perform other tasks that vary depending on the environment type and platform. * **User policies** - allow users to create and manage Beanstalk applications and environments. ### Pricing * There is no additional charge for using Beanstalk. You pay only for underlying resources that you consume. ### Worker Environments * If your applications perform operations or workflows that take a long time to complete, you can offload these tasks to a dedicated worker environment. Decoupling your application frontend from a process that performs blocking operations is a common way to ensure that your application stays responsive under load. * One option is to spawn worker processes locally, return success and process the task asynchronously. This works if your instance can keep up with all the tasks sent to it. Under high load, however, an instance can become overwhelmed with background tasks and become unresponsive to higher priority requests. If individual users can generate multiple tasks, the increase in load might not correspond to an increase in users, making it hard to scale out the web tier. * Beanstalk worker environments simplify this process by managing the SQS queue and running the daemon process on each instance that reads from the queue for you. When daemon pull an item from the queue, it sends the HTTP POST request locally to on port 80 with contents of the queue message in the body. All that your application needs to do is perform a long-running task in response to POST. ### Periodic Tasks * You can define periodic tasks in a file named `cron.yaml` in your source bundle to add jobs to your worker environments queue automatically at a regular interval. * When the task runs, a daemon posts a message to the environment's SQS queue with the header indicating the job that needs to be performed. Any instance in the environment can pick up the message and run the job. * If you configure your worker environment with an existing SQS queue and choose FIFO queue, periodic tasks are not supported. * Beanstalk uses leader election to determine which instance in your worker environment queues the periodic task. Each instance attempts to become a leader by writing to the DynamoDB table. The first instance that succeeds is the leader, and must continue to write to the table to maintain leader status. If the leader goes out of service, another instance quickly takes its place. ### X-Ray * You can use console or configuration file to run X-Ray daemon on the instances in your environment. * You can use `XRayEnabled` option in the `aws:elasticbeanstalk:xray` namespace to enable debugging. Add this configuration to `debugging.config` or `xray-daemon.config`: ```yaml option_settings: aws:elasticbeanstalk:xray: XRayEnabled: true ``` ### Deployment options * **All at once** - deploy the new version to all instances simultaneously. All instances in your environment are out of service for a short time while the deployment occurs. * **Rolling** - deploy the new version in batches. Each batch is taken out of service during the deployment phase, reducing your environment capacity by the number of instances in a batch. * **Rolling with additional batch** - deploys the new version in batches, but first launch the additional batch of instances to ensure full capacity during the deployment process. * **Immutable** - deploy a new version to a fresh group of instances by performing the immutable update. * **Blue/green** - deploy a new version to a separate environment, and then swap CNAMES of the two environments to redirect traffic to the new version instantly. ### Platform updates * Beanstalk regularly releases new platform versions to update all Linux-based and Windows-based platforms. New platform version provide update to existing software components and support for new features and configuration options. * You can use Beanstalk console of CLI to update your environment platform version. Depending of platform version you'd like to update to, Beanstalk recommends one of two methods for performing platform updates: * **Update your environment platform version** - this is the recommended method when you're updating to the latest platform version, without a change in the runtime, web server or application server versions, and without a change in major platform version. * **Perform a blue/green deployment** - this is the recommended method when you're updating to a different runtime, web server or application server version, or to a different major platform version. This is a good approach when you want to take advantage of new runtime capabilities or the latest Beanstalk functionality. ### Deploying with CLI * CLI provides interactive commands that simplify creating, updating and monitoring environments from a local repository. It is recommended that you use CLI as part of your everyday development and testing cycle as an alternative to AWS Console. * You can tell CLI to deploy ZIP or WAR file that you generate as part of a separate build process by adding the following lines to `.elasticbeanstalk/config.yaml` in your project folder: ```yaml deploy: artifact: path/to/your/build/artifact.zip ``` * If you configure the CLI in your Git repository, and you don't commit the artifact to source, use the `--staged` option to deploy the latest build: `eb deploy --staged` # Storage & Data Management #### Which services have "maintenance window" option: * RDS * Elasticache * Redshift * DynamoDB DAX * Neptune * DocumentDB # S3 Simple Storage Service ## S3 - Simple Storage Service - * **S3 is object storage** * Can store any files * Size from 0 bytes to 5 TB * **S3 is universal namespace** * Each bucket name must be unique across entire S3 * **Objects** * Key - name of the object * Value - data * Version ID * Metadata * Subresources * Access Control Lists (ACLs) * Torrents * **Consistency** * **Read after write consistency** for PUTs of new objects * **Eventual consistency** for overwrite PUTs and DELETEs (can take some time to propagate) * **Guarantees** * 99.99% availability * 99.999999999% durability (11x9s - "eleven nines") * **Features** * Tiered storage * Lifecycle management * Versioning * Encryption * MFA delete * Security with ACLs and Bucket Policies * **Storage classes** * **S3 Standard** - 99.99% availability and 11x9s durability, stored redundantly across multiple devices in multiple facilities, and designed to sustain the loss of 2 facilities concurrently. * **S3 IA (Infrequent Access)** - for data that is accessed less frequently but requires rapid access when needed. * **S3 One Zone IA** - cheaper than IA. For data that does not require multiple Availability Zone data resilience. * **S3 Intelligent Tiering** - optimizes cost by automatically moving objects into appropriate and most cost effective tier. * **S3 Glacier** - low cost storage for data archiving. Retrieval times configurable. * **S3 Glacier Deep Archive** - lowest cost with 12 hours of retrieval times. * **S3 charges** * Storage * Requests * Storage Management Pricing * Data Transfer Pricing * Transfer Acceleration * Cross Region Replication Pricing * **MFA Delete and Versioning** * S3 versioning enables you to revert to older versions of S3 objects. * Multiple versions of an object are stored in the same bucket. * Versioning also protects you from accidental / malicious deletes. * With versioning enabled, a DELETE action doesn't delete the object version, but applies a delete marker instead. * To permanently delete, provide the object Version ID in the delete request. * MFA Delete provides an additional layer of protection to S3 Versioning. * Once enabled, MFA Delete will enforce 2 things: * You'll need a valid code from your MFA device in order to permanently delete an object version. * MFA also needed to suspend / reactivate versioning on an S3 bucket. * **Encryption** * in-transit - SSL / TLS * at rest - Server-side achieved by: * SSE-S3 - S3 managed key * SSE-KMS - Using Key Management Service * SSE-C - Server side encryption with customer provided key * client-side encryption * **Cross-region replication** * Versioning must be enabled on both the source and the destination buckets * Regions must be unique * Existing files in the existing bucket are not replicated automatically * All subsequent updates will be replicated automatically * Delete markers are not replicated * Deleting individual versions or delete markers are not replicated * **Lifecycle policies** * Automates moving your objects between different storage tiers * Can be used in conjunction with versioning * Can be applied to current versions and previous versions * **Transfer Acceleration** * Files are uploaded to edge locations first, and then from edge locations propagated to S3 * Largest file that can be uploaded to S3 using PUT is 5Gb * Key prefixing is no longer needed to improve performance on S3. S3 uses key-value to determine partition for objects. **Enforcing encryption on S3 buckets** * If the file is to be encrypted at upload time, the `x-amz-server-side-encryption` parameter will be included in the request header * Two options are currently available: * `x-amz-server-side-encryption: AES256` * `x-amz-server-side-encryption: kms` * When this parameter is included in the the header of the PUT request, it tells S3 to encrypt the object at the time of upload, using the specified encryption method. * You can enforce the use of Server-Side Encryption by using a Bucket Policy which denies any S3 PUT request which does not include the `x-amz-server-side-encryption` parameter in the request header. Example of the bucket policy that denies `PutObject` operations if server-side encryption header is not specified in the request: ```javascript { "Id": "Policy1585498423331", "Version": "2012-10-17", "Statement": [ { "Sid": "Stmt1585498419704", "Action": [ "s3:PutObject" ], "Effect": "Deny", "Resource": "arn:aws:s3:::mybucketnamehere", "Condition": { "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" } }, "Principal": "*" } ] } ``` **S3 Batch operations** Batch operations is a new feature that makes it simple to manage billions of objects stored in S3. Customers can make changes to object properties and metadata, and perform other storage management tasks - such as copying objects between buckets, replacing tag sets, modifying access controls, and restoring archived objects from Glacier - for any number of S3 objects in minutes. #### Sharing S3 bucket across accounts * Using bucket policies and IAM (applies across the entire bucket). Programmatic access only. * Using bucket ACLs and IAM (individual objects). Programmatic access only. * Cross-account IAM roles. Programmatic and Console access. # Storage Gateway * Storage Gateway consists of an on-premises software appliance which connects with AWS cloud-based storage to give you a seamless and secure integration between your on-premises IT environment and AWS. * **File Gateway** * Files stored as objects in S3 buckets * Accessed using SMB or NFS mount points * To your on-premises systems this appears like a file system mount backed by S3 * All the benefits of S3: bucket policies, S2 versioning, lifecycle management, replication, etc. * Low-cost alternative to on-premises storage * **Volume Gateway** * Provides cloud backed storage which is accessed using iSCSI protocol * 2 different types available: * Gateway Stored Volumes * The gateway stores all your data locally, so your applications get low latency access to the entire dataset * You need your own storage infrastructure as all data is stored locally in your data center * Provides durable off-site async backups in the form of EBS snapshots which are stored in S3 * Gateway Cached Volumes * The gateway stores all your data in S3 and caches only frequently accessed data locally * You need only enough local storage capacity to store the frequently accessed data * Applications still get low-latency access to frequently used data without a large investment in on-premise storage * **Tape Gateway** * Virtual Tape Library which provides cost effective data archiving in the cloud using Glacier * You don't need to invest in your own tape backup infrastructure * Integrates with existing tape backup infrastructure - NetBackup, Backup Exec, Veeam, etc. which connect to the VTL using iSCSI * Data is stored on virtual tapes which are stored in Glacier and accessed using VTL # RDS Relational data store ### AWS database types * RDS (OLTP - online transaction processing) * SQL * MySQL * PostgreSQL * Oracle * MariaDB * NoSQL * DynamoDB * OLAP * RedShift * Cache (Elasticache) * Memcached * Redis ### Backups with RDS * Automated backups * Database snapshots Automated backups allow to recover your database to any point in time with a "retention period". The retention period can be between 1-35 days. Automated backups will take a full daily snapshot and will also store transaction logs throughout the day. When you do a recovery, AWS will first choose the most recent daily backup, and then apply transaction logs relevant to that day. This allows you to do a point-in-time recovery down to a second, within the retention period. Automated backups are enabled by default. The backup data is stored in S3 and you get free storage space equal to the size of your database. So if you have an RDS instance of 10 Gb, you'll get 10Gb worth of storage. Backups are taken within a defined window. During the backup window, storage I/O may be suspended while your data is being backed up and you may experience elevated latency. Database snapshots are done manually. They are stored even after you delete the original RDS instance, unlike automated backups. Whenever you restore an automated backup or a manual backup, the restored version of the database will be a new RDS instance with a new DNS endpoint. ### Encryption at rest Encryption at rest is supported for MySQL, Oracle, SQL Server, PostgeSQL, MariaDB and Aurora. Encryption is done using the AWS KMS. Once your RDS instance is encrypted, the data stored at rest in the underlying storage, as are its automated backups, read replicas and snapshots. #### Sharing encrypted RDS snapshots between accounts You can share database snapshots that have been encrypted at rest using the AES-256 encryption algorithm. The steps are following: * Create a custom KMS encryption key. * Create snapshot using the custom key. * Share the custom KMS key that was used to encrypt the snapshot. * Use Console, CLI or RDS API to share the encrypted snapshot with other accounts. Restrictions: * You can't share encrypted snapshots as public. * You can't share Oracle or Microsoft SQL Server snapshots that are encrypted using Transparent Data Encryption (TDE). * You can't share snapshots that has been encrypted using the default AWS KMS encryption key of the AWS account that shared the snapshot. ### Multi-AZ and Replication Multi-AZ allows you to have an exact copy of your production database in another Availability Zone. AWS handles the replication for you, so when your production database is written to, this write is automatically be synchronized to the standby database. In the event of planned database maintenance, DB instance failure or an AZ failure, RDS will automatically failover to the standby, so that database operations can resume quickly without administrative intervention. Multi-AZ is for disaster recovery only. It's not primarily used for improving performance. For performance improvement you need **read replicas**. Multi-AZ is available for the following databases: * SQL Server * Oracle * MySQL * PostgreSQL * MariaDB * Aurora (fault-tolerant by default) Read replicas allow you to have a read-only copy of your production database. This is achieved by using asynchronous replication from the primary RDS instance to the replica. You use read replicas primarily for read-heavy database workloads. Read replicas available for the following databases: * MySQL * PostgreSQL * MariaDB * Oracle * Aurora Things to know about read replicas: * Used for scaling, not for disaster recovery * Must have automatic backups turned on in order to deploy a read replica. * You can have up to 5 read replicas of any DB. * Each read replica will have it's own DNS endpoint. * You can have read replicas that have multi-AZ. * You can create read replicas of Multi-AZ databases. * Read replicas can be promoted to their own databases. This breaks the replication. * You can have a read replica in another region. ## Aurora Amazon Aurora is a MySQL-compatible, relational database engine, combines the speed and availability of high-end commercial databases with the simplicity and cost-effectiveness of open-source databases. Amazon Aurora provides up to 5 times better performance than MySQL at a pricepoint 1/10 that of a commercial database while delivering similar performance and availability. * Starts with 10Gb, scales up to 64Gb. * Compute resources can scale up to 32 vCPU and 244 Gb of RAM. * 2 copies of your data is contained in each availability zone with minimum of 3 available zones (not all regions supported). ### Scaling * Aurora is designed to transparently handle the loss of up to 2 copies of data without affecting database write ability and up to 3 copies without affecting read availability. * Aurora storage is also self-healing. Data blocks and disks are continuously scanned for errors and repaired automatically. ### Replication * Two types of replicas supported: * Aurora replicas (up to 15) * MySQL replicas (up to 15) ### Backups * Automated backups are always enabled on Aurora instances. Backups do not impact database performance. * You can also take snapshots with Aurora. This also does not impact performance. * You can share Aurora snapshots with other AWS accounts. ### Encryption * Encryption at rest is turned on by default. Once encryption is turned on, all read replicas will be encrypted. ### Failover * Failover is defined by tiers. The lower the tier the higher the priority with Tier 0 being the highest priority available. ### Cross region replication * Creating a cross-region replica will also create a new Aurora cluster in the target region. If the replication is disrupted, you will have to set it up again. It is recommended that you select "Multi-AZ deployment" to ensure high availability for the target cluster. ### Aurora Serverless ![](https://486712189-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LyFJfu8WpLS6CqNwIrW%2F-M3SgVIjEMdotifSXgkV%2F-M3SgXZXwvdIw3ONQBGy%2Faws-rds-aurora-serverless.png?alt=media\&token=800b88c8-cfae-4d0c-89f2-c130625d72dc) * Aurora Serverless is an on-demand, auto-scaling configuration for Aurora where the database will automatically startup, shutdown, and scale up or down capacity based on your application needs. * You pay on a per-second basis for the database capacity you use when the database is active, and you can migrate between standard and serverless configurations with a few clicks in RDS Console. # DynamoDB AWS DynamoDB is a fast and flexible NoSQL database service for all applications that need consistent, single-digit millisecond latency at any scale. It is a fully managed database and supports both document and key-value data models. ### Basics * NoSQL database that provides fast and predictable performance with seamless scalability. * Offers encryption at rest. * You can create database tables that can store and retrieve any amount of data, and serve any level of request traffic. * You can scale up or down your table throughput capacity without downtime without downtime or performance degradation, and use console to monitor resource utilization, and performance metrics. * Provides on-demand backup capability as well as point-in-time recovery, you can restore that table to any point in time during the last 35 days. * All of your data is stored in partitions, backed by SSDs and automatically replicated across multiple AZs in AWS region, providing built-in high availability and durability. * You can create tables that are automatically replicated across two or more regions, with full support for multi-master writes. ### Core Components * **Tables** - a collection of items * DynamoDB stores data in a table, which is a collection of data. * Are seamless. * There is initial limit of 256 tables per region. * **Items** - a collection of attributes * DynamoDB uses primary keys to uniquely identify each item in a table and secondary indexes to provide more querying flexibility. * Each table contains zero or more items. * **Attributes** - a fundamental data element * DynamoDB supports nested attributes up to 32 levels deep. * **Primary Key** - uniquely identifies each item in a table, so that no two items can have the same key * Must be scalar * **Partition key** - a simple primary key, composed of one attribute. * **Partition key and sort key (composite primary key)** - composed of two attributes * DynamoDB uses the partition key value as an input to an internal hash function. The output from the hash function determines the partition in which the item will be stored. All items with the same partition key are stored together, in sorted order by sort key value. If no sort key is used, no two items can have the same partition key value. * **Secondary indexes** - lets you query the data in the table using an alternative key, in addition to queries against the primary key * You can create one or more secondary indexes on the table. Supports local secondary indexes and global secondary indexes. * **Global secondary index** - an index with partition key and sort key that can be different from those of the table. * **Local secondary index** - an index that has the same partition key as the table, but a different sort key. * You can define up to 5 global secondary indexes and up to 5 local secondary indexes. * **Streams** - an optional feature that captures the data modification event in DynamoDB tables * The naming convention for DynamoDB stream endpoints is `streams.dynamodb.amazonaws.com` * Each event is represented by a stream record and captures the following events: * a new item is added to the table - captures the image of the entire item, including all of its attributes * an item is updated - captures the "before" and "after" image of any attributes that were modified in the item. * an item is deleted - captures the image of the entire item before it was deleted. * Each stream record also contains the name of the table, the event timestamp, and other metadata. * Stream records are organized into groups, or shards, Each shard acts as a container for multiple stream records, and contains information required for accessing and iterating through these records. * Stream records have a lifetime of 24 hours, after that they are removed from the stream. * You can use streams with Lambda to create a trigger. * Streams enable powerful solutions such as data replication within or across regions, materialized views of data in DynamoDB tables, data analytics using Kinesis materialized views and much more. ### Data Types for Attributes * **Scalar types** - a scalar type can represent exactly one value. The scalar types are number, string, binary, boolean and null. Primary keys should be scalar types. * **Document types** - a document type can represent a complex structure with nested attributes such as you would find in a JSON document. Document types are list and map. * **Set types** - a set types can represent multiple scalar values. The set types are string set, number set and binary set. #### Other notes * When you read data from DynamoDB table, the response might not reflect the results of a recently completed write operation. The response might include some stale data, but you should eventually have consistent reads. * When you request a strongly consistent reads, DynamoDB returns result with the most up-to-date data, reflecting the updates from all prior write operations that were successful. A strongly consistent read might not be available is there is a network delay or outage. * DynamoDB does not support strongly consistent reads across regions. * When you create a table or index in DynamoDB, you must specify your throughput capacity requirements for read and write activity in terms of: * One **read capacity unit (RCU)** represents one strongly consistent read per second, or two eventually consistent reads per second, for an item up to 4KB in size. If you need to read an item that is larger than 4KB, DynamoDB will need to consume additional RCUs. * One **write capacity unit (WCU)** represents one write per second for an item up to 1KB in size. If you need to write an item that is larger than 1KB, DynamoDB will need to consume additional WCUs. * Throttling prevents your application from consuming too many capacity units. DynamoDB can throttle read or write requests that exceed throughput settings for a table, and can also throttle read requests for an index. * When a request is throttled, it fails with an HTTP 400 error (BadRequest) and a `ProvisionedThroughputExceedException` ### Throughput management * **DynamoDB autoscaling** * Define a range (upper and lower limit) for RCU and WCU, and define target utilization percentage within a range. * A table or a global secondary index can increase its provisioned RCUs to handle sudden increase in traffic, without request throttling. * DynamoDB autoscaling can decrease the throughput when the workload decreases so that you don't pay for unused provisioned capacity. * **Provisioned throughput** - manually defined maximum amount of capacity that the application can consume from a table or index. If your application exceeds provisioned throughput settings, it is a subject to request throttling. * **Reserved capacity** - with reserved capacity, you pay a one-time upfront fee to a minimum usage level over a period of time, for cost saving solutions. ### Capacity unit consumption * **RCU** - strongly consistent reads consume 1 capacity unit, while eventually consistent read request consume $$1/2$$ of read capacity unit * `GetItem` - reads single item * `BatchGetItem` - reads up to 100 items * `Query` - reads multiple items that have the same partition key * `Scan` - reads all of the items in the table * **WCU** - write capacity unit * `PutItem` - writes single item * `UpdateItem` - modifies a single item * `DeleteItem` - removes a single item * `BatchWriteItem` - writes up to 25 items to one or more tables ### Autoscaling * When you use AWS Console to create a new table, autoscaling is enabled by default. * You create a scaling policy for a table or a global secondary index. The scaling policy specifies whether you want to scale read capacity or write capacity (or both) and the minimum and maximum provisioned capacity unit settings for the table or index. The scaling policy also contains a target utilization, which is the percentage of consumed provisioned throughput at a point in time. * Autoscaling does not prevent you from manually modifying provisioned throughput. * If you enable autoscaling for a table that has a global secondary indexes, AWS highly recommends that you also apply autoscaling uniformly to those indexes. ### DynamoDB Items * You can use `UpdateItem` operation to implement an atomic counter - a numeric attribute that is incremented, unconditionally, without interfering with other write requests. * DynamoDB optionally supports conditional writes for these operations: `PutItem`, `UpdateItem`, `DeleteItem`. A conditional write will succeed only if the item attributes meet one or more expected conditions. * Conditional writes can be idempotent if the conditional check is on the same attribute that is being updated. DynamoDB performs a given write request only if the certain attribute values in the item match what you expect them to be at the time of the request. * Expressions * To get only a few attributes of an item, use a `projection` expression. * An expression attribute name is a placeholder that you use in an expression, as an alternative to an actual attribute name. An expression attribute name must begin with a `#` and be followed by one or more alphanumeric characters. * For `PutItem`, `UpdateItem` and `DeleteItem` operations, you can specify a condition expression to determine which items should be modified. If the condition expression evaluates to true, the operation succeeds. * An update expression specifies how `UpdateItem` will modify attributes of an item - for example, setting a scalar value, or removing elements from a list or a map. ### Time To Live (TTL) * Allows you to define when items in a table expire so that they can be automatically deleted from the database. ### Queries * A query operation finds items based on a primary key values. You can query any table or secondary index that has a composite primary key. * A key condition expression is a search criteria that determines the items to be read from table or index. * You must specify the partition key name and value as an equality condition. * You can optionally provide a second condition for the sort key. * A single query operation can retrieve maximum of 1Mb. * For further refining of query operations you can optionally provide a filter expression, to determine which items within the query results should be returned. All of the other results are discarded. * Query operation allows you to limit the number of items that it returns in the result by setting the `Limit` parameter to the maximum number of items you want. * DynamoDB paginates the results from query operations, where query results are divided into "pages" of data that are 1Mb in size (or less). * `ScannedCount` is a number of items that matched the key condition expression, before filter expression (if present) was applied. * `Count` is the number of items that remain, after the filter expression (if present) was applied. ### Scans * A scan operation reads every item in a table or secondary index. By default, a `Scan` operation returns all of the data attributes for every item in the table or index. * Scan always returns a result set. If no matching items are found, the result set will be empty. * A single scan request can retrieve a maximum of 1Mb of data. * You can optionally provide a filter expression. * You can limit the number of items in the result. * DynamoDB paginates the results from `Scan` operations. * `ScannedCount` is the number of items evaluated, before any scan filter is applied. * `Count` is the number of items that remain, after a filter expression (if present) was applied. * A `Scan` operation performs eventually consistent reads, by default. * By default, `Scan` operation process data sequentially. ### Global Tables * Global tables provide a solution for deploying multi-region, multi-master databases, without having to build and maintain your own replication solution. * You specify the AWS regions where you want the table to be available. DynamoDB performs all tasks to create internal tables in these regions, and propagate ongoing data changes to all of them. * Replica tables: * A single DynamoDB table that functions as a part of a global table. * Each replica stores the same set of items. * Any given global table can only have one replica table per region. * You can add new or delete replicas from global table. * To ensure eventual consistency, DynamoDB global tables use a "last write wins" reconciliation between concurrent updates, where DynamoDB makes a best effort to determine the last writer. * If a single regions becomes isolated or degraded, your application can redirect to a different region and perform reads and writes against different replica table. DynamoDB also keeps track of any writes that have been performed, but have not yet been propagated to all of the replica tables. * Requirements for adding a new replica table: * must have the same partition key as all of the other replicas * must have the same write capacity management settings specified * must have same name as all of the other replicas * must have streams enabled, with the stream containing both new and old images of the item * none of the replica tables in the global table can contain any data * If global secondary indexes are specified, then the following conditions must also be met: * global secondary index must have the same name * global secondary index must have the same partition key and sort key (if present) ### On-demand Backup and Restore * You can use IAM to restrict DynamoDB backup and restore actions for some resources * All backup and restore actions are captured and recorded in CloudTrail * Backups: * Each time you create a backup, the entire table is backed up * All backups and restores in the DynamoDB work without consuming any provisioned throughput on the table. * DynamoDB backups do no guarantee causal consistency across the items; however the skew between updates in a backup is usually much less than a second * Backup and restore works only in the same AWS region as the source table * Included in the backup are * database data * global secondary indexes * local secondary indexes * streams * provisioned RCU and WCU * While backup is in progress you can't do the following: * pause or cancel backup operation * delete the source table of the backup * disable backups on the table * Restore: * You can not overwrite the existing table during the restore operation * You restore backup to a new table * For tables with even data distribution across your primary keys, the restore time is proportional to the largest single partition by item count and not the overall table size. * If your source table contains data with significant skew, the time to restore may increase. ### Security * Encryption * Encrypts your data at rest using KMS key * Encryption at rest can be enabled only when you're creating new table * After encryption is enabled, it can not be disabled * Uses AES 256 encryption * The following are encrypted * base table * LSI * GSI * Authentication and access control * Access to DynamoDB requires credentials * Aside from valid credentials, you also need permissions to create or access DynamoDB resources * You can create indexes and streams only in the context of the existing DynamoDB table, referred to as subresources * Resources and subresources have unique ARN associated with them * A permission policy describes who has access to what * Identity based policies: * attach a permission policy to a user or a group in your account * attach a permission policy to a role (grant cross-account permissions) * Policy elements * Resource - use an ARN to identify the resource that the policy applies to * Action - use action keywords to identify resource operations that you want to allow or deny * Effect - specify the effect, either allow or deny, when the user requests the specific action * Principal - the user that the policy is attached to is the implicit principal * Web Identity Federation - customers can sign in to an Identity Provider and then obtain temporary security credentials from AWS STS. # ElastiCache Amazon ElastiCache is a web service that makes it easy to deploy, operate and scale an in-memory cache in the cloud. The service improves the performance of web applications by allowing you to retrieve information from fast, managed, in-memory caches, instead of relying entirely on slower disk-based databases. ElastiCache supports two open-source in-memory caching engines: * Memcached * Redis ## Monitoring When it comes to monitoring caching engines, there are 4 important metrics to look at: * CPU utilization * Swap usage * Evictions * Concurrent connections ### CPU utilizations * Memcached * Multi-threaded * Can handle loads up to 90%. If it exceeds 90%, add more nodes to the cluster * Redis * Not multi-threaded. To determine the point in which to scale, take 90% and divide by the number of cores. ### Swap usage * Memcached * Should be around 0 most of the time and should not exceed 50 Mb. * If this exceeds 50 Mb, you should increase the `memcached_connections_parameter` * Redis * No swap usage metrics, instead use `reserved_memory` ### Evictions * Memcached * There is no recommended setting. Choose a threshold based off your application. Either scale up (increase the memory of the existing nodes) or scale out (add more nodes). * Redis * There is no recommended setting, choose a threshold based off your application * Only scale out (add read replicas) ### Concurrent connections * Memcached and Redis * There is no recommended setting * If there is a spike in number of concurrent connections, this can either mean a large traffic spike or your application is not releasing connections as it should be. # Redshift Amazon Redshift is a fast and powerful, fully-managed, petabyte-scale data warehouse service. ### Redshift can be configured as follows * Single node * Multi-node * Leader node - manages client connections and receives queries * Compute node - store data and perform queries and computations. Can create up to 128 compute nodes. ### Redshift advanced compression Columnar data stores can be compressed much more than row-based data stores because similar data is stored sequentially on disk. Amazon Redshift employs multiple compression techniques and can often achieve significant compression relative to traditional relational data stores. In addition, Amazon Redshift does not require indexes or materialized views, and so uses less space than traditional RDS. When loading data into an empty table, Amazon Redshift automatically samples data and selects the most appropriate compression scheme. ### Massively Parallel Processing (MPP) Amazon Redshift automatically distributes data and query load across all nodes. Redshift makes it easy to add nodes to your data warehouse and enables you to maintain fast query performance as your data warehouse grows. ### Backups * Enabled by default, with 1 day retention period. * Maximum retention period is 35 days. * Redshift always attempts to maintain at least 3 copies of your data (the original and replica on the compute nodes and a backup in S3). * Redshift can also asynchronously replicate your snapshots to S3 in another region for disaster recovery. ### Encryption * Encrypted in transit using SSL * Encrypted at rest using AES-256 * By default Redshift takes care of key management, but KMS or CloudHSM keys can be used to. ### Availability * Currently only available in 1 AZ * Can restore snapshots to new AZ in the event of an outage. # EBS Elastic Block Store {% hint style="info" %} IOPS - Input / output Operations per Second * TiB - Tibibyte ( $$2^{40}$$ bytes), 1TiB \~= 1.0995 TB * GiB - Gibibyte ( $$2^{30}$$ bytes), 1GiB \~= 1.074 GB {% endhint %} Amazon EBS provides persistent block storage volumes for use with EC2 instances. Each EBS volume is automatically replicated within its AZ to protect from component failure, offering high availability and durability. ### Types * General purpose SSD * Provisioned IOPS SSD * Throughput optimized HDD * Cold HDD * Magnetic #### General purpose SSD General purpose SSD volume that balances price and performance for a wide variety of transaction workloads * Use case: most workloads * API name: gp2 * Size: 1GiB - 16 TiB * Max IOPS: 16000 #### Provisioned IOPS SSD High-performance SSD volume designed for mission-critical operations * Use case: databases * API name: io1 * Size: 4GiB - 16TiB * Max IOPS: 64000 #### Throughput-optimized HDD Low cost HDD volume designed for frequently accessed, throughput intensive workloads. * Use case: big data, data warehouse * API name: st1 * Size: 500GiB - 16TiB * Max IOPS: 500 #### Cold HDD Lowest cost HDD volume designed for less frequently accessed workloads. * Use case: file servers * API name: sc1 * Size: 500GiB - 16TiB * Max IOPS: 250 #### Magnetic Previous generation HDD * Use case: workloads where data is infrequently accessed * API name: Standard * Size: 1GiB - 1TiB * Max IOPS: 40-200 ### Volumes and Snapshots * Volumes exist on EBS. Snapshots exist on S3. * Snapshots are point-in-time copies of volumes. * Snapshots are incremental - this means that only the blocks that have changed are moved to S3. * If this is your first snapshot, it may take some time to create. * To create a snapshot for EBS volume that serve as a root device, you should stop the instance before taking a snapshot. However, you can take a snapshot while instance is running. * You can create AMIs from both volumes and snapshots. * You can change EBS volume sizes on the fly, including the size and storage type. * Volumes will always be in the same availability zone as EC2 instance it's attached to. * To move EC2 volume from one AZ to another, take a snapshot of it, create an AMI of the snapshot to launch the EC2 instance in another AZ. * To move and EC2 volume from one region to another, take a snapshot of it, create an AMI from the snapshot, and then copy AMI from one region to the other. Then use the copied AMI to launch the new EC2 instance in the new region. ### EBS encryption * Snapshots of encrypted volumes are encrypted automatically. * Volumes restored from encrypted snapshots are encrypted automatically. * You can share snapshots, but only if they are unencrypted. These snapshots can be shared with another AWS account or made public. * You can now encrypt root device volumes upon creation of the EC2 instance. ### EBS vs Instance Store Volumes All AMIs are categorized as either backed by EBS or backed by instance store. * For EBS volumes: the root device for an instance launched from the AMI is an Amazon EBS volume created from EBS snapshot. * For instance store volumes: the root device for an instance launched from the AMI is an instance store volume created from a template stored in S3.
* Instance store volumes are sometimes called ***Ephemeral Storage*** * Instance store volumes can not be stopped. If the underlying host fails, you will lose your data. * EBS backed instances can be stopped. You will not lose the data on this instance if it's stopped. * You can reboot both, you will not lose your data. * By default, both root volumes will be deleted on permination. However, with EBS volumes, you can tell AWS to keep root device volume. ### I/O credits * When your volume requires more than baseline performance I/O level, it simply uses I/O credits in the credit balance to burst to the required performance level, up to maximum of 3000 IOPS. * Each volume receives an initial I/O credit balance of 5,400,000 I/O credits. * This is enough to sustain the maximum burst performance of 3000 IOPS for 30 minutes. * When you're not going over your provisioned I/O level, you will be earning credits. ### Pre-warming EBS volumes New EBS volumes receive their maximum performance the moment they are available and do not require initialization (formerly known as pre-warming). However, storage blocks on volumes that were restored from snapshots must be initialized (pulled down from S3 and written to the volume). before you can access the block. This preliminary action takes time and can cause a significant increase in latency of an I/O operation the first time each block is accessed. For most applications, amortizing this cost over the lifetime of the volume is acceptable. Performance is restored after the data is accessed once. You can avoid this performance hit in the production environment by reading from all of the blocks on your volume before you use it; this process is called initialization. For a new volume created from snapshot, you should read all the blocks that have data before using the volume. ### Modifying EBS volumes If your EBS volume is attached to a current generation EC2 instance type, you can increase its size, change it's volume type or (for io1 volumes) adjust its IOPS performance, all without detaching it. You can apply those changes to detached volumes as well. * Issue the modification command (console or command line). * Monitor the progress of the modification. * If the size of the volume was modified, extend the volume's file system to take advantage of the increased storage capacity. # EFS Elastic File System Amazon EFS is a file storage service for EC2 instances. EFS is easy to use and provides simple interface that allows you to create and configure file systems quickly and easily. With EFS, storage capacity is elastic, growing and shrinking automatically as you add or remove files, so your applications have the storage they need, when they need it. * Supports the Network File System v4 protocol (NFSv4). * You only pay for the storage you use (no pre-provisioning required). * Can scale up to the petabytes. * Can support thousands of concurrent NFS connections. * Data is stored across multiple AZs within a region. * Read after write consistency. # FSx Amazon FSx for Windows File Server provides a fully managed native Microsoft Windows file system so you can easily move your Windows-based applications that require file storage to AWS. Amazon FSx is built on Windows Server. * Managed Windows Server that runs Windows Server Message Block (SMB)-based file services. * Designed for Windows and Windows applications. * Supports Active Directory users, access control lists, groups and security policies, along with Distributed File System (DFS) namespaces and replication. Amazon FSx for Lustre is a fully managed file system that is optimized for compute-intensive workloads, such as high-performance computing, machine learning, media data processing workflows, and electronic design automations (EDA). With Amazon FSx, you can launch and run a Lustre file system that can process massive data sets at up to hundreds of gigabytes per second of throughput, millions of IOPS, and submillisecond latencies. # Snowball ### Snowball * Snowball is a physical device used for transporting many terabytes or petabytes of data into and out of AWS * Makes large scale of data transfer fast, easy and secure * Comes in tamper-resistant enclosure * Uses 256-bit encryption * It's region specific, not for transporting data from one region to another ### When to use Snowball * When you have many TB or PB of data to upload * You don't want to make expensive upgrades to your network for a one-off data transfer * If you frequently experience data backlog If you're in a physically isolated environment, high-bandwidth internet is not available or is cost-prohibitive * If it takes more than a week to upload your data ### Snowball Edge * Each Snowball Edge is a 100TB device, which also features onboard compute power which can be clustered to act as a single storage and compute pool. * Designed to undertake local processing / edge computing, as well as data transfer. * S3 compatible endpoint, supports NFS, and can also run Lambda functions as data is copied to the device. * S3 buckets and Lambda functions come pre-configured on the device. # Athena * Athena is an interactive query service that enables you to analyse and query data located in S3 using standard SQL. * Serverless, nothing to provision, pay per query / per TB scanned. * No need to setup complex ETL processes. * Works directly with data stored on S3. ### Use cases * Can be used to query log files in S3, e.g. ELB logs, S3 access logs, etc. * Generate business reports on data stored in S3. * Analyse AWS cost and Usage reports. * Run queries on click-stream data. # Encryption and Downtime * For most resources, encryption can only be enabled at creation. * **EFS** - if you want to encrypt an EFS that is already exist, you'll need to create a new EFS and migrate your data. * **RDS** - if you want to encrypt existing RDS, you need to create new encrypted database and migrate your data. * **EBS** - encryption must be selected at creation time * you can not encrypt an unencrypted volume or unencrypt an encrypted volume. * you can migrate data between encrypted and unencrypted volumes (e.g. using `rsync` or `Robocopy`) * if you want to encrypt an existing volume, you can create a snapshot, copy the snapshot and apply encryption at the same time to give you an encrypted snapshot. Then restore the encrypted snapshot to a new encrypted volume. * **S3 buckets** - you can enable encryption on your buckets at any time. * **S3 objects** - you can enable individual S3 object encryption at any time. # Untitled # Security & Compliance # IAM Identity and Access Management * Consists of the following: * Users * Groups * Roles * Policies * IAM is universal, it does not apply to regions, works across all regions * Least privileges principle used: when new users, groups or roles are created, they don't get any permissions until explicitly granted ### IAM Policies * **AWS-managed policy** - an IAM policy which is created and administered by AWS. These AWS-provided policies allow you to assign appropriate permissions to your users, groups and roles without having to write the policy yourself. A single managed policy can be attached to multiple users, groups or roles within the same AWS account and across different accounts. You can not change the permissions defined in an AWS-managed policy. * **Customer-managed policy** - a standalone policy that you create and administer inside your own AWS account. You can attach this policy to multiple users, groups and roles - but only within your own account. * **Inline policy** - an IAM policy which is embedded within a single user, group or role to which it applies. There is a strict 1:1 relationship between the entity and the policy. When you delete the user, group or role in which the inline policy is embedded, the policy is also be deleted. #### MFA Reporting and IAM * You can enable MFA using the CLI and by using Console. * MFA can be enabled on both root account and user accounts. * You can enforce the use of MFA with the CLI by using the STS token service. * You can report on who's using the MFA on a per-user basis using the `Credentials Report` `aws iam create-virtual-mfa-device --virtual-mfa-device-name EC2-User --outfile /home/ec2-user/QRCode.png --bootstrap-method QRCodePNG aws iam enable-mfa-device --user-name EC2-User --serial-number arn:aws:iam::"USERNUMBERHERE":mfa/EC2-User --authentication-code-1 "CODE1HERE" --authentication-code-2 "CODE2HERE"` # Web Identity Federation * Federation allows users to authenticate with **Web Identity Provider** (Google, Facebook, etc). * The user authenticates first with Web ID Provider and receives a token, which is exchanged for temporary AWS credentials allowing them to assume IAM role
* **Cognito** is an **Identity Broker** which handles interaction between your applications and the Web ID Provider: * Provides sign up, sign in, and guest user access * Syncs user data for a seamless experience across your devices * Cognito is the AWS recommended approach for Web Identity Federation, particularly for mobile apps. * Cognito uses **User Pools** to manage user sign up and sign in directly or via Web ID Provider * Cognito acts as an Identity Broker, handling all interactions with Web ID Provider * Cognito uses push synchronization to send a silent push notification of user data updates to multiple device types associated with a user ID. **STS AssumeRoleWithWebIdentity** * Part of STS (Security Token Service) * Allows users who have authenticated with Web ID Provider to access AWS resources * Once the user has authenticated, the application makes the '`assume-role-with-web-identity`' API call. * If successful, STS will return temporary credentials enabling access to AWS resources * AssumedRoleUser ARN and AssumedRoleID are used to programmatically reference the temporary credentials - not an IAM role or user. * Mobile apps should use Cognito for federation instead of STS AssumeRoleWithWebIdentity # Organizations Organizations allow you to manage multiple AWS accounts at once. With Organizations, you can create groups of accounts and then apply policies to those groups. * **Control access** - with organizations you can create **Service Control Policies (SCPs)** that centrally control AWS service use across multiple AWS accounts. * **Automate AWS account creation** - you can use AWS Organizations APIs to automate the creation and management of new AWS accounts. The Organizations APIs enable you to create new accounts programmatically, and to add the new accounts to a group. The policies attached to the group are automatically applied to the new account. * **Consolidated billing** - AWS Organizations enables you to setup a single payment method for all the AWS accounts in your organization through consolidated billing. With consolidated billing you can see a combined view of charges incurred by all your accounts, as well as take advantage of pricing benefits from aggregated usage, such as volume discounts for EC2 and S3. # Service Catalog # Tags and Resource Groups * A tag is a label that you assign to a AWS resource, it consists of a key and a value, both of which you define. * You can use resource groups to organize your AWS resources. * Resource groups make it easier to manage and automate tasks on large number of resources at one time. # STS Security Token Service * Grants users limited and temporary access to AWS resources. Users can come from these sources: * Federation (typically Active Directory) * Uses Security Assertion Markup Language (SAML) * Grants temporary access based off the user Active Directory credentials * Does not need to be a user in IAM * Single sign on allows users to login to AWS console without assigning IAM credentials * Federation with mobile apps * Use Facebook / Google / Amazon or other OpenID providers to login. * Cross account access * Let's users from one AWS account access resources in another AWS account # KMS Key Management Service A managed service that enables you to easily encrypt your data. KMS provides a highly available key storage, management and auditing solution for you to encrypt data within your own applications and control the encryption of stored data across AWS services. ### Features * KMS is integrated with CloudTrail, which provides you the ability to audit who used which keys, on which resources and when. * Customer Master Keys (CMKs) are used to control access to data encryption keys that encrypt and decrypt your data. * You can choose KMS to automatically rotate master keys created with KMS once per year without the need to re-encrypt your data that has already been encrypted with your master key. * To help ensure that your keys and your data is highly available, KMS stores multiple copies of encrypted versions of your keys in systems that are designed for 11x9% durability. ### Concepts * **Customer Master Keys (CMKs)** - you can use CMKs to encrypt and decrypt up to 4Kb of data. Typically, you use CMKs to generate, encrypt, and decrypt the data keys that you use outside of KMS to encrypt your data. Master keys are 256 bits in length. * There are 3 types of CMKs: * **Customer-managed CMKs** are CMKs that you create, own and manage. You have full control over these CMKs, including establishing and maintaining their key policies, IAM policies and grants, enabling and disabling them, rotating their cryptographic material, adding tags, adding aliases that refer to the CMK, and scheduling the CMK deletion. * **AWS-managed CMKs** are CMKs in your account that are created, managed and used on your behalf by AWS services that integrate with KMS. You can view AWS-managed CMKs in your account, view their key policies, and audit their use in CloudTrail logs.However, you can not manage these CMKs, or change their permissions. And, you can not use AWS-managed CMKs in cryptographic operations directly, the service that creates them, uses them on your behalf. * **AWS-owned CMKs** are not in your account. They are part of collection of CMKs that AWS owns and manages for use in multiple AWS accounts. AWS services can use AWS-owned CMKs to protect your data. You can not view, manage or use AWS-owned CMKs or audit their use, | Type | Can view | Can manage | | -------------------- | -------- | ---------- | | Customer-managed CMK | Yes | Yes | | AWS-managed CMK | Yes | No | | AWS-owned CMK | No | No | * **Data keys** - encryption keys that you can use to encrypt data, including large amounts of data and other other data encryption keys. * You can use CMKs to generate, encrypt and decrypt data keys. However, KMS does not store, manage or track your data keys, or perform cryptographic operations with data keys. * Data keys can be generated at 128 bit or 256 bit length and encrypted under a master key you define. * **Envelope encryption** - the practice of encrypting plaintext data with a data key, and then encrypting the data key under another key. The top-level plaintext encryption key is known as master key. * **Encryption context** - all KMS cryptographic operations accept an encryption context, an optional set of key-value pairs that can contain additional contextual information about the data. * **Key policies** - when you create a CMK, permissions that determine who can use and manage that CMK are contained in a document called the key policy. * **Grants** - a grant is an alternative to policy. You can use grants to give long-term access that allow AWS principals to use your CMKs. * **Grant tokens** - when you create a grant, the permissions specified in the grant might not take effect immediately due to eventual consistency. If you need to mitigate the potential delay, use grant tokens instead. * When you enable **automatic rotation** for a customer-managed CMK, KMS generates new cryptographic material so it can be used to decrypt data that is encrypted. * An **alias** is an optional display name for a CMK. Each CMK can have multiple aliases, but each alias points to only one CMK. The alias name must be unique in AWS account and region. * KMS supports key stores backed by AWS **CloudHSM** clusters. A key store is a secure location for storing cryptographic keys. * You can connect directly to KMS through a private **VPC endpoint** in your VPC instead of connecting over the internet. When you use a VPC endpoint, communication between your VPC and KMS is conducted entirely within AWS network. ### Importing keys * A CMK contains a key material used to encrypt and decrypt data. When you create a CMK, by default, AWS generates the key material for that CMK. But you can create a CMK without a key material and then import your own key material into that CMK. * When you import key material, you can specify expiration date. When the key material expires, KMS deletes the key material and CMK becomes unusable. You can also delete key material on demand. ### Deleting keys * Deleting the CMK also deletes the key material and all metadata associated with CMK and it's irreversible. You can no longer decrypt the data that was encrypted under that CMK, which means the data becomes unrecoverable. * You can temporarily disable keys so they can not be used by anyone. ### Pricing * Each CMK that you create in KMS, regardless whether you use it with KMS-generated key material or key material imported by you, costs you until you delete them. * For a key material generated by KMS, if you opt-in to have CMK automatically rotated each year, each newly rotated version will raise the cost of the KMS per month. ### Limits | Description | Limit | | -------------- | ----- | | CMKs | 10000 | | Aliases | 10000 | | Grants per CMK | 10000 | # GuardDuty * It is a managed threat detection service * Continuously monitors multiple AWS accounts for malicious activity or unusual behavior * Detection types * Reconnaissance attacks - brute force, port scans, port probes, etc * Instance compromises - malicious communications, spambot activities, outbound SSH brute force attacks, EC2 credential exfiltration, etc * Account compromises - malicious API calls, disabled CloudTrail, password compromises * Simple dashboard view * CloudWatch event triggers, with further partner integrations: Splunk, CrowdStrike, SumoLogic, etc. * Behavioral anomalies * Monitors CloudTrail, VPC flow logs and more * Continually updated * Public Security intelligence feeds * Malicious IP addresses * Partner intelligence feeds * Machine learning models * Abnormal behavior # Compliance # Marketplace Security Products * Can purchase security products from third-party vendors on AWS Marketplace * Firewalls, hardened OS's, WAF's, Antivirus, Security Monitoring * Free, Hourly, Monthly, Annual, BYOL, etc. * CIS (Center of Internet Security) OS hardening # DDOS * A Distributed Denial Of Service (DDOS) attack is an attack that attempts to make your website or application unavailable to end users. This can be achieved by multiple mechanisms, such as large packet floods, by using a combination of reflection and amplification, or by using large botnets. How to mitigate DDOS * Minimize the attack surface area * Be ready to scale to absorb the attack * Safeguard exposed resources * Learn normal behavior * Create a plan for attack # Compliance Frameworks * **ISO/IEC 27001:2005** - specifies the requirements for establishing, implementing, operating, monitoring, reviewing, maintaining and improving a documented Information Security Management System within the context of the organization's overall business risks. * **FedRAMP** - The Federal Risk and Authorization Management Program, is a government-wide program that provides a standardized approach to security assessment, authorization and continuous monitoring for cloud products and services. * **HIPAA** - Federal Health Insurance Portability and Accountability Act of 1996. The primary goal of the law is to make it easier for people to keep health insurance, protect the confidentiality and security of healthcare information and help the healthcare industry control administrative costs. * **NIST** - National Institute of Standards and Technology - framework for improving critical infrastructure cybersecurity. A set of industry standards and best practices to help organizations manage cybersecurity risks. * **PCI DSS v3.2** - The Payment Card Industry Data Security Standard is a widely accepted set of policies and procedures intended to optimize the security of credit, debit, and cash card transactions and protect cardholders against misuse of their personal information. Requirements: * **1: Install and maintain a firewall configuration to protect cardholder data.** * **2: Do not use vendor supplied defaults for system passwords and other security parameters.** * **3: Protect cardholder data at rest.** * **4: Encrypt transmission of cardholder data across open, public networks.** * **5: Protect all systems against malware and regularly update antivirus software or programs.** * **6: Develop and maintain secure systems and applications.** * **7: Restrict access to cardholder data by business need to know.** * **8: Identify and authenticate access to system components.** * **9: Restrict physical access to cardholder data.** * **10: Track and monitor all access to network resources and cardholder data.** * **11: Regularly test security systems and processes.** * **12: Maintain a policy that addresses information security for all personnel.** * Other frameworks: * **SAS70** - Statement on Auditing Standards No.70. * **SOC1** - Service Organization Controls - accounting standards. * **FISMA** - Federal Information Security Modernization Act. * **FIPS 140-2** - US Government computer security standard used to approve cryptographic modules. Rated from level 1 to Level 4, with 4 being the highest security. CloudHSM meets the Level 3 standard. # High Availability # Global Infrastructure The AWS Global Infrastructure builds around **Regions** and **Availability Zones**. So far, there are: * 65 availability zones * 22 geographic regions * 1 local region ### Regions Regions provide physically separated availability zones, which are connected with low latency, high throughput, and highly redundant networking. ### Availability Zones Availability Zones offer high availability, fault tolerance and scalability. * Consists of one or more discrete data centers, each with redundant power, networking and connectivity, housed in separate facilities. * An availability zone is represented by a region code followed by a letter identifier, for example - `us-east-1a` * Local region is a single data center designated to compliment an existing AWS region * Edge locations are locations where end users access services located at AWS. # Disaster recovery * **RTO - Recovery Time Objective** - is the time it takes after the disruption to restore a business process to its service level. * **RPO - Recovery Point Objective** - is the acceptable amount of data loss measured in time before the disaster occurs. ### Disaster recovery strategies * **Backup and restore** - storing backup data on S3 and recover data quickly and reliably. * **Pilot light** - for quick recovery into AWS - quicker recovery times than backup and restore, because core pieces of the system are already running and are continually kept up-to-date * **Warm standby** - a scaled-down version of a fully functional environment is always running in the cloud. * **Multi-site** - run your infrastructure on another site, in an active-active configuration. # Elastic Load Balancers ELB AWS supports 3 types of load balancers: * Application load balancer (ALB) * Network load balancer (NLB) * Classic load balancer (CLB) Tips: * Instances monitored by ELB are reported as: InService or OutOfService * Health checks check the instance health by talking to it * Load balancers have their own DNS names, you are never given an IP address. #### ALB Application load balancers are best suited for load balancing of HTTP(S) traffic. They operate at Level 7 and are application aware. They are intelligent and you can create advanced request routing, sending specific requests to specific web services. #### NLB Network load balancers are best suited for load balancing of TCP traffic where extreme performance is required. Operating at the connection level (OSI Level 4), NLB are capable of handling millions of requests per second, while maintaining ultra-low latencies. #### CLB Classic load balancers are the legacy ELB. You can load balance HTTP(S) applications and use Level 7 specific features, such as X-Forwarded and sticky sessions. You can also use strict Level 4 load balancing for applications that rely purely on the TCP protocol. If your application stops responding, CLB responds with HTTP 504 error. This means that application is having issues. ### Sticky sessions CLB routes each request independently to the registered EC2 instance with the smallest load. Sticky sessions allow you to bind a user session to a specific EC2 instance. This ensures that all requests from the user during the session are sent to the same instance. You can enable sticky sessions for ALB as well, but the traffic will be sent at the target group level. ### Cross-zone load balancing With cross-zone load balancing each load balancer node for your CLB distributes requests eventy across the registered instances in all enabled AZs. If cross-zone load balancing is disabled, each load balancer node distributes requests evenly across the registered instances in its AZ only. CLB has cross-zone load balancing off by default, ALB cross-zone load balancing is always on. ### Path patterns You can create a listener with rules to forward requests based on the URL path. This is known as path-based routing. If you are running microservices, you can route traffic to multiple backend services using path-based routing. For example, you can route general requests to one target group and requests to render images to another target group. ## Pre-warming your ELB Are you expecting a large spike in traffic for an event? Get in touch with Amazon and have them pre-warm your load balancers. ELBs scale best with a gradual increase in traffic load. They do not respond well to spiky loads, and can break if too much flash traffic is directed their way. This is covered under the ELB best practices, and can be critical to having your event traffic handled gracefully, or being left wondering what just happened to your application stack when there is a sudden drop in traffic. Key pieces of information to relay to Amazon when contacting them are the total number of expected requests, and the average request response size. One other key piece of information has to do with operating at scale. If you are terminating your SSL on the ELB, and the HTTPS request response size is small, be sure to stress that point with Amazon support. Small request responses coupled with SSL termination on the ELB may result in overloading the ELBs, even though Amazon will have scaled them to meet your anticipated demand. AWS will need to know: * start and end dates * expected request rate per second * total size of a typical request ## Monitoring Four different ways to monitor your load balancers: * CloudWatch metrics * Access Logs * Request Tracing * CloudTrai Logs ### CloudWatch metrics ELB publishes data points to CloudWatch for your load balancers and your targets. CloudWatch enables you to retrieve statistics about those data points as an ordered set of time series data. #### ELB CloudWatch Metrics #### Overall health * **BackendConnectionErrors** - number of unsuccessful connections to backend instances * **HealthyHostCount** - number of healthy instances registered * **UnHealthHostCount** - number of unhealthy instances * **HttpCode\_Backend\_2XX,3XX,4XX,5XX** #### Performance * **Latency** - number of seconds taken for registered instance to respond / connect * **RequestCount** - number of requests completed / connections made during the specified interval (1 or 5 minutes) * **SurgeQueueLength** - number of pending requests, max 1024, additional requests will be rejected (Classic ELB only) * **SpilloverCount** - number of requests rejected because the surge queue is full (Classic ELB only) ### Access Logs ELB provide access logs that capture detailed information such as a time the request was received, the client's IP address, latencies, request paths, and server responses. You can use these access logs to analyze patterns and troubleshoot issues. Access logging is an optional feature of ELB that is disabled by default. After you enable access logging for your load balancer, ELB captures the logs and stores them in S3 bucket that you specify as compressed files. You can disable access logging at any time. Access logs can store data where the EC2 instance has been deleted. For example, you have a fleet of EC2 instances behind an autoscaling group. For some reason your application has loads of 5XX errors which is only reported by your end customers a couple of days after the event. If you aren't storing the web server logs anywhere persistent, it's still possible to trace these 5XX errors using access logs which would be stored in S3. ### Request Tracing You can use request tracing to track HTTP requests from clients to targets or other services. When the load balancer receives a request from a client, it adds or updates the `X-Amzn-Trace-Id` header before sending the request to the target. Any services or applications between the load balancer and the target can also add or update this header. Available for ALB only. ### CloudTrail You can use CloudTrail to capture detailed logs about the calls made to ELB API and store them as the log files in S3. # Untitled # Monitoring & Reporting ### CloudWatch vs CloudTrail vs Config? * CloudWatch - monitors performance * CloudTrail - monitors API calls in the AWS platform * Config - records the state of your AWS environment and can notify you of changes # Cost Explorer Cost Explorer is a tool that enables you to view and analyze your cost and usage. You can explore your usage and cost using main graph, cost and usage reports of the Cost Explorer reserved instance reports. You can view data for up to the last 13 months, forecast how much you're likely to spend for the next 3 months, and get recommendations for what reserved instances to purchase. You can use Cost Explorer to identify areas that need further inquiry and see trends that you can use to understand your costs. After you or AWS applies tags to your AWS resources and you activate the tags in the Billing and Cost Management Console, AWS generates a cost allocation report as a CSV with your usage and costs grouped by your active tags. You can apply tags that represent business categories (such as cost centers, app names, or owners) to organize your costs across multiple services. # CloudWatch AWS CloudWatch is a monitoring service to monitor your AWS resources, as well as the applications that run on your AWS. CloudWatch can be used on-premise - not restricted to just AWS resources. Just need to download and install the SSM agent and a CloudWatch agent. * EC2 Host level metrics: * CPU * Network * Disk utilization * Status check * Standard monitoring - 5 minutes * Detailed monitoring - 1 minute ### **What can I do with CloudWatch** * **Dashboards** - create dashboards to see what is happening with your AWS account * **Alarms** - allows you to set alarms that notify you when particular thresholds are hit * **Events** - helps you to respond to state changes in your AWS resources * **Logs** - helps you aggregate, monitor and store logs ### CloudWatch metrics storage duration * You can retrieve data using the GetMetricsStatistics API or by using third-party tools offered by AWS partners * You can store your data in CloudWatch Logs for as long as you want. By default, CloudWatch Logs will store your data indefinitely. You can change the retention for each Log Group at any time. * You can retrieve data from any terminated EC2 or ELB instance after its termination. ### Granularity * It depends on AWS service. Many default metrics for many default services are 1 minute, but it can be 3 or 5 minutes depending on the service. * For custom metrics, the minimum granularity that you can have is 1 minute. ### Alarms You can create an alarm to monitor any CloudWatch metric in your account. This can include EC2 CPU utilization, ELB latency or even the charges on your AWS bill. You can set the appropriate threshold in which to trigger the alarms and also set what actions should taken if an alarm state is reached. ### Dashboards Dashboards are customizable home pages in the CloudWatch console that you can use to monitor your resources in a single view, even those resources that are spread across different regions. You can use dashboards to create customized views of the metrics and alarms for your AWS resources.\ To add a widget, change to the region that you need, then add the widget to the dashboard. Remember to save. # Systems Manager Systems Manager is an AWS service that you can use to view and control your infrastructure on AWS. Using the Systems Manager console, you can view operational data from multiple AWS services and automate operational tasks across your AWS resources. * Integrates with CloudWatch allowing you view your dashboards, view operational data and detect problems. * Includes `Run Command` which automates operational tasks across resources - e.g. security patching, package installs, etc. * Allows you to run predefined commands on one or more EC2 instances. * Stop, restart, terminate, resize instances. * Attach / detach EBS volumes. * Create snapshots, backup DynamoDB. * Apply patches and updates * Run an Ansible playbook * Run a shell script * Organize your inventory, grouping resources together by application or environment - including on-premises systems. ### Systems Manager Parameter Store * Confidential information, such as passwords, database connection strings, and license codes can be stored in SSM Parameter Store. * You can store values as plain text or you can encrypt the data. * You can then reference these values by using their names. * You can use this service with EC2, CloudFormation, Lambda, EC2 Run Command, etc. # Config AWS Config is a fully managed service that provides you with an AWS resource inventory, configuration history and configuration notifications to enable security and governance. * Enables * compliance auditing * security analysis * resource tracking * Provides * configuration snapshots and log config changes of AWS resources * automated compliance checking ### Terminology * **Configuration Items** - point-in-time attributes of resources * **Configuration Snapshots** - collection of config items * **Configuration Stream** - stream of changed config items * **Configuration History** - collection of config items for a resource over time * **Configuration Recorder** - the configuration of config that reads and stores config items ### Recorder setup * logs config for account in region * stores in S3 * notifies SNS ### What can we see * Resource type * Resource ID * Compliance * Timeline * Configuration details * Relationships * Changes * CloudTrail events ### Compliance checks * Trigger * Periodic * Configuration snapshot delivery * Managed rules * About 40 (maybe more...) * Basic but fundamental # CloudTrail * Enables * After-the-fact incident investigation * Near realtime intrusion detection * Industry and regulatory compliance * Provides * Logs API call details (for supported services) * What is logged * Metadata around API call * The identity of the API caller * The time of the API call * The source IP address of the API caller * The request parameters * The response elements returned by the service * CloudTrail event logs: * Sent to an S3 bucket * You manage the retention in S3 * Delivered every 5 minutes with up 15 minutes delay * Notification available * Can be aggregated across regions * Can be aggregated across accounts * Validating CloudTrail log file integrity: * Was the log files modified or deleted? * CloudTrail log file integrity validation * SHA-256 hashing * SHA-256 hashing with RSA for digital signing * Log files are delivered with a 'digest' file (if enabled) * Digest file can be used to validate the integrity of the log files * Securing CloudTrail logs * Use IAM policies and S3 bucket policies to restrict access to the S3 bucket containing the log files. Place employees who have a security role, into IAM group with attached policies that enable access to the logs. * Use SSE-S3 or SSE-KMS to encrypt the logs * Configure SNS notifications and log file validation on the 'Trail'. Develop a solution that when triggered by SNS will validate the logs using the provided digest file. * Restrict delete access with IAM and bucket policies. Configure S3 MFA Delete. Validate that logs have not been deleted using the log file validation. * By default logs will be kept indefinitely. Use S3 object lifecycle management to remove the files after the required period of time, or move the files to AWS Glacier for more cost-effective long term storage. # Cost control * Why focus on cost? * Produce more rounded, cloud-ready designs * Who is responsible for cost control? * You * Business owners * Developers * Operations * Finance * Dealing with budget owners * Solution design * Separate one-off and monthly costs * Include non-AWS costs * Link to AWS calculator * Sign-off section * Include a clear bill of materials * Nothing is built without signed off design * Building solutions * Building to design and specification * 'Just in time' provisioning * Running solutions * Identifying cost savings * Gamification (cost-saving leaderboard) * KPIs * Incentives * Reviewing projects * New projects - week after launch, after 1 month * Ongoing projects - review every 3 months * Tagging resources * Tags - what are they? * Key / Value pairs * A way to identify and group resources * Maximum of 50 or 10 tags per resources * Character set and length limits * Some resources can not be tagged * Tagging standard scheme * Match your company, IT or project structure * Untagged resource policy * Document it and set a start date * Potential tags * 'Name' is a given * 'Purpose' - web, app, mobile, etc. * 'Project' - application, new app, etc * 'Creator' - name of a person or tool * 'Environment' - staging, test, UAT * 'Freetext' - anything at all * Leave rome for expansion * Set and get tags * Console * CLI * CloudFormation * SDKs * Bulk tag editing can be performed with 'Tag Editor' * Tag enforcement can be done with 'Tag Policies' * Resource Groups can be created with group AWS resources by the given set of tags # Untitled # Networking # Networking 101 ## DNS - Domain Name Service * **Top Level Domain** - .com, .edu. These top level domains are controlled by IANA (Internet Assigned Number Authority) in a root zone database. * **Registrar** - is an authority that can assign domain names directly under one or more top level domains. These domains are registered with InterNIC, a service of ICANN, which enforces uniqueness of domain names across the internet. Each domain name becomes registered in a central database known as WHOIS database. * **SOA - Start of Authority Record** - the SOA record stores information about: * The name of the server that supplies the data for the zone * The administrator of the zone * The current version of the data file * The default number of seconds for the TTL file on resource records. * **NS - Name Server Records**, they are used by Top Level Domain servers to direct traffic to the Content DNS server which contains the authoritative DNS records. * User -> TLD -> NS -> SOA * **A-Record** - an "A" record is a fundamental type of the DNS record. The "A" in the A-Record stands for "Address". The A-Record is used to translate the name of the domain to an IP address. * **TTL** - the length that a DNS record is cached on either the resolving server or the users own local PC is equal to the value of "Time To Live" in seconds. The lower the TTL, the faster changes to the DNS records take to propagate throughout the internet. * **CNAME** - Canonical Name - A CNAME can be used to resolve one domain name to another. * **Alias Record** - Alias records are used to map resource record sets in your hosted zone to ELB, CloudFront distributions, or S3 buckets that are configured as websites. Alias records work as CNAME record in the you can map one DNS record name to another "target" DNS name.\ Example: "demo.com" -> elb123.elb.aws.com\ Key difference: a CNAME can't be used for naked domain names (zone apex record). You can't have a CNAME for , it must be either an A-Record or an Alias record. ## CIDR - Classless Interdomain Routing CIDR is a notation for describing blocks of IP addresses and is used heavily in various networking configurations. IP addresses contain 4 octets, each consisting of 8 bits, giving values between 0 and 255. The decimal value that comes after the slash is the number of bits consisting of the routing prefix. This in turn can be translated into netmask, and also designates how many available addresses are in the block: * 10.0.1.0/28 => 00001010 00000000 00000001 0000\_\_\_\_ (4 empty bits) * netmask: 255.255.255.240 * first IP: 10.0.1.1 * last IP: 10.0.14 * available IPs: 16 ( $$2^4$$ ) # Route53 DNS server Route53 is a highly available and scalable DNS web service. ### Routing policies * Simple routing * Weighted routing * Latency-based routing * Failover routing * Geoproximity routing (traffic flow only) * Multivalue Answer routing #### Simple Routing If you choose the simple routing policy you can only have one record with multiple IP addresses. If you specify multiple values in a record, Route53 returns all values to the user in a random order. #### Weighted Routing Allows you to split your traffic based on different weights assigned. #### Latency Routing Allows you to route your traffic based on the lowest network latency for your end user (i.e. which region will give them the fastest response time). To use latency-based routing, you create a latency resource record set for the EC2 (or ELB) resource in each region that hosts your website. When Route53 receives a query for your site, it selects the latency resource record set for the region that gives the user the lowest latency. Route53 then responds with the value associated with that resource record set. #### Failover Routing Failover routing policies are used when you want to create an active/passive setup. For example, you may want your primary website to be in *eu-west-2* and your secondary website in *ap-southeast-2*. Route53 will monitor the health of your primary site using a health check (a healthcheck monitors the health of your endpoints). #### Geolocation Routing Geolocation routing policy lets you choose where your traffic will be sent based on the geographic location of your users (i.e. the location from which DNS queries originate). #### Geoproximity Routing Geoproximity routing lets Route53 route traffic to your resources based on the geographic location of your users and your resources. You can also optionally choose to route more traffic or less to a given resource by specifying a value, known as a bias. A bias expands or shrinks the size of the geographic region from which traffic is routed to a resource. To use groproximity routing, you must use Route53 traffic flow. #### Multivalue Answer Routing Multivalue answer routing lets you configure Route53 to return multiple values, such as IP addresses for your web server, in response to DNS queries. You can specify multiple values for almost any record, but multivalue answer routing also lets you check the health of each resource, so Route53 returns only values for healthy resources. This is similar to simple routing, however it allows you to put healthchecks on each record set. ### Limits With Route 53 there is a default limit of 50 domain names. However, this limit can be increased by contacting AWS support. # CloudFront CDN - Content Delivery Network CloudFront is a content delivery network. **A content delivery network (CDN)** is a system of distributed servers (network) that delivers web pages and other web content to a user based on a geographic location of the user, the origin of the webpage, and a content delivery server. CloudFront can be used to deliver your entire website, including dynamic, static, streaming and interactive content using the global network of edge locations. Requests for your content are automatically routed to the nearest edge location, so content is delivered with the best possible performance. One of the purposes of CloudFront is to reduce the number of requests that your origin server must respond to directly. This reduces the load on your origin server and also reduces the latency because more objects are served from CloudFront edge locations which are closer to your users. * **Edge location** - The location where content will be cached. This is separate to an AWS Region / Zone * **Origin** - This is the origin of all the files that the CDN will distribute. This can be either an S3 bucket, an EC2 instance, Elastic Load Balancer or Route53. * **Distribution** - This is a name given to the CDN which consists of collection of Edge locations * Web distribution - for websites * RTMP - for media streaming * Edge locations are not just for READ only operations - you can write to them to * Objects are cached for the life of TTL (Time To Live) * You can clear cached objects, but you will be charged ### Cache Hit Ratios The more request the CloudFront is able to serve from edge locations, the better it works. The ratio of requests served from edge locations (rather than the origin) is known as cache hit ratio. The more requests from edge location, the better the performance. You can view the percentage of viewer requests that are hits, misses and errors in the CloudFront console. ### Maximizing Cache Hit Ratio The following strategies can maximize your cache hit ratios: * **Specifying how long CloudFront caches your objects** - to increase your cache hit ratio, you can configure your origin to add a `Cache-Control=max-age` directive to your objects, and specify the longest practical `max-age`. The shorter the cache duration, the more frequently CloudFront forwards another request to your origin to determine whether the object has changed and, if so, to get the latest version. * **Caching based on query string parameters** * **Caching based on cookie values** - create separate cache behaviors for static and dynamic content, and configure CloudFront to forward cookies to your origin only for dynamic content. * **Caching based on request headers** - if you configure CloudFront to cache based on request headers, you can improve caching if you configure CloudFront to forward and cache based on only specific headers instead of forwarding and caching based on all headers. Also try to avoid caching based on headers that have large number of unique values. * **Remove `Accept-Encoding` header when compression is not needed** - by default, when CloudFront receives a request, it checks the value of the `Accept-Encoding` header. If the value of the header contains `gzip`, then CloudFront adds the header `Accept-Encoding: gzip` to the cache key and then forwards it to the origin. The behavior ensures that CloudFront serves either an object or a compressed version of the object, based on the value of the `Accept-Encoding` header. If compression is not enabled - because the origin does not support it, CloudFront doesn't support it, or the content is not compressible - you can increase the cache hit ratio by specifying different behavior. * **Serve media content by using HTTP** - you can use CloudFront to deliver on-demand video or live streaming video using any HTTP origin. One way you can setup video workflows in the cloud is by using CloudFront together with AWS Media Services. # VPC Virtual Private Cloud ![](https://486712189-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LyFJfu8WpLS6CqNwIrW%2F-M2ehgUfThx6vtmSZYdg%2F-M2ei5jNWdGZrji8xnIT%2Fnat-instance-diagram.png?alt=media\&token=2c44fecc-4337-4999-b243-751ab253dc9c) Amazon VPC lets you provision a logically isolated section of the AWS cloud, where you can launch AWS resources in a virtual network that you define. You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways. You can easily customize the network configuration for your VPC. For example, you can create a public facing subnet for your web servers, that has access to the internet, and place your backend systems, such as databases or application servers, in a private subnet with no internet access. You can leverage multiple layers of security, including security groups and network access control lists, to help control access to EC2 instances in each subnet. Additionally, you can create hardware VPN connection between your corporate datacenter and your VPC and leverage the AWS cloud as an extension of your corporate datacenter. ### VPC Features * Launch instances into subnet of your choosing * Assign custom IP address ranges in each subnet * Create Internet Gateway and attach it to your VPC * Much better security control over your AWS resources * Instance security groups * Subnet network access control lists (ACLs) ### VPC Peering * Allows you to connect one VPC with another via a direct network route using private IP addresses. * Instances behave as if they were on the same private network * You can peer VPCs with other AWS accounts as well as with other VPCs in the same account. * Peering is a star configuration: i.e. 1 central VPC peers with 4 others. ***No transitive peering.*** * You can peer between regions. ### VPC tips * Think of VPC as a logical datacenter in AWS. * Consists of IGWs (Internet Gateways or Virtual Private Gateways), Route Tables, Network ACLs, Subnets and Security Groups * 1 subnet = 1 availability zone * Security groups are stateful * Network ACLs are stateless * No transitive peering is allowed between VPCs. * When you create a VPC, a default Route Table, Network ACL and a default security group is created. No subnets or default Internet Gateway is created. * Amazon always reserves 5 IP addresses within your subnet. * You can only have 1 IGW per VPC. * 5 VPCs per region by default (can be increased). ## Network Access Translation (NAT) ### NAT instances You can use NAT instance in a public subnet in your VPC to enable instances in the private subnet to initiate outbound IPv4 traffic to the internet or other AWS services, but prevent the instances from receiving the inbound traffic initiated by someone on the internet. #### Tips * When creating a NAT instance, disable source/destination check on the instance. * NAT instances must be a public subnet. * There must be a route out of the private subnet to the NAT instance in order for this to work. * The amount of traffic the NAT instance can support depends on the instance size. * You can create high availability using Autoscaling Group., multiple subnets in different AZs, and a script to automate failover. * NAT instance is behind the security group. ### NAT Gateways Similar to NAT instances, but managed by AWS. NAT Gateways are recommended, instead of NAT instances. #### Tips * Redundant inside the Availability Group. * Preferred by the enterprise * Starts of 5Gb/s and scales currently up to 45Gb/s. * No maintenance (patching) needed. * Not associated with security groups. * Automatically assigned a public IP address. * No need to disable source/destination checks. * Remember to update your route tables. * If you have resources in multiple AZs and they share one NAT Gateway, in the event that NAT Gateway's AZ is down, resources in the other AZ lose internet access. To create an AZ-independent architecture, create a NAT Gateway in each AZ and configure your routing to ensure that resources use the NAT Gateway in the same AZ. ## Security Groups * All inbound traffic is blocked by default. Protocols / ports must be explicitly open. * All outbound traffic is allowed.. * Changes to the security group take effect immediately. * You can have any number of EC2 instances within a security group. * You can have multiple security groups attached to to EC2 instance. * Security groups are stateful. * If you create an inbound rule allowing traffic in, that traffic is automatically allowed back out. * You can not block a specific IP address using security group, instead use Access Control Lists. * You can specify "allow" rules, but not "deny" rules. ## Network Access Control Lists (NACLs) A network ACL is an optional layer of security for your VPC that acts as a firewall for controlling traffic in and out of one or more subnets. #### Tips * Your VPC automatically comes with default network ACL, and by default it allows all inbound and outbound traffic. * You can create custom network ACLs. By default each custom NACL denies all inbound and outbound traffic until you add rules. * Each subnet in your VPC must be associated with a NACL, the subnet is automatically associated with the default NACL. * Block IP addresses using NACL, not Security Groups. * You can associate NACL with multiple subnets; however a subnet can only be associated with one NACL at a time. When you associate a subnet with NACL, previous association is removed. * NACLs contain a numbered list of rules that are evaluated in order, starting with the lowest numbered rule. * NACLs have separate inbound and outbound rules, and each rule can either allow or deny traffic. * NACLs are stateless: responses to the allowed inbound traffic are subject to the rules for outbound traffic (and vice versa). ## VPC Flow Logs VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. Flow Logs data is stored using CloudWatch. After you created the Flow Log, you can view and retrieve its data in the CloudWatch Logs. Flow logs can be created at 3 levels: * VPC * Subnet * Network interface #### Tips * You can not enable flow logs for VPCs that are peered with your VPC unless the peer VPC is in your account. * You can not tag a flow log. * After you created a flow log, you can not change it's configuration; for example, you can not associate a different IAM role with the flow log. Not all traffic is monitored * Traffic generated by instances when they contact the AWS DNS server, If you use your own DNS server, than all traffic to that DNS server is logged. * Traffic generated by WIndows instance for Amazon Windows Activation not logged. * Traffic to and from 169.254.169.254 IP for instance metadata is not logged. * DHCP traffic is not logged. * Traffic to the reserved IP address for the default VPC router is not logged. ## Bastion Host A bastion host is a special purpose computer on a network specifically designed and configured to withstand attacks. The computer generally hosts a single application, for example, a proxy server, and all other services are removed or limited to reduce the threat to the computer. It's hardened in this manner primarily due to its location and purpose, which is either on the outside of a firewall on in a demilitarized zone (DMZ) and usually involves access from untrusted networks or computers. ## VPC Endpoint A VPC Endpoint enables you to privately connect your VPC to supported AWS services and VPC endpoint services powered by PrivateLink without requiring the Internet Gateway, NAT device, VPN connection or AWS DirectConnect connection. Instances in your VPC do not require public IP addresses to communicate with resources in the service. Traffic between your VPC and the other service does not leave the Amazon network. Endpoints are virtual devices. They are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in your VPC and services without imposing availability risks or bandwidth constraints on your network traffic. There are 2 types of VPC endpoints: * Interface endpoints * Gateway endpoints Interface endpoint is an elastic network interface with a private IP address that serves as an entry point for traffic destined to a supported service. Many AWS services are supported. Following gateway endpoints are supported: * S3 * DynamoDB # DirectConnect ## Direct Connect AWS Direct Connect is a cloud service solution that makes it easy to establish a dedicated network connection from your premises to AWS. Using AWS Direct Connect you can establish private connectivity between AWS and your datacenter, office, or colocation environment, which in many cases can reduce your network costs, increase bandwidth throughput and provide a more consistent network experience than internet-based connection. **BGP - Border Gateway Protocol** - is a standardized exterior gateway protocol designed to exchange routing and reachability information. It's used by AWS Direct Connect. ### Steps to setting up a Direct Connect * Create a virtual interface in the Direct Connect console. This a **PUBLIC Virtual Interface**. * Go to the VPC console and then to VPN connections. Create a customer gateway. * Create a Virtual Private Gateway. * Attach a Virtual Private Gateway to the desired VPC. * Select VPN Connections and create new VPN Connection. * Select the Virtual Private Gateway and the Customer Gateway. * Once the VPN is available, set up the VPN on the customer gateway firewall. {% embed url="" %} # WAF Web Application Firewall * AWS WAF is a web application firewall that lets you monitor the HTTP and HTTPS requests that are forwarded to CloudWatch or an ALB to to API Gateway. WAF also lets you control access to your content. * You can configure conditions such as what IP addresses are allowed to make this request or what query string parameters need to be passed for the request to be allowed, and then the ALB or CloudFront will either allow this content to be received or to give HTTP 403. * You can define conditions by using characteristics of web requests such as: * IP addresses that requests originate from * Country that requests originate from * Values in request headers * Strings that appear in requests, either specific strings or strings that match regular expressions * Length or requests * Presence of SQL code that is likely to be malicious * Presence of a script that is likely to be malicious (XSS attack) * At its most basic level, WAF allows 3 different behaviors: * Allow all requests except the ones that you specify * Block all requests except the ones that you specify * Count the requests that match the properties that you specify # Shield * Standard * Free service that protects all AWS customers on ELB, CloudFront or Route53. * Protects against SYN/UDP floods, reflection attacks, and other Layer 3 / Layer 4 attacks. * Advanced * Shield Advanced provides enhanced protection for your application running behind ELB, CloudFront or Route53 against larger and more sophisticated attacks. $3000 / month. * Always-on, flow-based monitoring of network traffic and active application monitoring to provide near real-time notifications of DDoS attacks. * DDoS Response Team (DRT) to manage and mitigate DDoS attacks. * Protects your AWS bill against higher fees due to ELB, CloudFront and Route53 usage spikes during DDoS. # Global Accelerator AWS Global Accelerator is a service in which you create accelerators to improve availability and performance of your applications for local and global users. Global Accelerator directs traffic to optimal endpoints over the AWS global network. This improves the availability and performance of your internet applications that are used by a global audience. By default, Global Accelerator provides you with 2 static IP addresses that you can associate with your accelerator, or you can bring your own. Includes following components: * **Static IP addresses** - Global Accelerator provides you with 2 IP addresses, or you can bring your own. * **Accelerator** - directs traffic to optimal endpoints over AWS global network to improve the availability and performance of your web applications. Each accelerator includes one or more listeners. * **DNS name** - Global Accelerator assigns each accelerator a default DNS name - similar to **abcdefg123455z.awsglobalaccelerator.com** - that points to the static IP addresses that Global Accelerator assigns to you. Depending on the use case, you can use your accelerator's static IP addresses or DNS name to route traffic to your accelerator, or setup DNS records to route traffic using your own custom domain name. * **Network Zone** - A network zone services the static IP addresses for your accelerator from a unique IP subnet. Similar to AWS Availability Zone, a network zone is an isolated unit with its own set of physical infrastructure. When you configure accelerator, by default, Global Accelerator allocates 2 IPv4 addresses for it. If one IP address from a network zone becomes unavailable due to IP address blocking by certain client networks, or network disruptions, client applications can retry on the healthy static IP address from the other isolated network zone. * **Listener** - A listener processes inbound connections from clients to Global Accelerator, based on the port (or port range) and protocol that you configure. Global Accelerator supports both TCP and UDP protocols. Each listener has one or more endpoint groups associated with it, and traffic is forwarded to endpoints in one of the groups. You associate endpoint groups with listeners by specifying the regions that you want to distribute traffic to. Traffic is distributed to optimal endpoints within the endpoint groups associated with endpoint listener. * **Endpoint Group** - Each endpont group is associated with AWS region. Endpoint groups include one or more endpoints in a region. You can increase or reduce the percentage of traffic that would be otherwise directed to an endpoint group by adjusting a setting called a traffic dial. The traffic dial lets you easily do performance testing or blue/green deployment testing for new releases across different AWS regions, for example. * **Endpoint** - Endpoints can be NLB, ALB, EC2 instances or Elastic IP addresses. An ALB endpoint can be an internet-facing or internal. Traffic is routed to endpoints based on configuration options that you choose, such as endpoint weights. For each endpoint, you can configure weights, which a numbers that you can use to specify the proportion of traffic to route to each one. This can be useful, for example, to do performance testing within a region. # Deployment & Provisioning # Untitled # Untitled # Automation & Optimization # CloudFormation * CloudFormation is a service that allows you to manage, configure and provision your AWS infrastructure as a code (IaaC). * Resources are defined using a CloudFormation template. * CloudFormation interpretes and makes the appropriate API calls to create the resources you have defined. * Supports YAML or JSON. ### Benefits * Infrastructure provisioned consistently, with fewer mistakes * Less time and effort than configuring things manually * You can version control and peer review your templates * Free to use (charged only for what you create) * Can be used to manage updates and dependencies * Can be used to rollback and delete the entire stack ### Template * YAML or JSON used to describe the end state of the infrastructure you are either provisioning or changing * After creating the template, you upload it to CloudFormation using S3 * CloudFormation reads the template and makes the API calls on your behalf * The resulting resources are called a Stack * `Resources` is the only mandatory section of the CloudFormation template * `Transform` section is used to reference additional code stored in S3, allowing for code reuse * All keys in the template file are CASE SENSITIVE, if there is a mistake in the template stack creation/update will fail. ```yaml AWSTemplateFormatVersion: 2010-09-09 Description: | Parameters: Metadata: Mappings: Conditions: Resources: # required Transform: Outputs: ``` ### [Resources](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html) * Resources are key components of the stack * Resources section is a required section that need to be defined in CloudFormation template ```yaml Resources: LogicalID: Type: Resource type Properties: Set of properties ``` ### [Intrinsic Functions](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference.html) **Important:** You can't nest short form functions consecutively. Invalid: ```yaml AvailabilityZone: !Select - 0 - !GetAZs !Ref 'AWS::Region' ``` Valid: ```yaml AvailabilityZone: !Select - 0 - Fn::GetAZs: !Ref 'AWS::Region' ``` * [**Ref**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-ref.html) - The intrinsic function Ref returns the value of the specified parameter or resource. * [**Fn::FindInMap**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-findinmap.html) - returns the value corresponding to keys in a two-level map that is declared in the Mappings section. ```yaml Mappings: RegionMap: us-east-1: HVM64: "ami-0ff8a91507f77f867" HVMG2: "ami-0a584ac55a7631c0c" us-west-1: HVM64: "ami-0bdb828fd58c52235" HVMG2: "ami-066ee5fd4a9ef77f1" eu-west-1: HVM64: "ami-047bb4163c506cd98" HVMG2: "ami-31c2f645" ap-southeast-1: HVM64: "ami-08569b978cc4dfa10" HVMG2: "ami-0be9df32ae9f92309" ap-northeast-1: HVM64: "ami-06cd52961ce9f0d85" HVMG2: "ami-053cdd503598e4a9d" Resources: myEC2Instance: Type: "AWS::EC2::Instance" Properties: ImageId: !FindInMap - RegionMap - !Ref 'AWS::Region' - HVM64 InstanceType: m1.small ``` * [**Fn::Select**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-select.html) - returns a single object from a list of objects by index. ```yaml Parameters: DbSubnetIpBlocks: Description: "Comma-delimited list of three CIDR blocks" Type: CommaDelimitedList Default: "10.0.48.0/24, 10.0.112.0/24, 10.0.176.0/24" Subnet0: Type: "AWS::EC2::Subnet" Properties: VpcId: !Ref VPC CidrBlock: !Select [ 0, !Ref DbSubnetIpBlocks ] ``` * [**Fn::GetAtt**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-getatt.html) - returns the value of an attribute from a resource in the template. To find what properties a specific resource can return with `Fn::GetAtt`, refer to that Resource documentation (for instance, [EC2 Instance Return Values](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-instance.html)) ```yaml !GetAtt myELB.DNSName ``` * [**Fn::ImportValue**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-importvalue.html) - The intrinsic function Fn::ImportValue returns the value of an output exported by another stack. You typically use this function to create cross-stack references. ```yaml Fn::ImportValue: !Sub "${NetworkStackName}-SecurityGroupID" ``` * [**Fn::Sub**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-sub.html) - substitutes variables in an input string with values that you specify. In your templates, you can use this function to construct commands or outputs that include values that aren't available until you create or update a stack. ```yaml !Sub 'arn:aws:ec2:${AWS::Region}:${AWS::AccountId}:vpc/${vpc}' ``` * [**Fn::Join**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-join.html) - appends a set of values into a single value, separated by the specified delimiter. If a delimiter is the empty string, the set of values are concatenated with no delimiter. ```yaml !Join - '' - - 'arn:' - !Ref AWS::Partition - ':s3:::elasticbeanstalk-*-' - !Ref 'AWS::AccountId' ``` * [**Fn::Split**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-split.html) - To split a string into a list of string values so that you can select an element from the resulting string list, use the Fn::Split intrinsic function. Specify the location of splits with a delimiter, such as , (a comma). After you split a string, use the Fn::Select function to pick a specific element. ```yaml !Select [2, !Split [",", !ImportValue AccountSubnetIDs]] ``` * [**Fn::Base64**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-base64.html) - returns the Base64 representation of the input string. This function is typically used to pass encoded data to Amazon EC2 instances by way of the UserData property. ```yaml Resources: SimpleEC2Instance: Type: "AWS::EC2::Instance" Properties: ImageId: ami-0d6621c01e8c2de2c InstanceType: t3.nano KeyName: test-cfn-kp SecurityGroups: - default UserData: !Base64 | #!/bin/bash yum update -y amazon-linux-extras install -y lamp-mariadb10.2-php7.2 php7.2 yum install -y httpd mariadb-server systemctl start httpd systemctl enable httpd usermod -a -G apache ec2-user chown -R ec2-user:apache /var/www chmod 2775 /var/www find /var/www -type d -exec chmod 2775 {} \; find /var/www -type f -exec chmod 0664 {} \; echo "" > /var/www/html/phpinfo.php Tags: - Key: Name Value: SimpleEC2 ``` * [**Fn::GetAZs**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-getavailabilityzones.html) - returns an array that lists Availability Zones for a specified region. Because customers have access to different Availability Zones, the intrinsic function Fn::GetAZs enables template authors to write templates that adapt to the calling user's access. That way you don't have to hard-code a full list of Availability Zones for a specified region. ```yaml AvailabilityZone: !Select - 0 - Fn::GetAZs: !Ref 'AWS::Region' ``` * [**Fn::Cidr**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-cidr.html) - returns an array of CIDR address blocks. The number of CIDR blocks returned is dependent on the count parameter. ```yaml !Cidr [ "192.168.0.0/24", 6, 5 ] ``` * [**Fn::Transform**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-transform.html) - specifies a macro to perform custom processing on part of a stack template. Macros enable you to perform custom processing on templates, from simple actions like find-and-replace operations to extensive transformations of entire templates. #### [Condition Intrinsic Functions](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html) * [**Fn::Equals**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html#intrinsic-function-reference-conditions-equals) - Compares if two values are equal. Returns true if the two values are equal or false if they aren't. * [**Fn::If**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html#intrinsic-function-reference-conditions-if) - Returns one value if the specified condition evaluates to true and another value if the specified condition evaluates to false. * [**Fn::And**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html#intrinsic-function-reference-conditions-and) - Returns true if all the specified conditions evaluate to true, or returns false if any one of the conditions evaluates to false. Fn::And acts as an AND operator. The minimum number of conditions that you can include is 2, and the maximum is 10. * [**Fn::Not**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html#intrinsic-function-reference-conditions-not) - Returns true for a condition that evaluates to false or returns false for a condition that evaluates to true. Fn::Not acts as a NOT operator. * [**Fn::Or**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html#intrinsic-function-reference-conditions-or) - Returns true if any one of the specified conditions evaluate to true, or returns false if all of the conditions evaluates to false. Fn::Or acts as an OR operator. The minimum number of conditions that you can include is 2, and the maximum is 10. ### [Pseudo Parameters](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/pseudo-parameter-reference.html) Pseudo parameters are parameters that are predefined by AWS CloudFormation. You do not declare them in your template. Use them the same way as you would a parameter, as the argument for the Ref function. * **AWS::AccountId** - Current account ID * **AWS::NotificationARNs** - List of notification ARNs for current stack * **AWS::NoValue** - Removes resource property. Used with Fn::If * **AWS::Partition** - Partition that the resource is in * **AWS::Region** - Current region * **AWS::StackId** - Current stack ID * **AWS::StackName** - Current name of the stack * **AWS::URLSuffix** - Suffix for a domain, typically `amazonaws.com` ### [Parameters](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) * Enable us to input custom values to our template each time when we create or update the stack * There can be maximum of 60 parameters in the template * Each parameter must be given a logical name (logical ID), which must be alphanumeric and unique among all logical names within the template * Each parameter must be assigned a parameter type that is supported by AWS CloudFormation * Each parameter must be assigned a value at runtime for AWS CloudFormation to successfully provision the stack. We can optionally specify a default value to use unless another value is provided * Parameters must be declared and referenced from within the same template. You can reference parameters from the Resources and Outputs sections of the template * Parameter type can one of the supported built-in types, like String, List, etc, or AWS-specific parameters, like `AWS::EC2::KeyPair::KeyName` or parameters that are linked to SSM Parameter Store (`AWS::SSM::Parameter::Value`) ```yaml Parameters: ParameterLogicalID: Type: DataType ParameterProperty: value ``` ### [Mappings](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/mappings-section-structure.html) * The optional Mappings section matches a key to a corresponding set of named values. For example, if you want to set values based on a region, you can create a mapping that uses the region name as a key and contains the values you want to specify for each specific region. You use the `Fn::FindInMap` intrinsic function to retrieve values in a map. ```yaml Mappings: Mapping01: Key01: Name: Value01 Key02: Name: Value02 Key03: Name: Value03 ``` ### [Conditions](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/conditions-section-structure.html) * The optional Conditions section contains statements that define the circumstances under which entities are created or configured. For example, you can create a condition and then associate it with a resource or output so that AWS CloudFormation only creates the resource or output if the condition is true. Similarly, you can associate the condition with a property so that AWS CloudFormation only sets the property to a specific value if the condition is true. If the condition is false, AWS CloudFormation sets the property to a different value that you specify. ```yaml Conditions: Logical ID: Intrinsic function ``` * Conditions are evaluated based on predefined pseudo parameters or input parameter values that we specify when we create or update stack * Within each condition we can reference other condition * We can associate these conditions in three places * Resources * Resource properties * Outputs * At stack creation or stack update, CloudFormation evaluates all condifitions in our template. During stack update, Resources that are now associated with a false condition are deleted. * **Note:** During stack update we can't update conditions by themselves. We can update conditions only when we include changes that add, modify or delete resources. ### [Outputs](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/outputs-section-structure.html) * Output section declares output values that we can * Import into another stack (to create cross-stack references) * When using nested stacks, we can see how outputs of a nested stack are used in Root Stack * We can view outputs in the CloudFormation console * We can declare maximum of 60outputs in a template ```yaml Outputs: Logical ID: Description: Information about the value Value: Value to return Export: Name: Value to export ``` * Export (optional property) * Export contain resource output used for cross-stack reference * For each AWS account, Export name must be unique within the region. As it should be unique, we create the export name as `"AWS::StackName"-ExportName` * We can't create cross-stack references across regions * We can use the intrinsic function `Fn::ImportValue` to import values that have been exported within the same region * For outputs, the value of the `Name` property of an `Export` can't use `Ref` of `GetAtt` function that depend on a resource * We can't delete a stack if another stack references one of it's outputs * We can't modify of remove an output value that is referenced by another stack * We can use Outputs in combination with Conditions. ### [Metadata](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/metadata-section-structure.html) * You can use the optional Metadata section to include arbitrary JSON or YAML objects that provide details about the template. For example, you can include template implementation details about specific resources. During a stack update, you cannot update the Metadata section by itself. You can update it only when you include changes that add, modify, or delete resources. * `AWS::CloudFormation::Init` - Defines configuration tasks for the cfn-init helper script. This script is useful for configuring and installing applications on EC2 instances. * `AWS::CloudFormation::Interface` - Defines the grouping and ordering of input parameters when they are displayed in the AWS CloudFormation console. By default, the AWS CloudFormation console alphabetically sorts parameters by their logical ID. * `AWS::CloudFormation::Designer` - Describes how your resources are laid out in AWS CloudFormation Designer (Designer). Designer automatically adds this information when you use it to create and update templates. ### [Helper scripts](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-helper-scripts-reference.html) AWS CloudFormation provides the following Python helper scripts that you can use to install software and start services on an Amazon EC2 instance that you create as part of your stack: * [**cfn-init**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html): Use to retrieve and interpret resource metadata, install packages, create files, and start services. * [**cfn-signal**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-signal.html): Use to signal with a CreationPolicy or WaitCondition, so you can synchronize other resources in the stack when the prerequisite resource or application is ready. * [**cfn-get-metadata**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-get-metadata.html): Use to retrieve metadata for a resource or path to a specific key. * [**cfn-hup**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-hup.html): Use to check for updates to metadata and execute custom hooks when changes are detected. You call the scripts directly from your template. The scripts work in conjunction with resource metadata that's defined in the same template. The scripts run on the Amazon EC2 instance during the stack creation process. #### [AWS::CloudFormation::Init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-init.html) * Use the AWS::CloudFormation::Init type to include metadata on an Amazon EC2 instance for the cfn-init helper script. If your template calls the cfn-init script, the script looks for resource metadata rooted in the AWS::CloudFormation::Init metadata key. * The metadata is organized into config keys, which you can group into configsets. You can specify a configset when you call cfn-init in your template. If you don't specify a configset, cfn-init looks for a single config key named **config**. * The cfn-init helper script processes these configuration sections in the following order: packages, groups, users, sources, files, commands, and then services. If you require a different order, separate your sections into different config keys, and then use a configset that specifies the order in which the config keys should be processed. ```yaml Resources: MyInstance: Type: AWS::EC2::Instance Metadata: AWS::CloudFormation::Init: config: packages: : groups: : users: : sources: : files: : commands: : services: : Properties: : ``` # Links CloudFormation resources * **AWS CLI command reference** - * # Github resources CloudFormation-related Github resources ### Projects * **Former2** - * **Troposphere** - * **CFN Python Lint** - * **CFN Nag** - ### VS Code Extensions * **Serverless IDE VS Code** - * **CloudFormation YAML Snippets** - * **CloudFormation Extension** - * **CFN Lint Extension** - # YAML 101 ### Key/value pairs * YAML document consists of key/value pairs * Key/value pairs are separated by colon followed by space * Supports different data types * Integers * Floating-point numbers * Strings, enclosed with quotes if they have special symbols * Boolean * Binary * Dates, in ISO:8601 format * Null value ```yaml Name: Dave Age: 25 GPA: 4.2 Occupation: Engineer State: 'New Jersey' About: "I'm a software engineer" Score: null Male: true DateOfBirth: 1990-09-15T19:07:00 ``` ### Lists * YAML lists are indented with a dash * All items are on the same level * There are 2 types of writing arrays: * Block sequence - each entry indicated with a dash followed by a space * Flow sequence - all elements are on the same line, separated with commas and enclosed by \[]. ```yaml PeopleBlock: - John - Mike - Tom - Jake PeopleFlow: [John, Mike, Tom, Jake] ``` ### Dictionaries * A set of properties grouped under an item * Dictionaries contain key/value pairs ```yaml Dave: Age: 25 GPA: 4.2 Occupation: Engineer State: 'New Jersey' About: "I'm a software engineer" Score: null Male: true DateOfBirth: 1990-09-15T19:07:00 ``` ### Lists with Dictionaries ```yaml Personnel: - Dave: Age: 24 Occupation: Engineer State: CA - Mike: Age: 30 Occupation: Manager State: TX - John: Age: 40 Occupation: Designer State: WA ``` ### Lists with Dictionaries containing Lists ```yaml Personnel: - Dave: Age: 24 Occupation: Engineer State: CA Degrees: - Bachelor - Masters - PHD - Mike: Age: 30 Occupation: Manager State: TX Degrees: [Bachelor, Masters] - John: Age: 40 Occupation: Designer State: WA Degrees: - Masters ``` ### Pipes * Pipe notation is also referred as literal block * All new lines, indentation, extra spaces are preserved ```yaml Resource: Name: My resource Description: | This is a description, with new lines and | special symbols Prop: value ``` ### Greater than * Also referred as folded block * Renders the text as a single line * All new lines will be replaced with a single space * Blank lines are converted to a new line character ```yaml Resource: Name: My resource Description: > This is a description, with new lines and | special symbols Will render everything as a single line Prop: value ``` ### Comments * Comments are defined with '#' symbol ```yaml # resource definition Resource: Name: My resource ``` ### Anchor / merge * Allows to define and reference blocks * CloudFormation has very limited support for anchors ```yaml MyAnchor: &a Prop1: value1 Prop2: value2 AnotherPlace: <<: *a Prop3: value3 ``` # Videos ## AWS re:Invent 2019: \[REPEAT 1] Best practices for authoring AWS CloudFormation (DOP302-R1) {% embed url="" %} ### Authoring Best Practices * Parameters: Avoid hardcoding values, can add validation to users and improve UX with console grouping, labels, descriptions; keep secrets in SSM Parameter Store and Secrets Manager * Mappings: As a case statement, helps maintain a set of information for various environments * Conditions: Simple if/then statements (e.g. if dev do this, if prod do that) * Imports and exports, leverage cross-stack references or export/import values through SSM * Use !Sub over !Join * Leverage SSM Parameter Store for latest AMI instance IDs ### Testing & Deployment Best Practices * Run Lint in headless mode, prevent promoting templates with errors * Use [TaskCat](https://github.com/aws-quickstart/taskcat/tree/master/taskcat) to live-test infrastructure * Use ChangeSets to know what effect the change will have on the underlying resources before actually deploying it * Use StackSets to deploy across multiple accounts and regions * Use automated deployment pipelines to deploy infrastructure changes * Refactor large stacks with resource import * Detect and remediate drift ### StackSets best practices * Partially deploy your CloudFormation StackSet updates to reduce blast radius; great for sanity testing / releasing incrementally * Depending on your speed needs, consider setting a higher concurrent account limit * Use parameter overrides to define specific parameters in account-region pairs * Separate stacks by function and frequency of changes needed # OpsWorks # Untitled # Application Services # SQS Simple Queue Service Amazon SQS is a web service that gives you access to a message queue that can be used to store messages while waiting for a computer to process them. SQS is a distributed queue system that enables web service applications to quickly and reliably queue messages that one component in the application generates to be consumed by another component. A queue is a temporary repository for messages that are awaiting processing. Using SQS you can decouple the components of an application so they run independently, easing message management between components. Any component of a distributed application can store messages in a fail-safe queue. Messages can contain up to 256Kb of text in any format. Any component can later retrieve the messages programmatically using the Amazon SQS API. There are 2 types of queue: * standard * FIFO - first in, first out SQS offers standard as a default queue type. A standard queue lets you have a nearly-unlimited number of transactions per second. Standard queues guarantee that the message is delivered a least once. However, occasionally, more than one copy of a message might be delivered out of order. Standard queues provide best-effort ordering which ensures that messages are generally delivered in the same order as they are sent. FIFO queues complements the standard queue. The most important feature of this queue type are FIFO delivery and exactly once processing: the order in which the messages are sent and received is strictly preserved and a message is delivered once and remains available until a consumer processes and deletes it; duplicates are not introduced into the queue. FIFO queues also support message groups that allow multiple ordered message groups within a single queue. FIFO queues are limited to 300 transactions per seconds, but have all the capabilities of the standard queues. # SWF Simple Workflow Service Amazon SFW is a web service that makes it easy to coordinate work across distributed application components. SWF enables application components. SWF enables applications for a range of use cases, including media processing, web application backends, business process workflows, and analytics pipelines, to be designed as a coordination of tasks. Tasks represent invocations of various processing steps in an application which can be performed by executable code, web service calls, human actions and scripts. #### SWF Actors * **Workflow starters** - an application that can initiate (start) a workflow. * **Deciders** - control the flow of activity tasks in a workflow execution. If something has finished (or failed) in a workflow, a decider decides what to do next. * **Activity workers** - carry out the activity tasks. ### SQS vs SWF * SQS has a retention period of up to 14 days, with SWF workflow executions can last up to 1 year. * SWF represents a task-oriented API, whereas SQS offers a message-oriented API. * SWF ensures that a task is assigned only once and is never duplicated. With SQS, you need to handle duplicate messages. * SWF keeps track of all the tasks and events in an application. With SQS, you need to implement your own application-level tracking, especially if your application uses multiple queues. # SNS Simple Notification Service SNS is a web service that makes it easy to setup, operate and send notifications from the cloud. SNS benefits: * Instantaneous, push-based delivery (no polling) * Simple APIs and easy integration with applications * Flexible message delivery over multiple transport protocols * Inexpensive, pay-as-you-go model with no upfront costs. * Web-based. Management Console offers simplicity of a point-and-click interface. # Untitled # Serverless # Lambda AWS Lambda is a compute service where you can upload your code and create a Lambda function. AWS Lambda takes care of the provisioning and managing the servers that you use to run the code. You don't have to worry about operating systems, patching, scaling, etc. You can use Lambda in the following ways: * as an event-driven compute service where Lambda runs your code in response to events. These events could be changes in S3 or DynamoDB. * as a compute service that runs your code in response to HTTP requests using API Gateway or API calls made using AWS SDK. AWS Lambda natively supports Java, Go, PowerShell, NodeJS, C#, Python, Ruby and provides runtime API which allows you to use any additional language. Using Lambda with other services: * Services that Lambda reads from: * Kinesis * DynamoDB * SQS * Services that invoke Lambda synchronously: * ELB * Cognito * Lex * Alexa * API Gateway * CloudFront (Lambda\@Edge) * Kinesis Data Firehose * Step Functions * Services that invoke Lambda asynchronously: * S3 * SNS * SES * CloudFormation * CloudWatch Logs * CloudWatch Events * CodeCommit * Config * IoT events To improve performance, Lambda may choose to retain an instance of your function and reuse it to serve a subsequent request, rather that creating a new copy. Your code should not assume that this will always happen. Lambda code must be stateless. Keeping function stateless enables Lambda to rapidly launch as many copies of the function as needed. ### Limits Following limits apply per region and can be increased: | Description | Limit | | -------------------------- | ----- | | Concurrent executions | 1000 | | Function and layer storage | 75 Gb | Per function limits, can not be changed: | Description | Limit | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- | | Memory allocation | 128 Mb - 3008 Mb, 64 Mb increment | | Timeout | 900 seconds | | Environment variables | 4 Kb | | Resource-based policy | 20 Kb | | Layers | 5 | | Burst concurrency | 500 - 3000 | | Invocation frequency |
  • 10x concurrent limit, synchronous, all sources
  • 10x concurrent limit, asynchronous, non-AWS
  • unlimited, AWS sources
| | Payload |
  • 6 Mb, synchronous
  • 256 Kb, asynchronous
| | Deployment package |
  • 50 Mb, zipped, direct upload
  • 250 Mb, unzipped, including layers
  • 3 Mb, console editor
| | ENIs per VPC | 160 | | Test events | 10 | | /tmp storage | 512 Mb | | File descriptors | 1024 | | exec processes / threads | 1024 | ### Versioning and aliases * By default, there is only one version of the code, referred to as `$LATEST` * You can use versions to manage the deployment of your Lambda code. You can change the function code and settings only of the unpublished version of a function. When you publish a version, the code and most of the settings are locked. * You can create one or more aliases for your Lambda function. An alias is like a pointer to a specific Lambda function version. You can access the function version using the alias ARN. Each alias has unique ARN. An alias can only point to a function version, not to another alias. You can update the alias to point to a new version of the function. * An alias can be used to split traffic between two published versions of the function. ### Scalability and Availability * Lambda is designed to use replication and redundancy for both the service itself and for the Lambda functions it operates. * When you update the function, there will be a brief window of time, when requests could be served by either the old or the new version of your function. * Lambda is designed to run many instances of your functions in parallel. However, it has a default safety throttle for number of concurrent executions per account per region. * On exceeding the throttle limit, Lambda functions being invoked synchronously will return a throttling error (HTTP 429 error code). Lambda functions being invoked asynchronously can absorb reasonable bursts of traffic for approximately 15-30 minutes after which incoming events will be rejected and throttled. ### Error handling * On failure, Lambda functions being invoked synchronously will respond with an exception. Lambda functions being invoked asynchronously are retried at least 3 times. * On exceeding the retry policy for asynchronous invocations, you can configure a "dead letter queue" (DLQ) into which the event will be placed; in absence of a configured DLQ the event may be rejected. ### VPC access * You can configure a function to connect to private subnets in a VPC. Lambda creates an ENI (Elastic Network Interface) for each combination of security group and subnet in your function's VPC configuration in a process that can take some time. * Multiple functions connected to the same subnets share ENIs, so connecting additional functions is much quicker. * By default, Lambda runs in a secure VPC with access to AWS services and the internet. When you connect a function to VPC in your account, it does not have access to the internet, unless the VPC provides access. Monitoring * Lambda monitors functions on your behalf and sends metrics to CloudWatch. * The `AWS/Lambda` namespace includes the following metrics: * **Invocations** - measures the number of times a function is invoked in response to an event or API call. * **Errors** - measures the number of invocations that failed due to errors in the function. * **DeadLetterErrors** - incremented when Lambda is unable to write the failed event payload to your configured DLQ. * **Duration** - measures function execution time. * **Throttles** - measures the number of invocation attempts that were throttled due to invocation rates exceeding the concurrent limit. * **ConcurrentExecutions** - emitted as an aggregate for all functions in the account. Measures sum of concurrent executions for a given function at a given point in time. * **UnreservedConcurrentExecutions** - emitted as an aggregate metric for all functions in the account only. Represents the sum of the concurrency of the functions that don't have a custom concurrency limit specified. ### Compliance * Lambda is SOC, HIPAA, PCI and ISO compliant. ### Lambda\@Edge * Lets you run Lambda functions to customize content that CloudFront delivers, executing the functions in AWS locations closer to the viewer. The functions run in response to CloudFront events, without provisioning or managing servers. * You can use Lambda functions to change CloudFront responses at the following points: * After CloudFront receives a request from a viewer. * Before CloudFront forwards request to the origin. * After CloudFront receives the response from the origin. * Before CloudFront forwards the response to the viewer. ### Lambda with DynamoDB streams * DynamoDB is integrated with Lambda so that you can create triggers. With triggers you can react to data modifications in DynamoDB tables. * After you enable DynamoDB streams on a table, associate the DynamoDB table with Lambda function. Lambda polls the stream and invokes your Lambda function synchronously when it detects new stream records. * Configure the StreamSpecification you want for your DynamoDB streams: * StreamEnabled - whether or not stream is enabled. * StreamViewType - when an item in the table is modified, StreamViewType is determines what information is written to the stream for this table. Valid values for the StreamViewType are: * KEYS\_ONLY - only the key attributes of the modified items are written to the stream. * NEW\_IMAGE - the entire item, as it appears after it was modified, is written to the stream. * OLD\_IMAGE - the entire item, as it appears before it was modified, is written to the stream. * NEW\_AND\_OLD\_IMAGE - both the new and the old item images of the item are written to the stream. # API Gateway API Gateway is fully managed service that makes it easy for developers to publish, maintain, monitor and secure API at any scale. What API Gateway can do: * expose an HTTPS endpoint to define a RESTful API. * connect to services like DynamoDB and Lambda. * Send each API endpoint to a different target. * Scale and run efficiently with low cost. * Track and control use by API key. * Throttle requests to prevent attacks. * Maintain multiple versions of the API. ### Concepts * API deployment - a point-in-time snapshot of your API Gateway resources and methods. To be available to the clients to use, the deployment must be associated with one or more API stages. * API endpoint - hostnames APIs in API Gateway, which are deployed to a specific region, and of the format: `{rest-api-id}.execute-api.{region}.amazonaws.com` * API key - an alphanumeric string that API Gateway uses to identify app developer who uses your API. * API stage - a logical reference to a lifecycle state of your API. API stages are identified by API ID and stage name. * Model - data schema specifying the data structure of a request or response payload. * Private API - an API that is exposed through interface VPC endpoints and isolated from the public internet. * Private integration - an API Gateway integration type for a client to access resources inside a customer's VPC through a private VPC endpoint without exposing resources to the public internet. * Proxy integration - you can setup a proxy integration as an HTTP proxy integration type or a Lambda proxy integration type: * For HTTP proxy integration, API Gateway passes the entire request and response between frontend and HTTP backend. * For Lambda proxy integration, API gateway sends the entire request as an input to a backend Lambda function. * Usage plan - provides selected API clients with access to one or more deployed APIs. You can use usage plan to configure throttling and quota limits, which are enforced on individual client API keys. ### API endpoint types * **Edge optimized endpoint**: the default hostname of an API Gateway API that is deployed to the specified region while using a CloudFront distribution to facilitate client access typically from across AWS regions. API requests are routed to the nearest CloudFront Point of Presence. * **Regional endpoint:** the hostname of an API that is deployed to the specified region and intended to serve clients, such as EC2 instances, in the same AWS region. API requests are targeted directly to the region-specific API Gateway without going through the CloudFront distribution. You can apply latency-based routing on regional endpoints to deploy API to multiple regions using the same regional API endpoint configuration, set the same custom domain name for each deployed API and configure latency-based DNS records in Route53 to route client requests to the region that has the lowest latency. * **Private endpoint:** allows the client to securely access private API resources inside the VPC. Private APIs are isolated from the public internet, and they can only be accessed using VPC endpoints for API Gateway that have been granted access. ### Features * API Gateway can execute Lambda code in your account, start Step Function state machines, or make calls to Beanstalk, EC2 or web services outside AWS with publicly accessible HTTP endpoints. * API Gateway helps you define plans that meter and restrict third-party developer access to your API. * API Gateway helps you manage traffic to your backend systems by allowing you to set throttling rules based on the number of requests per second for each HTTP method in your APIs. * You can setup a cache with customizable keys and time-to-live (TTL) in seconds for your API data to avoid hitting your backend services for each request. * API Gateway lets you make multiple versions of the same API simultaneously with API Lifecycle. * After you build, test and deploy your APIs, you can package them in an API Gateway usage plan and sell the plan as SaaS product through AWS Marketplace. * API Gateway offers the ability to create, update and delete documentation associated with each portion of your API, such as methods and resources. * All of the APIs created expose HTTPS endpoints only. API Gateway does not support unencrypted HTTP endpoints. ### Monitoring * API Gateway is integrated with CloudWatch, so you get backend performance metrics, such as API calls, latency and error rates. * You can setup a custom alarm on API Gateway APIs. * API Gateway can also log API execution errors to CloudWatch Logs ### Security * To authorize and verify API requests to AWS services, API Gateway can help you leverage sigv4. Using sigv4 authentication, you can use IAM and access policies to authorize access to your APIs and all your other AWS resources. * You can enable WAF (Web Application Firewall) for your APIs in API Gateway, making it easier to protect your APIs against common web exploits. ### Pricing * You pay only for the API calls you receive and the amount of data transferred out. * API Gateway also provides optional data caching charged at an hourly rate that varies based on the cache size you select. ### Limits | Description | Limit | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | | Throttle limit, per account per region. With additional burst capacity provided by the token bucket algorithm, using a maximum bucket capacity of 5000 requests. Can be increased | 10000 requests/sec | | Maximum number of regional APIs per account per region | 600 | | Maximum number of private APIs per account per region | 600 | | Maximum number of Edge-Optimized APIs per account per region | 120 | | Maximum number of stages per API | 10 | | Header value size | 10 Kb | | Payload size | 10 Mb | # DynamoDB {% content-ref url="/pages/-M2UfGrEk9boMn5RaKJ\_" %} [DynamoDB](/cloud/aws/storage/dynamodb) {% endcontent-ref %} # SAM Serverless Application Model * An open source framework for building serverless applications. * It provides shorthand syntax to express functions, APIs, databases, and event source mappings. * You create JSON or YAML configuration template to model your application. * During deployment, SAM transforms and expands the SAM syntax into CloudFormation template. Any resource that you can declare in a CloudFormation template, you can also declare in a SAM template. * The SAM CLI provides Lambda-like execution environment that lets you locally build, test and debug applications defined by SAM templates. You can also use SAM CLI to deploy your applications to AWS. * You can use SAM to build serverless applications that use any runtime supported by AWS Lambda. You can also use SAM CLI to locally debug functions written in NodeJS, Java, Python and Go. ### Syntax * `AWS::Serverless::Api` * this resource type describes an API Gateway resource. It's useful for advanced use cases where you want full control and flexibility when you configure your APIs. * `AWS::Serverless::Application` * this resource type embeds a serverless application from AWS Serverless Application Repository or from an S3 bucket as a nested resource. Nested applications deployed as a nested stacks, which can contain multiple other resources. * `AWS::Serverless::Function` * this resource type describes configuration information for creating a Lambda function. You can describe any event source that you want to attach to the Lambda function - such as S3, DynamoDB Streams, and Kinesis Data Streams. * `AWS::Serverless::LayerVersion` * this resource type creates Lambda layer version that contain libraries or runtime code needed by a Lambda function. When a serverless layer version is transformed, SAM also transforms the logical ID of the resource so that old layer versions are not automatically deleted by CloudFormation when the resource is updated. * `AWS::Serverless::SimpleTable` * this resource type provide simple syntax for describing how to create DynamoDB tables. * The optional `Transform` section of a CloudFormation template specifies one or more macros that CloudFormation uses to process your template. Aside from macros you create, CloudFormation is also supports `AWS::Serverless` transform, which is a macro hosted on CloudFormation. The `AWS::Transform` specifies the version of SAM to use. This model defines the SAM syntax that you can use and how CloudFormation process it. ### Common CLI commands * `sam init` generates pre-configured SAM templates. * `sam local` supports local invocation and testing of your Lambda functions and SAM-based serverless applications by executing your function code locally in a Lambda-like execution environment. * `sam package` and `sam deploy` commands let you bundle your application code and dependencies into a deployment package and then deploy your serverless application to the AWS. * `sam logs` command enables you to fetch, tail and filter logs for Lambda functions. * The output of the `sam publish` command includes a link to the AWS Serverless Application Repository directly to your application. ### Controlling access to APIs * You can use SAM to control who can access your API Gateway APIs by enabling authorization within your SAM template. * **A Lambda authorizer** (formerly known as custom authorizer) is a Lambda function that you provide to control access to your API. When your API is called, this function is called with request context or an authorization token that are provided by the client application. The Lambda function returns a policy document that specify the operations that the caller is authorized to perform, if any. There are two types of authorizers: * Token based type receives the caller identity in a bearer token, such as JWT or OAuth. * Request parameter based type receives the caller identity in a combination of headers, query string parameters, stageVariables and $context variables. * **Cognito user pools** or user directories in Cognito. A client of your application must first sign a user in to the user pool and obtain an identity or access token for the user. Then your API is called with one of the returned tokens. The API call succeeds only if the required token is valid. ## Installation * Create account * Configure IAM permissions - requires a user with admin credentials and programmatic access * Install Docker * Install Homebrew * Install AWS SAM CLI AWS Jenkins plugin AWS Toolkit for JetBrains ## Setting up AWS Credentials * With AWS CLI `aws configure` command * Manually by editing `~/.aws/credentials file` `[default]` `aws_access_key_id = your_access_key_id` `aws_secret_access_key = your_secret_access_key` * Through environment variables `export AWS_ACCESS_KEY_ID=your_access_key_id` `export AWS_SECRET_ACCESS_KEY=your_secret_access_key` ### Getting started commands: Step 1 - Initializing application `sam init` Step 2 - Build your application `sam build` Step 3 - Deploy your application `sam deploy --guided` ### samconfig.toml This file contains all the information about where and how to deploy the app. Example: ```bash version = 0.1 [default] [default.deploy] [default.deploy.parameters] stack_name = "my-serverless-app" <-- Stack name in CloudFormation s3_bucket = "mybucket-serverless-deploy" <-- Target bucket, preferably with versioning enabled s3_prefix = "my-serverless-app" <-- Subfolder for deployed application region = "us-west-2" profile = "<< IAM profile with programmatic access and necessary permissions >>" confirm_changeset = true capabilities = "CAPABILITY_IAM" ``` ### Running SAM application locally ```bash sam local start-api -p 9500 --skip-pull-image --region=us-west-2 ``` This will start a service locally on port 9500, and will not check for latest Docker image (this will speed up invocations, but Lambda Docker image must be present on the machine it's running on). Service supports hot reload. Additional configuration can be found by running: `sam local start-api --help` ### Making One-off Invocations `sam local invoke "HelloWorldFunction" -e events/event.json` where "HelloWorldFunction" is the name of the function as it is defined in template.yaml "Resources" section. ### Generating sample events `sam local generate-event apigateway aws-proxy --body "" --path "hello" --method GET > api-event.json` You can use this command to generate sample payloads from different event sources such as S3, API Gateway, and SNS. These payloads contain the information that the event sources send to your Lambda functions. Generate the event that S3 sends to your Lambda function when a new object is uploaded `sam local generate-event s3 [put/delete]` You can even customize the event by adding parameter flags. To find which flags apply to your command, run: `sam local generate-event s3 [put/delete] --help` Then you can add in those flags that you wish to customize using `sam local generate-event s3 [put/delete] --bucket --key ` After you generate a sample event, you can use it to test your Lambda function locally `sam local generate-event s3 [put/delete] --bucket --key | sam local invoke ` Supported services: * alexa-skills-kit * alexa-smart-home * apigateway * batch * cloudformation * cloudfront * cloudwatch * codecommit * codepipeline * cognito * config * connect * dynamodb * kinesis * lex * rekognition * s3 * sagemaker * ses * sns * sqs * stepfunctions ### Deleting the deployment * from Console, delete the stack * using "`aws cloudformation delete-stack`" command ## AWS SAM Specification You use the AWS SAM specification to define your serverless application. AWS SAM templates are an extension of AWS CloudFormation templates, with some additional components that make them easier to work with. The primary differences between AWS SAM templates and AWS CloudFormation templates are the following: * **Transform declaration**. The declaration Transform: AWS::Serverless-2016-10-31 is required for AWS SAM templates. This declaration identifies an AWS CloudFormation template as an AWS SAM template. * **Globals section**. The Globals section is unique to AWS SAM. It defines properties that are common to all your serverless functions and APIs. All the AWS::Serverless::Function, AWS::Serverless::Api, and AWS::Serverless::SimpleTable resources inherit the properties that are defined in the Globals section * **Resources section**. In AWS SAM templates the Resources section can contain a combination of AWS CloudFormation resources and AWS SAM resources. Following are not specific to SAM: * **Description (optional)**. A text string that describes the template. * **Metadata (optional)**. Objects that provide additional information about the template. * **Parameters (optional)**. Values to pass to your template at runtime (when you create or update a stack). You can refer to parameters from the Resources and Outputs sections of the template. * **Mappings (optional)**. A mapping of keys and associated values that you can use to specify conditional parameter values, similar to a lookup table. You can match a key to a corresponding value by using the Fn::FindInMap intrinsic function in the Resources and Outputs sections. * **Conditions (optional)**. Conditions that control whether certain resources are created or whether certain resource properties are assigned a value during stack creation or update. For example, you could conditionally create a resource that depends on whether the stack is for a production or test environment. * **Outputs (optional)**. Describes the values that are returned whenever you view your stack's properties. For example, you can declare an output for an S3 bucket name, and then call the aws cloudformation describe-stacks AWS CLI command to view the name. ### Globals [Reference](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-template-anatomy-globals.html) Resources in an AWS SAM template tend to have shared configuration, such as Runtime, Memory, VPCConfig, Environment, and Cors. Instead of duplicating this information in every resource, you can write them once in the Globals section and let your resources inherit them. ```yaml Globals: Function: Runtime: nodejs6.10 Timeout: 180 Handler: index.handler Environment: Variables: TABLE_NAME: data-table ``` Supported resources and props: ```yaml Globals: Function: # Properties of AWS::Serverless::Function Handler: Runtime: CodeUri: DeadLetterQueue: Description: MemorySize: Timeout: VpcConfig: Environment: Tags: Tracing: KmsKeyArn: Layers: AutoPublishAlias: DeploymentPreference: PermissionsBoundary: ReservedConcurrentExecutions: Api: # Properties of AWS::Serverless::Api # Also works with Implicit APIs Auth: Name: DefinitionUri: CacheClusterEnabled: CacheClusterSize: Variables: EndpointConfiguration: MethodSettings: BinaryMediaTypes: MinimumCompressionSize: Cors: GatewayResponses: AccessLogSetting: CanarySetting: TracingEnabled: OpenApiVersion: SimpleTable: # Properties of AWS::Serverless::SimpleTable SSESpecification: ``` ### AWS::Serverless::Api [Reference](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-api.html) ```yaml Type: AWS::Serverless::Api Properties: AccessLogSetting: AccessLogSetting Auth: ApiAuth <-- SAM specific BinaryMediaTypes: List CacheClusterEnabled: Boolean CacheClusterSize: String CanarySetting: CanarySetting Cors: String | CorsConfiguration <-- SAM specific DefinitionBody: String DefinitionUri: String | ApiDefinition Domain: DomainConfiguration EndpointConfiguration: String GatewayResponses: Map MethodSettings: MethodSettings MinimumCompressionSize: Integer Models: Map Name: String OpenApiVersion: String StageName: String <-- Required in SAM Tags: Map TracingEnabled: Boolean Variables: Map ``` example ```yaml Resources: HelloWorldFunction: Type: AWS::Serverless::Function Properties: FunctionName: 'HelloWorldFunc' Description: 'This is a description for this function' CodeUri: hello-world/ Handler: app.lambdaHandler Runtime: nodejs12.x Events: HelloWorld: Type: Api Properties: Path: /hello Method: get RestApiId: !Ref ApiGateway ApiGateway: Type: AWS::Serverless::Api Description: 'gateway desc here' Properties: Name: demo-rest-api StageName: prod Cors: "'*'" ``` ### AWS::Serverless::Application [Reference](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-application.html) Embeds a serverless application from the AWS Serverless Application Repository or from an Amazon S3 bucket as a nested application. Nested applications are deployed as nested AWS::CloudFormation::Stack resources, which can contain multiple other resources including other AWS::Serverless::Application resources. ```yaml Type: AWS::Serverless::Application Properties: Location: String | ApplicationLocationObject NotificationARNs: List Parameters: Map Tags: Map TimeoutInMinutes: Integer ``` # Untitled # Well-Architected Framework * Well-architected framework is a set of principles. * These principles are documented as 5 pillars: * Operational Excellence * Security * Cost Optimization * Reliability * Performance Efficiency ### General Design Principles * **Stop guessing capacity needs** - scale up and down as required * **Automate everything** - automated systems ensure consistency and reliability. * **Test at scale** - test an accurate replica of production on-demand. * **Adapt and evolve** - adapt the architecture as needed to meet new challenges. * **Be data driven** - drive decisions through data. * **Game days** - practice, practice, practice. ### The Five Pillars * **Operational Excellence** * Does your architecture work? Will it continue to work? * There are six design principles for operational excellence in the cloud: * Perform operations as code * Annotate documentation * Make frequent, small, reversible changes * Refine operations procedures frequently * Anticipate failure * Learn from all operational failures (and success) * Prioritize to align with business priorities * What is the business goal? * What are the critical pieces needed to meet that goal? * Any compliance restrictions/requirements? * Dependencies between services? * Design your architecture to support business priorities * Is the design observable? * Is the entire design code? Can it be redeployed in even of a failure? * Are your logs and observations actionable? Can you derive values from data you're collecting? * Is your workload ready to go live * Are your processes consistent? * Is operational code properly managed? * Are tests in place? * Are you anticipating failure? * Ensure your workloads are actually working * Metrics indicate health of each service * Metrics show overall health * Are you monitoring business metrics too? * Responding to events * Anticipate planned and unplanned events * Respond in code * Connect observations with 3rd party tools as needed * Learn from success or failure * Post-event, have runbooks changed? * Are teams evaluating their processes? * Test assumptions * Experiment early and often to find better solutions * **Cost Optimization** * Spend only what you have to. Deliver business value for the lowest price point. * There are five design principles for cost optimization in the cloud: * Adopt a consumption model * Measure overall efficiency * Stop spending money on data center operations * Analyze and attribute expenditure * Use managed services to reduce cost of ownership * Use the appropriate resources and configurations * Provision for current needs with an eye to the future * "Right size" to lowest resource that meets the needs * Use data to choose purchase options * Optimize by geography * Default to managed services * Optimize data transfer * Matching supply and demand * Know how much you're spending and where * Understand your stakeholders * Implement a governance model * Attribute cost to teams/projects * Tag AWS resources * Track lifecycle of the resources * Continuously work to maximize value delivered * Align utilization with requirements * Report and validate findings * Evaluate new services for value * Continue push for managed services, if they're cost-effective * **Reliability** * There are five design principles for reliability in the cloud: * Test recovery procedures * Automatically recover from failure * Scale horizontally to increase aggregate system availability * Stop guessing capacity, reduce idle resources * Manage change in automation * Will this system work consistently and recover quickly * Recover from issues automatically * Scale horizontally first for resiliency * Reduce idle resources * Manage change through automation * Understand the default and requested limits * Are you planning beyond current limits for a resource? * Will you scale past specific resource limits? * Can those limits be lifted? * Can you plan around those limits? * Networking * IP address space management (are you considering IPv6) * Subnets structures * Resilient topologies * Ability to handle sudden increase in traffic * Provide consistent performance regardless (latency) * Ensure your application is ready for business use * Can users access your application? * Deploy without an issue * Can you push issue to a planned downtime? * Can your application withstand partial outages? * **Performance Efficiency** * There are five design principles for performance efficiency in the cloud: * Democratize advanced technologies * Go global in minutes * Use serverless architectures * Experiment more often * Mechanical sympathy * Remove bottlenecks, reduce waste * Let AWS do the work whenever possible * Reduce latency through regions and AWS Edge * Serverless whenever possible, then containers, only then fall down to instances * Experiment as new services are released * Think about the user, not your tech stack * Is this the optimal solution for this workload * What type of compute best suits? * Which data store is ideal for this workload? * Does your network design complement compute and data store choices? * Continuously ensure choices work for your workloads * Is infrastructure stored as code? * Are deployments simple and automated? * Can benchmarks be taken automatically? * Does load testing interfere with production? * Monitoring * Use active and passive monitoring where appropriate * Understand the 5 phases of monitoring - generation, aggregation, real-time processing, storage, analytics * Create actionable metrics * **Security** * There are six design principles for security in the cloud: * Implement a strong identity foundation * Enable traceability * Apply security at all layers * Automate security best practices * Protect data in transit and at rest * Prepare for security events * Does this system work only as intended? * Identities have the least privileges required * Know who did what and when * Security is woven into the fabric of the system * Automate security tasks * Encrypt all data at rest and in transit * Prepare for the worst * Look for abnormal behavior in your logs * Capture and analyze logs * Regularly audit controls and configurations (AWS CloudFormation drift, AWS Config) * Defense in depth * Establish trust boundaries * Protect the network in/out * Protect all hosts * Configure services to meet security posture needs * Enforce service level protection * Classify and protect data * How sensitive is the data? * Who should have access to the data and when? * Encrypt in transit and at rest * Backup your data, test backups * Contain and recover from an unplanned event * Do you have a plan to tag affected resources? * Can you adjust permissions to allow for containment? * Can you redeploy to recover quickly? * Did you learn from the incident and adjust? # Azure * Microsoft's public cloud computing platform * Over 200 individual products and services * Build, run, and manage applications on Microsoft's global infrastructure * **IaaS** - Infrastructure as a Service * Virtual servers * You are responsible for maintaining the OS * **PaaS** - Platform as a Service (managed) * Cloud vendor maintains infrastructure for you * You focus on application code and data * **SaaS** - Software as a Service (managed) * Vendor provides a full software stack * Allows you to supplement or replace existing on-premise computing services * Main advantage: pay-as-you-go pricing * no up-front commitment for resources (though, in the long run prepaying saves money) * billed by the second for using resources # Tools ### Azure CLI * **Stable** - Text commands don't change and the CLI is in the stable state * **Structure** - CLI commands are structured very logically and all follow the same pattern * **Cross-Platform** - CLI works on Windows, Mac, Linux * **Automation** - It is simple to automate the CLI commands for future use * **Logging** - Keep track of who run what command and when in various ways ### PowerShell * **Cmdlet** - A script that performs a specific task. "New-AzVm" is a task that creates new virtual machine * **Azure Resource Manager** - PowerShell also uses the Resource Manager, like the Portal and CLI, to manipulate Azure resources * **Versatile** - You can use PowerShell for many other tasks and areas, not just for Azure. ### CloudShell * **Access** - Access from anywhere using a web browser or mobile app. Authenticated and secure. * **Shell** - Choose between Bash (Azure CLI) or PowerShell * **Tools** - Included tools are: interpreters, modules, Azure tools. Language support for NodeJS, .NET, and Python * **Storage** - Dedicated storage to persist data between sessions * **File Editor** - A complete file editor is available. ### ARM (Azure Resource Manager) Templates * **Describe resource usage** - what are you creating, updating, deleting? * **Common Syntax** - Defined language for all ARM templates, making it easier to formalize and learn * **Idempotent** - Every ARM template can be applied multiple times, and the result is always the same * **Source Control** - Can be checked-in into your source control system. Keep track of all changes to the ARM templates * **Reuse** - Use a combination of multiple partial ARM templates to achieve the end result. * **Declarative** - Specify what you want, not how it's done * **No Human Errors** - Automation means humans don't repeat the same mistakes # Organization & Management ### Regions and Availability Zones * **Region** - a group of data centers in a single geographic location. For example, "Central US", "South India", etc. Provides high availability and fault tolerance. Deployments are closer (geographically) to your end users. Defends against regional outages. * **Availability Zone** - one of several unique locations in a region. There might be one or more individual data centers per zone. Each zone is self-contained (power, cooling, networking, etc). Availability zone deployments are mainly for fault tolerance, protecting against a single point of failure.
### Azure Resource Manager (ARM) Centralized management layer - no matter how you connect to Azure, all requests go through ARM to provide access control * Web portal * Command-line interface (CLI) * Application Access * Access Control (authentication) ### Tenancy * Everything starts with a single **Azure Tenant**. Single organization instance of Azure AD. * Each Tenant can have one or more **Management Groups**. Management group serves as a grouping component (optional), central management of multiple subscriptions. * Each Management Group can have one or more **Subscriptions**. Subscription is a primary billing and access isolation boundary, each subscription has its own billing agreement. * Each Subscription can have one or more **Resource Groups**. All Azure resources are created in Resource Groups, serve as a container for resources with same purpose/lifecycle. * Each Resource Group can contain one or more **Resources** (VMs, DBs, Functions, etc).

Azure Tenant

### # Authentication & Authorization ### Identity & Access Management (IAM) #### IAM Components "Who" - **Azure Active Directory (AD)** - Manages Azure identities. Azure AD is a cloud-based identity service * One per tenant * Provides identity - "who you are?" * Identity = "**security principal**" (technical term) * Manage end users (people) or applications * Email format (end user) - "Can do what" - **Azure Role-Based Access Control (RBAC)** - Provides fine-grained access management to Azure resources. Controls access using **roles**: * Assign roles to a security principal * **Roles** are collections of specific **permissions** * There are **general** role and **specific** role types: * Owner - general role type, full access to all resources in scope * Virtual Machine Contributor - only access to manage VMs "On which resources" - **Scope** - Controls the scope of access in the resource hierarchy. A scope defines a set of resources allowed to access: * Roles granted to various layers of the resource hierarchy * Lower levels inherit roles from the higher levels * Centralized management # Compute # Networking # Storage # Databases # Security # Privacy, Compliance & Trust # Cost Management # Docker # Useful Links List of Docker-related links ### Links * [Docker Hub](https://hub.docker.com/) - Where all docker images are * [Docker documentation](https://docs.docker.com/) - Official Docker documentation * [Play with Docker](https://labs.play-with-docker.com/) - Docker in the browser! (Docker in Docker, actually :)) ### Courses * [Docker Mastery: with Kubernetes +Swarm from a Docker Captain](https://www.udemy.com/course/docker-mastery/) * [Docker and Kubernetes: The Complete Guide](https://www.udemy.com/course/docker-and-kubernetes-the-complete-guide/) * [Docker for Node.js Projects From a Docker Captain](https://www.udemy.com/course/docker-mastery-for-nodejs/) ### Books * [Docker in Practice, Second Edition](https://www.manning.com/books/docker-in-practice-second-edition) (ISBN: 9781617294808) --- [Next Page](/llms-full.txt/1)