• VPC
  • ENI
  • EIP
  • Peering
  • Endpoint
• Security
  • Security group
  • Network ACL
• NAT
  • NATGW
• VPN
  • VPGW
  • TGW
• ELB
  • CLB
  • ALB
  • NLB
  • GLB
• ACM
• Route 53
  • Record types
  • Routing policies
  • Health check
• CloudFront
  • Origins
  • Signed URL/Cookie
  • Costs
  • Field Level Encryption
• Global Accelerator
• API Gateway
  • API Types and Integrations
  • Security
  • Stages
  • Caching
  • Usage plans and API Keys
  • Logging and Tracing
• Direct Connect
• Other services

What is Amazon VPC.

Default VPC has internet connectivity (internet gateway attached) and /16 (65536 hosts) subnet mask.

VPC can span multiple AZs. AZs have names and IDs. ID uniquely identifies an AZ, while names can differ between accounts. VPC can have max 6 CIDR blocks - min size /28, max is /16.

Reachability Analyzer - builds a network configuration model and checks the reachability based on configuration settings (does not send packets). In case of feasibility issue detects the blocking component (SG, Network ACL, etc).

# Query info on subnet given its CIDR block
$ aws ec2 describe-subnets --filters Name=cidr-block,Values="10.0.11.0/24"

# Create VPC
$ aws ec2 create-vpc --cidr-block <cidr_block>

# Create subet
$ aws ec2 create-subnet --vpc-id <vpc_id> --cidr-block <cidr_block> --availability-zone <availability_zone>

Free of charge:

• ingress into AZ
• ingress into S3
• between instances in the same AZ, if private IP is used
• S3 to CloudFront traffic

Charged Per GB:

• between AZs via private IP - $0.01
• between AZs via public IP - $0.02
• between regions - $0.02
• egress S3 - $0.09
• egress CloudFront - $0.85

Default subnet has /20 (4096 hosts) mask.

Subnet is always mapped to a single AZ.

AWS reserves 5 IP addresses in subnet (first 4 and last one).

1. network address
2. reserved for router
3. reserved for AWS DNS
4. reserved for future use
5. broadcast address (since AWS does not support broadcast, it can not be used)

All traffic in the VPC traverses a route table (implied router). AWS sets the first IP address in a subnet to the route table. Every subnet must be associated with a route table (only one). Multiple subnets can use a single route table.

For public networking Internet Gateway must be present in the VPC. One VPC can only be attached to one IGW and vice versa. Custom VPC doesn't come with IGW.

Internet connectivity requirements:

• IGW must be attached to VPC
• instances must have either public or elastic IP
• subnet route table must point to the IGW
• ACL and security groups rules must be configured to allow ingress and egress traffic

DNS resolution, enabled by default, uses Amazon DNS server (169.254.169.253) or reserved IP in the VPC for DNS queries. Otherwise custom DNS server can be set up.

DNS hostnames, enabled by default in default VPC (and disabled in custom VPC), assigns public hostnames, if an instance has a public IPv4. DNS resolution must be also enabled for this setting to work.

Both settings must be enabled to use Custom DNS Names in Private Hosted Zone.

Logs both ingress and egress traffic as 1 or 10 minute aggregations. Flow log can be set on whole VPC or be specified at subnet or ENI level. Logs can be sent to CloudWatch Log Group or S3 bucket. Only primary private IP of VPC resources is shown. No logs are captures for DNS, DHCP, NLB, or 169.254.196.x traffic.

Flow (5 tuple) - unidirectional stream of packets that share a common source IP and port, destination IP and port, and protocol.

Log status (the last field in log entry):

• OK - no problems
• NODATA - no traffic
• SKIPDATA - error, some flows weren't logged

Captures, duplicates and sends VPC traffic data to custom endpoint for analysis.

Traffic is captured from specified ENI(s) (sources) and is forwarded to specified targets (ENI or NLB). Source and target can be in the same or different VPC through VPC peering.

EIGW works only with IPv6, similar to NATGW, which works only with IPv4 - allows outbound access to the internet, while preventing internet to initiate connection. Does not need IGW.

Virtual network card. In AWS Management Console and in AWS documentation can also be referred as network interface.

Can be created by user and get attached or detached from EC2. Each instance has a default primary network interface, which can not be detached. One instance can have multiple ENIs. Security groups are actually attached to ENI. ENI is a single AZ resource like EC2 and subnet.

EIP is allocated per account and can be kept as long as it is needed. Bound to ENI (which is connected to an instance) and can be moved to another ENI. Only 5 per account (can be increased).

When EIP is assigned to an instance, its already existing public address gets replaced. Incurs charges when it not associated with running instance. AWS owned IP address is bound to a single AWS region and can not be moved (also address is picked randomly by AWS).

Generally bad practice, DNS resolution should be used instead.

# List existing addresses
$ aws ec2 describe-addresses
# Create EIP
# Outputs AllocationID among other info
$ aws ec2 allocate-address

# Release EIP
# No output implies success
$ aws ec2 releaes-address --allocation-id <allocation_id>

# Associate with ec2
$ aws ec2 associate-address --instance-id <instance_id> --allocation-id <allocation_id>

Privately connects 2 VPCs enabling resources (instance-to-instance) from one VPC to communicate with resources in another VPC. Route tables must be updated in each subnet. Must not have overlapping CIDR blocks. Inter-region peering does not support IPv6. Works between accounts too.

An instance in one VPC can't use IGW, NATGW, Virtual Private Gateway in another VPC. Peering connection is also not transitive - Peering connections A->B, B->C do not create a connection between A and C, must create Peering connection with each VPC. SGs can be referenced from peered VPC.

Private connection from VPC to AWS services (Powered by PowerLink).

By default, traffic from resources in VPC to AWS services goes through public internet (IGW). By using VPC Endpoint establishes direct connection to AWS services within AWS, thus, eliminating costs associated with egress traffic.

Endpoint is set to a specific AWS service, f.e. S3. When creating a connection AWS automatically inserts a new entry to the specified Route table. AWS also attaches a policy to Endpoint, which controls what actions can be performed via that Endpoint (additional security/permissions layer) - doesn't not interfere or overwrite role policy attached to resources in VPC.

pl in route table entry created by VPC Endpoint service stands for prefix lists.

# jiew current prefix list
$ aws ec2 describe-prefix-lists

Connection types:

• interface - provisions ENI as an entry point; must attach SG; supports most AWS services
• gateway - provisions a gateway, thus, must be set as a destination point in route table; supports S3 and DynamoDB

PrivateLink provides secure and scalable way to expose a service to multiple other VPCs, same or different accounts. Service is exposed via NLB, while consumer needs to set up ENI or GWLB. Connection between the two goes through private AWS network, PrivateLink.

It is recommended to use SGs for white-listing traffic and ACLs for blacklisting traffic.

AWS creates default security group for new VPC. SG is locked down to the VPC it was created in - can not be moved.

Security group allows all outbound and denies all inbound traffic by default. Works at the instance level; one instance can belong to multiple security groups. Rules are only permissive. Rules can reference IP address or range or another SG. SG is stateful - response traffic is allowed, if initial connection is allowed. Good practice to maintain separate security group for SSH access. time out response most likely means it is a SG issue, while connection refused means it is an application issue. Other SGs can be referenced as a source when setting a SG - that means instances that have that SG attached are authorized to access newly created SG.

Network ACL (Access Control List) - optional security for VPC that acts as a firewall for one or more subnets. Sits between subnet and route table. Default ACL allows both inbound and outbound traffic, while custom ACL by default denies both inbound and outbound traffic. Non-matching traffic is denied by explicit deny rule. Star (asterisk) rule means if traffic doesn't match any other rule, it is denied; this rule can not be removed. ACL is a list of numbered rules, which are applied from lowest to highest (recommended increment is 100, so that there is space to add more rules later); when lower number rule has matched, it is immediately applied, regardless of higher numbered rules. ACL is stateless - responses for outbound traffic are subject to inbound rules.

Every subnet must be associated with an ACL (only one), if not, it is associated with default ACL. ACL can have multiple subnets associated with it.

NAT device is used to provide internet access to resources in private subnet, but prevent internet from initiating access.

• NAT gateway (recommended)
• NAT instance (runs as an instance in public subnet), must disable source/destination check in EC2

Managed service. Must be launched in public subnet (to have internet access) and have an EIP (can be selected at launch time). Route table of private subnet must be updated.

Provides single AZ resiliency. For fault tolerance deploy multiple NATGWs in different AZs.

VPN services provide encrypted IPsec connection over internet. Can be implemented as Virtual Private Gateway or Transit gateway.

Transit VPC sits between remote site(s) and VPC(s) and acts as an intermediate VPC, which accepts VPN connections from remote site(s) and forwards to the target VPC(s).

Establish VPN connection with resources inside VPC. Can connect with only one VPC. Connection is established between VPGW and Customer Gateway, which is set in on-prem network that could also be behind NAT device. Must enable Route Propagation for VPGW in route table.

Multiple sites that are connected via VPN to the same VPGW can communicate with each other through CloudHub. Dynamic routing must be set up and route tables must be updated.

Regional resource that can connect multiple VPCs in one or multiple accounts, on-prem networks with VPCs. Supports Direct Connect Gateway and VPN. Terminates VPN connection - there is no need for VPGW, and connection can be set directly with subnets. Can peer connect multiple TGWs across regions. Cross-account sharing is done via Resource Access Manager

TGW route table controls traffic flow (can block traffic as well). Supports multicast. Doesn't incur charges when there are no attachments.

# Create a Transit Gateway
$ aws ec2 create-transit-gateway

# Attach Transit Gateway
$ aws ec2 create-transit-gateway-vpc-attachment --transit-gateway-id <transit_gateway_id> --vpc-id <vpc_id> --subnet-ids <subnet_id>

Managed load balancer service.

Operates on a regional level. Uses round-robin load balancing by default.

Provides:

• spread load
• expose single point of access
• handle failures (healthcheck)
• ssl termination (talks https to clients and http to backend)
• enforce stickiness cookies
• separate public from private traffic

Types:

• Classic LB (2009, v1)
• Application LB (2016, v2)
• Network LB (2017, v2)
• Gateway LB (2020, v2)

Load balancers (any type) have a static host name (do not resolve underlying IP). LB 503 error indicates capacity issue or no registered targets. In connection error event check security groups. 504 means that LB couldn't establish connection with the target and/or application is having issues.

Integrates with EC2, ECS and Lambda.

Connection draining (CLB) or deregistration delay (ALB, NLB) allows active connections to complete (within defined time period) before load balancer stops sending traffic to de-registering or unhealthy target. Time period can be set between 1 to 3600 seconds; default is 300 seconds. Can also be disabled by setting value of 0.

It is possible to implement sticky session (session affinity), so that the same client is always redirected to the same instance behind load balancer (CLB and ALB). Implemented as a cookie with an expiration date. Used to ensure that a client doesn't lose his session data.

Application-based cookie:

• custom - generated by target application, and can include any other custom attributes; cookie name must be specified for each target group, and can not be any of the reserved names - AWSALB, AWSALBAPP, AWSALBTG.
• application - generated by load balancer, AWSALBAPP

Duration-based cookie - generated by load balancer, name is AWSALB for ALB and AWSELB for CLB.

Cross-zone load balancing can be used to spread traffic evenly across all instances in different AZs. When enabled, each node of load balancer can forward traffic to any instance in any AZ. When disabled, each node forwards traffic to instances in its AZ. Each node gets even share of total requests from client - 50% for 2 AZs.

• ALB - enabled by default (can be disabled at target group level), free of charge for inter AZ traffic
• NLB, GLB - disabled by default, but can be enabled; pay for inter AZ traffic

SNI (Service Name Indication) works with ALB and NBL. Allows loading multiple SSL/TLS certificates onto one web server (to serve multiple websites). Clients must indicate the hostname of the target server. For ALB and NLB each listener can specify a separate certificate.

Shown as deprecated and is not recommended to be used. Supports HTTP/S, TCP. Provides HTTP or TCP based health checks, and fixed external hostname. Doesn't support IPv6.

Layer 7 (HTTP/S) load balancer that forwards traffic to applications across multiple instances (target groups) or multiple applications on the same machine (containers). Supports HTTP/2 and WebSocket, IPv4 and IPv6. Also able to redirect HTTP to HTTPS. Client's IP is inserted as a X-Forwarded-For header (also X-Forwarded-Port for port and X-Forwarded-Proto for protocol). Provides fixed external hostname.

Weighted target groups provide traffic distribution based on the ration of each target group's weight to the total.

Target groups:

• EC2 instances
• ECS tasks
• Lambda functions
• private IPs

Routing options:

• URL path - example.com/some_path
• hostname in URL - one.example.com
• query strings and headers - example.com/some_path?id=1

ALB has it's own SG for controlling traffic, which can be references in EC2 instance's SG.

Great for micro-services and container-based application.

Layer 4 (TCP, UDP, TLS) high performance (millions of requests per second) and low latency (100ms vs 400ms for ALB) load balancer. Not included in AWS free tier.

Has one static IP per AZ set by AWS, and supports assigning Elastic IP (instead of static IP by AWS).

Backend (connection between load balancer and target group) can be elavated to HTTP, while frontend is TCP.

Health checks support TCP, HTTP(S).

Target groups:

• EC2 instances - if instance ID is specified, traffic is routed to primary private IP in primary ENI, otherwise IP can be specified directly for non-primary IPs
• private IPs
• ALB

Layer 3 (IP) load balancer that forwards traffic to 3rd party network virtual appliances before sending it to the original target. Virtual appliance could be a firewall, Intrusion Detection and Prevention Systems (IDPS), packet inspection, payload manipulator and so on. Appliance target group can either drop the packet based on it's internal logic or send back to GLB, which in turn will send it to original target.

Target groups:

• EC2 instances
• private IPs

Uses GENEVE protocol on port 6081.

ACM issues TLS certificates to use with AWS services. Before issuing a certificate, user must verify that he owns the DNS records for the domain. Certificates are region specific.

Register a domain in Route53, double check hosted zones. Then go to ACM and request a certificate. For domain names a good practice is to enter full domain example.com and a wildcard *.example.com - to be able to include www.example.com and custom subdomain as well. Chose DNS validation as it is more reliable option. Once request is made, it is pending validation and expects a custom CNAME entry to be present. Route53 can automatically create it.

Fully managed and authoritative (customer can update records) DNS solution and Domain Registrar. The only AWS service with 100% availability SLA. 53 references the traditional DNS port.

Functions:

• domain registration
• domain name system
• health check for wep app
• auto naming of service discovery

Provides both public and private (can be resolved only within VPC) hosted zones. $0.50 per month per hosted zone.

Supported record types:

• A
• AAAA
• CNAME
• NS
• CAA, DS, NAPTR, PTR, SOA, TXT, SPF, SRV

Each record contains the following information/attributes:

• domain/subdomain name (example.com)
• record type (A, AAAA, etc)
• value (IP address)
• routing policy (how Route53 should respond to queries)
• TTL (in DNS resolvers)

Alias is an extension to DNS functionality. Maps a hostname to a AWS resource (A/AAAA). Recognizes changes in IP address. Works both for root and non-root domains, as opposed to CNAME (only for non-root). TTL is automatically set by Route53. Can not be set to EC2 DNS name. Requests are free of charge.

Define how Route53 responds to DNS queries.

Geoproximity routing is based on the location of users and resources. Allows shifting traffic to resources based on bias - more traffic (1 to 99), less traffic (-1 to -99). Resources can be AWS (specify region) or non-AWS (specify longitude, latitude). Available as part of advanced feature - Route53 Traffic Flow.

IP-based routing policy directs traffic based on pre-defined CIDR blocks. Can be useful to direct traffic from specific ISP.

Active-active redundancy means in normal circumstances both replicas handle requests.

Active-passive (active-standby) redundancy means secondary replica does not serve any user requests unless first (primary) one fails. Pilot light and warm standby are possible architectures that implement active-passive redundancy.

Health checkers are global and located outside VPC. Multiple checkers (about 15) send requests to endpoint - above 18% successful request is considered healthy (2xx and 3xx responds).

Health checks are integrated with CloudWatch as metrics.

Endpoint type sends requests to applications, servers or other AWS resources.

Configurations:

• healthy/unhealthy threshold
• interval - 30 or 10 seconds
• HTTP/S or TCP
• locations of health checkers
• can be set up to read the received message - first 5120 bytes will be read

Firewall rules must accept incoming requests from Route53 health checkers.

Can be used directly with EC2s, if no load balancer is used, or with load balancers in multiple-regions. In general, a way to set up an automatic DNS failover.

Calculated health check combines the results of multiple health checks (up to 256) into single one. Can be combined with OR, AND or NOT operators.

It is also possible to specify how many children health checks have to pass to make parent check pass.

Health checks can be based on CloudWatch alarm - when alarm is triggered, endpoint is considered unhealthy.

Can be used to check resources in private subnets or on-prem, since Route53 health checkers are located outside client VPC globally.

Content Delivery Network (CDN) service. Traditionally supports static content delivery, but now also supports dynamic content with intelligent caching.

Caches data closer to clients (in Edge location facilities). Integrates with Shield and WAF, provides DDoS protection. Forwards original request along with query strings and headers to the origin and caches response before sending to the client.

Charges for retrieval and HTTP requests. Generally cheaper than S3 fees. For customer facing bucket deploy CloudFront that will get requested objects (no associated costs for requests between CloudFront and S3) and cache them for future requests.

Allowed methods is a list of HTTP methods that a client can request from CloudFront.

Real time logs can be enabled, which sends logs to Kinesis Data Streams. Can be configured based on Sampling Rate (percentage of requests to send), specific field(s) or specific Cache Behaviour.

• S3 bucket - CloudFront distributes and cache files; can also be used as ingress to upload files to S3.
• HTTP origin:
  • ALB or EC2 (must be public), SG must accept requests from CloudFront IPs
  • S3 static website
  • any other HTTP backend

S3 can restrict access only to CloudFront through OAI, Origin Access Identity, similar to a role.

Multiple Origins feature allows routing to different origins based on path.

Origin group consists of one primary and one secondary origin. Provides HA and failover.

Geo Restriction - restrict who can access distribution (country is determined via 3rd party Geo-IP database):

• whitelist - allow access only if a client is in one of the countries in the list of approved countries
• blacklist - deny access only if a client is in one of the countries in the list of banned countries

Objects are cached for the duration of TTL setting, and are automatically cleared upon expiration. Each object has a unique key, which by default consists of hostname and resource portion of URL, but can optionally be enhanced by other elements - HTTP headers, query stings, etc.

Information above is defined in a Cache Policy (also predefined managed policies are available), which defines how objects are cached.

In contrast Origin Request Policy defined original request parts that should be forwarded to origin, but not necessarily be part of cache.

Manual clearing (CloudFront invalidation) is possible for additional charge. Either all files (*) or specific path (/images/*) can be specified for invalidation.

Cache behaviors define different settings based on path or file patterns, e.g. /api/* or *.jpg. Each behavior can be configured to a different origin and/or cache policy. Default behavior is always last to be processed and is applied to all files /*.

Distribute premium shared content. Access is granted via path and can work with any origin.

Signed URL gives access to individual files, while signed cookies give access to multiple files.

Policy rules:

• expiration date
• IP ranges that can access it
• Trusted signers (which AWS accounts can create signed URLs)

Signer types:

• trusted key group (recommended) - create and rotate keys using API, acces to which will in turn in managed by IAM
• CloudFront Key Pair - key is managed by root account

Lightweight functions (in JavaScript) for high-scale, latency sensitive CDN customizations. Applies only to viewer requests and responses (client to and from CloudFront). Can be scaled to millions of request with sub-millisecond response time.

Use cases:

• Cache key normalization (transform request attribute, such as headers, cookies, URL, etc, to optimal cache key)
• Header manipulation (insert/modify/delete HTTP headers in request or response)
• URL rewrite or redirect
• Request authentication and/or authorization

Edge locations have different pricing (per GB) depending on location. More data transferred - lower the price per GB.

Number of Edge locaitons can be reduced for cost reduction. Configured through Prices Classes:

• All - all regions
• 200 - most regions, but most expensive ones are excluded (100 + Africa and East)
• 100 - least expensive regions (generally North America and Europe)

Encrypt specific fields in order to add extra security on top of HTTPS. Uses asymmetric encryption. Client specifies which field(s) to encrypt (up to 10) in POST request, data is encrypted at Edge location and is only decrypted at origin - CloudFront and ALB can not see the data.

Provide public access to S3 bucket through CloudFront distribution:

1. Create CloudFront Origin Access Identity
2. Create a bucket policy granting read-only access to bucket objects (object CanonicalUser from CloudFront origin access identity)

   {
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "CanonicalUser": "..."
               }
               "Action": "s3:GetObject",
               "Resource": "arn:aws:s3:::bucket-name/*"
           }
       ]
   }

3. Create a distribution - specify S3 bucket's domain, and CloudFront origin access Id

Networking service that sends user's traffic through AWS's global network infrastructure, improving network performance by 60%.

Utilizes Edge locations and uses IP based resolution instead of DNS. Provides 2 Anycast IPv4 addresses that send traffic to the closest Edge Location. Connection can be then forwarded to a resource in any AWS region. Endpoints can be EIP, EC2, ALB, NLB - public or private. Health checks are available.

Weighted endpoints provide traffic distribution based on the ration of each endpoint's weight to the total.

Overall similar to CloudFront, thus, uses cases are:

• non-HTTP protocol - gaming (UDP), IoT (MQTT), or voice over IP
• static IP is required
• instance failover (best fail-tolerance)

Fully managed API management service - publish, maintain, monitor, and secure.

Provides monitoring and metrics on API calls. Works with both VPC and on-premise applications, and supports RESTful and Websocket APIs.

Key features:

• WebSocket protocol support
• API versioning
• Multiple environment management
• Authentication and authorization
• OpenAPI (formerly Swagger) for import and export via definitions file
• Request and response validation
• API response caching - default TTL is 300 seconds.
• API keys
• Request throttling - default is 10,000 requests per second per region, and 5,000 concurrent requests across all APIs per region. Both limits can be requested to be increased, hitting the limit results in 429 HTTP error message.
• Logging through CloudWatch

Endpoint types:

• Edge-optimized (default) is for global clients; requests are routed through Edge locations, while API is still located (deployed) in a single region.
• Regional is used within one region. CloudFront can still be deployed manually to have more control over caching strategy and distribution.
• Private type is only accessible from VPC via interface VPC endpoint (ENI); use resource policy to define access to the endpoint

To support applications using legacy SOAP (Simple Object Access Protocol, returns objects in XML format) protocol either configure as a SOAP web service pass through or transform XML response to JSON.

Request validation can be configured to avoid unnecessary calls to the backend. Checks include validating request parameters in URI, query strings, and headers (also ensuring the values are non-blank). Check are performed against OpenAPI definition file via x-amazon-apigateway-request-validation block.

An Account limit of 10000 request per second is set across all APIs. Can be increased upon request. 429 Too Many Requests is returned when the limit is reached. Limits can also be set on stage and method levels.

Errors:

• 400 Bad request
• 403 Access denied
• 429 Quota exceeded
• 502 Bad gateway - usually due to incompatible output returned by a backend, also could be due to out-of-order invocations.
• 503 Service unavailable
• 504 Integration failure - time out exception after 29 seconds

API types:

• HTTP - Lambda proxy, HTTP proxy, and private integrations (no data mapping). Supports OIDC, OAuth 2.0 and CORS. No usage plans nor API keys. Low-latency and cost-efficient.
• WebSocket
• REST API
• REST API private

HTTP vs REST API.

Integration types:

• Lambda
• HTTP - on-prem, ALB and so on (supports rate limiting, caching, user authentication, etc)
• AWS Service
• VPC link
• Mock - simulate backend response (specify status code and message)

Lambda Proxy (AWS_PROXY) option passes client request as an input to Lambda function - request and response can not be modified by API Gateway. For HTTP Proxy option request is similarly sent to the backend and response is forwarded back by API Gateway. HTTP headers can be added.

Mapping templates (parameter mapping) can be used to modify requests and/or responses, rename or modify query parameters, modify body content, add headers, and filter output results. Uses Velocity Template Language, which can utilize loops, conditionals, and so on. Content-Type must be set to either applicaiton/json or application/xml.

• Request
  • Headers
  • Query strings
  • Request path
• Response
  • Headers
  • Status code

API Gateway resource policy can be used to configure additional authorization capabilities, such as cross-account access, enforcing source IP range, or allowing access only within VPC.

Authorization policy is attached to user/group in AWS. Leverages Sig v4 (credentials are placed in header). Works only for AWS identities. Provides both authentication and authorization capabilities. Request flow:

1. client accesses API Gateway
2. API Gateway contacts IAM and verifies received policy
3. IAM returns associated policy
4. based on policy API Gateway forwards request to backend

User is automatically verified by Cognito. Only authenticates user, but doesn't provide authorization. Request flow:

1. client accesses Cognito and receives a token
2. client accesses API Gateway (along with token)
3. API Gateway contacts Cognito to verify token, and forwards request to backend
4. backend must implement authorization

Formerly Custom Authorizers, uses Lambda function to validate token that is passed in request header. Function must return IAM policy. Result of authentication can be cached. Helps to use OAuth, SAML or other 3rd party type of authentication. Provides both authentication and authorization. There are associated costs with each Lambda invocation. Request flow:

1. client accesses API Gateway (along with token)
2. API Gateway invokes Lambda function
3. function verifies the token and returned associated IAM policy
4. based on policy API Gateway forwards request to backend

Changes to API Gateway come to an effect via deployment to stages (number is not limited), which act as a logical references to a set of API. Can be named, and, therefore, represent any logical group, e.g. dev, int, prod or v1, v2, v3. Each stage has it's own configuration, and can be rolled back, because of stored history of deployments. Also each stage has it's own unique invoke URL in the form - https://<api_id>.execute-api.<region>.amazonaws.com/<stage_name>.

Stage variables behave similarly to environment variables, and allow applying changes to a stage without redeployment (format is ${stage_variables.<variable_name>). Can be used in Lambda ARN, HTTP endpoint, or parameter mapping templates - change URL API Gateway is configured to redirect requests, change configuration parameter that are passed to Lambda.

Configurations include cache, request throttling and WAF settings, and client certificates. Monitoring is supported through CloudWatch and X-Ray integrations.

Canary deployment allows deploying a new version as before, but specifying percentage-wise amount of requests that will be directed to old and new versions (canary and current stage) respectively. Once new version is confirmed to be functional, it can be promoted to become a single version served by the stage.

• Modify the stage to update canary settings
• Deploy new version
• Promote new version

Cache settings can be applied per stage, with TTL and invalidation option also applicable on per method level.

• TTL - default 300 seconds, 0-3600s
• Encryption
• Total capacity 0.5GB to 237GB
• Expensive (should be used in prod only)

Clients can invalidate entire cache using Cache-Control: max-age=0 header. Control who can perform cache invalidation using authorization settings and execute-api:InvalidateCache IAM permission.

Usage plan defines who can access API stages and methods, how much and how fast. Individual throttling and quotas can be imposed on clients. API Keys are used to identify clients, which is an alphanumeric string value. Must be supplied in x-api-key header.

Configuration steps:

• Create APIs and configure methods to require API Key
• Generate and distribute API Keys
• Create Usage Plan
• Associate API Keys and Usage Plan

Logging is supported via CloudWatch integration. Logs contain information about request and response body. Logging settings can be set on stage level, including log level, but also can be overwritten on individual API level.

Tracing is supported via X-Ray integration.

Metric can be observed via CloudWatch metrics. Provide data per stage; optional detailed monitoring can also be enabled. Popular metrics:

• CacheHitCount and CacheMissCount
• Count (total number of requests)
• IntegrationLatency (time between API Gateway relays a request to backend and receives a response)
• Latency (time between request from client and response to the client, include integration latency and other API Gateway overhead)
• 4xxError and 5xxError

Maximum 29 second to perform a request by API Gateway.

Direct Connect (DX) established dedicated private connection to AWS bypassing the internet. Direct Connect Gateway is used to connect customer network to multiple VPCs (even in different regions). Data in transit is not encrypted - need to set up VPN on top of Direct Connect for IPsec-encryption.

• dedicated - physical connection that terminates at Direct Connect location
• hosted - "Last-mile" connection is provided by a Direct Connect partner

High resiliency model establishes 1 Direct Connect connection with each on-prem location. Maximum resiliency models establishes 2 Direct Connect connections with each location.

• AWS Outposts
• Edge locations

Fully operational mini region inside customer's site.

Also called AWS Point of Presence.

Global network of servers outside of regions. CloudFront, Route53, and Global Accelerator leverage Edge locations.

API Gateway also can use Edge location alongside Lambda at Edge.