SHA256
moved study stuff
This commit is contained in:
1 parent
8eeb419ba4
commit
888fe03d46
37 files changed
No files matched your search
@@ -0,0 +1,30 @@
|
||||
# Amazon Certificate Manager
|
||||
Provisions, manages, and deploys public and private SSL/TLS certificate for use with [[AWS]] Services.
|
||||
|
||||
ACM handles the complexity of creating and managing public SSL/TLS certificates for your [[AWS]] based websites and applications.
|
||||
|
||||
ACM handles two kinds of certificates:
|
||||
1. Public - Certificates provided by ACM (Free)
|
||||
2. Privates - Certificates you import ($400 / month)
|
||||
|
||||
ACM can handle multiple subdomains and wildcard domains (*.example.com).
|
||||
|
||||
ACM can be attached to the following [[AWS]] resources:
|
||||
- [[ELB]]
|
||||
- [[_CloudFront|CloudFront]]
|
||||
- [[API Gateway]]
|
||||
- [[_Elastic BeanStalk|_Elastic BeanStalk]] (through [[ELB]])
|
||||
|
||||
## Types
|
||||
### Terminating SSL at Load Balancer
|
||||
All traffic in-transit beyond the ALB is unencrypted
|
||||

|
||||
|
||||
You can add as many EC2 instances to the ALB as you need, and you don't need to install certificates on each instances. Less secure, in theory, if someone can grab the data in between the ALB and EC2 instances.
|
||||
|
||||
### Terminating SSL End-to-End
|
||||
Traffic is encrypted in-transit all the way to the application.
|
||||

|
||||
|
||||
It guarantees encryption is end to end. It's more complicated to maintain certificates. You can't do this with ACM by itself. You can set up Let's Encrypt for it.
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 37 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
@@ -0,0 +1,3 @@
|
||||
# Application Load Balancer
|
||||
Placeholder.
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
# [[API]] Gateway
|
||||
A front to some kind of application on [[AWS]].
|
||||
|
||||
Can be one of three flavors:
|
||||
- [[REST]]
|
||||
- [[HTTP]]
|
||||
- WebSocket
|
||||
|
||||
|
||||
https://app.exampro.co/student/material/dva-c02/6956
|
||||
|
||||
Still a placeholder.
|
||||
@@ -0,0 +1,43 @@
|
||||
# GraphQL
|
||||
GraphQL is an FOSS agnostic query adaptor that allows you to query data from many different data sources. GraphQL is used to build APIs where clients will send a query for nested data. GraphQL mitigates the issue of versioned or rapidly changing APIs compared to REST APIs because you can request the data you want.
|
||||
|
||||
GraphQL schemas are written in the GraphQL SDL (Schema Definition Language) composed on:
|
||||
- **Types**. Represent objects and their **fields**:
|
||||
```graphql
|
||||
type Query {
|
||||
me: User
|
||||
}
|
||||
|
||||
type User {
|
||||
id: ID
|
||||
name: String
|
||||
}
|
||||
```
|
||||
- **Fields**
|
||||
- **Queries**. Define the exact shape of the data needed by the client:
|
||||
```graphql
|
||||
query CurrentUser {
|
||||
currentUser {
|
||||
name
|
||||
age
|
||||
}
|
||||
}
|
||||
```
|
||||
- **Mutations**. Allow for data to be create, updated or deleted:
|
||||
```graphql
|
||||
mutation CreateUser($name: String!, $age: Int!) {
|
||||
createUser(userName: $name, age: $age) {
|
||||
name
|
||||
age
|
||||
}
|
||||
}
|
||||
```
|
||||
- **Subscriptions**. Supports live updates sent from the server to the client:
|
||||
```graphql
|
||||
subscription {
|
||||
newPerson {
|
||||
name
|
||||
age
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,44 @@
|
||||
# AppSync
|
||||
AppSync is a fully managed [[GraphQL|GraphQL]] service.
|
||||
|
||||
Notes:
|
||||
- It can support real-time [[API]]s via GraphQL subscriptions.
|
||||
- AppSync supports custom domains
|
||||
- AppSync has a query editor built into the UI
|
||||
|
||||
## Resolvers
|
||||
Resolvers attached to specific fields within your types in your schema. used to implement the state-changing operations for your query, mutation, and subscription field operations.
|
||||
|
||||
Runtimes:
|
||||
- **`APPSYNC_JS`**: JavaScript
|
||||
- **VTL**: Velocity Template Language.
|
||||
|
||||
## Data Sources
|
||||
Where data is being pulled from.
|
||||
|
||||
- DynamoDB Table
|
||||
- Amazon OpenSearch
|
||||
- AWS [[_Lambda|Lambda Function]]
|
||||
- [[HTTP]] Endpoint
|
||||
- Amazon EventBridge
|
||||
- Relational Database (RDS HTTP Endpoint)
|
||||
|
||||
## API Types
|
||||
- **GraphQL APIs** - single API from multiple data sources
|
||||
- **Merged APIs** - a collection of Graph APIs that act as one API
|
||||
- Useful if you have multiple teams that manage their own API but you want to treat all the APIs as a single API.
|
||||
|
||||
## Caching Options
|
||||
- **None**: Self explanatory; no caching, resolvers will always fetch from data sources.
|
||||
- **Full request caching**: Self explanatory; caches all requests.
|
||||
- **Per-resolver caching**: specific operation or field defined in a resolver will return responses from the cache.
|
||||
Caching isn't serverless; you must provision an on-demand instance.
|
||||
|
||||
# Authorisation
|
||||
- API Key
|
||||
- AWS IAM
|
||||
- Cognito User Pools
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
# Athena
|
||||
|
||||
Amazon Athena is like a library with a massive, disorganised warehouse of books (your data in [[_S3|S3]]). Instead of hiring a librarian to manually sort and read every book each time you ask a question, Athena uses a card catalog system ([[AWS]] Glue Data Catalog). You write a query like `find all books by author X published after 2000` on a slip of paper (SQL Query). The catalog tells Athena exactly which shelves and boxes contain relevant books, so it only opens those boxes and scans those pages. Each book is read by a team of temporary workers (distributed query engine) who work in parallel, each reading different pages and jotting down answers on sticky notes. The workers then hand their notes to a foreman (coordinator) who combines them into a single answer. Crucially, the workers never move the books or write in them - they just read. They are paid per page read (data scanned), so you want the catalog to be precise to avoid paying for scanning the entire warehouse. If the catalog is wrong (a box contains fictions when it's actually non-fiction), the workers might miss books or scan irrelevant ones, wasting time and money. Athena's power is that it can query any book in any format (CSV, JSON, Parquet), as long as the catalog describes how to interpret it, and it never alters the original books.
|
||||
|
||||
|
||||
@@ -0,0 +1,14 @@
|
||||
# [[_CloudFront|CloudFront]] Functions
|
||||
Lightweight edge functions. They are cheaper, faster, but more limited than [[Lambda@Edge|Lambda@Edge]] functions.
|
||||
|
||||
Only supports ECMAScript 5.1 (JavaScript).
|
||||
|
||||
They live directly at Edge Locations.
|
||||
|
||||
Uses:
|
||||
- Cache key normalisation
|
||||
- Header manipulation
|
||||
- Status code modification and body generation
|
||||
- URL redirects and rewrites
|
||||
- Request authorisation
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
# Lambda@Edge
|
||||
Supported Languages:
|
||||
- Python
|
||||
- JavaScript
|
||||
|
||||
They are deployed at Regional Edge Caches for [[_CloudFront|CloudFront]].
|
||||
|
||||
@@ -0,0 +1,136 @@
|
||||
# CloudFront
|
||||
## What is it?
|
||||
[[_CloudFront|CloudFront]] is a CDN. It can be used for:
|
||||
- Static & Dynamic content
|
||||
- Video Streaming
|
||||
- Web Sockets
|
||||
|
||||
### Benefits
|
||||
- [[_CloudFront|CloudFront]] can be fronted with [[AWS WAF]] for OWASP's top 10 protection.
|
||||
- [[_CloudFront|CloudFront]] can stream [[Videos On Demand]] using [[ISS Microsoft Smooth Streaming]]
|
||||
|
||||
### Core components
|
||||
**Origin**: Location where all original files are located. Examples include: [[_S3|S3]], EC2, ELB, Route53.
|
||||
**Edge Locations**: Compute located strategically close to end users.
|
||||
**Regional Caches**: Compute located in board geographical locations to speed up requests for edge locations.
|
||||
**Distribution**: A collection of Edge locations and Regional Cache that defines how cached content should behave.
|
||||
|
||||
## Running Code
|
||||
|
||||
### Stages where [[Lambda@Edge]] and [[CloudFront Functions]] can trigger
|
||||
The order that the functions trigger within CloudFront is:
|
||||
| Order | Stage | L@E | CF Fns | Description | Example Use Cases |
|
||||
|--|---|---|---|---|--|
|
||||
| 1 | Viewer Request | ✔️ | ✔️ | When CloudFront receives a request from the viewer. | Redirection (`HTTP` -> `HTTPS`), Cookie Inspection for Auth, Modify Headers for A/B Testing |
|
||||
| 2 | Origin Request | ✔️ | ❌ | Before CloudFront forwards the request to the origin. | Add security headers (CSP/HSTS), set cookies for client side tracking, customise error messages |
|
||||
| 3 | Origin Response | ✔️ | ❌ | After CloudFront receives the request from the origin. | Rewrite URLs for SEO or routing, inject headers for origin authentication, selective content serving based on user agent (desktop/mobile mode). |
|
||||
| 4 | Viewer Response | ✔️ | ✔️ | Before CloudFront returns the response to the viewer. | Modify headers to control caching, update URLs in HTML for versioning, customise error responses from origin. |
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Viewer
|
||||
participant Edge
|
||||
participant Origin
|
||||
|
||||
Viewer->>Edge: Viewer Request
|
||||
Edge->>Origin: Origin Request
|
||||
Origin->>Edge: Origin Response
|
||||
Edge->>Viewer: Viewer Response
|
||||
```
|
||||
|
||||
### Difference between [[Lambda@Edge]] and [[CloudFront Functions]]
|
||||
| | CF Fns | L@E |
|
||||
|---|---|---|
|
||||
| Programming Languages | JavaScript (ECMAScript 5.1) | Node.JS and Python |
|
||||
| Event Sources | Viewer only | Viewer and Origin |
|
||||
| Scale | +10,000,000 requests/s | 10,000 requests/s/Region |
|
||||
| Function Duration | Submilisecond | Up to 5s (Viewer) / Up to 30s (Origin) |
|
||||
| Max Memory | 2MB | 128MB-3,008MB |
|
||||
| Max Bundle Size | 10KB | 1MB (Viewer) / 50MB (Origin) |
|
||||
| Network, File System, and Request Body Access | ❌ | ✔️ |
|
||||
| Access to geolocation | ✔️ | ❌ (Viewer request) / ✔️ (Origin request & response, Viewer response) |
|
||||
| Can build/test entirely within CloudFront | ✔️ | ❌ |
|
||||
| Functions logging and metrics | ✔️ | ✔️ |
|
||||
| Pricing | Cheaper. Free tier available; charged pre request. | More expensive. Charged per request & function duration. |
|
||||
|
||||
## CloudFront Origin
|
||||
It's the source where CloudFront will send requests.
|
||||
|
||||
### CloudFront Origin Groups
|
||||
It allows you to group a **primary** and **secondary origin** together as a destination for requests to enable high availability and fault tolerance.
|
||||
|
||||
The **Primary Origin** is where **all** the requests will be sent.
|
||||
The **Secondary Origin** is where the requests will be sent if the **Primary Origin** is **not available**. It will act like a **failover** origin.
|
||||
|
||||
The **failover** criteria is based on **HTTP Status Codes**: 400, 403, 404, 416, 500, 502, 503, 504.
|
||||
|
||||
CloudFront will failover on: `GET`, `HEAD`, and `OPTION` requests.
|
||||
CloudFront will NOT failover on: `PUT`, `POST`, `PATCH`, and `DELETE`.
|
||||
|
||||
## CloudFront Caching Policy
|
||||
### Cache Key
|
||||
The **Cache Key** is a unique identifier for every object in the cache and determines whether a viewer request results in a cache hit.
|
||||
A cache hit occurs when a viewer request generates the same **Cache Key** as a prior request and the object for that cache key is in the edge location's cache.
|
||||
The more people hit the cache, the better the application performance will be.
|
||||
|
||||
### Cache Policy
|
||||
A **Cache Policy** determines the **Cache Key**.
|
||||
|
||||
[[AWS]] has managed **Cache Policies** for use:
|
||||
- `Amplify`
|
||||
- `CachingDisabled`
|
||||
- `CachingOptimized`
|
||||
- `CachingOptimizedForUncompressedObjects`
|
||||
- `Elemental-MediaPackage`
|
||||
|
||||
You can make your own **Caching Policy**:
|
||||
- **TTL Settings**:
|
||||
- **Minimum** / **Maximum** **TTL**: min / max time to hold the file in the cache.
|
||||
- **Default TTL**: default time to hold a file in the cache.
|
||||
|
||||
- **Cache Key Settings**:
|
||||
- **Headers**: which headers are a part of the **Cache Key**.
|
||||
- **Cookies**: which cookies are a part of the **Cache Key**.
|
||||
- **Query String**: which query string parameters are a part of the **Cache Key**.
|
||||
- **Compression Support**: What compression format is part of the **Cache Key**.
|
||||
|
||||
### Origin Request
|
||||
Happens when there is a cache miss and CloudFront must reach out to Origin to retrieve data.
|
||||
|
||||
**Origin Request** always returns:
|
||||
- URL Path
|
||||
- Request Body (if present)
|
||||
- Specific HTTP Headers:
|
||||
- Host
|
||||
- User Agent
|
||||
- `X-Amz-Cf-Id`
|
||||
|
||||
**Origin Request** doesn't include these by default:
|
||||
- URL Query String
|
||||
- Cookies
|
||||
- All other HTTP Headers
|
||||
|
||||
**Cache Key** information (set by the **Cache Policy**) are automatically included in **Origin Requests**:
|
||||
- URL Query Strings
|
||||
- HTTP Headers
|
||||
- Cookies
|
||||
|
||||
### Response Header Policy
|
||||
Allows you to modify the HTTP Headers in the response that viewers will see.
|
||||
[[AWS]] has managed policies for you to use and you can make your own also.
|
||||
|
||||
⚠️ If you are dealing with CORS, you will be setting things here, as this will mess with them.
|
||||
|
||||
## Origin Access Identity
|
||||
**OAI** makes sure that an S3 bucket is only accessible through **CloudFront** and not the internet.
|
||||
Lots of drawbacks. Not available anymore.
|
||||
|
||||
## Origin Access Control
|
||||
Same as Origin Access Identity, makes sure that an [[_S3|S3]] bucket is only accessible through **CloudFront** and not the internet.
|
||||
|
||||
Overview:
|
||||
* Enhanced sec.
|
||||
* Comprehensive [[HTTP]] support.
|
||||
* Supports uploading and downloading encrypted [[_S3|S3]] objects with SSE-KMS.
|
||||
* Supports accessing [[_S3|S3]] in all [[AWS]] Regions.
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
# CodeBuild
|
||||
- A fully managed build service in the cloud.
|
||||
- Compiles your code, runs unit tests, and produces artifacts that are ready to deploy.
|
||||
- Eliminates the need to provision, manage, and scale your own build server
|
||||
- Provides prepackaged build environments for popular programming languages and build tools such as Apache, Maven, Gradle, and more.
|
||||
- You can also customise environments to use your own build tools
|
||||
- Scaled automatically to meet peak build requests.
|
||||
|
||||
## Workflow
|
||||
1. Trigger a build
|
||||
* You can trigger a build with AWS Console, CLI, SDK or [[_CodePipeline|CodePipeline]] trigger (like pushing to `main`).
|
||||
2. Passes the code onto CodeBuild.
|
||||
3. You give it a `buildspec.yaml` file, which is generally part of your code base.
|
||||
* You can override it with other build commands.
|
||||
4. Push into a bucket, or any other AWS SDK action (I think?)
|
||||
|
||||
## Build Environments
|
||||
The Docker images that run the CodeBuild, can be managed by [[AWS]] or you. If you need specific software, you need to make an image and upload it to ECR and reference it in the pipeline.
|
||||
|
||||
## `buildspec.yml`
|
||||
- Provides the build instructions.
|
||||
- Needs to be in the root of your project folder (`/buildspec.yml`, relative to the project root) (by default).
|
||||
|
||||
### Phases
|
||||
1. `install`: only for installing packages in the build environment. (Code gets pulled before this step.)
|
||||
2. `pre_build`: commands that run before building.
|
||||
3. `build`: commands that you run during the build.
|
||||
4. `post_build`: commands you run after the build.
|
||||
|
||||
### Artifacts
|
||||
Where we can find the build output
|
||||
How it prepares it for uploading to S3 output bucket.
|
||||
Basically Zips that go to S3, or ECR images, anything else that SDK can touch.
|
||||
|
||||
## Use Cases
|
||||
- Generating static pages to host on S3.
|
||||
- Run test code & report test coverage. For example, a developer needs to ensure their code passes all tests before being allowed to make/merge a PR.
|
||||
@@ -0,0 +1,11 @@
|
||||
# CodeCommit
|
||||
A fully-managed source control service that hosts secure Git-based repositories. (GitHub for [[AWS]])
|
||||
|
||||
## Special features
|
||||
- In scope with many compliance programs (HIPPA).
|
||||
- Repositories encrypted at rest & in transit.
|
||||
- Can handle repositories with large numbers of files or branches, large file sizes and lengthy revision histories.
|
||||
- No limit on the size of your repositories or on the file types you can store.
|
||||
- Keeps your repositories close to your production resources in AWS Cloud, which helps to increase the speed and frequency of your development life-cycle.
|
||||
- Uses IAM to control which [[AWS]] users have access to which repositories.
|
||||
|
||||
@@ -0,0 +1,42 @@
|
||||
# CodeDeploy
|
||||
- A fully managed deploy service in the cloud.
|
||||
- Can deploy EC2, On-Prem, [[_Lambda|Lambda]], or ECS.
|
||||
- Rapidly release new features.
|
||||
- Update AWS [[_Lambda|Lambda]] function versions.
|
||||
- Avoid downtime during application deployments.
|
||||
- Integrates with existing CI/CD tools eg. Jenkins, [[_CodePipeline|CodePipeline]].
|
||||
- Integrates with existing management tools eg. Puppet, Chef, Ansible.
|
||||
|
||||
## Core Components
|
||||
### Application
|
||||
The unique identifier for the application being deployed. Ensures the correct combination of revision deployment configuration, and group are referenced during deployment.
|
||||
|
||||
### Deployment Groups
|
||||
A set of EC2 instances or [[_Lambda|Lambda Functions]] where the new revision is deployed to.
|
||||
|
||||
### Deployment
|
||||
This is the process and components used to apply a new application revision.
|
||||
|
||||
### Deployment Configuration
|
||||
A set of deployment rules used during deployment - with success/failure conditions included
|
||||
|
||||
### AppSpec File
|
||||
Contains the deployment actions that CodeDeploy should execute during deployment.
|
||||
|
||||
### Revision
|
||||
This is everything required to deploy a new version: AppSpec file, application files, configuration files, executables.
|
||||
|
||||
## Deployments
|
||||
### In-Place
|
||||
- The app on each instance in the deployment group is **stopped**.
|
||||
- The latest app revision is installed, and the new version of the application is started and validated.
|
||||
- You can use a **load balancer** so that each instance is unregistered during its deployment and then restored to service after the deployment is complete.
|
||||
- ==Only deployments that use the EC2/On-Premises compute platform can use in-place deployments.==
|
||||
|
||||
### Blue/Green
|
||||
- Instances are provisioned for the replacement environment.
|
||||
- The latest application version is installed on the replacement instances
|
||||
- An optional wait time occurs for activities such as application testing and system verification.
|
||||
- Instances in the replacement environment are registered with an ELB, causing traffic to be rerouted to them.
|
||||
- Instances in the original environment are unregistered and can be terminated or kept running for other uses.
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
# CodePipeline
|
||||
A fully managed CI/CD pipeline.
|
||||
|
||||
- **Pipeline** is what encompasses all components.
|
||||
- **Stage** represents a step in the pipeline. The most common steps would be [[_CodeCommit|Source]] -> [[_CodePipeline|Build]] -> [[CodeDeploy||Deploy]]. You may add many stages, so use your creativity.
|
||||
- **Action Groups** group several **Actions** together.
|
||||
- **Actions** do things. The can pull source code, build and run tests, deploy to production, invoke a [[_Lambda|Lambda]], invoke a [[_CloudFormation|CloudFormation]] template.
|
||||
- **Artifacts** are zips containing files outputted by an **Action**. An **Artifact** can be passed to any future **Actions** and some **Actions** require to input an **Artifact** and can optionally output an **Artifact**.
|
||||
- **Stage Transitions** link the pipeline stages together.
|
||||
|
||||
## CodePipeline Actions
|
||||
Actions are not restricted to specific stages. You can use Deploy Actions is a Build Stage. Pipeline are only limited by your creativity. You can create custom actions if you need functionality beyond default.
|
||||
@@ -0,0 +1,7 @@
|
||||
# Elastic Load Balancer
|
||||
An ELB is a general term for multiple types of "load balancer" in [[AWS]].
|
||||
|
||||
Examples include:
|
||||
- [[_ALB|Application Load Balancer]]
|
||||
- [[_NLB|Network Load Balancer]]
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
# Lambda
|
||||
#Placeholder
|
||||
A Docker container or a runner that runs code for you. At a high level, it can run code behind an [[API Gateway|API Gateway]], interact with basically all [[AWS]] Resources (most commonly [[_S3|S3]], [[_DynamoDB|DynamoDB]], other [[_Lambda|Lambdas]]).
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
# Network Load Balancer
|
||||
Placeholder.
|
||||
|
||||
@@ -0,0 +1,128 @@
|
||||
# DynamoDB Read/Write Units — Numeric Practice, Set 3
|
||||
|
||||
20 questions. Give a numeric answer for each, using `1 = <number>`, `2 = <number>`, and so on.
|
||||
|
||||
## Assumptions
|
||||
|
||||
- Assume provisioned capacity and steady workloads.
|
||||
- All item sizes are exact DynamoDB item sizes, including attribute names and values.
|
||||
- Each read accesses an individual item, not a Query or Scan. Transactional operations count individual items, not transaction API calls.
|
||||
- Normal writes are non-transactional. All writes create new items.
|
||||
- Ignore indexes, replication, retries, failed requests, burst capacity and partition limits.
|
||||
- Questions 1–14 ask for exact throughput requirements: fractional RCU answers are valid; do not round the final result to a whole number.
|
||||
- Questions 15–18 ask for the maximum number of individual item operations per second.
|
||||
- Questions 19–20 ask for whole-number provisioned capacity settings.
|
||||
|
||||
## Questions
|
||||
|
||||
### 1. You normally write six separate 1.8 KB items every second. How many WCUs are required?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 2. You normally write nine separate 0.7 KB items every second. How many WCUs are required?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 3. You normally write four separate 3.01 KB items every second. How many WCUs are required?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 4. You transactionally write three separate 2.01 KB items every second. How many WCUs are required?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 5. You transactionally write six separate 1 KB items every second. How many WCUs are required?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 6. You perform strongly consistent reads of five separate 5 KB items every second. How many RCUs of throughput are required?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 7. You perform strongly consistent reads of three separate 12 KB items every second. How many RCUs of throughput are required?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 8. You perform eventually consistent reads of nine separate 0.8 KB items every second. How many RCUs of throughput are required?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 9. You perform eventually consistent reads of five separate 8.01 KB items every second. How many RCUs of throughput are required?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 10. You perform eventually consistent reads of seven separate 8 KB items every second. How many RCUs of throughput are required?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 11. You transactionally read five separate 4.01 KB items every second. How many RCUs of throughput are required?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 12. You transactionally read three separate 11 KB items every second. How many RCUs of throughput are required?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 13. Each second, you normally write two 0.6 KB items and three 2.4 KB items to the same table. How many WCUs are required in total?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 14. Each second, you perform strongly consistent reads of two 5 KB items and eventually consistent reads of three 1 KB items from the same table. How many RCUs of throughput are required in total?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 15. You have 28 WCUs available. What is the maximum number of normal item writes per second you can sustain if each item is 3.2 KB?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 16. You have 30 WCUs available. What is the maximum number of transactional item writes per second you can sustain if each item is 2.2 KB?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 17. You have 15 RCUs available. What is the maximum number of eventually consistent item reads per second you can sustain if each item is 9 KB?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 18. You have 32 RCUs available. What is the maximum number of transactional item reads per second you can sustain if each item is 5 KB?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 19. You perform eventually consistent reads of eleven separate 3 KB items every second. What is the minimum WHOLE NUMBER of RCUs you must provision?
|
||||
|
||||
Answer: ______
|
||||
|
||||
### 20. You perform eventually consistent reads of five separate 12.01 KB items every second. What is the minimum WHOLE NUMBER of RCUs you must provision?
|
||||
|
||||
Answer: ______
|
||||
|
||||
## Answer key
|
||||
|
||||
<details>
|
||||
<summary>Show answers and calculations</summary>
|
||||
|
||||
`ceil` means round up to the next whole number. Sizes are divided by the 1 KB write or 4 KB read increment before rounding.
|
||||
|
||||
1. **12 WCUs** — `ceil(1.8 / 1) × 6 = 2 × 6`.
|
||||
2. **9 WCUs** — `ceil(0.7 / 1) × 9 = 1 × 9`.
|
||||
3. **16 WCUs** — `ceil(3.01 / 1) × 4 = 4 × 4`.
|
||||
4. **18 WCUs** — `ceil(2.01 / 1) × 3 × 2 = 3 × 3 × 2`.
|
||||
5. **12 WCUs** — `ceil(1 / 1) × 6 × 2 = 1 × 6 × 2`.
|
||||
6. **10 RCUs** — `ceil(5 / 4) × 5 = 2 × 5`.
|
||||
7. **9 RCUs** — `ceil(12 / 4) × 3 = 3 × 3`.
|
||||
8. **4.5 RCUs** — `ceil(0.8 / 4) × 9 × 0.5 = 1 × 9 × 0.5`.
|
||||
9. **7.5 RCUs** — `ceil(8.01 / 4) × 5 × 0.5 = 3 × 5 × 0.5`.
|
||||
10. **7 RCUs** — `ceil(8 / 4) × 7 × 0.5 = 2 × 7 × 0.5`.
|
||||
11. **20 RCUs** — `ceil(4.01 / 4) × 5 × 2 = 2 × 5 × 2`.
|
||||
12. **18 RCUs** — `ceil(11 / 4) × 3 × 2 = 3 × 3 × 2`.
|
||||
13. **11 WCUs** — `(ceil(0.6 / 1) × 2) + (ceil(2.4 / 1) × 3) = 2 + 9`.
|
||||
14. **5.5 RCUs** — `(ceil(5 / 4) × 2) + (ceil(1 / 4) × 3 × 0.5) = 4 + 1.5`.
|
||||
15. **7 writes/s** — `28 / ceil(3.2 / 1) = 28 / 4`.
|
||||
16. **5 transactional item writes/s** — `30 / (ceil(2.2 / 1) × 2) = 30 / 6`.
|
||||
17. **10 reads/s** — `15 / (ceil(9 / 4) × 0.5) = 15 / 1.5`.
|
||||
18. **8 transactional item reads/s** — `32 / (ceil(5 / 4) × 2) = 32 / 4`.
|
||||
19. **6 provisioned RCUs** — `ceil(ceil(3 / 4) × 11 × 0.5) = ceil(5.5)`.
|
||||
20. **10 provisioned RCUs** — `ceil(ceil(12.01 / 4) × 5 × 0.5) = ceil(10)`.
|
||||
|
||||
For questions 1–14, RCUs describe exact throughput requirements. Provisioned settings must be whole numbers, as explicitly requested in questions 19–20.
|
||||
|
||||
</details>
|
||||
@@ -0,0 +1,5 @@
|
||||
# [[_Route53|Route 53]] Record Sets
|
||||
Record sets are a collection of records which determine where to send traffic.
|
||||
|
||||
They are always changed in batch via the API.
|
||||
|
||||
@@ -0,0 +1,15 @@
|
||||
# [[_Route53|Route 53]] Hosted Zone
|
||||
A hosted zone is a container for [[Record Sets|Record Sets]], scoped to route traffic to a specific domain or subdomain.
|
||||
|
||||
There are 2 types of [[Route 53 Hosted Zone|Route 53 Hosted Zones]]:
|
||||
- Public Hosted Zones: How you want to route traffic inbound from the Internet
|
||||
- Private Hosted Zones: How you want to route traffic within an Amazon [[_VPC|VPC]].
|
||||
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
DomainHZ --> RecordSet
|
||||
RecordSet --> WildcardRecordSet
|
||||
```
|
||||
|
||||
Revisit this.
|
||||
@@ -0,0 +1,10 @@
|
||||
# [[_Route53|Route 53]] Use Cases
|
||||
Use Route 53 to get your custom domains to point at your [[AWS]] Resources.
|
||||
|
||||

|
||||
1. Incoming internet traffic.
|
||||
2. Route traffic to our web backed by [[_ALB|ALB]].
|
||||
3. Route traffic to an instance we use to tweak our AMI.
|
||||
4. Route traffic to [[_API Gateway|API Gateway]], which powers our [[API]].
|
||||
5. Route traffic to [[_CloudFront|CloudFront]] which serves our [[_S3|S3]] static hosted website.
|
||||
6. Route traffic to an Elastic IP (EIP), which is a static IP that hosts a game server.
|
||||
@@ -0,0 +1,16 @@
|
||||
# Route 53
|
||||
A DNS with [[AWS]] Services.
|
||||
|
||||
You can:
|
||||
- Register and manage domains.
|
||||
- Create various records sets on a domain.
|
||||
- Implement complex traffic flows (Blue/Green[^1], failovers).
|
||||
- Continuously monitor records via health checks.
|
||||
- Resolve [[_VPC|VPC]]'s outside of [[AWS]].
|
||||
|
||||
[^1]: See [[Deployments|Deployments]].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 137 KiB |
@@ -0,0 +1,3 @@
|
||||
# S3
|
||||
Think of Stanley's Bucket from The Stanley Parable.
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
# VPC
|
||||
Virtual Private Connection.
|
||||
|
||||
A private link between 2 places. It can be used as a way to connect 2 different [[AWS]] accounts via a link that only these two accounts can use. Consider this a [[VPN]] between two places that is managed by [[AWS]].
|
||||
@@ -0,0 +1,100 @@
|
||||
# X-Ray
|
||||
[[_X-Ray|AWS X-Ray]] is a [[AWS]] Managed service for diagnosing issues (performance and failures) in a microservice architecture. The main idea is that you pass headers in your calls, [[AWS]] picks up on those headers and looks at the propagation of the requests across bits of [[AWS]].
|
||||
|
||||
It's a distributed tracing system.
|
||||
|
||||
## Anatomy of X-Ray
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
API["X-Ray API"] --> Console["X-Ray Console"]
|
||||
Daemon["X-Ray Daemon"] --> API
|
||||
SDK["X-Ray SDK"] --> Daemon
|
||||
Other["Other Clients:\nAWS SDK or AWS CLI"] --> API
|
||||
Other --> Daemon
|
||||
API --> Other
|
||||
```
|
||||
|
||||
## X-Ray SDK
|
||||
- The SDK provides **interceptors** to trace [[HTTP]] requests
|
||||
- **Client handlers** to **instrument** AWS SDK clients that your application uses to call other [[AWS]] Services
|
||||
- A [[HTTP]] Client to use to instrument calls to other internal and external [[HTTP]] web services
|
||||
|
||||
## X-Ray Instrumentation
|
||||
Measure the level of product's performance to diagnose errors and write trace information.
|
||||
|
||||
## X-Ray-Daemon
|
||||
It buffers segments into a queue and uploads in batches.
|
||||
It's available to be installed on Linux, Windows, Mac
|
||||
Comes with [[_Elastic BeanStalk]] and [[_Lambda]] by default.
|
||||
|
||||
## X-Ray Concepts
|
||||
* **Segments**:
|
||||
* Details about the host (IP address/kind of host).
|
||||
* Request information.
|
||||
* The time/duration.
|
||||
* Errors and Faults.
|
||||
* Response Statuses.
|
||||
|
||||
* **Subsegments**:
|
||||
* More granular timing information.
|
||||
* Can contain calls to other [[AWS]] services.
|
||||
|
||||
* **Service Graph**:
|
||||
* Just the UI graph in the Console.
|
||||
|
||||
* **Traces**:
|
||||
* A Trace ID is the path of a request through your application.
|
||||
* Gets passed along to everything else, so that it can be tracked.
|
||||
* Not every trace gets recorded.
|
||||
|
||||
* **Sampling**:
|
||||
* [[_X-Ray|AWS X-Ray]] uses a sampling algorithm to determine which requests get traced.
|
||||
* Default is:
|
||||
* The first request each second...
|
||||
* And 5% of any additional requests.
|
||||
* Idea is to reduce service charges when you are getting started. The default sampling rate is low.
|
||||
* You can create limits for the rates.
|
||||
|
||||
* **Tracing Header**:
|
||||
* All requests are traced up to a configurable minimum.
|
||||
* After that minimum, a percentage of requests are traced to avoid unnecessary cost. (See above)
|
||||
* [The sampling decision and the trace ID are added to HTTP requests in tracing headers named `X-Amzn-Trace-Id`.]{.underline}
|
||||
* The Tracing Header determines if the trace shows up in the viewer.
|
||||
|
||||
* **Filter Expressions**:
|
||||
* Applications make a lot of data, you can filter it.
|
||||
|
||||
* **Groups**:
|
||||
* Named Filter Expressions.
|
||||
* Groups only update after you update them, the data before still remains. (subsequent traces only)
|
||||
|
||||
* **Annotations**:
|
||||
* Up to 50 annotations per trace.
|
||||
* Use to record data that you want to group traces in the console, or when calling the `GetTraceSummaries` API.
|
||||
|
||||
* **Metadata**:
|
||||
* Metadata are not indexed and values can be any type, including lists and objects.
|
||||
* Use Metadata to record data you want to store in the trace but don't need to use for searching traces.
|
||||
|
||||
* **Errors, Faults, and Exceptions**:
|
||||
* X-Ray records the Stack Trace and exception details if available.
|
||||
|
||||
## X-Ray Service Integration
|
||||
- [[_Lambda|Lambda]]
|
||||
- [[_API Gateway|API Gateway]]
|
||||
- ELB
|
||||
- SNS
|
||||
- SQS
|
||||
- App Mesh
|
||||
- CloudTrail
|
||||
- CloudWatch
|
||||
- AWS Config
|
||||
- EB
|
||||
- EC2
|
||||
- ECS
|
||||
- Fargate
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
# [[CRUD|CRUD]] vs [[REST|REST]]
|
||||
[[REST|REST]] is an architectural style for designing web services. It represents state transfer through HTTP methods.
|
||||
|
||||
[[CRUD]] is more general. It represents the 4 foundational actions of data management: Create, Read, Update, Delete.
|
||||
|
||||
@@ -0,0 +1,24 @@
|
||||
# [[AWS]] Deployments
|
||||
|
||||
[[_CodeDeploy|CodeDeploy]]
|
||||
[[_Elastic BeanStalk|_Elastic BeanStalk]]
|
||||
|
||||
| Service | Kind | Impact | Description | Service Scope |
|
||||
|---|---|--|---|--|
|
||||
| `CodeDeploy` | In-place | Lowered Capacity | Stops apps on _every_ instance, installs latest version, then new version is started and then validated. Can be used in conjunction with a load balancer so that each instance is unregistered before update and the reregistered after being verified. | EC2 / On-Prem. |
|
||||
| `CodeDeploy` | Blue/Green | Higher Cost | Make a new set of instances, install the latest version, start the latest version and then validate them. Once validated, they replace and existing instance in the ELB. The old instances can be terminated or kept running. | EC2 / On-Prem, Lambda & ECS. |
|
||||
| `ElasticBeanstalk` | All at Once | Downtime | Default policy. Takes everything out of service. Recreates the instances and boots them again. Fastest deployment for EB. | EB |
|
||||
| `ElasticBeanstalk` | Rolling | Lowered Capacity | Slowly switch out instances over time. Safer than **All at Once**. | EB |
|
||||
| `ElasticBeanstalk` | Rolling with Additional Batches | Higher Cost | You spin up an extra batch. Then you switch out the old instances over time until one is left, which you discard. | EB |
|
||||
| `ElasticBeanstalk` | Immutable | Higher Cost | You spin up an entire extra Auto Scailing Group, then once ready, point the ELB to the new ASG. The safest way to deploy applications because the old instances remain. | EB |
|
||||
| `ElasticBeanstalk` | Blue/Green | Higher Cost | You spin up an entire extra ELB, then switch out the URLs. | EB |
|
||||
| `ElasticBeanstalk` | Traffic Shifting | Higher Cost | You spin up and extra ELB, the split the traffic between the two, until you are satisfied your application works. | EB |
|
||||
| | | | | |
|
||||
| | | | | |
|
||||
| | | | | |
|
||||
| | | | | |
|
||||
| | | | | |
|
||||
| .............................................................................................................................................. | | | | |
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,2 @@
|
||||
# API
|
||||
Application Programming Interface. A way that a program can interact with another program or computer.
|
||||
@@ -0,0 +1,2 @@
|
||||
# [[AWS]]
|
||||
Amazon Web Services. Plain and simple.
|
||||
@@ -0,0 +1,2 @@
|
||||
# CRUD
|
||||
Stands for Create, Read, Update, Delete. These are the four foundational actions of data management.
|
||||
@@ -0,0 +1,2 @@
|
||||
# HTTP
|
||||
Hypertext Transfer Protocol. Web browser protocol.
|
||||
@@ -0,0 +1,2 @@
|
||||
# HTTPS
|
||||
Stands for Hypertext Transfer Protocol Secure. It is [[HTTP]] with a layer of encryption, either on the Application on IP layer.
|
||||
@@ -0,0 +1,3 @@
|
||||
# REST
|
||||
Representational State Transfer. A kind of [[CRUD]]. It uses [[HTTP]] methods to provide data manipulation.
|
||||
|
||||
@@ -0,0 +1,2 @@
|
||||
# SQL
|
||||
Structured Query Language. Usually used to interface with databases by performing [[CRUD]] operations.
|
||||
@@ -0,0 +1,2 @@
|
||||
# VPN
|
||||
Virtual Private Network. Secures connections between two networks.
|
||||
Reference in new issue
Block a user