Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
Access control list (ACL): A firewall/security layer on the subnet level
ACLs have several contexts (e.g., you can set them on entire S3 buckets or individual objects within a bucket)
Auto scaling: Automates the process of adding or removing EC2 instances based on traffic demand for your application
That's one use-case. Another very common one is for availability or automated, scheduled re-deployments. In the former case, if you experience a node-fault, the faulted node is rebuilt (even if there's only one node under management). In the latter case, you can use scheduled scale-down/scale-up actions (useful when you have Internet-facing resources that you'd like to ensure won't be home to advanced, persistent threats.
Elastic Load Balancing (ELB): Evenly distributes traffic between EC2 instances that are associated with it
You'd probably want to drop the "evenly". Depending on what distribution-policy you set on an ELB and the nature of the distributed workloads, the resultant distribution can be far from even.
Folder: Any “subfolder” created in a bucket
Don't technically exist. Buckets don't really have hierarchical storage like you have on traditional filesystems. The thing that's presented to you in the S3 web UI as though it were a folder is simply a groupable "key".
High availability: Refers to systems that are durable and likely to operate continuously without failure for a long time
Should be defined less in terms of "systems" than "services": a given service can be made highly-available (frequently with things like clustering or scaling-groups paired ELBs) even though the underlying systems (EC2s, containers, etc.) may be quite ephemeral or perishable.
Roles: How different AWS services are granted permission to communicate and share data
Like ACLs, roles have more than a single context. Basically, you use roles (and associated IAM policies) to grant permissions to other AWS-hosted/managed resources. Roles can be assigned to Instances, users, managed-service components, etc.
Route 53: Where you configure and manage web domains for websites or applications you host on AWS
Basically just a managed-DNS solution with hooks to other AWS services (e.g., availability-monitoring). As a DNS solution, it can be used to host:IP mapping for more than just web-servers ...and, can include supporting things like email sender-validation, directory referrals, etc..
Scalability: The ability of a system to easily increase in size and capacity in a cost-effective way
Again, probably better framing in terms of "services" rather than systems. While you may be able to scale individual systems it's not super common to do so. The usual goal is to size a service's backing components to match demand.
Security group (SG): Firewall/security layer on the server/instance level
SGs operate at the cloud/network layer. Servers/instances that implement firewalling capabilities do so through things like Windows' Advanced Firewall or Linux's firewalld.
Subnet: A subsection of a network and generally includes all the computers in a specific location
You'd be better off stopping immediately after the word "network". Groupings of "all computers in a specific location" are "availability zones" (and groupings of availability zones are "regions"). Within a given region, you'd assign a contiguous block of IPs, then subdivide that block across however many zones you want to include in the VPC. Even measured in terms of availability zones, it's very common that your network design locates networked assets across multiple subnets.
At any rate, all that subnets really are - whether in cloud or legacy hosting-environments - are logical segmentations of larger network address-blocks.
Your notes has been really insightful!
Made me reach out for the book I'm reading and the course by linuxacademy, some of points are valid but aren't presented in the book or the online course.
Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
Coming up on four years of providing cloud-enablement services for a few different organizations. Have also had to pass the architecture and DevOps AWS exams twice, now (fortunately, AWS shifted to a three-year renewal-schedule, recently). That "enablement" has been split between writing tools and documentation for those organizations as well as walk-throughs and after action reports. :p
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
ACLs have several contexts (e.g., you can set them on entire S3 buckets or individual objects within a bucket)
That's one use-case. Another very common one is for availability or automated, scheduled re-deployments. In the former case, if you experience a node-fault, the faulted node is rebuilt (even if there's only one node under management). In the latter case, you can use scheduled scale-down/scale-up actions (useful when you have Internet-facing resources that you'd like to ensure won't be home to advanced, persistent threats.
You'd probably want to drop the "evenly". Depending on what distribution-policy you set on an ELB and the nature of the distributed workloads, the resultant distribution can be far from even.
Don't technically exist. Buckets don't really have hierarchical storage like you have on traditional filesystems. The thing that's presented to you in the S3 web UI as though it were a folder is simply a groupable "key".
Should be defined less in terms of "systems" than "services": a given service can be made highly-available (frequently with things like clustering or scaling-groups paired ELBs) even though the underlying systems (EC2s, containers, etc.) may be quite ephemeral or perishable.
Like ACLs, roles have more than a single context. Basically, you use roles (and associated IAM policies) to grant permissions to other AWS-hosted/managed resources. Roles can be assigned to Instances, users, managed-service components, etc.
Basically just a managed-DNS solution with hooks to other AWS services (e.g., availability-monitoring). As a DNS solution, it can be used to host:IP mapping for more than just web-servers ...and, can include supporting things like email sender-validation, directory referrals, etc..
Again, probably better framing in terms of "services" rather than systems. While you may be able to scale individual systems it's not super common to do so. The usual goal is to size a service's backing components to match demand.
SGs operate at the cloud/network layer. Servers/instances that implement firewalling capabilities do so through things like Windows' Advanced Firewall or Linux's firewalld.
You'd be better off stopping immediately after the word "network". Groupings of "all computers in a specific location" are "availability zones" (and groupings of availability zones are "regions"). Within a given region, you'd assign a contiguous block of IPs, then subdivide that block across however many zones you want to include in the VPC. Even measured in terms of availability zones, it's very common that your network design locates networked assets across multiple subnets.
At any rate, all that subnets really are - whether in cloud or legacy hosting-environments - are logical segmentations of larger network address-blocks.
Thank you sir!
Your notes has been really insightful!
Made me reach out for the book I'm reading and the course by linuxacademy, some of points are valid but aren't presented in the book or the online course.
Again thank you a lot!
It made my day!
Regards,
Alok
PS: I'm editing the article based on your notes. 😁
Coming up on four years of providing cloud-enablement services for a few different organizations. Have also had to pass the architecture and DevOps AWS exams twice, now (fortunately, AWS shifted to a three-year renewal-schedule, recently). That "enablement" has been split between writing tools and documentation for those organizations as well as walk-throughs and after action reports. :p