Cloud Computing


Google Cloud Architect Accelerated Learning Path for AWS professionals:
  • In AWS, have been using AWS CloudShell for writing and running bash scripts to manage AWS resources without setting up credentials and installing packages on the multiple local machines use. To reimplement scripts in Google Cloud should use Cloud Shell.

  • In AWS, there is an admin user, Tamara, who manages the organization with an attached policy that allows all IAM actions on all resources within the organization. Could grant similar permissions in Google Cloud by Add Tamara to an admin group that is assigned the roles/resourcemanager.organizationAdmin on the organization.

  • The AWS resource hierarchy uses organizational units to organize accounts, which then contain resources. Could create a similar hierarchy in Google Cloud with Folders, projects, and resources.

  • Alex is a Storage Admin, responsible for managing objects in Cloud Storage. He needs to have the right permissions for every project across the organization. Should Add Alex to a group that has the roles/storage.objectAdmin role assigned at the organizational level.

  • In AWS, there is an IAM role and instance profiles set up for use by a web app to access other services and resources. Need to set up the equivalent environment in Google, should use Google Cloud IAM service account.
  • There is an AWS security group that is set up on a VPC, and then associated with instances. If want to replicate this environment in Google Cloud, should use Google firewall rules defined at the network level.

  • If want to connect to Google Workspace and YouTube, but organization cannot meet Google's peering requirements, could use Carrier Peering.

  • AWS VPCs are Regional unless they are peered using VPC peering and contain AZ subnets, while Google Cloud VPCs are global, and contain regional subnets/subnets span regions.

  • A Cloud Router implements dynamic VPN that allows topology to be discovered and shared automatically, which reduces manual static route maintenance.

  • Google Cloud VPC Peering enables to connect two VPC networks from different organizations.

  • There is an AWS EC2 instance without an external IP address assigned, but that connects to AWS services and APIs through an AWS NAT Gateway. If want to configure a similar scenario with a Compute Engine VM, should Use Google APIs and services by enabling Private Google Access on the subnet used by the VM's network interface.
Last edited:


  • A financial services company receives a regular data feed from its credit card servicing partner. Approximately 5,000 records are sent every 15 mins in plaintext, delivered over HTTPS directly into an Amazon S3 bucket with server-side encryption. This feed contains sensitive credit card Primary Account Number (PAN) data. The company needs to automatically mask the PAN before sending the data to another S3 bucket for additional internal processing. The company also needs to remove and merge specific fields, and then transform the record into JSON format. Additionally, extra feeds are likely to be added in the future, so any design needs to be easily expandable. Solution will meet these requirements is Create an AWS Glue crawler and custom classifier based on the data feed formats and build a table definition to match. Trigger an AWS Lambda function on file delivery to start an AWS Glue ETL job to transform the entire record according to the processing and transformation requirements. Define the output format as JSON. Once complete, have the ETL job send the results to another S3 bucket for internal processing.
    Can use a Glue crawler to populate the AWS Glue Data Catalog with tables. The Lambda function can be triggered using S3 event notifications when object create events occur. The Lambda function will then trigger the Glue ETL job to transform the records masking the sensitive data and modifying the output format to JSON.

  • A company is migrating an app to the AWS cloud. The app runs in an on-premises DC and writes thousands of images into a mounted NFS file system each night. After the company migrates the app, the company will host the app on an Amazon EC2 instance with a mounted Amazon Elastic File System (EFS) file system.
    The company has established an AWS Direct Connect connection to AWS. Before the migration cutover, a solution architect must build a process that will replicate the newly created on-premises images to the EFS file system. The MOST operationally efficient way to replicate the images is Deploy an AWS DataSync agent to an on-prem server that has access to the NFS file system. Send data over the Direct Connect connection to an AWS PrivateLink int.
    AWS DataSync uses to replicate the on-prem images to the EFS file system over the Direct Connect connection. AWS DataSync is a service that automates and accelerates data transfer between on-prem storage systems and AWS storage services. It can transfer data to and from Amazon EFS, FSx for Windows File Server, and S3. To use AWS DataSync, the company needs to deploy an AWS DataSync agent to an on-prem server that has access to the NFS file system. The agent connects to the AWS DataSync service endpoint in the AWS Region where the EFS File system is located. The company can use an AWS PrivateLink interface endpoint to connect to the service endpoint securely and privately over the Direct Connect connection. The company can then create a task in AWS DataSync that specifies the source location (the NFS file system), the destination location (the EFS file system), and the options for the data transfer (such as schedule, bandwidth limit, and verification). AWS DataSync will then perform the data transfer efficiently and securely, using encryption in transit and at rest.
การออกแบบระบบสำหรับผู้เริ่มต้น: ส่วนที่ 1 — การเริ่มต้นใช้งาน

หลายบริษัทใช้การสัมภาษณ์การออกแบบระบบเพื่อทดสอบทักษะการแก้ปัญหาของวิศวกร — คู่มือการออกแบบระบบฉบับสมบูรณ์ในปี 2566

เมื่อเปิด App Taxi ที่ใช้ประจำ จองรถ และเพลิดเพลินกับการสนทนากับเพื่อนๆ ในขณะที่ Taxi พาไปยังจุดหมายปลายทาง รู้มั้ยว่ามีระบบที่ซับซ้อนทำงานอยู่เบื้องหลัง

นี่คือความลับ - ศาสตร์และศิลป์ของการออกแบบระบบ

บทความนี้มีจุดมุ่งหมายเพื่อให้ความเข้าใจที่ชัดเจนเกี่ยวกับการสร้างระบบที่ปรับขนาดได้และแข็งแกร่ง การออกแบบระบบอาจฟังดูน่ากลัว ดังนั้นก่อนอื่นเราจะเข้าใจรากฐานก่อนที่จะพูดถึงหัวข้อที่ซับซ้อน ในบทความแรกของเรา เราจะเจาะลึกลงไปในสี่เสาหลักของการออกแบบระบบ ได้แก่ ประสิทธิภาพ ความสามารถในการปรับขนาด ความน่าเชื่อถือ และความปลอดภัย


ปัจจุบันบริษัทด้าน Technology กำลังนำการสัมภาษณ์การออกแบบระบบมาใช้เพื่อประเมินทักษะการวางแผนและการแก้ปัญหาของผู้สมัคร เป้าหมายหลักของการสัมภาษณ์การออกแบบระบบไม่ใช่เพื่อประเมินความรู้เกี่ยวกับ Algorithm หรือการเขียน Code แต่เพื่อทำความเข้าใจความสามารถส่วนบุคคลในการออกแบบระบบที่แข็งแกร่ง ปรับขนาดได้ และมีประสิทธิภาพ ผู้สัมภาษณ์ต้องการประเมินทักษะการสื่อสารของผู้สมัครด้วย พวกเขาต้องการให้ผู้สมัครถามคำถามที่ถูกต้อง ถามข้อกำหนด อธิบายวิธีการเลือกการออกแบบ กล่าวถึงปัญหาคอขวดในสถาปัตยกรรม ฯลฯ


ความเป็นเลิศในการออกแบบระบบเป็นการเน้นย้ำถึงความเก่งกาจในฐานะนัก Technology และแสดงถึงความสามารถในการเป็นผู้นำโครงการ และ Team งาน ทำให้ทักษะนี้เป็นทักษะที่สำคัญสำหรับผู้ที่อยากทำ Role ที่สร้าง Impact ทาง Technology ที่เปลี่ยนแปลงตลอดเวลา

มาเริ่มกันเลย — การออกแบบระบบครั้งแรก

ลองจินตนาการว่ากำลังใกล้จะเปิดตัว Web Application ใหม่ล่าสุด แล้วเลือกสถาปัตยกรรมที่เรียบง่ายแบบนี้


ก่อนจะดำดิ่งลึกลงไปอีก หยุดที่นี่สักครู่ คุณสามารถมองเห็นข้อผิดพลาดและปัญหาที่อาจเกิดขึ้นในสถาปัตยกรรมได้มั้ย?

ตอนนี้ ให้พิจารณาคำถามเหล่านี้:

ถาม: หน้า Web ของคุณ Load ด้วยความเร็วสูงไม่ว่าจะมีคนเข้าถึงจากที่ไหนก็ตามมั้ย?

ถาม: เมื่อผู้ใช้มีส่วนร่วมในงานที่เกี่ยวข้องกับการเพิ่ม เปลี่ยนแปลง หรือลบข้อมูล (การดำเนินการ CRUD (Create, Read, Update, Delete)) การตอบสนองจะรวดเร็วมั้ย หรือพวกเขาจะหงุดหงิดใจมั้ย?

ถาม: ลองจินตนาการถึงจำนวนผู้ใช้ของคุณที่เพิ่มขึ้นอย่างรวดเร็วจาก 100 คนธรรมดาๆ ไปสู่ 1 ล้านคนในชั่วข้ามคืน ระบบของคุณสามารถยืนหยัดท่ามกลางคำขอรายวันจำนวนมาก (1 ล้านคำขอ/วัน) ได้มั้ย?

ถาม: จะเกิดอะไรขึ้นหาก Service ในเครื่องของคุณ เช่น Backend หรือฐานข้อมูลของคุณ ประสบปัญหาและหยุดทำงาน? ทุกเครื่องอาจพังได้ซักวัน

ถาม: จะเกิดอะไรขึ้นหากฐานข้อมูลของคุณขัดข้องส่งผลให้ข้อมูลสูญหาย?

ถาม: จะเกิดอะไรขึ้นหากมีการโจมตีทาง Cyber บนโครงสร้างพื้นฐาน (Infrastructure) ของคุณ? คุณมีการป้องกันที่เหมาะสมบนโครงสร้างพื้นฐานของคุณมั้ย?

ถาม: จะเกิดอะไรขึ้นหากศูนย์ข้อมูล (Data Center) ทั้งหมดของคุณ (ที่ Application ของคุณ Host อยู่) หยุดทำงานเนื่องจากภัยพิบัติ?

และอื่น ๆ…

4 เสาหลักสำคัญของการออกแบบระบบ

คำถามข้างต้น แม้ว่าจะแตกต่างกันออกไป แต่เกี่ยวข้องกับเสาหลักสี่ข้อนี้:
  1. ประสิทธิภาพ
  2. ความสามารถในการขยายขนาด
  3. ความน่าเชื่อถือ
  4. ความปลอดภัย


  1. ประสิทธิภาพ

    ลองนึกภาพการไปร้านค้าและรอ Queue นานเกินไป การดำเนินการที่ Counter อาจช้า หรือพนักงานไม่เพียงพอที่จะรองรับปริมาณลูกค้า ในโลก Digital ความเร็วที่ Website หรือ App ของคุณตอบสนองจะคล้ายกับเวลาที่รอในร้านค้านั่นเอง

    ประสิทธิภาพสามารถกำหนดเป็นตัวชี้วัดว่าระบบ (หรือ Application) ตอบสนองต่อคำขอของผู้ใช้ได้อย่างมีประสิทธิภาพและประสิทธิผล ปัจจัยหลายประการอาจส่งผลต่อประสิทธิภาพของระบบ


    ลองนึกภาพทางหลวง ถนนสอง Lane อาจใช้ได้สำหรับเมืองเล็กๆ แต่เมืองที่พลุกพล่านจะต้องใช้ Lane และทางด่วนหลาย Lane เช่นเดียวกับประเภทและความจุของ Hardware และ Software ของคุณ การเลือกประเภทระบบที่ถูกต้องสำหรับงาน ไม่ว่าจะเป็น Server ที่แข็งแกร่งสำหรับ Application ที่มีความต้องการสูงหรือระบบรองสำหรับงานเฉพาะ เป็นสิ่งสำคัญยิ่งในการรับรองประสิทธิภาพสูงสุด


    Latency และ Throughput:

    ลองนึกภาพ Latency คือระยะเวลาที่รถยนต์ใช้เดินทางจากจุด A ไปยัง B ในขณะที่ Throughput หมายถึงจำนวนรถยนต์ที่สามารถข้ามจุดตรวจได้ภายในหนึ่งชั่วโมง

    Propagation Delay, การหยุดชะงักในการส่งข้อมูล และเวลาประมวลผล สามารถส่งผลต่อเวลาในการตอบสนองได้ ในทางกลับกัน Throughput อาจได้รับผลกระทบจากขีดจำกัดของ Bandwidth และสภาพของเครือข่าย ด้วยการเพิ่มประสิทธิภาพทั้ง Latency และ Throughput เรามั่นใจว่าผู้ใช้จะได้รับข้อมูลอย่างรวดเร็วในปริมาณที่เพียงพอ
Last edited:



  1. 1*Q6fCRQYQHWBVJTGnr7eObw.jpeg

    ลองนึกภาพรถบรรทุกคันหนึ่งเสียกลางถนนที่พลุกพล่านทำให้เกิดความล่าช้า หรือลูกค้าใช้เวลาอยู่ที่ Counter นานขึ้นเพราะบัตร Credit ใช้งานไม่ได้


    ข้อผิดพลาดในระบบของคุณอาจทำให้เกิดการหยุดชะงักที่คล้ายกัน การตรวจสอบและแก้ไขข้อผิดพลาดอย่างรวดเร็วทำให้การทำงานราบรื่นยิ่งขึ้น


    เหมือนมี Pump น้ำมันบนทางหลวงเพียงแห่งเดียว คนจะหนาแน่นเกินไป ทำให้เกิดความล่าช้า (Delay) เพิ่มขึ้น อย่างไรก็ตาม รถยนต์สามารถเติมน้ำมันและเคลื่อนที่ได้อย่างมีประสิทธิภาพหากมีหลายสถานี

    ทรัพยากรอาจเกิดเป็นคอขวด และระบบอาจทำงานช้าลง ดังนั้น การเพิ่มประสิทธิภาพวิธีใช้ทรัพยากร เช่น หน่วยความจำหรือ CPU จึงเป็นสิ่งสำคัญในการป้องกันปัญหาคอขวด



    Concurrency และ Parallelism:

    พิจารณา Concurrency เป็นการจัดการงานหลายอย่างพร้อมกัน เช่น เจ้าหน้าที่ด่านเก็บค่าผ่านทางเพียงคนเดียวที่สลับระหว่าง Lane รถยนต์ได้อย่างมีประสิทธิภาพ ไม่ได้หมายความว่างานต่างๆ เกิดขึ้นพร้อมๆ กัน แต่ระบบได้รับการออกแบบมาให้จัดการงานหลายอย่างได้อย่างมีประสิทธิภาพ

    อย่างไรก็ตาม Parallelism ก็เหมือนกับการมีเจ้าหน้าที่ตู้เก็บค่าผ่านทางหลายราย โดยแต่ละคนประมวลผลรถพร้อมกัน Parallelism หมายถึงงานต่างๆ จะถูกดำเนินการไปพร้อมๆ กัน ส่งผลให้การประมวลผลโดยรวมเร็วขึ้น


    ประสิทธิภาพเป็นเรื่องเกี่ยวกับการทำให้แน่ใจว่า Web Application ของคุณทำงานได้อย่างรวดเร็ว มันควรจะเกิดขึ้นทันทีเมื่อมีคน Click ปุ่ม หรือ Load Page หาก Site ของคุณช้า ผู้คนอาจออกไป และไม่กลับมาอีกเลย

  2. ความสามารถในการขยายขนาด:

    ลองนึกภาพร้านอาหารเล็กๆ ที่จู่ๆ ก็ได้รับความนิยม ในตอนแรกจะมีโต๊ะเพียงไม่กี่โต๊ะและมีเมนูจำกัด แต่เมื่อลูกค้าเข้ามามากขึ้นเรื่อยๆ ร้านอาหารก็ต้องขยายที่นั่ง อาจจะเปิดสาขาใหม่ หรือแม้แต่เสนออาหารหลากหลายรสชาติให้มากขึ้น

    ในโลก Digital ความสามารถในการปรับขนาดช่วยให้มั่นใจได้ว่า Application ของคุณเป็นเหมือนร้านอาหารที่ปรับเปลี่ยนได้แห่งนี้ ซึ่งพร้อมเสมอที่จะให้บริการผู้ใช้จำนวนมากขึ้นโดยไม่ทำให้ช้าลงหรือหยุดทำงาน เรามาสำรวจแนวคิดและกลยุทธ์บางอย่างเพื่อให้มั่นใจถึงความสามารถในการขยายขนาดกัน

    Load Balancer:

    ลองนึกถึงผู้จัดการที่นำลูกค้าไปยังส่วนที่พลุกพล่านน้อยกว่า Load Balancer จะกระจายคำขอของผู้ใช้ไปยัง Server หลายเครื่อง ทำให้มั่นใจได้ว่าไม่มี Server ใดถูกใช้งานมากเกินไป มักใช้ในระบบที่ปรับขนาดได้

    Horizontal vs. Vertical Scalability:

    ลองนึกถึงการเพิ่มโต๊ะในร้านอาหาร (แนวนอน) เทียบกับการทำให้แต่ละโต๊ะใหญ่ขึ้น (แนวตั้ง) ความสามารถในการขยายในแนวนอนเกี่ยวข้องกับการเพิ่มเครื่องจักรมากขึ้น ในขณะที่ความสามารถในการขยายในแนวตั้งคือเพิ่มความสามารถของเครื่องเดียว


    Auto Scaling:

    การปรับขนาดอัตโนมัติจะปรับจำนวนทรัพยากร เช่น Server ตามปริมาณการใช้งานและความต้องการที่เข้ามา ในช่วงที่มีการรับส่งข้อมูลสูง จะเพิ่มทรัพยากรมากขึ้นเพื่อจัดการกับ Load และเมื่อปริมาณการรับส่งข้อมูลลดลง ก็ลดทรัพยากรลงเพื่อหลีกเลี่ยงความสิ้นเปลือง สิ่งนี้ทำให้มั่นใจได้ว่า Application ของคุณยังคงตอบสนองแม้ในช่วง Peak ที่ไม่คาดคิด ขณะเดียวกันก็คุ้มค่าอีกด้วย

    คุณสามารถตั้งค่า Metric ตามตัวปรับขนาดอัตโนมัติที่จะปรับขนาดโครงสร้างพื้นฐานได้ตลอดเวลา ตัวอย่างเช่น หากการใช้ทรัพยากรของคุณ > 80% เป็นเวลา 2 นาที ให้เพิ่มทรัพยากร และในทำนองเดียวกัน หากการใช้ทรัพยากรยังคง < 50% เป็นเวลา 10 นาที ให้ลบทรัพยากรออก


    เหมือนมี Chef หลายคนในครัวเตรียมอาหารจานเดียวกัน ดังนั้นหากความต้องการอาหารจานนั้นเพิ่มขึ้น คุณจะมี Chef มากขึ้นตามความต้องการ นอกจากนี้ร้านอาหารจะยังคง Serve อาหารจานเดิมต่อไปได้หาก Chef คนใดคนหนึ่งป่วยหรือลาออกไป ในทำนองเดียวกัน การสร้างสำเนาข้อมูลหลายชุด จะทำให้สามารถทนต่อข้อผิดพลาดและเข้าถึงข้อมูลได้เร็วขึ้น



    คนเหล่านี้เปรียบเสมือน Chef ผู้เชี่ยวชาญในร้านอาหารของคุณ ซึ่งแต่ละคนทุ่มเทให้กับงานเฉพาะด้าน ในด้าน Technology บริการมุ่งเน้นไปที่ Function เฉพาะ และสามารถปรับขนาดได้อย่างอิสระ แต่ละบริการสามารถทำงานได้ด้วยตนเองโดยไม่ต้องพึ่งพาบริการอื่น Service Bus หรือ Message Broker สร้างการเชื่อมโยงระหว่างบริการเหล่านั้นเพื่อการแลกเปลี่ยนข้อมูล



    คุณเคยใช้ Drive-Thru ของร้านอาหารบ้างมั้ย? แทนที่จะจอดรถแล้วเดินเข้าไป คุณขับรถมา สั่งอาหาร ชำระเงิน และรับอาหารโดยไม่ต้องลงจากรถ

    ในทำนองเดียวกัน Cache จะเก็บข้อมูลที่ใช้บ่อยเพื่อให้สามารถเรียกได้อย่างรวดเร็ว โดยไม่ต้องเข้าถึงข้อมูลจริงๆ


    Asynchronous Processes (Queues):

    ลองนึกภาพการส่งข้อความ และทำงานอื่นของคุณต่อไปแทนที่จะรอการตอบกลับ ในการออกแบบระบบ จะคล้ายกับการใช้ Message Queue แทนที่จะให้ผู้ใช้รอให้แต่ละงานเสร็จสิ้นทีละงาน งานจะเรียงกันเป็น Queue ขณะที่ผู้ใช้ทำกิจกรรมอื่น งานเหล่านี้จะได้รับการจัดการอย่างเงียบๆ อยู่เบื้องหลัง สิ่งนี้ทำให้ผู้ใช้ไม่ต้องรอนาน และงานต่างๆ จะได้รับการจัดการอย่างมีประสิทธิภาพ


  3. ความน่าเชื่อถือ:

    ลองจินตนาการว่าคุณกำลังเดินทางด้วยเที่ยวบินระยะไกล ประสบการณ์ที่คุณคาดหวังไม่ใช่แค่เรื่องความรวดเร็วแต่คือความมั่นใจ คุณคาดหวังที่จะไปถึงจุดหมายปลายทางได้อย่างปลอดภัยโดยไม่เจอความปั่นป่วนหรือสถานการณ์ที่ไม่คาดฝัน


    ในโลก Technology ความน่าเชื่อถือคือความมั่นใจ ช่วยให้มั่นใจได้ว่าระบบของคุณยังคงทำงานอยู่ และแม้ว่าจะเกิดปัญหาขึ้น ระบบก็สามารถกู้คืนได้โดยไม่ทำให้ผู้ใช้ต้องหยุดชะงักมากนัก ต่อไปนี้คือองค์ประกอบหลักของความน่าเชื่อถือ:


    นึกถึงการคาดหวังให้สายการบินมีเครื่องบินสำรองคอย Standby อยู่เสมอ หากเครื่องบินที่เราจะเดินทางมีปัญหา เครื่องบินสำรองก็พร้อมรับประกันว่าผู้โดยสารจะไม่เกิดความล่าช้า ในทำนองเดียวกัน ในการออกแบบระบบ การมี Server หลายตัวกระจายอยู่ในสถานที่ต่างๆ ทำให้มั่นใจได้ว่าหากเครื่องนึง Offline อีกเครื่องนึงจะเข้ามาแทนที่ได้ทันที ทำให้บริการต่างๆ ทำงานได้อย่างราบรื่นสำหรับผู้ใช้งาน


    วัดจาก Percent ของเวลาในช่วงเวลาที่กำหนดที่ระบบสามารถทำงานที่ได้รับมอบหมายได้โดยไม่มีความล้มเหลวใดๆ


    เครื่องบินมักบรรทุกเชื้อเพลิงเพิ่มเติม หรือมีเครื่องยนต์หลายเครื่องเพื่อสำรอง ใน Digital ระบบก็ควรจะมีระบบสำรองไว้ด้วย สิ่งนี้สามารถเกิดขึ้นได้โดยใช้การ Replicate หรือเตรียมทรัพยากรสำรองให้พร้อม

    Fault Detection:

    นักบินคอย Monitor เครื่องบินโดยใช้เครื่องมือต่างๆ อย่างต่อเนื่อง ในทำนองเดียวกัน ระบบของคุณควรสามารถตรวจจับและแจ้งเตือนความผิดปกติ ได้ทันที ซึ่งมักเกิดขึ้นผ่านเครื่องมือตรวจสอบหลายตัวรวมกัน Heartbeat และ Mechanism ที่คล้ายกันถูกใช้เพื่อตรวจจับบริการอื่น ๆ

    Fault Tolerance:

    เครื่องบินได้รับการออกแบบมาให้บินต่อไปได้แม้ว่าเครื่องยนต์ตัวใดตัวหนึ่งจะขัดข้องก็ตาม ในทำนองเดียวกัน ระบบที่ได้รับการออกแบบมาอย่างดีควรยังคงใช้งานได้แม้จะเผชิญกับความล้มเหลวบางส่วนก็ตาม ในการออกแบบระบบในทางปฏิบัติ ระบบสำรองข้อมูลและ Failover มักจะหมายถึงประเด็นนี้ โดยไม่ให้มีจุดล้มเหลวโดยสิ้นเชิงเพียงจุดเดียว (Single Point of Complete Failure)


    เมื่อเครื่องบินเผชิญกับสภาวะที่ไม่เอื้ออำนวย เครื่องบินอาจเปลี่ยนเส้นทางไปยังสนามบินอื่น ในทำนองเดียวกัน ระบบ Digital ควรมีแผนในการกู้คืนข้อมูลหรือการดำเนินงานหลังจากเกิดความล้มเหลว การสำรองข้อมูลเป็นประจำ และวิธีการกู้คืน สามารถช่วยในเรื่องนี้ได้


    ความน่าเชื่อถือสร้างความไว้วางใจและรับรองว่าผู้ใช้จะได้รับประสบการณ์ที่ราบรื่น การออกแบบเพื่อความน่าเชื่อถือ คือการออกแบบเพื่อความไว้วางใจ
Last edited:



  1. ความปลอดภัย:

    ลองคิดว่า Website หรือ App ของคุณเป็นเหมือนบ้าน คุณจะไม่เปิดประตูบ้านทิ้งไว้ให้ใครเข้ามาใช่มั้ย?


    การรักษาความปลอดภัยคือการ Lock ประตูบ้าน Digital ของคุณ ช่วยปกป้อง Website, ข้อมูล และที่สำคัญที่สุด ผู้ใช้ของคุณ จากผู้ไม่ประสงค์ดีบน Internet ที่ต้องการก่อให้เกิดอันตราย การใช้ Protocol ขั้นสูงและเครื่องมือตรวจสอบสามารถทำหน้าที่เหมือนผู้เฝ้าระวัง โดยอนุญาตเฉพาะการรับส่งข้อมูลที่ถูกต้องเท่านั้น ให้เราดูแนวคิดทั่วไปบางประการในระดับสูงดังนี้

    Public Key Cryptography:

    คือระบบ Lock และกุญแจแบบพิเศษ คุณ Share Lock เป็นสาธารณะ แต่มีเพียงคุณเท่านั้นที่มีกุญแจเฉพาะเพื่อเปิดมัน ในระบบ Digital การเข้ารหัส Key สาธารณะช่วยให้เกิดการสื่อสารที่ปลอดภัย โดยมีเพียงผู้รับที่ต้องการเท่านั้นที่สามารถถอดรหัสข้อความได้

    Digital Certificates & Signatures:

    คือตราประทับเอกสารรับรองความถูกต้อง ใบรับรอง Digital รับรองความถูกต้องของ Website ในขณะที่ลายเซ็น Digital รับประกันความสมบูรณ์ของข้อมูลที่ Share ทำให้ผู้ใช้มั่นใจในความน่าเชื่อถือของ Website



    เหมือนกับการส่งจดหมายปิดผนึกผ่านบริการจัดส่งที่เชื่อถือได้ HTTPS เข้ารหัสข้อมูลระหว่างผู้ใช้และ Website เพื่อให้มั่นใจว่าคนที่สอดรู้สอดเห็นไม่สามารถอ่านข้อความได้


    จินตนาการถึงกำแพงด้านนอกของปราสาทที่คอยปกป้องผู้รุกราน Firewall ทำหน้าที่คล้ายกัน โดยสร้างกำแพงกั้นระหว่างเครือข่ายภายในที่เชื่อถือได้และภัยคุกคามที่อาจเกิดขึ้นจากภายนอก คุณสามารถควบคุมกฎที่คุณต้องการได้เอง

    Identity & Access Management:

    เหมือน Club พิเศษ เฉพาะผู้ที่อยู่ในรายชื่อแขกเท่านั้นที่สามารถเข้าได้ ไม่ใช่ทุกคน การจัดการข้อมูลประจำตัวทำให้มั่นใจได้ว่าผู้ใช้คือใคร ในขณะที่การจัดการการเข้าถึง รวมถึงการเข้าถึงตามบทบาท และระบบ เช่น OAuth2 จะกำหนดพื้นที่ หรือข้อมูลที่ผู้ใช้สามารถเข้าถึงได้ โดยขึ้นอยู่กับบทบาทหรือสิทธิ์ของผู้ใช้


    เช่นเดียวกับจุดอ่อนในป้อมปราการ ผู้โจมตีสามารถโจมตีช่องโหว่ได้ การตระหนักรู้และการป้องกันช่องโหว่ทั่วไป เช่น SQL Injection, การโจมตี Cross-Site Scripting (XSS) หรือการโจมตี Cross-Site Request Forgery (CSRF) เป็นสิ่งสำคัญในการเสริมการป้องกันระบบของคุณ

    เราพึ่งเห็นแค่ยอดภูเขาน้ำแข็ง โดยเฉพาะอย่างยิ่งในเรื่องความปลอดภัย มีแนวคิดอื่นๆ อีกมากมาย แต่สำหรับตอนนี้ ให้เราทำให้มันง่ายที่นี่


ดู Diagram สถาปัตยกรรมระบบอีกครั้ง! ถามตัวเองด้วยคำถามเดียวกัน มันเพียงพอแล้วหรือยัง?


คำตอบคือ “มันขึ้นอยู่กับ”

ลองนึกถึงการออกแบบระบบเหมือนกับการสร้าง Block คุณไม่จำเป็นต้องมี Block ทุกประเภทสำหรับทุกโครงสร้าง Block บางอันอาจมีราคาแพงหรือใช้เวลาตั้งค่านานกว่า เลือกสิ่งที่เหมาะสมกับโครงการของคุณที่สุด ไม่ใช่ทุกโครงการที่ต้องการทุก Block

ต่อไปนี้คือโครงสร้างพื้นฐานที่สามารถปรับขนาดได้ ไม่ต้องกังวลหากคุณไม่เข้าใจทุกอย่าง อย่างไรก็ตาม สิ่งสำคัญคือต้องทราบถึงความซับซ้อนที่เกี่ยวข้อง


การออกแบบระบบที่ได้รับการออกแบบมาอย่างดีและรอบคอบเป็นหัวใจสำคัญของ App และ Website Online เช่นเดียวกับฐานที่แข็งแกร่งของอาคาร องค์ประกอบหลักสี่ส่วน ได้แก่ ประสิทธิภาพ ความสามารถในการขยาย ความน่าเชื่อถือ และความปลอดภัย รวบรวมทุกอย่างไว้ด้วยกัน หากไม่เข้าใจสิ่งเหล่านี้เสียก่อน ก็เหมือนกับการสร้างบ้านบนทรายนั่นเอง

An e-commerce company is revamping its IT infrastructure and is planning to use AWS services. The company's CIO has asked a solution architect to design a simple, highly available, and loosely coupled order processing app. The app is responsible for receiving and processing orders before storing them in an Amazon DynamoDB table. The app has a sporadic traffic pattern and should be able to scale during marketing campaigns to process the orders with minaimal delays. The MOST reliable approach to meet the requirements is Receive the orders in an Amazon SQS queue and invoke an AWS Lambda function to process them.
The best option is to use Amazon SQS and AWS Lambda to create a serverless order processing app.
Amazon SQS is a fully managed message queue service that can decouple the order receiving and processing components, making the app more scalable and fault-tolerant.
AWS Lambda is a serverless compute services that can automatically scale to handle the incoming message from the SQS queue and process them according to the business logic. It can also integrate with Amazon DynamoDB to store the processed orders in a fast and flexible NoSQL DB. This approach eliminates the need to provision, manage, or scale any servers or containers, and reduces the operational overhead and cost.
Using EC2-hosted DB to receive the orders introduces a single point of failure and a scalability bottleneck. EC2 instances also require more mangement and configuration than serverless services.
Using AWS Step Functions to receive the orders adds unnecessary complexity and cost to the app. AWS Step Functions is a service that coordinates multiple AWS services into a serverless workflow, but it is not designed to handle high-volume, sporadic, or unpredictable traffic patterns. It also charges per state transition, which can be expensive for a large number of orders. Launching an ECS container to process each order also requires more resources and management than invoking a Lambda function.
Using Amazon Kinesis Data Streams to receive the orders is not suitable for this use case. Amazon Kinesis Data Streams is a service that enable real-time processing of streaming data at scale, but it is not meant for asynchronous message queuing. It requires consumers to poll the data from the stream, which can introduce latency and complexity. It also charges per shard hour, which can be expensive for a sporadic traffic pattern.
การออกแบบระบบสำหรับผู้เริ่มต้น - ตอนที่ 2: ทำความเข้าใจสถาปัตยกรรม 3 Tier โดยใช้การเปรียบเทียบในชีวิตประจำวัน:

ก่อนหน้านี้ ในส่วนที่ 1 ของ Serie นี้ เราได้วาง Block พื้นฐานของการออกแบบระบบ ในภาคที่สองของ "การออกแบบระบบสำหรับผู้เริ่มต้น" เราจะแจกแจงสถาปัตยกรรม 3 Tier ทีละชั้น โดยใช้การเปรียบเทียบง่ายๆ และตัวอย่างที่เกี่ยวข้อง

ในตอนท้ายของตอนนี้ คุณควรจะสามารถเข้าใจสถาปัตยกรรมและส่วนประกอบแต่ละอย่างใน Diagram ด้านบนได้ ฟังดูน่าสนใจ? เรามาเริ่มต้นกัน

สถาปัตยกรรม 3 Tier คืออะไร?

ลองนึกภาพการเดินเข้าไปในร้านอาหาร มี Counter สั่งอาหารที่ลูกค้าสั่ง มีห้องครัวที่ Chef เตรียมอาหาร และห้องเก็บของวัตถุดิบ ในโลกของ Technology สถาปัตยกรรม Three-Tier ก็ทำงานในลักษณะเดียวกัน เช่นเดียวกับในร้านอาหาร แต่ละแผนกมีหน้าที่เฉพาะเพื่อให้แน่ใจว่าทุกอย่างดำเนินไปอย่างราบรื่น


สถาปัตยกรรม 3-Tier สามชั้น:

สถาปัตยกรรม 3-Tier นั้นทันสมัยและมีสามชั้นดังต่อไปนี้:
  1. Presentation Layer
  2. Logic Layer
  3. Data Layer
Last edited:


มาเจาะลึกการทำงานของแต่ละ Layer กันดีกว่า

  1. Presentation Layer — Counter สั่งอาหารและบริเวณรับประทานอาหาร:

    คุณเห็น Menu ตัดสินใจว่าคุณต้องการอะไร สั่งซื้อที่ Counter จากนั้นรอรับคำสั่งซื้อของคุณ เมื่อพร้อมแล้ว คุณสามารถรับมันจากการรวบรวม Order และนั่งในบริเวณที่รับประทานอาหารเพื่อเพลิดเพลินกับมื้ออาหารของคุณ

    นี่คือหน้าตาของ App ของคุณ เหมือน Counter สั่งอาหารที่มีแสงสว่างจ้าในร้านอาหารที่คุณชื่นชอบ เป็นสิ่งที่ผู้ใช้เห็นและโต้ตอบด้วย ไม่ว่าจะเป็น Website, App หรือ Interface อื่นๆ

  2. Logic Layer — พื้นที่เตรียมอาหารในครัว:

    เมื่อคุณสั่งซื้อ รายละเอียดจะไปที่บริเวณห้องครัว ซึ่งพนักงานจะทำตามขั้นตอนเฉพาะเพื่อปรุงอาหาร ใส่เครื่องปรุงที่เหมาะสม และบรรจุอาหารของคุณ นี่เป็นพื้นที่ส่วนตัว และไม่อนุญาตให้ลูกค้าเข้าในครัว

    นี่คือตรรกะทางธุรกิจของ App ของคุณ เช่นเดียวกับพนักงานที่อยู่หลัง Counter Layer นี้รับคำขอจาก Presentation Layer ดึงส่วนผสมที่ถูกต้องหรือข้อมูลดิบจาก Data Layer, ประมวลผล จากนั้นจึงบรรจุหีบห่ออย่างเรียบร้อยเพื่อให้ผู้ใช้เห็น

  3. Data Layer — ที่เก็บอาหาร:

    คิดว่านี่คือห้องครัวที่เก็บวัตถุดิบต่างๆ มันเป็นพื้นที่หวงห้าม เฉพาะพนักงานที่ได้รับอนุญาตซึ่งต้องการส่วนผสมในการเตรียมอาหารเท่านั้นที่จะเข้าที่จัดเก็บนี้ได้

    นี่คือ Layer พื้นฐานที่จัดเก็บข้อมูลไว้อย่างปลอดภัย เช่นเดียวกับห้องเก็บของที่มีหน่วยจัดเก็บข้อมูลเพื่อเก็บส่วนผสม Data Layer จะมีฐานข้อมูลและ Solution การจัดเก็บข้อมูลเพื่อรักษาข้อมูลผู้ใช้และ App เมื่อ App ต้องการข้อมูล Layer นี้จะเริ่มทำงาน

การสำรวจสถาปัตยกรรม 3 Tier:

เราได้สัมผัสภาพรวมของสถาปัตยกรรม 3 Tier โดยใช้ตัวอย่างร้านอาหาร ตอนนี้เรามาดูกันดีกว่าว่าเบื้องหลังทุกประสบการณ์ผู้ใช้ Digital มีองค์ประกอบที่ซ่อนอยู่ซึ่งทำให้ทุกอย่างทำงานได้อย่างราบรื่น ให้เราดูรายละเอียดพวกมัน แต่ก่อนหน้านั้นนี่คือภาพที่คุณควรไปอย่างละเอียด


  1. ระบบชื่อ Domain (DNS) — สมุดที่อยู่แบบ Dynamic:

    ลองนึกภาพคุณมีเพื่อนที่ย้ายบ้านบ่อยๆ คุณจะต้องตรวจสอบที่อยู่ล่าสุดทุกครั้งที่คุณต้องการไปหา DNS เปรียบเสมือนสมุดที่อยู่ที่ได้รับการ Update อย่างต่อเนื่องซึ่งจะให้ที่อยู่ล่าสุดแก่คุณเสมอ แม้ว่าจะมีการเปลี่ยนแปลงหลังการเข้าชมครั้งล่าสุดก็ตาม


    DNS แปลชื่อ Domain ที่เป็นภาษาคน เช่น ให้เป็นที่อยู่ IP เช่น ซึ่งอำนวยความสะดวกในการสื่อสารระหว่างเครื่องต่างๆ ที่อยู่ IP ที่เกี่ยวข้องกับชื่อ Domain อาจมีการเปลี่ยนแปลงด้วยเหตุผลหลายประการ ด้วย DNS คุณสามารถเข้าถึง Site ได้อย่างต่อเนื่องโดยใช้ชื่อ Domain เดียวกัน แม้ว่าที่อยู่ IP จะเปลี่ยนไปก็ตาม

    หมายเหตุ: หากคุณ Restart VM (เช่น EC2 ใน AWS) ที่อยู่ IP ของเครื่องอาจเปลี่ยนแปลง หรือเครื่องสามารถทำงานล้มเหลว หรือ Reboot ได้ ซึ่งสามารถเปลี่ยนที่อยู่ IP ของเครื่องได้เช่นกัน

  2. Load Balancer — คนเฝ้าประตู:

    ในงานที่ได้รับความนิยม พนักงานเปิดประตูจะคอยดูแลไม่ให้ทุกคนเข้าไปเบียดเสียดในทางเข้าเดียว พนักงานเปิดประตูจะพาแขกไปยังทางเข้าที่พลุกพล่านน้อยกว่า หากประตูบานใดบานหนึ่งมีคนมากเกินไป เราได้พูดคุยกันแล้วถึงวิธีการใช้ Load Balancer เพื่อให้แน่ใจว่าระบบสามารถปรับขยายได้ในส่วนแรกของ Serie

    เช่นเดียวกับแขกจำนวนมาก คำขอต่างๆ ไหลไปสู่ Event Digital ของเรา — Load Balancer จะตรวจสอบอย่างรวดเร็วและนำแต่ละคำขอไปยัง Web Server ที่เหมาะสมที่สุด (เช่น ที่มี Load น้อยที่สุด)


    สำหรับข้อมูล Dynamic, Web Server อาจส่งคำขอเพิ่มเติมไปยัง Application Server ผ่านทาง Load Balancer ตัวที่สอง คิดว่ามีคนเฝ้าประตูสองคน คนหนึ่งสำหรับทางเข้าหลัก และอีกคนสำหรับส่วน VIP พิเศษด้านใน ทั้งสองทำงานร่วมกันเพื่อรับประกันการไหลที่ราบรื่น ทำให้มั่นใจได้ว่าแขกทุกคน (หรือคำขอ) จะพบจุดที่สมบูรณ์แบบโดยไม่มีสะดุด

    Load Balancer ยังคอยตรวจสอบสถานะของแต่ละ Server ที่เกี่ยวข้องด้วย หาก Server ล่มหรือไม่ตอบสนอง Load balancer สามารถเปลี่ยนเส้นทางการรับส่งข้อมูลเพื่อให้แน่ใจว่าบริการไม่หยุดชะงัก

    หมายเหตุ: Load Balancer และ Auto Scaling Group สร้าง Team ที่ยอดเยี่ยม Load Balancer กระจายการรับส่งข้อมูลของผู้ใช้ไปยัง Server เพื่อให้แน่ใจว่าสิ่งต่างๆ ทำงานได้อย่างราบรื่น ในเวลาเดียวกัน Auto Scaling Group จะคอยจับตาดู Server เหล่านี้ หากมีผู้ใช้เข้ามาจำนวนมากหรือทำงานช้าลง Auto Scaling Group จะปรับเปลี่ยน มันสามารถเพิ่ม Server ได้มากขึ้นเมื่อ Busy หรือลด Server บางส่วนเมื่อ Load ลดลง

  3. Front End Server (Presentation Layer) — แผนกต้อนรับ:

    ลองนึกภาพการเดินเข้าไปในสำนักงานขนาดใหญ่หรือ Lobby ของโรงแรม ตรงทางเข้าจะมีแผนกต้อนรับ คุณได้รับการต้อนรับ ยื่นแผ่นพับหรือ Brochure และนำไปที่สำนักงานหรือห้อง บางครั้ง หากคุณมาประจำ พนักงานต้อนรับอาจจดจำความต้องการของคุณและแนะนำคุณได้อย่างรวดเร็ว ซึ่งจะทำให้ประสบการณ์ของคุณราบรื่นยิ่งขึ้น

    Frontend Server เปรียบเสมือนแผนกตอนรับของโลก Digital พวกเขา Host Web Interface ที่ผู้ใช้เห็นและโต้ตอบด้วย Browser ของคุณส่งคำขอหน้า Web เช่น Web Server ดึงข้อมูลที่ต้องการและส่งกลับ HTML สำหรับโครงสร้าง, CSS สำหรับ Style และ JavaScript (JS) สำหรับองค์ประกอบเชิงโต้ตอบ เมื่อสิ่งเหล่านี้พร้อมแล้ว Browser ของคุณจะทำหน้าที่ต่อ โดยสร้างมันลงในหน้าที่คุณเห็นและโต้ตอบด้วย


    สำหรับ Website ที่เปลี่ยนแปลงอยู่ตลอดเวลาตามการโต้ตอบของผู้ใช้ เช่น เมื่อตรวจสอบคำแนะนำส่วนบุคคล หรือ Update Live Feed Browser/อุปกรณ์ของคุณจะเปิดช่องทางการสื่อสารไว้กับ Backend

    หมายเหตุ: เราได้อธิบาย Model การแสดงผลฝั่ง Server ไว้ข้างต้น ตรงกันข้ามกับการแสดงผลฝั่ง Client โดยที่ Web Server ให้ข้อมูลขั้นต่ำที่ Browser ต้องการเท่านั้น จากนั้น Browser จะใช้ JavaScript เพื่อดึงข้อมูลเพิ่มเติมจาก Server โดยตรง Framework เช่น Angular และ React ใช้การ Render ฝั่ง Client
    NextJS เป็น Extension ที่ยอดเยี่ยมสำหรับ React หากคุณต้องการเจาะลึกการ Render ฝั่ง Server

  4. Backend Server (Application Layer) — พื้นที่ทำงานของ Office:

    เมื่อผ่านแผนกต้อนรับไปแล้ว งานจริงก็เกิดขึ้นในห้องทำงานและสำนักงาน นี่คือจุดที่งานเสร็จสมบูรณ์ ประมวลผลเอกสาร และให้บริการต่างๆ

    จุดสำคัญของ Web App Dynamic ทุกตัวคือ Backend Server มันทำงานเป็นเครื่องมือคำนวณ เมื่อผู้ใช้ดำเนินการบน Web App คำขอจะถูกส่งต่อไปยัง Server เหล่านี้ Server โต้ตอบกับฐานข้อมูล โดยดึงข้อมูลดิบที่อยู่ระหว่างการประมวลผล เปลี่ยนให้เป็นข้อมูลที่มีโครงสร้างที่มีความหมาย ข้อมูลนี้จะถูกส่งกลับไปยัง Client


    หมายเหตุ: Backend Server โดยพื้นฐานแล้วเป็นเครื่องที่มีระบบปฏิบัติการเป็นแกนหลัก Platform เช่น AWS EC2 หรือ Azure VMs ช่วยให้คุณสามารถตั้งค่า Server เหล่านี้ได้อย่างง่ายดาย คุณสามารถเลือกระบบปฏิบัติการ โครงสร้างพื้นฐาน Hardware และปรับใช้ตรรกะที่กำหนดเองที่เขียนในภาษาที่คุณเลือกได้ ความยืดหยุ่นนี้ทำให้เกิด Solution ที่ปรับแต่งตามความต้องการของคุณ

  5. ฐานข้อมูล (Data Layer)— ตู้เก็บเอกสาร:

    ทุกสำนักงานมีตู้เก็บเอกสารสำหรับจัดเก็บเอกสารสำคัญเพื่อใช้อ้างอิงในอนาคต ต้องการ File จากสามเดือนที่แล้วมั้ย? ตรวจสอบตู้


    ในทำนองเดียวกัน ฐานข้อมูลจัดเก็บข้อมูลที่จำเป็นทั้งหมดสำหรับ Website ตั้งแต่ Profile ผู้ใช้ไปจนถึงเนื้อหา เมื่อ Website จำเป็นต้องเรียกคืนข้อมูลที่บันทึกไว้ Website จะดึงข้อมูลจากฐานข้อมูลผ่านบริการ Backend ฐานข้อมูลไม่เปิดให้บุคคลทั่วไปเข้า คุณไม่ต้องการให้ใครมายุ่งกับมัน - ใช่มั้ย?


    หมายเหตุ: เมื่อพูดถึงฐานข้อมูล คุณมักจะได้ยินเกี่ยวกับ SQL และ NoSQL ฐานข้อมูล SQL เช่น MySQL และ PostgreSQL มีโครงสร้างและใช้ Schema คงที่ ทำให้เหมาะสำหรับการสืบค้นที่ซับซ้อน ในทางกลับกัน ฐานข้อมูล NoSQL เช่น MongoDB และ Cassandra มีความยืดหยุ่นมากกว่าในการจัดเก็บข้อมูล และมีความสามารถในการปรับขนาดได้ดีเยี่ยม ซึ่งมักนิยมใช้กับ Big Data และ App แบบ Real-time
Last edited:


  1. .
  2. .
  3. .
  4. .
  5. .
  6. Cache — ตัวจัดระเบียบ Desktop:

    ในสำนักงาน คุณมักจะเก็บ File และบันทึกย่อที่ใช้บ่อยที่สุดไว้ใกล้มือเพื่อการเข้าถึงที่รวดเร็ว ทำไม เพราะคุณไม่ต้องการวุ่นวายกับการค้นหามัน

    Cache เป็นส่วนประกอบการจัดเก็บข้อมูลในหน่วยความจำความเร็วสูงที่เก็บชุดย่อยของข้อมูล ซึ่งโดยทั่วไปจะเป็นข้อมูลชั่วคราว (มีอายุสั้น ไม่ถาวร) เพื่อให้คำขอข้อมูลนั้นในอนาคตได้รับการตอบสนองเร็วกว่าการเข้าถึงข้อมูลหลักของสถานที่จัดเก็บข้อมูล

    Cache สามารถใช้ได้ในเกือบทุกองค์ประกอบที่คุณนึกถึง ในด้าน Browser มันเหมือนกับการเก็บ Snapshot Website อย่างรวดเร็ว แทนที่จะ Download ทุกอย่างใหม่ Browser สามารถใช้องค์ประกอบที่ Cache ไว้ ทำให้ Website Load เร็วขึ้น


    สำหรับ Backend การ Cache คือการจดจำคำขอข้อมูลล่าสุด หากผู้ใช้สองคนขอข้อมูลเดียวกัน ทำไมต้องดึงข้อมูลจากฐานข้อมูลสองครั้งแล้วประมวลผลใหม่ Cache Backend จะให้ Cache ทันทีเมื่อขอครั้งที่สอง


    สุดท้ายนี้ ในระดับฐานข้อมูล Cache จะป้องกันการดำเนินการซ้ำซ้อน หากมีการเข้าถึงข้อมูลเมื่อเร็วๆ นี้ Cache ฐานข้อมูลจะนำเสนอข้อมูลดังกล่าว ช่วยให้ฐานข้อมูลไม่ต้องทำงานเดิมอีกครั้ง Cache ทั้งหมดเหล่านี้ทำให้ผู้ใช้ปลายทางโต้ตอบได้อย่างราบรื่นและรวดเร็วยิ่งขึ้น

    การเพิ่มประสิทธิภาพด้วย Cache ช่วยเพิ่มประสิทธิภาพ แต่ก็เป็นการลงทุนเช่นกัน การค้นหาจุดที่เหมาะสมระหว่างข้อดีด้านความเร็วและต้นทุนเป็นกุญแจสำคัญในการพิจารณาเพื่อประโยชน์สูงสุด

    หมายเหตุ: การเอาข้อมูลเก่าใน Cache ออกถือเป็นแนวคิดที่สำคัญในวิทยาการ Computer มันเกี่ยวข้องกับการตัดสินใจว่าเมื่อไหร่ควร Update หรือลบข้อมูลออกจาก Cache คำพูดที่มีชื่อเสียงในสาขานี้เน้นย้ำถึงความซับซ้อนว่า: “มีเพียงสองสิ่งที่ยากในวิทยาการ Computer: การเอาข้อมูลเก่าใน Cache ออก และการตั้งชื่อสิ่งต่างๆ”

  7. Regions — เหมือนกับร้านกาแฟที่คุณชื่นชอบ:

    ลองนึกถึงร้านกาแฟหรือร้าน Fast-food ที่คุณชื่นชอบ ไม่ว่าจะเป็น Starbucks หรือ McDonald's พวกเขาสร้างชื่อให้กับตัวเองด้วยการมีสาขาในเมืองต่างๆ ทั่วโลก คุณสามารถเดินเข้าไปในร้านไหนก็ได้เหล่านี้ และแม้ว่าคุณจะอยู่เมืองอื่นหรือแม้แต่ประเทศอื่น แต่ก็ให้ความรู้สึกคุ้นเคย


    ในทำนองเดียวกัน ผู้ให้บริการ Cloud ก็สร้างศูนย์ข้อมูลของตนอย่างมีกลยุทธ์ในที่ตั้งทางภูมิศาสตร์ต่างๆ ทั่วโลก สถานที่ที่แตกต่างกันแต่ละแห่งเหล่านี้เรียกว่า 'Region' มันให้ประโยชน์หลายประการ ตัวอย่างเช่น:
    • Data Redundancy: ด้วยการจัดเก็บข้อมูลในหลายภูมิภาค ผู้ให้บริการ Cloud จึงทำให้มั่นใจได้ว่าแม้ว่าจะมีการหยุดทำงานหรือปัญหาในภูมิภาคหนึ่ง ข้อมูลของคุณยังคงปลอดภัยและสามารถเข้าถึงได้จากที่อื่น คุณสามารถเยี่ยมชมร้านอื่นๆ ได้เสมอหากร้าน McDonald's ร้านนึงปิดอยู่


    • Optimized Content Delivery: การมีศูนย์ข้อมูลใกล้กับจุดที่ผู้ใช้อยู่ หมายความว่าข้อมูลเดินทางในระยะทางที่สั้นลง ส่งผลให้ Load เร็วขึ้นและประสบการณ์ผู้ใช้ดีขึ้น คุณอาจจะเลือกร้าน McDonald's ใกล้บ้านคุณมากที่สุด


      ดังนั้น เมื่อเลือกผู้ให้บริการ Cloud หรือตั้งค่าสถาปัตยกรรม Cloud แนวทางปฏิบัติที่ดีคือ Deploy ใน Region ที่รองรับกลุ่มเป้าหมายของคุณได้ดีที่สุด
  8. VPC (Virtual Private Cloud) — เกาะส่วนตัว:

    ลองนึกภาพหมู่เกาะที่แต่ละเกาะมีเจ้าของคนละคนกัน ทุกเกาะมีความแตกต่าง และมีทรัพยากรเป็นของตัวเอง แต่ละเกาะยังคงเป็นอิสระ โดยปกป้องทรัพยากรและกิจกรรมของตนจากเกาะอื่นๆ หากต้องการค้าขายหรือสื่อสารระหว่างเกาะ พวกเขาจะต้องสร้างการเชื่อมต่อหรือทางเดินตามกฎเกณฑ์บางประการ

    VPC คือพื้นที่เครือข่ายส่วนตัว ภายในสภาพแวดล้อม Cloud มันเป็นที่ปลอดภัยสำหรับทรัพยากร ทำให้มั่นใจได้ว่าพวกมันจะถูกแยกออกจากผู้ใช้รายอื่น ภายใน VPC คุณสามารถควบคุมช่วง IP Subnet (จะกล่าวถึงในเร็วๆ นี้) ทรัพยากร และการกำหนดเส้นทางต่างๆ


    VPC เป็นคำศัพท์เฉพาะสำหรับ AWS หากใช้ Azure คุณจะพบกับคำที่คล้ายคลึงกัน นั่นคือ Azure Virtual Network (VNet)

    คุณสามารถสร้างหลาย VPC ในบัญชีเดียวกันได้ตลอดเวลา ตามค่าเริ่มต้น VPC เหล่านี้ทำงานแยกจากกันและไม่สื่อสารระหว่างกัน หากคุณต้องการให้ VPC สองตัวขึ้นไปแลกเปลี่ยนข้อมูลหรือเชื่อมต่อกัน คุณต้องตั้งค่า 'VPC Peering' กระบวนการนี้สร้างการเชื่อมต่อเครือข่ายโดยตรงระหว่าง VPC ทำให้สามารถโต้ตอบได้โดยไม่ต้องเปิดเผยทรัพยากรของตนสู่ Internet สาธารณะ

    หมายเหตุ: เมื่อสร้างบัญชีใหม่ใน AWS คุณจะได้รับการจัดสรร VPC เริ่มต้นในภูมิภาคของคุณโดยอัตโนมัติ โดย VPC ของคุณจะยังคงไม่ปรากฏให้ผู้ใช้รายอื่นเห็น ทรัพยากรที่คุณจัดเตรียม การตั้งค่าสถาปัตยกรรมของคุณ และกิจกรรมทั้งหมดภายใน VPC ของคุณนั้นเป็นแบบส่วนตัว ทำให้มั่นใจได้ว่าผู้อื่นจะไม่สามารถแอบดูได้ เว้นแต่คุณจะอนุญาตให้พวกเขาเข้าถึง
  9. Availability Zones (AZ) — สถานีไฟฟ้าแยกภายในภูมิภาค:

    ลองนึกถึงเมืองใหญ่ที่มีโรงไฟฟ้าหลายแห่ง หากสถานีนึงหยุดทำงาน สถานีอื่นๆ จะต้องเปิดไฟในเมืองให้สว่างแทน ทุกภูมิภาค Cloud มี AZ หลายแห่ง AZ แต่ละแห่งเปรียบเสมือนที่ตั้งศูนย์ข้อมูลของตัวเอง ซึ่งตั้งค่าให้ทำงานแยกกัน พวกมันทำงานร่วมกันแต่แยกจากกัน หาก AZ อันนึงมีปัญหา งานจะย้ายไปยังอีกอันนึง เพื่อให้แน่ใจว่าบริการต่างๆ ยังคงดำเนินต่อไปได้


    นี่คือการแสดงภาพแบบครอบคลุมซึ่งจะช่วยให้คุณเข้าใจวิธีการใช้ภูมิภาค และ AZ โดยทั่วไปเพื่อความยืดหยุ่นและ Redundancy

    คุณคิดว่าจะเกิดอะไรขึ้นหาก AZ III หยุดทำงานในภูมิภาค B?


    ใช่! คุณถูก. AZ อีกสองแห่งที่กำลังทำงานอยู่ในภูมิภาคเดียวกัน การรับส่งข้อมูลจะถูกเปลี่ยนเส้นทางไปยังพวกมัน และถ้าทั้งภูมิภาคล่มสลาย - อาจเป็นเพราะสงคราม?

    คุณพูดถูกอีกครั้ง Traffic จะถูกเปลี่ยนเส้นทางไปยังภูมิภาคอื่นและทุกอย่างจะทำงานได้ดียกเว้นว่ามันจะเกิดสงครามด้วย!
  10. Subnet — คุณจะไม่ยอมให้ใครเข้าไปในห้องนอนของคุณ ใช่มั้ย?:

    ลองนึกภาพบ้าน ด้านในจะมีห้องต่างๆ ห้องพักบางห้อง เช่น ห้องนั่งเล่น อาจเข้าถึงได้สำหรับแขก (Subnet สาธารณะ) แต่ห้องอื่นๆ เช่น ห้องนอนของคุณเป็นห้องส่วนตัว อนุญาตให้เฉพาะบางคน :sneaky: เข้าไปได้ - สิ่งเหล่านี้เป็นตัวแทนของพื้นที่ส่วนตัวของเรา (เครือข่ายย่อยส่วนตัว)


    Subnet ทำหน้าที่เป็น Segment เฉพาะภายใน VPC ซึ่งช่วยคุณจัดระเบียบทรัพยากร Cloud ของคุณ Subnet สาธารณะคือที่ที่คุณมักจะวางองค์ประกอบต่างๆ ที่โต้ตอบกับ Internet โดยตรง เช่น Web Server — คิดว่าสิ่งเหล่านี้เป็นพื้นที่เปิดของที่พักที่ยินดีต้อนรับผู้เยี่ยมชม


    ในทางกลับกัน Subnet ส่วนตัวจะถูกสงวนไว้สำหรับทรัพยากรที่ละเอียดอ่อนหรือสำคัญ เช่น ฐานข้อมูล หรือ Server App เฉพาะ ลองนึกภาพสิ่งเหล่านี้เป็นห้องส่วนตัวของบ้านที่เก็บสิ่งของมีค่าไว้ การแบ่งส่วนทรัพยากรในลักษณะนี้ช่วยเพิ่มความปลอดภัยและช่วยให้การตั้งค่าของคุณเป็นระเบียบ

    เมื่อพูดถึงการสื่อสารภายในเครือข่ายย่อย NAT Gateway เข้ามามีบทบาท เป็นเหมือนตู้ไปรษณีย์พิเศษ อนุญาตให้อุปกรณ์ในเครือข่ายย่อยส่วนตัวส่งจดหมายไปยัง Internet โดยไม่ต้องเปิดเผยที่อยู่บ้าน

การเปรียบเทียบ Cloud — เอกสารสรุป:

Landscape Cloud นั้นกว้างใหญ่ และเต็มไปด้วยตัวเลือกต่างๆ แต่ Amazon Web Services (AWS), Microsoft Azure และ Google Cloud Platform (GCP) เป็นผู้นำ หากต้องการทราบมุมมองที่ชัดเจนยิ่งขึ้นเกี่ยวกับข้อเสนอของพวกเค้า โปรดดูคำแนะนำแบบภาพสำหรับบริการต่างๆ ของพวกเขา


Last edited:


AWS re/Start Grad Training:

  • AWS Hybrid Storage Workshop:

  • Amazon CloudFront use AWS Edge Locations of the AWS Global Infrastructure to ensure low-latency delivery.

  • Can run apps and workloads from a Region closer to the end users to Decrease latency.

  • Networking, storage, compute, and DBs are examples of service categories that AWS offers.

  • AWS Regions are geographic areas that host two or more AZs.

  • Fault tolerant means that the infrastructure has built-in component redundancy and elastic and scalable means that resources dynamically adjust to increases or decreases in capacity requirements.

  • AZs within a Region are connected through low-latency links.

  • A data center can be used for more than one AZ.

  • Each Region is located in a separate geographic area and is a physical location that has multiple AZs.

  • AWS highly recommends provisioning compute resources across multiple AZs.

  • Edge Locations do not need to be located in the same general area as Regions.

  • A company is using Amazon OpenSearch Service to analyze data. The company loads data into an OpenSearch Service cluster with 10 data nodes from an Amazon S3 bucket that uses S3 Standard storage. The data resides in the cluster for 1 month for read-only analysis. After 1 month, the company deletes the index that contains the data from the cluster. For compliance purposes, the company must retain a copy of all input data.
    The company is concerned about ongoing costs and asks a solution architect to recommend a new solution. Solution will meet these requirements MOST cost-effectively is Reduce the number of data nodes in the cluster to 2. Add UltraWarm nodes to handle the expected capacity(, the company can reduce the cost of running the cluster). Configure the indexes to transition to UltraWarm when OpenSearch Service ingests the data (will ensure that the data is stored in the most cost-effective manner). Transition the input data to S3 Glacier Deep Archive after 1 month by using an S3 Lifecycle policy (will ensure that the data is retained for compliance purposes, while also reducing the ongoing costs).

  • Project 1 - 3 Tier Architecture:


  • In multi-account structure using AWS Organizations, AWS recommends that use the management account and its users and roles only for tasks that can be performed only by that account. Store all of AWS resources in other AWS accounts in the organization and keep them out of the management account. The one exception is that AWS does recommend that enable AWS CloudTrail and keep relevant CloudTrail trails and logs in the management account.
    One important reason to keep resources in other accounts is because Organizations SCPs do not work to restrict any users or roles in the management account.
    Separating resources from management account also help to understand the charges on invoices.

  • A company is migrating a legacy app from an on-premises data center to AWS. The app uses MongoDB as a key-value DB. According to the company's technical guidelines, all Amazon EC2 instances must be hosted in a private subnet without an internet connection. In addition, all connectivity between apps and DBs must be encrypted. The DB must be able to scale based on demand.
    Solution will meet these requirements is Create new Amazon DocumentDB (with MongoDB campatibility) tables for the app with Provisioned IOPS volumes. Use the cluster endpoint to connect to Amazon DocumentDB.
    Amazon DocumentDB (with MongoDB compatibility) can be a key-value DB that can scale based on demand and supports encryption in transit using TLS and at rest using AWS Key Management Servie (KMS). It is a fully managed document DB service that is designed to be compatible with the MongoDB API. It is a NoSQL DB that is optimized for storing, indexing, and querying JSON data. It also supports provisioned IOPS volumes that can scale up to 64 TiB of storage and 256,000 IOPS per cluster. To connect to its, can use the instance endpoint, which connects to a specific instance in the cluster, or the cluster endpoint, which connects to the primary instance or one of the replicas in the cluster. Using the cluster endpoint is recommended for high availability and load balancing purposes.

  • Solution Architect กำลังวางแผนที่จะย้ายฐานข้อมูล Microsoft SQL Server ที่สำคัญไปยัง AWS เนื่องจากฐานข้อมูลเป็นระบบเก่า ไปยังสถาปัตยกรรมข้อมูลสมัยใหม่ โดยจะต้องย้ายฐานข้อมูลโดยมีเวลาหยุดทำงานเกือบเป็นศูนย์
    สามารถใช้ Tool High Availability ของ Native DB เชื่อมต่อระบบต้นทาง (DB เก่า) กับ Instance Amazon RDS สำหรับ Microsoft SQL Server DB และ Configure Replication เมื่อทำการ Replication เสร็จ ก็สามารถเปลี่ยน Workload ไปหา Instance Amazon RDS for Microsoft SQL Server DB ได้เลย
  1. เปลี่ยนงาน(อีกครั้ง)ในวัย 30:
  2. Serverless คืออะไร?:
  3. Check Compliance ของ EC2 ด้วย Chef Inspec และ AWS Systems Manager:
  4. Tool ก็มี…ทำไมยังใช้ Python ทำ Cloud Automation อยู่:
  5. ใช้ AWS Inspector ช่วย Scan ช่องโหว่ Log4j:
  6. Tips and Tricks ในการสมัครใช้งาน AWS Account (Free Tier) เพื่อ Lab:
  7. ใช้ Terraform จัดการหลาย Account, Environment หรือ Cloud Platform:
  8. ใช้ IAM Policy และ Tag ป้องกันเผลอลบ Resource บน AWS โดยไม่ตั้งใจ:
  9. บังคับให้ใส่ Tag ทุกครั้งเมื่อสร้าง Resource บน AWS:
  10. การ Monitoring และ Notification บน AWS Backup (ดีกว่าวิธีของ AWS):

  1. Code:
  2. Code:
  3. Code:
    • Code:
      Your configuration specifies to merge with the ref 'refs/heads/master'from the remote, but no such ref was fetched.
      git config --local branch.master.merge refs/heads/main
      fatal: The upstream branch of your current branch does not matchthe name of your current branch.
      git config --global push.default current
  4. Code:
  5. Code:

Azure DevOps Engineer:

  • Any app that runs on Windows can save logs to Blob storage.

  • File system logging automatically turned off after 12 hours because Excessive logging can potentially cause app performance to degrade.
Last edited:


  • A company is expanding. The company plans to separate its resources into hundreds of different AWS accounts in multiple AWS Regions. A solution architect must recommend a solution that denies access to any operations outside of specifically designated Regions.
    Solution will meet these requirements is Launch an AWS Control Tower landing zone. Create OUs and attach SCPs that deny access to run services outside of the approved Regions.

  • An online retail company is migrating its legacy on-premises .NET app to AWS. The app runs on load-balanced (LB) frontend web servers, LB app servers, and a Microsoft SQL Server DB.
    The company wants to use AWS managed services where possible and does not want to rewrite the app. A solution architect needs to implement a solution to resolve scaling issues and minimize licensing costs as the app scales.
    Solution will meet these requirements MOST cost-effectively is Deploy Amazon EC2 instances in an Auto Scaling group behind an App Load Lalancer (ALB) for the web tier and for the app tier. Use Amazon Aurora PostgreSQL with Babelfish turned on the replatform the SQL Server DB.

  • A company hosts a data-processing app on Amazon EC2 instances. The app polls an Amazon EFS file system for newly uploaded files. When a new file is detected, the app extracts data from the file and runs logic to select a Docker container image to process the file. The app starts the appropriate container image and passes the file location as a parameter.
    The data processing that the container performs can take up to 2 hrs. When the processing is complete, the code that runs inside the container writes the file back to Amazon EFS and exits.
    The company needs to refactor the app to eliminate the EC2 instances that are running the containers. Solution will meet these requirements is Create AWS Lambda container images for the processing. Configure Lambda functions to use the container images. Extract the container selection logic to run as a decision Lambda function that invokes the appropriate Lambda processing function. Migrate the storage of file uploads to an Amazon S3 bucket.
    Update the processing code to use Amazon S3. Configure an S3 event notification to invoke the decision Lambda function when objects are created.
Multi Account Strategy:

Control Tower:

  • ตั้งค่าและควบคุมสภาพแวดล้อม AWS แบบหลายบัญชีที่ปลอดภัยโดยประสานบริการ AWS หลาย Service (Organizations, Service Catalog, IAM) ในนามของคุณ ในขณะเดียวกันก็รักษาความต้องการด้านความปลอดภัยและการปฏิบัติตามข้อกำหนด (Compliance) ของ App ของคุณ

  • ปรับใช้การควบคุมถิ่นที่อยู่ของข้อมูลและปฏิเสธการใช้ข้อมูลนอกภูมิภาคที่ระบุ

  • สร้าง Landing Zone ซึ่งเป็นสภาพแวดล้อม AWS แบบหลายบัญชีที่ออกแบบมาอย่างดี โดยอิงตามแนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยและการปฏิบัติตามข้อกำหนด

  • หลังจากการตั้งค่า Landing Zone คุณสามารถกำหนดค่า IAM Identity Center ด้วย Directory ที่รองรับ เช่น AWS Managed Microsoft AD

  • Account Factory จะจัดสรรบัญชีใหม่ในองค์กรของคุณโดยอัตโนมัติ โดยได้รับการกำหนดค่าล่วงหน้าให้ตรงกับความต้องการของคุณ

  • Guardrails เป็นกฎการกำกับดูแลที่บรรจุไว้ล่วงหน้าสำหรับการรักษาความปลอดภัย การดำเนินงาน และการปฏิบัติตามข้อกำหนด ซึ่งคุณสามารถเลือกและนำไปใช้ทั่วทั้งองค์กรหรือกับกลุ่มบัญชีเฉพาะได้ (SCP, CloudFormation, Config, Dashboard) บังคับ (Mandatory), เชิงป้องกัน, ตรวจสอบ หรือทางเลือก

  • Dashboard ช่วยให้คุณมองเห็นสภาพแวดล้อม AWS ของคุณได้อย่างต่อเนื่อง

  • Integrate รวมกับเครื่องมือ 3rd Party เพื่อเพิ่มขีดความสามารถ

  • หากต้องการย้ายบัญชีไปยัง Oraganization จาก Management Account ให้สร้างคำเชิญไปยังบัญชีอื่นและรอให้เค้ายอมรับคำเชิญ

  • ไม่มีค่าใช้จ่ายเพิ่มเติมในการใช้ AWS Control Tower แต่เมื่อคุณตั้งค่า AWS Control Tower คุณจะเริ่มมีค่าใช้จ่ายสำหรับบริการของ AWS ที่กำหนดค่าเพื่อตั้งค่า Landing Zone และ Mandatory Guardrails.
  • Retrieve file system logs using Azure CLI:
    az webapp log download --log-file  --resource-group learn-cb98e573-f681-4b18-a466-25eb122c1c3a --name contosofashions12851
    zipinfo -1
    unzip -j LogFiles/Application/*.txt
    code *.txt
    Ctrl+Q to close

  • Not all resources support tags, so will want to confirm that resource type supports them.

  • Tags are not inherited. Tags need to be applied to every supported resource that want tagged.

  • Resource groups can be nested.

  • The following approaches are a good usage/ways of Using tags:
    • to associate a cost center with resources for internal chargeback.
    • in conjunction with Azure Automation to schedule maintenance windows.
    • to store environment and department association.
  • The most efficient way to ensure a naming convention was followed across subscription is Crate a policy with naming requirements and assign it to the scope of subscription.

  • An ExpressRoute circuit with connectivity back to on-premises network would be good use of a resource lock.

  • An Azure Spring Apps cluster can also be created using the Azure portal.

  • The name of an Azure Spring Apps cluster should be unique across all of Azure.

  • On Azure Spring Apps, Spring Cloud Config Server can access Git repositories that are public, secured by SSH or using HTTP basic authentication.

  • Using Spring Cloud Config is a great solution because:
    • It uses Git, so configuration data can be tagged or rolled back.
    • Configuration is stored in a specific Git repository, which can be secured separately.
    • It provides a centralized place to store all configuration data, for all microservices.
    • It allows storing sensitive parameters (like DB password) outside of application.
  • Will research performance capability in Azure because The team needed to perpare for performance target negotiations.
    It's crucial that well prepared for negotiations. Understanding platform's capabilities before begin negotiating will help set realistic targets that are achievable.

  • The anticipated growth pattern of the workload is an important factor to include when working on identifying performance targets.

  • Identifying workload flows and their performance targets is a more effective way/contextualized to ensure that critical functions of the workload are designed appropriately, not individual resources.

  • In the context of designing to meet capacity requirements, one way that can choose the right resources for workload is Consider features that can fulfill the scalability requirements of workload.
    Being able to take advantage of built-in scaling features is a great design choice that can help meet capacity requirements.

  • Predictive modeling can help forecast the future capacity requirements of workload.

  • High latency communicating with on-premises IoT devices might affect compute requirements, so have to test the hypothesis.

  • Should test performance throughout the dev lifecycle, including production.

  • It is important to monitor both real and synthetic transactions workload to ensure that performance during real-world usage is acceptable.

  • If saw some inefficiencies in DB structure that could cause performance issues as the workload's usage increses, should planning on changing the DB structure.

  • By dedicating time during each cycle to address performance issues, the team will able to address longstanding issues and continuously improve the efficiency of workloand.

  • Implement new design patterns and components can boost performance in ways that may not be possible with current design.

  • An app performance monitoring tool can help analyze performance trends and identify execution bottlenecks.
Last edited:


  • A company runs an IoT platform on AWS IoT sensors in various locations send data to the company's Node js API servers on Amazon EC2 instances running behind an ALB. The data is stored in an Amazon RDS MySQL DB instance that uses a 4 TB General Purpose SSD volume. The number of sensors the company has deployed in the field has increased over time and is expected to grow significantly. The API servers are consistently overloaded and RDS metrics show high write latency. To resolve the issues permanently and enable growth as new sensors are provisioned should:
    Leverage Amazon Kinesis Data Streams and AWS Lambda to ingest and process the raw data. Amazon Kinesis Data Streams is a serverless streaming data service that simplifies the capture, processing, and storage of data streams at any scale. It can handle any amount of streaming data and process data from hundreds of thousands of sources with very low latency. AWS Lambda is a serverless compute service that lets run code without provisioning or managing servers. It can be triggered by Kinesis Data Streams events and process the data records in real time. It can also scale automatically based on the incoming data volume. By using them, the company can reduce the load on the API servers and improve the performance and scalability of the data ingestion and processing layer.
    And Re-architect the DB tier to use Amazon DynamoDB instead of an RDS MySQL DB instance. It is a fully managed key-value and document DB that delivers single-digit milisecond performance at any scale. It supports auto scaling, which automatically adjusts read and write capacity based on actual traffic patterns. It also supports on-demand capacity mode, which instantly accommodates up to double the previous peak traffic on a table. By using itinstead of RDS MySQL DB instance, the company can eliminate high write latency and improve scalability and performance of the DB tier.

  • A company is developing a new serverless API by using Amazon API Gateway and AWS Lambda. The company integrated the Lambda functions with API Gateway to use several shared libraries and custom classes. A solution architect needs to simplify the deployment of the solution and optimize for code reuse.
    Solution will meet these requirements is Deploy the shared libraries and custom classes to a Docker image. Upload the image to Amazon Elastic Container Registry (ECR). Create a Lambda layer that uses the Docker image as the source. Then, Deploy the API's Lambda functions as Zip packages. Configure the packages to use the Lambda layer.
    A Lambda layer is a distribution mechanism for libraries, custom runtimes, and other function dependencies. It allows to mange in-dev function code separately from dependencies, this way can easily update dependencies without having to update entire function code.
    By deplying the shared libraries and custom classes to a Docker image and uploading the image to Amazon ECR, it makes it easy to manage and version the dependencies. This way, the company can use the same version of the dependencies across different Lambda functions.
    By creating a Lambda layer that uses the Docker image as the source, the company can configure the API's Lambda functions to use the layer, reducing the need to include the dependencies in each function package, and making it easy to update the dependencies across all functions at once.

  • A company is migrating a document processing workload to AWS. The company has updated many apps to natively use the Amazon S3 API to store, retrive, and modify docs that a processing server generates at a rate of approximately 5 docs every second. After the doc processing is finished, customers can download the docs direcly from Amazon S3.
    During the migration, the company discovered that it could not immediately update the processing server that generates many docs to support the S3 API. The server runs on Linux and requires fast local access to the files that the server generates and modifies. When the server finishes processing, the files must be available to the public for download within 30 mins.
    Solution will meet these requirements with the LEAST amount of effort is Configure Amazon FSx for Lustre with an import and export policy. Link the new file system to an S3 bucket. Install the Lustre client and mount the doc store to an Amazon EC2 instance by using NFS.
    Amazon FSx for Lustre is a fully managed service that provides cost-effective, high-performance, scalable storage for compute workloads. Powered by Lustre, the world's most popular high-performance file system, it offers shared storage with sub-ms latencies, up to terabytes per sec of throughput, and millions of IOPS. It can also be linked to Amazon Simple Storage Service (S3) buckets, allowing to access and process data concurrently from both a high-performance file system and from the S3 API.

  • Use Azure CLI to deploy a web app:
    az appservice plan create --name $appPlan --resource-group $resourceGroup --location $appLocation --sku FREE
    az webapp create --name $appName --resource-group $resourceGroup --plan $appPlan --deployment-source-url $gitRepo
    az storage account create -n $storageAccount -g $resourceGroup -l $appLocation --sku Standard_LRS

  • Use Azure CLI to view the live log stream:
    az webapp log tail  --resource-group learn-cb98e573-f681-4b18-a466-25eb122c1c3a --name contosofashions12851
    Ctrl+C to stop

  • Using a common toolset ops and dev teams can make it easier to share knowledge and collaborate by reducing the number of communication and collaboration methods/issues.

  • Blameless postmortems is an example of building a continuous learning and experimentation mindset. They are a key component of DevOps culture and are used to learn from incidents and improve processes.

  • Lacking of standardization in toolset could affected productivity and quality.

  • Azure DevOps Boards is an example of an industry-standard tool for maintaining a backlog.

  • Testing early and often in the dev cycle helps dev velocity and efficiency by catching bugs early and reducing the cost of fixing them.

  • Azure DevOps provides reporting features that can help measure velocity and identify areas for improving quality and efficiency.

  • Adding additional monitoring to the app allow the team to identify the root cause.

  • Dashboards should be designed to provide the right information to the right people. This means that each team should have their own dashboard that provides the information they need to do their job.

  • Alerts should be actionable, not informational.

  • Deploying Infrastructure as Code (IaC) help deploy with confidence. It allows to consistently and repeatedly deploy workload, cutting down the risk of human error.

  • By moving the IaC code to the same repository as the app code, the team will cut down the risk of security or governance issues by applying the same standards across both codebases.

  • Using a common deployment manifest across workload environments ensures that DR environment mirrors primary environment, can be deployed quickly, and will go efficiently.

  • The doc available for the task is important, but shouldn't be a deciding factor when evaluating it for automation.

  • Automation is integral to the workload, and should be maintained with the same standards as the rest of the workload components for all WAF pillar areas.

  • A fundamental principle of safe deployment practices is All deployments should be automated through pipelines. This ensures that deployments are consistent and repeatable.
Last edited:


  • A company is migrating to the cloud. It wants to evaluate the configurations of VMs in its existing DC environment to ensure that it can size new Amazon EC2 instances accurately. The company wants to collect metrics, such as CPU, memory, and disk utilization, and it needs an inventory of what processes are running on each instance. The company would also like to monitor network connections to map communications between servers.
    Would enable the collection of this data MOST cost effectively is Use AWS App Discovery Service and deploy the data collection agent to each VM in the DC.
    The AWS App Discovery Service can help plan migration projects by collecting data about on-premises servers, such as configuration, performance, and network connections. The data collection agent is a lightweight software that can be installed on each server to gather this information. This option is more cost-effective than agentless discovery, which requires deploying a virtual appliance in the VMware environment, or using CloudWatch agent, which incurs additional charges for CloudWatch Logs. Scanning the servers over a VPN is not a valid option for AWS App Discovery Service.

  • A company has a legacy app that runs on multiple .NET Framework components. The components share the same Microsoft SQL Server DB and communicate with each other asynchronously by using Microsoft Message Queueing (MSMQ).
    The company is starting a migration to containerized .NET Core components and wants to refactor the app to run on AWS. The .NET Core components require complex orchestration. The company must have full control over networking and host configuration. The app's DB model is strongly relational. Solution will meet these requirements is Host the .NET Core components on Amazon Elastic Container Service (ECS) with the Amazon EC2 launch type. Host the DB on Amazon Aurora MySQL Serverless v2. Use Amazon Simple Queue Service (SQS) for asynchronous messaging.
    Amazon ECS is a fully managed container orchestration service that supports both AWS Fargate and Amazon EC2 as launch types. The Amazon EC2 launch type allows users to choose their own EC2 instances, configure their own networking settings, and access their own host OS.
    Hosting the DB on Amazon Aurora MySQL Serverless v2 will have a strongly relational DB model and using the same DB engine as SQL Server. MySQL is a compatible relational DB engine with SQL Server, and it can support most of the legacy app's DB model. Amazon Aurora MySQL Serverless v2 is a serverless version of Amazon Aurora MySQL that can scale up and down automatically based on demand.
    Using Amazon SQS for asynchronous messaging provides a compatible replacement for MSMQ, which is a queue-based messaging system. It is a fully managed message queuing service that enables decoupled and scalable microservices, distributed systems, and serverless apps.

  • A company has used IaC to provision a set of two Amazon EC2 instances. The instances have remained the same for several years. The company's business has grown rapidly in the past few months. In response the company's operations team has implemented an Auto Scaling group to manage the sudden increases in traffic. Company policy requires a monthly installation of security updates on all OS that are running.
    The most recent security update required a reboot. As a result, the Auto Scaling group terminated the instances and replaced them with new, unpatched instances. To avoid a recurrence of this issue a solution architect should recommend to Create an Elastic Load Balancer in front of the Auto Scaling group. Configure monitoring to ensure that target group health checks return healthy after the Auto Scaling group replaces the terminated instances. And Create automation scripts to patch an AMI, update the launch configuration, and invoke an Auto Scaling instance refresh.

S3 Storage Classes:​

Storage Class​
S3 StandardDefault
S3 Intelligent TieringAutomatically move data to most cost-effective storage tier, by monitoring access patterns.
Used when access patterns are not known.
S3 Standard-Infrequent Access (IA)For Long lived less frequently access data.
Charged for minimum 30 days.
S3 One Zone - IAStores data in One AZ Only.
Less expensive than standard IA.
S3 Glacier Instant RetrievalArchive rarely accessed data. Quick Retrieval.
Minimum storage period of 90 days.
S3 Glacier Deep ArchiveArchive rarely accessed data. Lowest cost data archiving.
Retrieval time in hours.


  • A recommended deployment strategy is Prefer small, frequent deployments are less risky and easier to roll back.

  • Feature flags allow to gradually/control expose new features to users, and to roll back the features if necessary.

  • Azure Monitor collect Data from a variety of sources, such as the app event log, the operating system (Windows and Linux), Azure resources, and custom data sources. It collects two types of data: metrics and logs. Metrics are numerical values that describe some aspect of a system at a particular time. Logs contain different kinds of data, such as event information, organized into records.

  • If a Web site seems slow, it is often because the Web server is receiving more traffic than it can handle. Request wait time is a common metric used to determine whether a server is overloaded.
Last edited: