Author: jayendrapatil

AWS Single Sign-On SSO

~ jayendrapatil

AWS Single Sign-On SSO

  • AWS Single Sign-On is a cloud-based single sign-on (SSO) service that makes it easy to centrally manage SSO access to all of the AWS accounts and cloud applications.
  • AWS SSO also helps manage access and permissions to commonly used third-party software as a service (SaaS) applications, AWS SSO-integrated applications as well as custom applications that support SAML 2.0.
  • AWS SSO includes a user portal where the end-users can find and access all their assigned AWS accounts, cloud applications, and custom applications in one place.

AWS SSO Features

  • AWS Organizations Integration
    • natively integrates with AWS Organizations and enumerates all the AWS accounts.
  • SSO access to AWS accounts and cloud applications
    • helps manage Single Sign-On across all the AWS accounts, cloud applications, AWS SSO-integrated applications, and custom SAML 2.0–based applications, without custom scripts or third-party SSO solutions.
  • Create and manage users and groups in AWS SSO
    • provides a default store to manage the users and groups directly in the console.
    • It also connects to an existing AWS Managed Microsoft AD directory and manages the users with standard Active Directory management tools provided in Windows Server.
  • Leverage your existing corporate identities
    • is integrated with Microsoft AD through the AWS Directory Service to allow sign-in to the AWS Single Sign-On user portal using their corporate Active Directory credentials.
  • Compatible with commonly used cloud applications
    • supports commonly used cloud applications such as Salesforce, Box, and Office 365.
  • Easy to set up and monitor usage
    • Is quick to set up, highly available and provides a completely secure infrastructure that scales to the needs and does not require software or hardware to manage.
    • Integrates with AWS CloudTrail providing the visibility to monitor and audit Single Sign-On activity in one place.
  • Co-exists with existing IAM users, roles, and policies
    • has no impact on the users, roles, or policies that are already managed in IAM.
  • No-cost identity management
    • available at no additional cost.

AWS SSO Identity Source

  • AWS SSO identity store
    • provides a default store to create and manage the users and groups, and assign their level of access to the AWS accounts and applications.
  • Active Directory
    • Supports self-managed Active Directory (AD) or AWS Managed Microsoft AD directory using AWS Directory Service.
  • External identity provider
    • Supports external identity providers (IdP) such as Okta or Azure AD.

AWS SSO Use Case

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Which of the following can a customer use to enable single sign-on (SSO) to the AWS Console?
    1. Amazon Connect
    2. AWS Single Sign-On
    3. Amazon Pinpoint
    4. Amazon Rekognition

References

AWS_Single_Sign-On

AWS Route 53 Routing Policy

~ Last updated on : ~ jayendrapatil ~ 7 Comments

AWS Route 53 Routing Policy

AWS Route 53 routing policy determines how AWS would respond to the DNS queries and provides multiple routing policy options.

Simple Routing Policy

  • Simple routing policy is a simple round-robin policy and can be applied when there is a single resource doing the function for the domain e.g. web server that serves content for the website.
  • Simple routing helps configure standard DNS records, with no special Route 53 routing such as weighted or latency.
  • Route 53 responds to the DNS queries based on the values in the resource record set e.g. IP address in an A record.
  • Simple routing does not allow the creation of multiple records with the same name and type, but multiple values can be specified in the same record, such as multiple IP addresses.
  • Route 53 displays all the values to resolve it recursively in random order and the resolver displays the values for the client. The client then chooses a value and resends the query.
  • Simple routing policy does not support health checks, so the record would be returned to the client even if it is unhealthy.
  • With Alias record enabled, only one AWS resource or one record can be specified in the current hosted zone.

Weighted Routing Policy

  • Weighted routing policy helps route traffic to different resources in specified proportions (weights) e.g., 75% to one server and 25% to the other during a pilot release
  • Weights can be assigned between any number from 0 to 255 inclusive.
  • Weighted routing policy can be applied when there are multiple resources that perform the same function e.g., webservers serving the same site
  • Weighted resource record sets allow associating multiple resources with a single DNS name.
  • Weighted routing policy use cases include
    • load balancing between regions
    • A/B testing and piloting new versions of software
  • To create a group of weighted resource record sets, two or more resource record sets can be created that has the same combination of DNS name and type, and each resource record set is assigned a unique identifier and a relative weight.
  • When processing a DNS query, Route 53 searches for a resource record set or a group of resource record sets that have the specified name and type.
  • Route 53 selects one from the group. The probability of any one resource record set being selected depends on its weight as a proportion of the total weight for all resource record sets in the group for e.g., suppose www.example.com has three resource record sets with weights of 1 (20%), 1 (20%), and 3 (60%)(sum = 5). On average, Route 53 selects each of the first two resource records sets one-fifth of the time and returns the third resource record set three-fifths of the time.
  • Weighted routing policy supports health checks.

Latency-based Routing (LBR) Policy

  • Latency-based Routing Policy helps respond to the DNS query based on which data center gives the user the lowest network latency.
  • Latency-based routing policy can be used when there are multiple resources performing the same function and Route 53 needs to be configured to respond to the DNS queries with the resources that provide the fastest response with the lowest latency.
  • A latency resource record set can be created for the EC2 resource in each region that hosts the application. When Route 53 receives a query for the corresponding domain, it selects the latency resource record set for the EC2 region that gives the user the lowest latency. Route 53 then responds with the value associated with that resource record set for e.g., you might have web servers for example.com in the EC2 data centers in Ireland and in Tokyo. When a user browses example.com from Singapore, Route 53 will pick up the data center (Tokyo) which has the lowest latency from the user’s location
  • Latency between hosts on the Internet can change over time as a result of changes in network connectivity and routing. Latency-based routing is based on latency measurements performed over a period of time, and the measurements reflect these changes for e.g. if the latency from the user in Singapore to Ireland improves, the user can be routed to Ireland
  • Latency-based routing cannot guarantee users from the same geographic will be served from the same location for any compliance reason
  • Latency resource record sets can be created using any record type that Route 53 supports except NS or SOA.
  • Latency-based routing policy supports health checks.

Failover Routing Policy

  • Failover routing policy allows active-passive failover configuration, in which one resource (primary) takes all traffic when it’s healthy and the other resource (secondary) takes all traffic when the first isn’t healthy.
  • Route 53 health checking agents will monitor each location/endpoint of the application to determine its availability.
  • Failover routing policy is applicable for Public hosted zones only.

Geolocation Routing Policy

  • Geolocation routing policy helps respond to DNS queries based on the geographic location of the users i.e. location from which the DNS queries originate.
  • Geolocation routing policy use cases include
    • localization of content and presenting some or all of the website in the user’s language
    • restrict distribution of content to only the locations in which you have distribution rights.
    • balancing load across endpoints in a predictable, easy-to-manage way, so that each user location is consistently routed to the same endpoint.
  • Geolocation routing policy allows geographic locations to be specified by continent, country, or by state (only in the US)
  • Geolocation record sets, if created, for overlapping geographic regions for e.g. continent, and then for the country within the same continent, priority goes to the smallest geographic region, which allows some queries for a continent to be routed to one resource and queries for selected countries on that continent to a different resource
  • Geolocation works by mapping IP addresses to locations, which might not be mapped to an exact geographic location.
  • A default resource record set can be created to handle these queries and also the ones which do not have an explicit record set created.
  • Route 53 returns a “no answer” response for queries from those locations if a default resource record set is not created.
  • Two geolocation resource record sets that specify the same geographic location cannot be created.
  • Route 53 supports the edns-client-subnet extension of EDNS0 (EDNS0 adds several optional extensions to the DNS protocol.) to improve the accuracy of geolocation routing.

Geoproximity Routing Policy

  • Geoproximity routing helps route traffic to the resources based on the geographic location of the users and the resources.
  • Geoproximity routing can be configured with a bias to optionally choose to route more traffic or less to a given resource. A bias expands or shrinks the size of the geographic region from which traffic is routed to a resource.
  • Route 53 Traffic flow can be used to create Geoproximity routing flows.
  • Route 53 supports both the AWS region where the resource is created and the latitude and longitude of the resource.

Multivalue Routing Policy

  • Multivalue routing helps return multiple values, e.g. IP addresses for the web servers, in response to DNS queries.
  • Multivalue routing also helps check the health of each resource, so only the values for healthy resources are returned.
  • Route 53 responds to DNS queries with up to eight healthy records and gives different answers to different DNS resolvers.
  • Multivalue answer routing is not a substitute for a load balancer, but the ability to return multiple health-checkable IP addresses is a way to use DNS to improve availability and load balancing.
  • To route traffic approximately randomly to multiple resources, such as web servers, one multivalue answer record can be created for each resource and, optionally, associate a Route 53 health check with each record. If a web server becomes unavailable after the resolver caches a response, client software can try another IP address in the response.

Route 53 Traffic Flow

  • Route 53 Traffic Flow helps easily manage traffic globally through a variety of routing types combined with DNS Failover in order to enable a variety of low-latency, fault-tolerant architectures.
  • Traffic Flow provides a simple visual editor, to easily manage how the end-users are routed to the application’s endpoints – whether in a single AWS region or distributed around the globe.
  • Traffic Flow routes traffic based on multiple criteria, such as endpoint health, geographic location, and latency.
  • Traffic Flow’s versioning feature maintains a history of changes to the traffic policies to allow easy rollback to the previous version.

Route 53 Complex Routing Policies

Route 53 Complex Routing Policies

  • Route 53 can be used to define more complex and nested routing policies
  • A combination of alias records (such as weighted alias and failover alias) and non-alias records can be used to build a decision tree that gives you greater control over how Route 53 responds to requests.
  • Resources would be created from the bottom of the tree

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You have deployed a web application targeting a global audience across multiple AWS Regions under the domain name example.com. You decide to use Route 53 Latency-Based Routing to serve web requests to users from the region closest to the user. To provide business continuity in the event of server downtime you configure weighted record sets associated with two web servers in separate Availability Zones per region. During a DR test you notice that when you disable all web servers in one of the regions Route 53 does not automatically direct all users to the other region. What could be happening? (Choose 2 answers)
    1. Latency resource record sets cannot be used in combination with weighted resource record sets.
    2. You did not setup an http health check for one or more of the weighted resource record sets associated with the disabled web servers
    3. The value of the weight associated with the latency alias resource record set in the region with the disabled servers is higher than the weight for the other region.
    4. One of the two working web servers in the other region did not pass its HTTP health check
    5. You did not set “Evaluate Target Health” to “Yes” on the latency alias resource record set associated with example.com in the region where you disabled the servers.
  2. The compliance department within your multi-national organization requires that all data for your customers that reside in the European Union (EU) must not leave the EU and also data for customers that reside in the US must not leave the US without explicit authorization. What must you do to comply with this requirement for a web based profile management application running on EC2?
    1. Run EC2 instances in multiple AWS Availability Zones in single Region and leverage an Elastic Load Balancer with session stickiness to route traffic to the appropriate zone to create their profile (should be in 2 different regions – US and Europe)
    2. Run EC2 instances in multiple Regions and leverage Route 53’s Latency Based Routing capabilities to route traffic to the appropriate region to create their profile (Latency based routing policy would not guarantee the compliance requirement)
    3. Run EC2 instances in multiple Regions and leverage a third party data provider to determine if a user needs to be redirect to the appropriate region to create their profile
    4. Run EC2 instances in multiple AWS Availability Zones in a single Region and leverage a third party data provider to determine if a user needs to be redirect to the appropriate zone to create their profile(should be in 2 different regions – US and Europe)
  3. A US-based company is expanding their web presence into Europe. The company wants to extend their AWS infrastructure from Northern Virginia (us-east-1) into the Dublin (eu-west-1) region. Which of the following options would enable an equivalent experience for users on both continents?
    1. Use a public-facing load balancer per region to load-balance web traffic, and enable HTTP health checks.
    2. Use a public-facing load balancer per region to load-balance web traffic, and enable sticky sessions.
    3. Use Amazon Route 53, and apply a geolocation routing policy to distribute traffic across both regions
    4. Use Amazon Route 53, and apply a weighted routing policy to distribute traffic across both regions.
  4. You have been asked to propose a multi-region deployment of a web-facing application where a controlled portion of your traffic is being processed by an alternate region. Which configuration would achieve that goal?
    1. Route 53 record sets with weighted routing policy
    2. Route 53 record sets with latency based routing policy
    3. Auto Scaling with scheduled scaling actions set
    4. Elastic Load Balancing with health checks enabled
  5. Your company is moving towards tracking web page users with a small tracking image loaded on each page. Currently you are serving this image out of us-east, but are starting to get concerned about the time it takes to load the image for users on the west coast. What are the two best ways to speed up serving this image? Choose 2 answers
    1. Use Route 53’s Latency Based Routing and serve the image out of us-west-2 as well as us-east-1
    2. Serve the image out through CloudFront
    3. Serve the image out of S3 so that it isn’t being served of your web application tier
    4. Use EBS PIOPs to serve the image faster out of your EC2 instances
  6. Your API requires the ability to stay online during AWS regional failures. Your API does not store any state, it only aggregates data from other sources – you do not have a database. What is a simple but effective way to achieve this uptime goal?
    1. Use a CloudFront distribution to serve up your API. Even if the region your API is in goes down, the edge locations CloudFront uses will be fine.
    2. Use an ELB and a cross-zone ELB deployment to create redundancy across datacenters. Even if a region fails, the other AZ will stay online.
    3. Create a Route53 Weighted Round Robin record, and if one region goes down, have that region redirect to the other region.
    4. Create a Route53 Latency Based Routing Record with Failover and point it to two identical deployments of your stateless API in two different regions. Make sure both regions use Auto Scaling Groups behind ELBs. (Refer link)

References

AWS Route 53 Resolver – Hybrid DNS

~ Last updated on : ~ jayendrapatil

AWS Route 53 Resolver – Hybrid DNS

  • Route 53 Resolver provides automatic DNS resolution within the VPC. It can help resolve DNS queries between VPCs and on-premises networks.
  • By default, Resolver answers DNS queries for VPC domain names such as domain names for EC2 instances or ELB load balancers.
  • Route 53 Resolver performs recursive lookups against public name servers for all other domain names.
  • However, on-premises instances cannot resolve Route 53 DNS entries and Route 53 cannot resolve on-premises DNS entries.
  • DNS resolution between VPC and on-premises network can be configured over a Direct Connect or VPN connection.
  • Route 53 Resolver is regional.
  • To use inbound or outbound forwarding, create a Resolver endpoint in the VPC.
  • As part of the definition of an endpoint, specify the IP addresses to forward inbound DNS queries to or the IP addresses that outbound queries originate from. For each IP address specified, Resolver automatically creates a VPC elastic network interface.

Inbound Endpoint – Forward DNS queries from resolvers on your network to AWS

  • DNS resolvers on the on-premises networks can forward DNS queries to Resolver in a specified VPC.
  • This enables DNS resolvers to easily resolve domain names for AWS resources such as EC2 instances or records in a Route 53 private hosted zone. 

Outbound Endpoint – Conditionally forward queries from a VPC to resolvers on your network

  • Route 53 Resolver can be configured to forward queries that it receives from EC2 instances in the VPCs to DNS resolvers on the on-premises networks.
  • To forward selected queries, Resolver rules can be created that specify the domain names for the DNS queries that you want to forward (such as example.com), and the IP addresses of the DNS resolvers on the on-premises network that you want to forward the queries to.
  • If a query matches multiple rules (example.com, acme.example.com), Resolver chooses the rule with the most specific match (acme.example.com) and forwards the query to the IP addresses that you specified in that rule. 

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company wants to install a new private intranet service using Amazon EC2 instances inside a Virtual Private Cloud (VPC). The VPC is connected to the company’s on-premises network using an AWS Site-to-Site VPN. The new service must communicate with the on-premises services already in place. On-premises services are accessed using company-owned hostnames. for instance, a DNS zone. This DNS zone is entirely on-premises and accessible only via the company’s private network. To connect the new service with current services, a solutions architect must guarantee that the new service can resolve hostnames on the company’s example domain. Which solution satisfies these criteria?
    1. Create an empty private zone in Route 53 for company.example . Add an additional NS record to the company’s on-premises company.example zone that points to the authoritative name servers for the new private zone in Route 53.
    2. Turn on DNS hostnames for the VPC. Configure a new outbound endpoint with Route 53 Resolver. Create a Resolver rule to forward requests for company.example to the on-premises name servers.
    3. Turn on DNS hostnames for the VPC. Configure a new inbound resolver endpoint with Route 53 Resolver. Configure the on-premises DNS server to forward requests for company.example to the new resolver.
    4. Use AWS Systems Manager to configure a run document that will install a hosts file that contains any required hostnames. Use an Amazon EventBridge (Amazon CloudWatch Events) rule to run the document when an instance is entering the running state.

References

AWS Storage Options – EBS & Instance Store

~ Last updated on : ~ jayendrapatil ~ 7 Comments

AWS Storage Options – EBS & Instance Store

  • Elastic Block Store – EBS and Instance Store provide block-level storage options for EC2 instances.

Elastic Block Store (EBS) volume

  • EBS provides durable block-level storage for use with EC2 instances
  • EBS volumes are off-instance, network-attached storage (NAS) that persists independently from the running life of a single EC2 instance.
  • EBS volume is attached to an instance and can be used as a physical hard drive, typically by formatting it with the file system of your choice and using the file I/O interface provided by the instance operating system.
  • EBS volume can be used to boot an EC2 instance (EBS-root AMIs only), and multiple EBS volumes can be attached to a single EC2 instance.
  • EBS volume can be attached to a single EC2 instance only at any point in time.
  • EBS Multi-Attach volume can be attached to multiple EC2 instances.
  • EBS provides the ability to take point-in-time snapshots, which are persisted in S3. These snapshots can be used to instantiate new EBS volumes and to protect data for long-term durability
  • EBS snapshots can be copied across AWS regions as well, making it easier to leverage multiple AWS regions for geographical expansion, data center migration, and disaster recovery

Ideal Usage Patterns

  • EBS is meant for data that changes relatively frequently and requires long-term persistence.
  • EBS volume provides access to raw block-level storage and is particularly well-suited for use as the primary storage for a database or file system
  • EBS Provisioned IOPS volumes are particularly well-suited for use with databases applications that require a high and consistent rate of random disk reads and writes

Anti-Patterns

  • Temporary Storage
    • EBS volume persists independent of the attached EC2 life cycle.
    • For temporary storage such as caches, buffers, queues, etc it is better to use local instance store volumes, SQS, or Elastic Cache
  • Highly-durable storage
    • EBS volumes with less than 20 GB of modified data since the last snapshot are designed for between 99.5% and 99.9% annual durability; volumes with more modified data can be expected to have proportionally lower durability
    • For highly durable storage, use S3 or Glacier which provides 99.999999999% annual durability per object
  • Static data or web content
    • For static web content, where data infrequently changes, EBS with EC2 would require a web server to serve the pages.
    • S3 may represent a more cost-effective and scalable solution for storing this fixed information and is served directly out of S3.

EBS Performance

  • EBS provides two volume types: standard volumes and Provisioned IOPS volumes which differ in performance characteristics and pricing model, allowing you to tailor the storage performance and cost to the needs of the applications.
  • EBS Volumes can be attached and striped across multiple similarly-provisioned EBS volumes using RAID 0 or logical volume manager software, thus aggregating available IOPs, total volume throughput, and total volume size.
  • Standard volumes offer cost-effective storage for applications with moderate or bursty I/O requirements. Standard volumes are also well suited for use as boot volumes, where the burst capability provides fast instance start-up times.
  • Provisioned IOPS volumes are designed to deliver predictable, high performance for I/O intensive workloads such as databases. With Provisioned IOPS, you specify an IOPS rate when creating a volume, and then EBS provisions that rate for the lifetime of the volume.
  • As EBS volumes are network-attached devices, other network I/O performed by the instance, as well as the total load on the shared network, can affect individual EBS volume performance.
  • EBS-optimized instances can be launched which deliver dedicated throughput between EC2 and EBS and enables instances to fully utilize the Provisioned IOPS on an EBS volume,
  • Each separate EBS volume can be configured as EBS standard or EBS Provisioned IOPS as needed. Alternatively, you could stripe the data.

EBS Durability & Availability

  • EBS volumes are designed to be highly available and reliable.
  • EBS volume data is replicated across multiple servers in a single AZ to prevent the loss of data from the failure of any single component.
  • EBS volume durability depends on both the size of the volume and the amount of data that has changed since your last snapshot
  • EBS snapshots are incremental, point-in-time backups, containing only the data blocks changed since the last snapshot.
  • Frequent snapshots are recommended to maximize both the durability and availability of their  EBS data
  • EBS snapshots provide an easy-to-use disk clone or disk image mechanism for backup, sharing, and disaster recovery.

EBS Cost Model

  • EBS pricing has 3 components: provisioned storage, I/O requests, and snapshot storage
  • Standard volumes are charged per GB-month of provisioned storage and per million I/O requests
  • EBS Provisioned IOPS volumes are charged per GB-month of provisioned storage and per Provisioned IOPS-month
  • For both volumes, EBS snapshots are charged per GB-month of data stored. EBS snapshot copy is charged for the data transferred between regions, and for the standard EBS snapshot charges in the destination region.
  • EBS volume storage capacity is allocated at the time of volume creation, and you are charged for this allocated storage even if not used.
  • For EBS snapshots, you are charged only for storage actually used (consumed). Note that EBS snapshots are incremental and compressed, so the storage used in any snapshot is generally much less than the storage consumed on an EBS volume

EBS Scalability and Elasticity

  • EBS volumes can easily and rapidly be provisioned and released to scale in and out with the changing total storage demands
  • EBS volumes cannot be resized, and if additional storage is needed either
    • An additional volume can be attached
    • Create a snapshot and create a new volume from the snapshot with a higher volume size
  • EBS volumes can be resized dynamically, but cannot be reduced by size.

Interfaces

  • AWS offers management APIs for EBS in both SOAP and REST formats which can be used to create, delete, describe, attach, and detach EBS volumes for the EC2 instances as well as to create, delete, and describe snapshots from EBS to S3; and to copy snapshots across regions.
  • Amazon also offers the same capabilities through AWS Management Console

Instance Store Volumes

  • Instance Store volumes are also referred to as Ephemeral Storage.
  • Instance Store volumes provide temporary block-level storage and consist of a preconfigured and pre-attached block of disk storage on the same physical server as the EC2 instance
  • Instance storage’s amount of disk storage depends on the Instance type and larger instances provide both more and larger instance store volumes. Smaller instance types such as micro instances can only be launched with EBS volumes.
  • Storage-optimized instances provide special purpose instance storage targeted to specific uses case for e.g. HI1 provides very fast solid-state drive (SSD) backed instance storage capable of supporting over 120,000 random read IOPS, and is optimized for very high random I/O performance and low cost per IOPS. While, HS1 instances are optimized for very high storage density, low storage cost, and high sequential I/O performance.
  • Instance store volumes, unlike EBS volumes, cannot be detached or attached to another instance.

Ideal Usage Patterns

  • EC2 local instance store volumes are fast, free (that is, included in the price of the EC2 instance) “scratch volumes” best suited for storing temporary data that is continually changing, such as buffers, caches, scratch data or can easily be regenerated, or data that is replicated for durability
  • High I/O instances provide instance store volumes backed by SSD, and are ideally suited for many high performance database workloads. for e.g. applications include NoSQL databases like Cassandra and MongoDB.
  • High storage instances support much higher storage density per EC2 instance and are ideally suited for applications that benefit from high sequential I/O performance across very large datasets. e.g. applications include data warehouses, Hadoop storage nodes, seismic analysis, cluster file systems, etc.

Anti-Patterns

  • Persistent storage
    • For persistent virtual disk storage similar to a physical disk drive for files or other data that must persist longer than the lifetime of a single  EC2 instance, EBS volumes or S3 are more appropriate.
  • Relational database storage
    • In most cases, relational databases require storage that persists beyond the lifetime of a single EC2 instance, making EBS volumes the natural choice.
  • Shared storage
    • Instance store volumes are dedicated to a single EC2 instance, and cannot be shared with other systems or users.
    • If you need storage that can be detached from one instance and attached to a different instance, or if you need the ability to share data easily, S3 or EBS volumes are the better choices.
  • Snapshots
    • If you need the convenience, long-term durability, availability, and shareability of point-in-time disk snapshots, EBS volumes are a better choice.

Instance Store Performance

  • Non-SSD-based instance store volumes in most EC2 instance families have performance characteristics similar to standard EBS volumes.
  • EC2 instance virtual machine and the local instance store volumes are located in the same physical server, and interaction with the storage is very fast, particularly for sequential access.
  • To further increase aggregate IOPS, or to improve sequential disk throughput, multiple instance store volumes can be grouped together using RAID 0 (disk striping) software.
  • Because the bandwidth to the disks is not limited by the network, aggregate sequential throughput for multiple instance volumes can be higher than for the same number of EBS volumes.
  • SSD instance store volumes in the EC2 high I/O instances provide from tens of thousands to hundreds of thousands of low-latency, random 4 KB random IOPS.
  • Because of the I/O characteristics of SSD devices, write performance can be variable.
  • Instance store volumes on EC2 high storage instances provide very high storage density and high sequential read and write performance. High storage instances are capable of delivering 2.6 GB/sec of sequential read and write performance when using a block size of 2 MB.

Instance Store Durability and Availability

  • EC2 local instance store volumes are not intended to be used as durable disk storage and they persist only during the life of the associate EC2 instance

Cost Model

  • Cost of the EC2 instance includes any local instance store volumes if the instance type provides them.
  • While there is no additional charge for data storage on local instance store volumes, note that data transferred to and from EC2 instance store volumes from other AZs or outside of an EC2 region may incur data transfer charges, and additional charges will apply for use of any persistent storage, such as S3, Glacier, EBS volumes, and EBS snapshots

Scalability and Elasticity

  • Local instance store volumes are tied to a particular EC2 instance and are fixed in number and size for a given EC2 instance type, so the scalability and elasticity of this storage are tied to the number of EC2 instances.

Interfaces

  • Instance store volumes are specified using the block device mapping feature of the EC2 API and the AWS Management Console
  • To the EC2 instance, an instance store volume appears just like a local disk drive. To write to and read data from instance store volumes, use the native file system I/O interfaces of the chosen operating system.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Which of the following provides the fastest storage medium?
    1. Amazon S3
    2. Amazon EBS using Provisioned IOPS (PIOPS)
    3. SSD Instance (ephemeral) store (SSD Instance Storage provides 100,000 IOPS on some instance types, much faster than any network-attached storage)
    4. AWS Storage Gateway

References

AWS Global Accelerator

AWS Global Accelerator
~ Last updated on : ~ jayendrapatil

AWS Global Accelerator

  • AWS Global Accelerator is a networking service that helps improve the availability and performance of the applications to global users.
  • AWS Global Accelerator optimizes the path to applications to keep packet loss, jitter, and latency consistently low.
  • helps improve the performance of the applications by lowering first-byte latency (the round trip time for a packet to go from a client to your endpoint and back again) and jitter (the variation of latency), and increasing throughput (amount of data transferred in a second) as compared to the public internet.
  • Global Accelerator uses the vast, well-monitored, congestion-free, redundant AWS global network to route TCP and UDP traffic to a healthy application endpoint in the closest AWS Region to the user.
  • is a global service that supports endpoints in multiple AWS Regions.
  • supports AWS application endpoints, such as ALBs, NLBs, EC2 Instances, and Elastic IPs without making user-facing changes.
  • provides two global static public IPs that act as a fixed entry point to the application hosted in one or more AWS Regions, improving availability.
  • helps anycast the static IP addresses from the AWS edge network which serves as the frontend interface of the applications.
  • Using static IP addresses ensures you don’t need to make any client-facing changes or update DNS records as you modify or replace endpoints.
  • allows you to bring your own IP addresses (BYOIP) and use them as a fixed entry point to the application endpoints
  • Global Accelerator allocates two static IPv4 addresses serviced by independent network zones which isolated units with their own set of physical infrastructure and service IP addresses from a unique IP subnet. If one IP address from a network zone becomes unavailable, due to network disruptions or IP address blocking by certain client networks, the client applications can retry using the healthy static IP address from the other isolated network zone.
  • currently supports IPv4 addresses.
  • continuously monitors the health of the application endpoints by using TCP, HTTP, and HTTPS health checks.
  • automatically re-routes the traffic to the nearest healthy available endpoint to mitigate endpoint failure.
  • terminates TCP connections from clients at AWS edge locations and, almost concurrently, establishes a new TCP connection with your endpoints. This gives clients faster response times (lower latency) and increased throughput.
  • supports Client Affinity which helps build stateful applications.
  • supports Client IP address preservation except for NLBs and EIPs endpoints.
  • integrates with AWS Shield Standard, which minimizes application downtime and latency from DDoS attacks by using always-on network flow monitoring and automated in-line mitigation.
  • does not support on-premises endpoints. However, an NLB can be configured to address the on-premises endpoints while Global Accelerator points to the NLB.

AWS Global Accelerator

Global Accelerator vs CloudFront

  • Global Accelerator and CloudFront both use the AWS global network and its edge locations around the world.
  • Both services integrate with AWS Shield for DDoS protection.
  • Performance
    • CloudFront improves performance for both cacheable content (such as images and videos) and dynamic content (such as API acceleration and dynamic site delivery).
    • Global Accelerator improves performance for a wide range of applications over TCP or UDP by proxying packets at the edge to applications running in one or more AWS Regions.
  • Use Cases
    • CloudFront is a good fit for HTTP use cases
    • Global Accelerator is a good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or VoIP, as well as for HTTP use cases that require static IP addresses or deterministic, fast regional failover.
  • Caching
    • CloudFront supports Edge caching
    • Global Accelerator does not support Edge Caching.

AWS CloudFront vs Global Accelerator

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. What features does AWS Global Accelerator provide? (Select TWO)
    1. Improved security
    2. Improved durability
    3. Improved performance
    4. Improved cost optimization
    5. Improved availability
  2. A company that develops web applications has launched hundreds of Application Load Balancers (ALBs) in multiple Regions. The company wants to create an allow list for the IPs of all the load balancers on its firewall device. A solutions architect is looking for a one-time, highly available solution to address this request, which will also help reduce the number of IPs that need to be allowed by the firewall. What should the solutions architect recommend to meet these requirements?
    1. Create an AWS Lambda function to keep track of the IPs for all the ALBs in different Regions. Keep refreshing this list.
    2. Set up a Network Load Balancer (NLB) with Elastic IPs. Register the private IPs of all the ALBs as targets to this NLB.
    3. Launch AWS Global Accelerator and create endpoints for all the Regions. Register all the ALBs in different Regions to the corresponding endpoints.
    4. Set up an Amazon EC2 instance, assign an Elastic IP to this EC2 instance, and configure the instance as a proxy to forward traffic to all the ALBs.

References

AWS_Global_Accelerator

AWS Route 53 Alias vs CNAME

Route 53 CNAME vs Alias Records
~ Last updated on : ~ jayendrapatil

AWS Route 53 Alias vs CNAME

  • Route 53 Alias records are similar to CNAME records, but there are some important differences.
  • Supported Resources
    • Alias records support selected AWS resources
      • Elastic Load Balancers
      • CloudFront distributions
      • API Gateway
      • Elastic Beanstalk
      • S3 Website
      • Global Accelerator
      • VPC Interface Endpoints
      • Route 53 record in the same hosted zone
    • Alias records do not support
      • EC2 DNS endpoint
      • RDS DNS endpoint
    • CNAME record can redirect DNS queries to any DNS record
  • Zone Apex or Root domain like example.com
    • Alias record supports mapping Zone Apex records
    • CNAME record does not support Zone Apex records
  • Charges
    • Route 53 doesn’t charge for alias queries to AWS resources
    • Route 53 charges for CNAME queries.
  • Record Type
    • Alias records only support A or AAAA record types
    • CNAME record redirects DNS queries for a record name regardless of the record type specified in the DNS query, such as A or AAAA.

Route 53 Alias vs CNAME Comparison

Route 53 CNAME vs Alias Records

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Which of the following statements are true about Amazon Route 53 resource records? Choose 2 answers
    1. An Alias record can map one DNS name to another Amazon Route 53 DNS name.
    2. A CNAME record can be created for your zone apex.
    3. An Amazon Route 53 CNAME record can point to any DNS record hosted anywhere.
    4. TTL can be set for an Alias record in Amazon Route 53.
    5. An Amazon Route 53 Alias record can point to any DNS record hosted anywhere.
  2. How can the domain’s zone apex for example “myzoneapexdomain com” be pointed towards an Elastic Load Balancer?
    1. By using an AAAA record
    2. By using an A record
    3. By using an Amazon Route 53 CNAME record
    4. By using an Amazon Route 53 Alias record

References

AWS_Route_53_Alias_CNAME_Comparision

AWS CloudFront Edge Functions

~ Last updated on : ~ jayendrapatil

AWS CloudFront Edge Functions

  • AWS CloudFront helps write your own code to customize how the CloudFront distributions process HTTP requests and responses.
  • The code runs close to the viewers (users) to minimize latency, and without having to manage servers or other infrastructure.
  • Custom code can manipulate the requests and responses that flow through CloudFront, perform basic authentication and authorization, generate HTTP responses at the edge, and more.
  • CloudFront Edge Functions currently supports two types
    • CloudFront Functions
    • Lambda@Edge

 

Architectural diagram.

CloudFront Functions

  • is a CloudFront native feature (code is managed entirely within CloudFront) and visible only on the CloudFront dashboard.
  • supports lightweight functions written only in JavaScript language
  • runs in Edge Locations
  • has process-based isolation
  • supports Viewer Request, Viewer Response trigger events only
    • Viewer Request: after CloudFront receives the request from the Viewer
    • Viewer Response: before CloudFront forwards the response to the Viewer
  • supports sub-millisecond execution time
  • scales to millions of requests/second
  • as they are built to be more scalable, performant, and cost-effective, they have the following limitations
    • no network access
    • no file system access
  • cannot access the request body
  • use-cases ideal for lightweight processing of web requests like
    • Cache-key manipulations and normalization
    • URL rewrites and redirects
    • HTTP header manipulation
    • Access authorization

Lambda@Edge

  • are Lambda functions and visible on the Lambda dashboard.
  • supports Node.js and Python languages, currently
  • runs in Regional Edge Caches
  • has VM-based isolation
  • supports Viewer Request, Viewer Response, Origin Request, and Origin Response trigger events.
    • Viewer Request: after CloudFront receives the request from the Viewer
    • Viewer Response: before CloudFront forwards the response to the Viewer
    • Origin Request: before CloudFront forwards the request to the Origin
    • Origin Response: after CloudFront receives the response from the Origin
  • supports longer execution time, 5 seconds for viewer triggers and 30 seconds for origin triggers
  • scales to 1000s of requests/second
  • has network and file system access
  • can access the request body
  • use-cases
    • Functions that take several milliseconds or more to complete.
    • Functions that require adjustable CPU or memory.
    • Functions that depend on third-party libraries (including the AWS SDK, for integration with other AWS services).
    • Functions that require network access to use external services for processing.
    • Functions that require file system access or access to the body of HTTP requests.
  • Limitations
    • Numbered version of the Lambda function should be used, not $LATEST or aliases.
    • Lambda function must be in the US East (N. Virginia) Region.

CloudFront Functions vs Lambda@Edge

CloudFront Functions vs Lambda@Edge

CloudFront Edge Functions Restrictions

  • Each event type (viewer request, origin request, origin response, and viewer response) can have only one edge function association.
  • CloudFront Functions and Lambda@Edge in viewer events (viewer request and viewer response) cannot be combined.
  • CloudFront does not invoke edge functions for viewer response events when the origin returns an HTTP status code 400 or higher.
  • Edge functions for viewer response events cannot modify the HTTP status code of the response, regardless of whether the response came from the origin or the CloudFront cache.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You’ve been given the requirement to customize the content which is distributed to users via a CloudFront Distribution. The content origin is an S3 bucket. How could you achieve this?
    1. Add an event to the S3 bucket. Make the event invoke a Lambda function to customize the content before rendering
    2. Add a Step Function. Add a step with a Lambda function just before the content gets delivered to the users.
    3. Use Lambda@Edge
    4. Use a separate application on an EC2 Instance for this purpose.
  2. A company’s packaged application dynamically creates and returns single-use text files in response to user requests. The company is using Amazon CloudFront for distribution but wants to further reduce data transfer costs. The company cannot modify the application’s source code. What should a solutions architect do to reduce costs?
    1. Use Lambda@Edge to compress the files as they are sent to users.
    2. Enable Amazon S3 Transfer Acceleration to reduce the response times.
    3. Enable caching on the CloudFront distribution to store generated files at the edge.
    4. Use Amazon S3 multipart uploads to move the files to Amazon S3 before returning them to users.

References

AWS CloudFront Security

~ Last updated on : ~ jayendrapatil

CloudFront Security

  • CloudFront Security has multiple features, including
    • Support for Encryption at Rest and Transit.
    • Prevent users in specific geographic locations from accessing content
    • Configure HTTPS connections.
    • Use signed URLs or cookies to restrict access for selected users.
    • Restrict access to content in S3 buckets using origin access identity – OAI, to prevent users from using the direct URL of the file.
    • Set up field-level encryption for specific content fields
    • Use AWS WAF web ACLs to create a web access control list (web ACL) to restrict access to your content.
    • Use geo-restriction, also known as geoblocking, to prevent users in specific geographic locations from accessing content served through a CloudFront distribution.
    • Integration with AWS Shield to protect from DDoS attacks.

Data Protection

  • CloudFront supports both Encryption at Rest and in Transit.
  • CloudFront provides Encryption in Transit and can be configured
    • to require viewers to use HTTPS to request the files so that connections are encrypted when CloudFront communicates with viewers.
    • to use HTTPS to get files from the origin, so that connections are encrypted when CloudFront communicates with the origin.
    • HTTPS can be enforced using the Viewer Protocol Policy and Origin Protocol Policy.
  • CloudFront provides Encryption at Rest
    • using SSDs which are encrypted for edge location points of presence (POPs), and encrypted EBS volumes for Regional Edge Caches (RECs).
    • Function code and configuration are always stored in an encrypted format on the encrypted SSDs on the edge location POPs, and in other storage locations used by CloudFront.

Restrict Viewer Access

Serving Private Content

  • To securely serve private content using CloudFront
    • Require the users to access the private content by using special CloudFront signed URLs or signed cookies with the following restrictions
      • end date and time, after which the URL is no longer valid
      • start date-time, when the URL becomes valid
      • IP address or range of addresses to access the URLs
    • Require that users access the S3 content only using CloudFront URLs, not S3 URLs. Requiring CloudFront URLs isn’t required, but recommended to prevent users from bypassing the restrictions specified in signed URLs or signed cookies.
  • Signed URLs or Signed Cookies can be used with CloudFront using an HTTP server as an origin. It requires the content to be publicly accessible and care should be taken to not share the direct URL of the content
  • Restriction for Origin can be applied by
    • For S3, using Origin Access Identity – OAI to grant only CloudFront access using Bucket policies or Object ACL, to the content and removing any other access permissions
    • For a Load balancer OR HTTP server, custom headers can be added by CloudFront which can be used at Origin to verify the request has come from CloudFront.
    • Custom origins can also be configured to allow traffic from CloudFront IPs only. CloudFront managed prefix list can be used to allow inbound traffic to the origin only from CloudFront’s origin-facing servers, preventing any non-CloudFront traffic from reaching your origin
  • Trusted Signer
    • To create signed URLs or signed cookies, at least one AWS account (trusted signer) is needed that has an active CloudFront key pair
    • Once the AWS account is added as a trusted signer to the distribution, CloudFront starts to require that users use signed URLs or signed cookies to access the objects.
    • Private key from the trusted signer’s key pair to sign a portion of the URL or the cookie. When someone requests a restricted object, CloudFront compares the signed portion of the URL or cookie with the unsigned portion to verify that the URL or cookie hasn’t been tampered with. CloudFront also validates the URL or cookie is valid for e.g, that the expiration date and time hasn’t passed.
    • Each Trusted signer AWS account used to create CloudFront signed URLs or signed cookies must have its own active CloudFront key pair, which should be frequently rotated
    • A maximum of 5 trusted signers can be assigned for each cache behavior or RTMP distribution

Signed URLs vs Signed Cookies

  • CloudFront signed URLs and signed cookies help to secure the content and provide control to decide who can access the content.
  • Use signed URLs in the following cases:
    • for RTMP distribution as signed cookies aren’t supported
    • to restrict access to individual files, for e.g., an installation download for the application.
    • users using a client, for e.g. a custom HTTP client, that doesn’t support cookies
  • Use signed cookies in the following cases:
    • provide access to multiple restricted files, e.g., all of the video files in HLS format or all of the files in the subscribers’ area of a website.
    • don’t want to change the current URLs.
  • Signed URLs take precedence over signed cookies, if both signed URLs and signed cookies are used to control access to the same files and a viewer uses a signed URL to request a file, CloudFront determines whether to return the file to the viewer based only on the signed URL.

Canned Policy vs Custom Policy

  • Canned policy or a custom policy is a policy statement, used by the Signed URLs, that helps define the restrictions for e.g. expiration date and timeCloudFront Signed URLs - Canned vs Custom Policy
  • CloudFront validates the expiration time at the start of the event.
  • If the user is downloading a large object, and the URL expires the download would still continue, and the same for RTMP distribution.
  • However, if the user is using range GET requests, or while streaming video skips to another position which might trigger another event, the request would fail.

S3 Origin Access Identity – OAI

CloudFront S3 Origin Access Identity - OAI

  • Origin Access Identity (OAI) can be used to prevent users from directly accessing objects from S3.
  • S3 origin objects must be granted public read permissions and hence the objects are accessible from both S3 as well as CloudFront.
  • Even though CloudFront does not expose the underlying S3 URL, it can be known to the user if shared directly or used by applications.
  • For using CloudFront signed URLs or signed cookies, it would be necessary to prevent users from having direct access to the S3 objects.
  • Users accessing S3 objects directly would
    • bypass the controls provided by CloudFront signed URLs or signed cookies, for e.g., control over the date-time that a user can no longer access the content and the IP addresses can be used to access content
    • CloudFront access logs are less useful because they’re incomplete.
  • Origin access identity, which is a special CloudFront user, can be created and associated with the distribution.
  • S3 bucket/object permissions need to be configured to only provide access to the Origin Access Identity.
  • When users access the object from CloudFront, it uses the OAI to fetch the content on the user’s behalf, while the S3 object’s direct access is restricted

Custom Headers

  • Custom headers can be added by CloudFront which can be used at Origin to verify the request has come from CloudFront.

CloudFront Security - Custom headers

  • A viewer accesses the website or application and requests one or more files, such as an image file and an HTML file.
  • DNS routes the request to the CloudFront edge location that can best serve the request – typically the nearest edge location in terms of latency.
  • At the edge location, AWS WAF inspects the incoming request according to configured web ACL rules.
  • At the edge location, CloudFront checks its cache for the requested content.
    • If the content is in the cache, CloudFront returns it to the user.
    • If the content isn’t in the cache, CloudFront adds the custom header, X-Origin-Verify , with the value of the secret from Secrets Manager, and forwards the request to the origin.
  • At the origin ALB, ALB rules or AWS WAF inspects the incoming request header, X-Origin-Verify, and allows the request if the string value is valid. If the header isn’t valid, AWS WAF blocks the request.
  • At the configured interval, Secrets Manager automatically rotates the custom header value and updates the origin AWS WAF and CloudFront configurations.

Geo-Restriction – Geoblocking

  • Geo restriction can help allow or prevent users in selected countries from accessing the content,
  • CloudFront distribution can be configured either to allow users in
    • whitelist of specified countries to access the content or to
    • deny users in a blacklist of specified countries to access the content
  • Geo restriction can be used to restrict access to all of the files that are
    associated with distribution and to restrict access at the country level.
  • CloudFront responds to a request from a viewer in a restricted country with an HTTP status code 403 (Forbidden).
  • Use a third-party geolocation service, if access is to be restricted to a subset of the files that are associated with a distribution or to restrict access at a finer granularity than the country level.

Field Level Encryption Config

  • CloudFront can enforce secure end-to-end connections to origin servers by using HTTPS.
  • Field-level encryption adds an additional layer of security that helps protect specific data throughout system processing so that only certain applications can see it.
  • Field-level encryption can be used to securely upload user-submitted sensitive information. The sensitive information provided by the clients is encrypted at the edge closer to the user and remains encrypted throughout the entire application stack, ensuring that only applications that need the data – and have the credentials to decrypt it – are able to do so.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You are building a system to distribute confidential training videos to employees. Using CloudFront, what method could be used to serve content that is stored in S3, but not publically accessible from S3 directly?
    1. Create an Origin Access Identity (OAI) for CloudFront and grant access to the objects in your S3 bucket to that OAI.
    2. Add the CloudFront account security group “amazon-cf/amazon-cf-sg” to the appropriate S3 bucket policy.
    3. Create an Identity and Access Management (IAM) User for CloudFront and grant access to the objects in your S3 bucket to that IAM User.
    4. Create a S3 bucket policy that lists the CloudFront distribution ID as the Principal and the target bucket as the Amazon Resource Name (ARN).
  2. A media production company wants to deliver high-definition raw video for preproduction and dubbing to customer all around the world. They would like to use Amazon CloudFront for their scenario, and they require the ability to limit downloads per customer and video file to a configurable number. A CloudFront download distribution with TTL=0 was already setup to make sure all client HTTP requests hit an authentication backend on Amazon Elastic Compute Cloud (EC2)/Amazon RDS first, which is responsible for restricting the number of downloads. Content is stored in S3 and configured to be accessible only via CloudFront. What else needs to be done to achieve an architecture that meets the requirements? Choose 2 answers
    1. Enable URL parameter forwarding, let the authentication backend count the number of downloads per customer in RDS, and return the content S3 URL unless the download limit is reached.
    2. Enable CloudFront logging into an S3 bucket, leverage EMR to analyze CloudFront logs to determine the number of downloads per customer, and return the content S3 URL unless the download limit is reached. (CloudFront logs are logged periodically and EMR not being real time, hence not suitable)
    3. Enable URL parameter forwarding, let the authentication backend count the number of downloads per customer in RDS, and invalidate the CloudFront distribution as soon as the download limit is reached. (Distribution are not invalidated but Objects)
    4. Enable CloudFront logging into the S3 bucket, let the authentication backend determine the number of downloads per customer by parsing those logs, and return the content S3 URL unless the download limit is reached. (CloudFront logs are logged periodically and EMR not being real time, hence not suitable)
    5. Configure a list of trusted signers, let the authentication backend count the number of download requests per customer in RDS, and return a dynamically signed URL unless the download limit is reached.
  3. To enable end-to-end HTTPS connections from the user‘s browser to the origin via CloudFront, which of the following options are valid? Choose 2 answers
    1. Use self-signed certificate in the origin and CloudFront default certificate in CloudFront. (Origin cannot be self-signed)
    2. Use the CloudFront default certificate in both origin and CloudFront (CloudFront cert cannot be applied to origin)
    3. Use a 3rd-party CA certificate in the origin and CloudFront default certificate in CloudFront
    4. Use 3rd-party CA certificate in both origin and CloudFront
    5. Use a self-signed certificate in both the origin and CloudFront (Origin cannot be self-signed)

References

AWS_CloudFront_Security

AWS CloudFront with S3

CloudFront S3 Origin Access Identity - OAI
~ Last updated on : ~ jayendrapatil

AWS CloudFront with S3

  • CloudFront can be used to distribute the content from an S3 bucket.
  • For an RTMP distribution, the S3 bucket is the only supported origin, and custom origins cannot be used
  • Using CloudFront over S3 has the following benefits
    • can be more cost-effective if the objects are frequently accessed as at higher usage, and the price for CloudFront data transfer is much lower than the price for S3 data transfer.
    • downloads are faster with CloudFront than with S3 alone because the objects are stored closer to the users
  • CloudFront provides two ways to send authenticated requests to an S3 origin: Origin Access Control (OAC) and Origin Access Identity (OAI).
  • When using S3 as the origin for distribution and the bucket is moved to a different region, CloudFront can take up to an hour to update its records to include the change of region when both of the following are true:
    • Origin Access Control (OAC) and Origin Access Identity (OAI) are used to restrict access to the bucket.
    • Bucket is moved to an S3 region that requires Signature Version 4 for authentication

Origin Access Identity – OAI

CloudFront S3 Origin Access Identity - OAI

  • S3 origin objects must be granted public read permissions and hence the objects are accessible from both S3 as well as CloudFront.
  • Even though CloudFront does not expose the underlying S3 URL, it can be known to the user if shared directly or used by applications.
  • For using CloudFront signed URLs or signed cookies to provide access to the objects, it would be necessary to prevent users from having direct access to the S3 objects.
  • Users accessing S3 objects directly would
    • bypass the controls provided by CloudFront signed URLs or signed cookies, for e.g., control over the date-time that a user can no longer access the content and the IP addresses can be used to access content
    • CloudFront access logs are less useful because they’re incomplete.
  • Origin Access Identity (OAI) can be used to prevent users from directly accessing objects from S3.
  • Origin access identity, which is a special CloudFront user, can be created and associated with the distribution.
  • S3 bucket/object permissions need to be configured to only provide access to the Origin Access Identity.
  • When users access the object from CloudFront, it uses the OAI to fetch the content on the user’s behalf, while the S3 object’s direct access is restricted

Origin Access Control – OAC

CloudFront Origin Access Control - OAC

  • Origin Access Control – OAC is recommended over Origin Access Identity – OAI and supports
    • Enhanced security practices like short-term credentials, frequent credential rotations, and resource-based policies
    • All S3 buckets in all AWS Regions
    • S3 server-side encryption with AWS KMS (SSE-KMS)
    • Comprehensive HTTP methods support including dynamic requests – OAC supports GET, PUT, POST, PATCH, DELETE, OPTIONS, and HEAD.
  • CloudFront OAC needs to be setup with permissions to access the S3 bucket origin, which can be done after creating a CloudFront distribution, but before adding the OAC to the S3 origin in the distribution configuration.
  • For buckets with objects encrypted using server-side encryption with AWS Key Management Service (SSE-KMS), the OAC must be provided with permission to use the AWS KMS key.

CloudFront with S3 Objects

  • CloudFront can be configured to include custom headers or modify existing headers whenever it forwards a request to the origin, to
    • validate the user is not accessing the origin directly, bypassing CDN
    • identify the CDN from which the request was forwarded, if more than one CloudFront distribution is configured to use the same origin
    • if users use viewers that don’t support CORS, configure CloudFront to forward the Origin header to the origin. That will cause the origin to return the Access-Control-Allow-Origin header for every request

Adding & Updating Objects

  • Objects just need to be added to the Origin and CloudFront would start distributing them when accessed.
  • For objects served by CloudFront, the Origin can be updated either by
    • Overwriting the original object
    • Create a different version and update the links exposed to the user.
  • For updating objects, it is recommended to use versioning e.g. have files or the entire folders with versions, so links can be changed when the objects are updated forcing a refresh.
  • With versioning,
    • there is no wait time for an object to expire before CloudFront begins to serve a new version of it.
    • there is no difference in consistency in the object served from the edge
    • no cost is involved to pay for object invalidation.

Removing/Invalidating Objects

  • Objects, by default, would be removed upon expiry (TTL) and the latest object would be fetched from the Origin
  • Objects can also be removed from the edge cache before it expires
    • File or Object Versioning to serve a different version of the object that has a different name.
    • Invalidate the object from edge caches. For the next request, CloudFront returns to the Origin to fetch the object
  • Object or File Versioning is recommended over Invalidating objects
    • if the objects need to be updated frequently.
    • enables to control which object a request returns even when the user has a version cached either locally or behind a corporate caching proxy.
    • makes it easier to analyze the results of object changes as CloudFront access logs include the names of the objects
    • provides a way to serve different versions to different users.
    • simplifies rolling forward & back between object revisions.
    • is less expensive, as no charges for invalidating objects.
    • for e.g. change header-v1.jpg to header-v2.jpg
  • Invalidating objects from the cache
    • objects in the cache can be invalidated explicitly before they expire to force a refresh
    • allows to invalidate selected objects
    • allows to invalidate multiple objects for e.g. objects in a directory or all of the objects whose names begin with the same characters, you can include the * wildcard at the end of the invalidation path.
    • the user might continue to see the old version until it expires from those caches.
    • A specified number of invalidation paths can be submitted each month for free. Any invalidation requests more than the allotted no. per month, a fee is charged for each submitted invalidation path
    • The First 1,000 invalidation paths requests submitted per month are free; charges apply for each invalidation path over 1,000 in a month.
    • Invalidation path can be for a single object for e.g. /js/ab.js or for multiple objects for e.g. /js/* and is counted as a single request even if the * wildcard request may invalidate thousands of objects.
  • For RTMP distribution, objects served cannot be invalidated

Partial Requests (Range GETs)

  • Partial requests using Range headers in a GET request help to download the object in smaller units, improving the efficiency of partial downloads and the recovery from partially failed transfers.
  • For a partial GET range request, CloudFront
    • checks the cache in the edge location for the requested range or the entire object and if exists, serves it immediately
    • if the requested range does not exist, it forwards the request to the origin and may request a larger range than the client requested to optimize performance
    • if the origin supports range header, it returns the requested object range and CloudFront returns the same to the viewer
    • if the origin does not support range header, it returns the complete object and CloudFront serves the entire object and caches it for future.
    • CloudFront uses the cached entire object to serve any future range GET header requests

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You are building a system to distribute confidential training videos to employees. Using CloudFront, what method could be used to serve content that is stored in S3, but not publically accessible from S3 directly?
    1. Create an Origin Access Identity (OAI) for CloudFront and grant access to the objects in your S3 bucket to that OAI.
    2. Add the CloudFront account security group “amazon-cf/amazon-cf-sg” to the appropriate S3 bucket policy.
    3. Create an Identity and Access Management (IAM) User for CloudFront and grant access to the objects in your S3 bucket to that IAM User.
    4. Create an S3 bucket policy that lists the CloudFront distribution ID as the Principal and the target bucket as the Amazon Resource Name (ARN).

References

CloudFront Restrict Access to S3

AWS Client VPN

~ jayendrapatil

AWS Client VPN

  • AWS Client VPN is a managed client-based VPN service that enables secure access to AWS resources and resources in the on-premises network
  • Client VPN allows accessing the resources from any location using an OpenVPN-based VPN client.
  • Client VPN establishes a secure TLS connection from any location using the OpenVPN client.
  • Client VPN automatically scales to the number of users connecting to the AWS resources and on-premises resources.
  • Client VPN supports client authentication using Active Directory, federated authentication, and certificate-based authentication.
  • Client VPN provides manageability with the ability to manage active client connections, with the ability to terminate active client connections and to view connection logs, which provide details on client connection attempts

AWS Client VPN

Client VPN Components

  • Client VPN endpoint
    • is the resource that is created and configured to enable and manage client VPN sessions.
    • is the resource where all client VPN sessions are terminated.
  • Target network
    • is the network associated with a Client VPN endpoint.
    • is a subnet from a VPC that enables establishing VPN sessions.
    • Multiple subnets can be associated with the Client VPN endpoint, however, each subnet must belong to a different Availability Zone.
  • Route
    • describes the available destination network routes.
    • Each route in the route table specifies the path for traffic to specific resources or networks.
  • Authorization rules
    • restrict the users who can access a network.
    • helps configure the AD or IdP group that is allowed access. Only users belonging to this group can access the specified network.
  • Client
    • end-user connecting to the Client VPN endpoint to establish a VPN session.
    • need to download an OpenVPN client and use the Client VPN configuration file to establish a VPN session.

Client VPN Authentication & Authorization

  • Client VPN provides authentication and authorization capabilities.
  • Authentication determines whether clients are allowed to connect to the Client VPN endpoint
  • Client VPN offers the following types of client authentication:
    • Active Directory authentication (user-based)
    • Mutual authentication (certificate-based)
    • Single sign-on (SAML-based federated authentication) (user-based)
  • Client VPN supports two types of authorization:
    • Security groups and
    • Network-based authorization (using authorization rules)
      • allows mapping of the Active Directory group or the SAML-based IdP group to the network they can have access to.

Client VPN Split Tunnel

  • Client VPN endpoint, by default, routes all traffic over the VPN tunnel.
  • Split-tunnel Client VPN endpoint helps when you do not want all user traffic to route through the Client VPN endpoint.
  • Split tunnel ensures only traffic with a destination to the network matching a route from the Client VPN endpoint route table is routed over the Client VPN tunnel.
  • Split-tunnel offers the following benefits:
    • Optimized routing of traffic from clients by having only the AWS destined traffic traverse the VPN tunnel.
    • Reduced volume of outgoing traffic from AWS, therefore reducing the data transfer cost.

Client VPN Limitations

  • Client CIDR ranges cannot overlap with the local CIDR of the VPC in which the associated subnet is located, or any routes manually added to the Client VPN endpoint’s route table.
  • Client CIDR ranges must have a block size between /22 and /12.
  • Client CIDR range cannot be changed after Client VPN endpoint creation.
  • Subnets associated with a Client VPN endpoint must be in the same VPC.
  • Multiple subnets from the same AZ cannot be associated with a Client VPN endpoint.
  • A Client VPN endpoint does not support subnet associations in a dedicated tenancy VPC.
  • Client VPN supports IPv4 traffic only.
  • Client VPN is not Federal Information Processing Standards (FIPS) compliant.
  • As Client VPN is a managed service and the IP address to which the DNS name resolves might change. Hence, it is not recommended to connect to the Client VPN endpoint by using IP addresses. Use DNS instead.
  • IP forwarding is currently disabled when using the AWS Client VPN Desktop Application.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company is developing an application on AWS. For analysis, the application transmits log files to an Amazon Elasticsearch Service (Amazon ES) cluster. Each piece of data must be contained inside a VPC. A number of the company’s developers work remotely. Other developers are based at three distinct business locations. The developers must connect to Amazon ES directly from their local development computers in order to study and display logs. Which solution will satisfy these criteria?
    1. Configure and set up an AWS Client VPN endpoint. Associate the Client VPN endpoint with a subnet in the VPC. Configure a Client VPN self-service portal. Instruct the developers to connect by using the client for Client VPN.
    2. Create a transit gateway, and connect it to the VPC. Create an AWS Site-to-Site VPN. Create an attachment to the transit gateway. Instruct the developers to connect by using an OpenVPN client.
    3. Create a transit gateway, and connect it to the VPC. Order an AWS Direct Connect connection. Set up a public VIF on the Direct Connect connection. Associate the public VIF with the transit gateway. Instruct the developers to connect to the Direct Connect connection.
    4. Create and configure a bastion host in a public subnet of the VPC. Configure the bastion host security group to allow SSH access from the company CIDR ranges. Instruct the developers to connect by using SSH.

References

AWS_Client_VPN