آمازون VPC Lattice – مطالعه امکان سنجی

آمازون VPC Lattice اکنون به طور کلی در دسترس است (مارس 2023) و در نهایت، من موفق شدم آن را امتحان کنم و ببینم که آیا انتظاراتی را که در AWS re:Invent 2022 برانگیخته بود برآورده می کند یا خیر. تعداد کمی از آنها وجود داشت، به عنوان مثال، داشتن توانایی اجتناب از استفاده از همتایان VPC یا نقاط پایانی سرویس VPC برای تسهیل ارتباط بین حساب‌ها، برنامه‌های کاربردی متقابل VPC در حالی که مدیریت شبکه اصلی را از پیکربندی سرویس‌های فردی در سراسر مجموعه جدا می‌کند، و همچنین به راحتی خدمات را تعریف و به یک شبکه برنامه گسترده‌تر متصل می‌کند. مش

محض احتیاط…

Amazon VPC Lattice یک سرویس شبکه برنامه کاربردی کاملاً مدیریت شده است که از آن برای اتصال، ایمن سازی و نظارت بر همه سرویس های خود در چندین حساب و ابرهای خصوصی مجازی (VPC) استفاده می کنید. ~ AWS

نیاز به دانستن بیشتر دارید؟ – اینجا را بررسی کنید زیرا بقیه این داستان فرض می کند که شما اصول اولیه را می دانید و همه چیز در مورد ارائه نتایج آزمایش های اولیه من با VPC Lattice و همچنین به اشتراک گذاشتن یافته ها و نظرات من است.

اثبات مفهوم

ایده ساده بود – من می‌خواستم قابلیت‌های کاربردی VPC Lattice را تا حد امکان با یک لمس سبک روی موارد غیر کاربردی آزمایش کنم. و بنابراین من به ساختن این پایان رسیدم…

آنچه در بالا می بینید یک مجموعه است شامل:

• دو حساب AWS بخشی از یک سازمان AWS هستند
• دو شبکه خدمات شبکه VPC که در آن تست شماره 1 از طریق رم به اشتراک گذاشته می شود
• دو سرویس شبکه VPC که در آن test-svc-1 از طریق RAM برای ارتباط با تست شماره 2 شبکه خدمات
• سه VPC مرتبط با شبکه های خدماتی که در آن VPC .103 فقط مشتری است
• test-svc-1 خدمات با چندین نوع هدف مختلف

توجه: این بیگودی‌های دارای لامبدا در هر سه VPC برای تسهیل ارسال درخواست‌های HTTP سفارشی به هر سرویس شبکه VPC برای اهداف آزمایشی وجود دارند. به کد منبع تابع Lambda نیاز دارید تا خودتان آن را امتحان کنید؟ این پیچیده نیست اما کار را انجام می دهد و اینجاست:

import json
import http.client
import ssl
from urllib.parse import urljoin

###################################################################################
REQ_PROTOCOL = '<???>'                            # options: 'http', 'https'
REQ_HOST     = '<???>'                            # e.g. myservice.mydomain.aws
REQ_PATH     = "https://dev.to/"                                # e.g. '/lambda80', '/lambda443'
REQ_HEADERS  = {                                  # a map of custom headers
    # "My-Header": "lambda-hh",                       
    "Content-Type": "application/json"
}
###################################################################################

def get(protocol, host, path, headers, event):
    """GET request"""

    if protocol == "https":
        conn = http.client.HTTPSConnection(host, context = ssl._create_unverified_context())
    elif protocol == "http":
        conn = http.client.HTTPConnection(host)
    else:
        return "[ERR] Unknown protocol provided!"

    try:
        conn.request('GET', path, json.dumps(event), headers)
        res = conn.getresponse()
        location_header = res.getheader("location")

        if location_header is not None:
            location = urljoin(path, location_header)
            # print(location)
            return get(protocol, host, location, headers, event)

        data = res.read()
    except Exception as error:
        return f"[ERR] {str(error)}"

    return data

def lambda_handler(event, context):
    """Lambda handler"""

    response = get(
        REQ_PROTOCOL,
        REQ_HOST,
        REQ_PATH,
        REQ_HEADERS,
        event
    )

    return {
        "statusCode": 200,
        "body": response,
        "headers": {
            "Content-Type": "application/json"
        }
    }

سرویس شبکه VPC

که test-svc-1 با این حال، عنصر اصلی است و بیشتر تمرکز بر روی سرویس VPC Lattice، جنبه‌های پیکربندی شبکه‌های سرویس و همچنین ارتباط بین حساب‌ها و متقابل VPC با سرویس‌ها بود. چندین میکروسرویس را به صورت خصوصی تحت ترکیب های مختلف پروتکل ها، پورت ها و مسیرهایی که توسط سرویس های محاسباتی AWS مختلف نشان داده شده و با گروه های هدف زیر (TGs) پیکربندی شده اند، در معرض دید قرار می دهد:

• EC2 در ASG
• ALB با EC2 در ASG
• ALB با ECS مجهز به Fargate
• توابع لامبدا

به غیر از یک تابع Lambda، هر چیز دیگری در زیرشبکه های خصوصی در چندین منطقه در دسترس اجرا می شود.

حدس بزن چی شده!؟ همه چیز خیلی خوب کار کرد!
اما هی! آیا این پیکربندی و عناصر آن آشنا به نظر نمی رسد؟
برای من، اینطور شد، از این رو می‌خواهم بیانیه زیر را به خطر بیاندازم…

سرویس شبکه VPC آمازون اجرای یک Application Load Balancer خصوصی با ویژگی‌های مرتبط با حساب و اعتبار در ذهن است.

سرویس شبکه VPC در مقابل ALB

اول از همه، VPC Lattice برای برآورده کردن تعادل بار لایه برنامه با اهداف وزنی و پشتیبانی از استقرار آبی/سبز (B/G) است.
علاوه بر این، بیایید نگاهی به انواع هدف گروه هدف در هر دو مورد داشته باشیم:

همانطور که می بینید هر دو TG تقریباً از یک نوع هدف با تنها تفاوت های کوچک پشتیبانی می کنند که لزوماً به این معنی نیست که یک گزینه از دست رفته است. به عنوان مثال حتی اگر مقیاس خودکار آمازون EC2 به صراحت در بخش Instances ذکر نشده است. من موفق شدم با موفقیت یک ASG را مطابق نمودار بالا ضمیمه کنم زیرا آن گزینه به سادگی وجود دارد:

بله، همان ASG را می توان همزمان به یک سرویس شبکه ALB و VPC متصل کرد. در اینجا هیچ چیز تعجب آور نیست زیرا ممکن است نیاز باشد که یک سرویس داده شده نه تنها به صورت خصوصی برای سرویس دیگری بلکه برای مشتریان از طریق یک شبکه عمومی نیز قابل دسترسی باشد.

علاوه بر این، پیکربندی مسیریابی سرویس شبکه VPC از شنوندگان و قوانین درست مانند مورد ALB تشکیل شده است، با این حال، تمام ترافیک فقط بدون هیچ گونه دستکاری قابل ارسال است.

در نهایت، هزینه‌های اجرای یک سرویس شبکه VPC در مقابل یک ALB تقریباً یکسان است. به عنوان مثال، در منطقه ایرلند (eu-west-1)، 0.0275 دلار در برابر 0.0252 دلار در ساعت است.

ادغام EKS

من معتقدم Gateway API و Amazon EKS مورد استفاده خاص تری را تشکیل می دهند که سزاوار لمس جداگانه است، بنابراین در محدوده این مطالعه نیست.
برای کسانی که علاقه مند هستند، می توانم بگویم که وجود دارد کنترلر API AWS Gateway با استفاده از شبکه VPC Amazon به شما امکان می دهد خدمات را در میان خوشه های مختلف EKS متصل کنید، و اطلاعات بیشتر در مورد نحوه انجام این کار را می توانید در اینجا بیابید.

ادمین در مقابل توسعه دهنده

یکی از ویژگی های کلیدی هنگام اعلام VPC Lattice این بود که در نهایت امکان تفکیک وظایف بین مدیران شبکه و توسعه دهندگان را فراهم می کند که اکنون می توانند آزادانه خدمات خود را تعریف و مدیریت کنند.
این من را به یاد زمان‌هایی می‌اندازد که مدت کوتاهی پس از معرفی AWS Lambda و پیش‌بینی دوران بدون عملیات‌ها بود. زمان همچنین در این مورد نشان خواهد داد که آیا هیچ دخالت ادمین در پیکربندی سرویس های VPC Lattice قابل انجام نیست یا خیر.
در هر صورت، ایده این است که توسعه دهندگان به سادگی یک VPC برای توسعه و تعریف سرویس های خود دریافت می کنند تا بتوانند آنها را با مدیرانی که شبکه های سرویس VPC Lattice را کنترل می کنند به اشتراک بگذارند:

• ارتباط سرویس ها و VPC ها به شبکه ها بر اساس نیازها،
• اشتراک گذاری شبکه های خدمات با حساب ها یا سازمان های AWS،
• اجرای احراز هویت در دسترسی به شبکه خدمات

اشتراک گذاری

هر دو سرویس شبکه VPC و شبکه های خدماتی را می توان با استفاده از AWS Resource Access Manager (RAM) به اشتراک گذاشت. در حالی که سرویس‌ها برای مرتبط شدن با شبکه‌های خدمات مختلف به اشتراک گذاشته می‌شوند، شبکه‌های خدماتی به اشتراک گذاشته می‌شوند تا دیگر مدیران بتوانند VPC‌های خود را مرتبط کرده و با سرویس‌های مرتبط با آن شبکه‌ها ارتباط برقرار کنند.
برای درک بهتر کارهایی که می‌توان به‌عنوان مالک و/یا مصرف‌کننده منابع مشترک انجام داد و یا نمی‌توان انجام داد، بخش «مسئولیت‌ها و مجوزها برای منابع مشترک» را در اسناد اسکن کنید زیرا اطلاعات موجود در آنجا می‌تواند هنگام طراحی معماری‌های پیچیده‌تر و درجه سازمانی بسیار مفید باشد. استراتژی ها.

امنیت

قوانینی که ارتباطات شبکه مجاز را بین سرویس های فردی ساکن در VPC ها تعریف می کند با استفاده از استفاده می شود گروه های امنیتی (SGs) پیکربندی شده برای هر VPC برای سرویس شبکه شبکه. از سوی دیگر، لیست های پیشوند مدیریت شده شبکه VPC IPv4 و IPv6، بخش دیگری از تنظیم را که شامل کلاینت ها می شود و قوانین امنیتی را هدف قرار می دهد، ساده می کند.

یکی دیگر از عناصر امنیتی گسترده تر هستند سیاست های احراز هویت که می تواند هم در شبکه خدمات و هم در سطح سرویس اعمال شود. آنها توسط اسناد خط مشی IAM نشان داده می شوند و قرار است به روشی دقیق تر کنترل کنند که کدام اصلی به کدام سرویس یا گروهی از خدمات دسترسی دارد.
هم سیاست‌های SG و هم سیاست‌های احراز هویت اختیاری هستند اما توصیه می‌شوند.

ثبت و نظارت

در حالی که همه ویژگی‌های خارج از جعبه به خوبی در اسناد توضیح داده شده‌اند، یک نکته قابل تاکید این است که هر دو سرویس شبکه VPC و گزارش‌های شبکه خدمات می‌توانند به صورت همزمان در موارد زیر پخش شوند:

• CloudWatch Log Group
• سطل S3
• جریان تحویل Kinesis Data Firehose

عالی! مایلم آن را برای هر سرویس AWS از جمله ALB ببینم.

بسته بندی شبکه VPC

هشدارها

از آنجایی که سرویس شبکه VPC آمازون هنوز جدید است، احتیاط ها و محدودیت هایی وجود دارد که باید درباره آنها بدانید. یکی از آنها که به عنوان موقت ادعا می شود، توانایی ایجاد تنها یک شرایط دقیق مسیر مطابقت (غیر حساس) شنونده در کنسول است. برای پیکربندی شرایط مطابقت HTTP برای PoC خود، مجبور شدم از دستور AWS CLI زیر استفاده کنم:

$ aws vpc-lattice create-rule \
--name lambda-hh \
--service-identifier svc-0ce77bf32833f5b5b \
--listener-identifier listener-0f287b2d41f2cb905 \
--action '{ "forward": { "targetGroups": [ { "targetGroupIdentifier": "tg-0096d77adfb1bcd29", "weight": 1 } ] } }' \
--match '{ "httpMatch": { "headerMatches": [ { "caseSensitive": false, "match": { "contains": "lambda-hh" }, "name": "My-Header" } ] } }' \
--priority 20

BTW، فکر نکنید که بتوانید هدر Host را با آن قانون مطابقت دهید – این مانند یک ALB با مسیریابی مبتنی بر میزبان نیست.
با این حال، ایجاد این قانون از طریق API منجر به مرتبط شد غیرقابل ویرایش شدن شنونده از کنسول دیگر (نگاه کنید به اسکرین شات بالا، دکمه “Edit listener” خاکستری است).

فقط به دلیل توانایی های ارائه شده با VPC Lattice، اشتهای شما برای سناریوهای پیچیده تر و پیچیده تر ممکن است افزایش یابد، بنابراین فراموش نکنید هر VPC می تواند به طور همزمان با یک شبکه خدمات مرتبط شود! بنابراین، مهم است که معماری خود را بر اساس آن طراحی کنید.

هنگام کار با لامبدا به عنوان هدف عمل می کند، تا زمانی که عملکرد شما نیازی به دسترسی به منابع VPC سفارشی شما نداشته باشد، نیازی به پیکربندی آن با VPC نیست. حتی زمانی که درخواستی را از طریق یک سرویس شبکه VPC به یک تابع Lambda تنظیم شده با VPC ارسال می کنید، از ENI مرتبط در آن VPC برای ارتباط استفاده نمی کند. در عوض، همیشه از طریق Lambda API در منطقه ای که در آن قرار دارد، با عملکرد شما ارتباط برقرار می کند، و آنچه در بالا به وضوح در عکس خروجی پرس و جو CW Logs Insights قابل مشاهده است – ورودی های بدون مقصدVpcId را ببینید.
آیا به جزئیات بیشتری در مورد آن نیاز دارید؟ نگاهی به داستان “پارادوکس امنیتی لامبدا” من در سال 2019 بیندازید.

همچنین یک چیز وجود دارد که من خیلی راحت از دستش می دهم. یعنی، حتی اگر اسناد می‌گویند که باید قوانینی داشته باشید که اجازه می‌دهد از کلاینت‌ها به شبکه VPC اجازه عبور داده شود. لیست سفید محلی مشتریانی که در VPC مرتبط با شبکه خدمات زندگی می کنند در حالی که فقط به کسانی که در طرف دیگر شبکه هستند اجازه می دهد. به عبارت دیگر، هنگام پیکربندی یک کلاینت (مانند آن test-svc-curler تابع لامبدا در VPC .103) شما باید:

• [Lambda SG] اجازه دادن به ترافیک خروجی به لیست پیشوند شبکه VPC
• [VPC SG] اجازه ترافیک ورودی از Lambda SG را بدهید

آخرین اما نه کم‌اهمیت، مطمئن شوید که پیش‌فرض چیست سهمیه خدمات هستند و در صورت درخواست می توان آنها را تنظیم کرد.

انتظارات

پس از تماشای ویدیوی مقدماتی re:Invent، در مورد مسیریابی مبتنی بر مسیر، انتظار کمی بیشتر داشتم. یعنی، من فکر می‌کردم که اجازه می‌دهد تا کل مسیریابی برنامه را در سطح خدمات شبکه VPC بدون توجه به نوع هدف تعریف کنیم. با داشتن فوروارد به عنوان تنها اقدام موجود، هنگام استفاده از EC2 یا ECS به عنوان هدف، آن مسیر همیشه به پشتیبان ارسال می شود که باید آن اطلاعات را در نظر بگیرد و بداند چگونه با چنین درخواست هایی برخورد کند و 404 را پرتاب نکند.
در حالی که هنگام استفاده از Lambda و Gateway API برای EKS مشکلی نیست، من فکر می‌کنم که اجتناب از همگام‌سازی نقشه مسیرها بین زیرساخت و کد برنامه، بسیار عالی است، به‌خصوص زمانی که ممکن است در مخازن مختلف نگهداری شوند و خطوط لوله استقرار مستقل داشته باشند. .

و سلام، پشتیبانی از هدف دروازه API خصوصی آمازون کجاست!؟

خوب، عالی و عالی!

در هر صورت، شک ندارم که Amazon VPC Lattice نسبت به آنچه که باید برای برآوردن کام‌های سرویس به سرویس خصوصی، بین حساب‌های متقابل و متقابل VPC ایجاد می‌شد، پیشرفت فوق‌العاده‌ای است. در حالی که همیشه فضایی برای بهبود و ویژگی‌های بیشتر وجود دارد، اما من مطمئن هستم که AWS با گذشت زمان و بر اساس بازخورد مشتریان آن‌ها را معرفی می‌کند، قبلاً کارها را آسان‌تر کرده است:

• ساده‌سازی کام‌های متقابل سرویس به سرویس،
• کاهش مشکل همپوشانی IP،
• افزایش امنیت ارتباطات سرویس به سرویس،
• تسهیل استقرار B/G یا تست A/B،
• حمایت از مهاجرت و فعالیت های نوسازی،
• و بیشتر.

در نهایت، یک چیز عالی در مورد VPC Lattice این است که سرویس‌ها می‌توانند با بسیاری از شبکه‌های خدمات مرتبط شوند و در عین حال حداکثر انعطاف‌پذیری و توسعه‌پذیری را فراهم کنند. بی صبرانه منتظر شروع استفاده از آن در پروژه های آینده باشید!