AWS Landing Zone ஐ விரிவுபடுத்துதல்

AWS அதன் உலகளாவிய தடத்தை விரிவுபடுத்தும் போது, நிறுவனங்களுக்கு புதிய regions க்கு தங்கள் கிளவுட் இருப்பை விரிவுபடுத்த கட்டமைக்கப்பட்ட அணுகுமுறை தேவை. AWS புதிய regions களை அறிமுகப்படுத்தும் போது, நிறுவனங்கள் தங்கள் தடத்தை விரிவுபடுத்த முயல்கின்றன. இந்த வழிகாட்டுதல் உங்கள் AWS Organization அல்லது Landing Zone ஐ விரிவுபடுத்துவதற்கான முக்கிய பரிசீலனைகள் மற்றும் சிறந்த நடைமுறைகளை கோடிட்டுக் காட்டுகிறது.

அடித்தளத்தை கட்டமைத்தல்

விரிவான governance controls களுடன் வலுவான கிளவுட் அடித்தளத்தை அமைப்பது ஒரு சிறந்த நடைமுறை மட்டுமல்ல -- இன்றைய மாறும் கிளவுட் சூழலில் இது ஒரு முக்கியமான அவசியம். தொடக்கத்திலிருந்தே வலுவான governance frameworks களை நிறுவுவதில் நேரத்தை முதலீடு செய்யும் நிறுவனங்கள், வளரும் போது அளவிடவும், தழுவலுக்கும், பாதுகாப்பை பராமரிக்கவும் சிறந்த நிலையில் இருப்பதைக் காண்கின்றன. வீடு கட்டுவது போல நினைத்துக் கொள்ளுங்கள்: வலுவான அடித்தளம் இல்லாமல், எந்த சேர்த்தல்களும் மாற்றங்களும் பெருகிய முறையில் ஆபத்தானதாகவும் சிக்கலானதாகவும் மாறும். Service Control Policies (SCPs), guardrails மற்றும் compliance frameworks உட்பட கிளவுட் governance controls, உங்கள் கிளவுட் உள்கட்டமைப்பு பாதுகாப்பாகவும், இணக்கமாகவும், நிர்வகிக்கக்கூடியதாகவும் இருப்பதை உறுதி செய்யும் கட்டிடக்கலை வரைபடங்கள் மற்றும் கட்டிட விதிகளாக செயல்படுகின்றன. புதிய regions க்கு விரிவாக்கும் போது, இந்த controls இருப்பது விரிவாக்க செயல்முறையை மேலும் நெறிப்படுத்தப்பட்டதாகவும் பாதுகாப்பானதாகவும் ஆக்குகிறது. பின்னர் governance controls களை மீண்டும் பொருத்துவது ஆரம்ப அமைப்பின் போது அவற்றை செயல்படுத்துவதை விட கணிசமாக சவாலானதும் ஆதார-தீவிரமானதும் என்பதை நிறுவனங்கள் அடிக்கடி கண்டுபிடிக்கின்றன. governance க்கான இந்த செயல்படு அணுகுமுறை பாதுகாப்பு சம்பவங்கள் மற்றும் compliance மீறல்களைத் தடுக்க உதவுவது மட்டுமல்லாமல், செயல்பாட்டு சிறப்பை பராமரிக்கும் அதே நேரத்தில் மாறும் வணிகத் தேவைகளுக்கு தழுவுவதற்கான நெகிழ்வுத்தன்மையையும் வழங்குகிறது.

Organization-First அணுகுமுறை vs. Control Tower: முக்கிய வேறுபாடுகள்

புதிய region க்கு விரிவாக்கும் போது, வாடிக்கையாளர்களுக்கு தங்கள் ஏற்கனவே உள்ள அமைப்பைப் பொறுத்து இரண்டு முதன்மை பாதைகள் உள்ளன. AWS Organizations கையேடு ஆனால் மிகவும் நெகிழ்வான அணுகுமுறையை வழங்குகிறது, செயல்படுத்தல் விவரங்களின் மீது நுணுக்கமான கட்டுப்பாட்டை அனுமதிக்கிறது. இந்த பாதைக்கு ஒவ்வொரு சேவையின் கையேடு கட்டமைப்பு மற்றும் Service Control Policies இன் தனிப்பயன் செயல்படுத்தல் தேவை, ஆனால் குறிப்பிட்ட தேவைகளுக்கு அதிகபட்ச நெகிழ்வுத்தன்மையை வழங்குகிறது. மாறாக, AWS Control Tower Account Factory உடன் மேலும் நெறிப்படுத்தப்பட்ட, தானியங்கி அணுகுமுறையை முன்கட்டமைக்கப்பட்ட governance controls மற்றும் தரப்படுத்தப்பட்ட guardrails உடன் வழங்குகிறது. Control Tower பல-கணக்கு அமைப்பு செயல்முறையை கணிசமாக எளிமைப்படுத்துகிறது, இருப்பினும் தூய Organizations அணுகுமுறையை விட குறைவான நெகிழ்வுத்தன்மை இருக்கலாம். இந்த பாதைகளுக்கு இடையிலான தேர்வு பெரும்பாலும் உங்கள் ஏற்கனவே உள்ள உள்கட்டமைப்பு மற்றும் குறிப்பிட்ட governance தேவைகளைப் பொறுத்தது.

Governance மற்றும் Security Controls

புதிய AWS regions க்கு விரிவாக்கும் போது ஒரு நல்ல விஷயம் என்னவென்றால், CloudTrail மற்றும் AWS Billing போன்ற சில அடித்தள சேவைகள் தங்கள் ஏற்கனவே உள்ள configurations களில் புதிய regions களை தானாகவே உள்ளடக்குகின்றன. CloudTrail, அனைத்து regions களுக்கும் கட்டமைக்கப்படும் போது, புதிய regions உங்கள் கணக்கிற்கு கிடைக்கும் போது அவற்றில் API activity ஐ தானாகவே log செய்யத் தொடங்கும், கூடுதல் அமைப்பு தேவையில்லை. இதேபோல், AWS Billing அனைத்து செயலில் உள்ள regions களின் செலவுகளை தானாகவே ஒருங்கிணைக்கிறது, AWS Cost Explorer மற்றும் AWS Bills மூலம் ஒருங்கிணைந்த செலவு மேலாண்மை மற்றும் அறிக்கையிடலை வழங்குகிறது.

எனினும், இந்த சேவைகள் தானாகவே தழுவினாலும், Service Control Policies, GuardDuty, Security Hub மற்றும் AWS Config போன்ற பிற பாதுகாப்பு மற்றும் செயல்பாட்டு சேவைகள் உங்கள் விரிவாக்கப்பட்ட தடத்தின் விரிவான coverage ஐ உறுதி செய்ய வெளிப்படையான பிராந்திய செயல்படுத்தல் தேவை என்பதை கவனிக்க வேண்டும்.

அணுகல் கட்டுப்பாடு

AWS Identity and Access Management (IAM) என்பது உங்கள் முழு AWS தடத்திலும் தடையின்றி செயல்படும் உலகளாவிய சேவைகளில் ஒன்றாகும். நீங்கள் ஒரு region க்கு விரிவாக்கும் போது, உங்கள் ஏற்கனவே உள்ள IAM users, roles மற்றும் policies ஏற்கனவே தயாராக உள்ளன - கூடுதல் கட்டமைப்பு தேவையில்லை! உங்கள் ஏற்கனவே உள்ள IAM principals பிற regions களில் உள்ளதைப் போலவே தானாகவே அதே அனுமதிகளைக் கொண்டிருக்கும் (உங்கள் policies region-குறிப்பிட்ட கட்டுப்பாடுகளை உள்ளடக்கவில்லை என்று கருதினால்). IAM இன் இந்த உலகளாவிய தன்மை மிகப்பெரிய நேர மிச்சமாகும் மற்றும் உங்கள் வளரும் AWS இருப்பு முழுவதும் நிலையான அணுகல் கட்டுப்பாடுகளை பராமரிக்க உதவுகிறது. நினைவில் கொள்ளுங்கள் - IAM உலகளாவியதாக இருந்தாலும், சில resource-based policies மற்றும் service-linked roles க்கு பிராந்திய பரிசீலனை தேவைப்படலாம், எனவே அதை உங்கள் விரிவாக்க சரிபார்ப்புப் பட்டியலில் வைத்திருங்கள்.

Service Control Policies

AWS Control Tower ஐப் பயன்படுத்தினால், நல்ல செய்தி உள்ளது - உள்ளமைந்த guardrails மற்றும் அவற்றுடன் தொடர்புடைய Service Control Policies (SCPs) Control Tower இல் செயல்படுத்தப்பட்டவுடன் எந்த புதிய region க்கும் தானாகவே அவற்றின் பாதுகாப்பை விரிவுபடுத்தும்! எனினும், தனிப்பயன் SCPs ஐப் பயன்படுத்தினால் (Control Tower அல்லது AWS Organizations இல்), புதிய region ஐ உள்ளடக்க அந்த policies களை கையேடாக புதுப்பிக்க வேண்டும். இது region-குறிப்பிட்ட controls அல்லது allowed-regions statements ஐப் பயன்படுத்தும் policies க்கு குறிப்பாக முக்கியம். எடுத்துக்காட்டாக, அனுமதிக்கப்பட்ட regions களை வெளிப்படையாக பட்டியலிடும் SCP இருந்தால், அந்த பட்டியலில் புதிய region ஐச் சேர்க்க வேண்டும், எடுத்துக்காட்டாக:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowedRegions",
            "Effect": "Deny",
            "NotAction": [
                "cloudfront:*",
                "iam:*",
                "route53:*",
                "support:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotLike": {
                    "aws:RequestedRegion": [
                        "ap-southeast-2",
                        "ap-southeast-4"  // Adding Asia Pacific (Melbourne) region
                    ]
                }
            }
        }
    ]
}

அந்த மாற்றங்கள் இல்லாமல் உங்கள் குழுக்கள் ஏன் ஆதாரங்களை launch செய்ய முடியவில்லை என்று யோசிக்கலாம். இந்த policy புதுப்பிப்புகளை உற்பத்தி சூழலில் முதலில் சோதிக்க நினைவில் கொள்ளுங்கள் - வாடிக்கையாளர் தாக்கத்தை குறைக்க நாங்கள் எப்போதும் விரும்புகிறோம்.

AWS Config

Service Control Policies போலவே, AWS Control Tower ஐப் பயன்படுத்தும் போது, Control Tower ஆதரிக்கும் எந்த புதிய region இலும் AWS Config தானாகவே செயல்படுத்தப்பட்டு கட்டமைக்கப்படுகிறது. எனினும், Control Tower இல்லாமல் Organizations வழியாக AWS Config ஐ இயக்கினால், அந்த பாதையை கையேடாக அமைக்க வேண்டும். இதன் பொருள் புதிய region இல் Config ஐ செயல்படுத்துதல், உங்கள் rules களை (தனிப்பயனானவற்றை மறக்காதீர்கள்!) deploy செய்தல் மற்றும் aggregators ஐ அமைத்தல் ஆகியவை. பல வாடிக்கையாளர்கள் இந்த செயல்முறையை தானியக்கமாக்க CloudFormation StackSets ஐப் பயன்படுத்துகின்றனர். தானியங்கி அல்லது கையேடு என்றாலும், உங்கள் governance மற்றும் compliance தேவைகளுக்கு நிலையான AWS Config coverage ஐ பராமரிப்பது முக்கியம்!

கூடுதல் பாதுகாப்பு சேவைகள்

AWS Security சேவைகள் பற்றியும் புதிய regions க்கு விரிவாக்கும் போது நீங்கள் தெரிந்துகொள்ள வேண்டியவை பற்றியும் ஆராய்வோம். உலகளாவிய அளவில் scoped IAM போலல்லாமல், பெரும்பாலான AWS Security சேவைகளுக்கு பிராந்திய rollout strategy தேவை - நீங்கள் செயல்படும் ஒவ்வொரு இடத்திலும் புதிய பாதுகாப்பு அலுவலகங்களைத் திறப்பது போல நினைத்துக் கொள்ளுங்கள்.

முதலில், பாதுகாப்பு குழுவைப் பற்றி பேசுவோம்: GuardDuty, Security Hub, Macie மற்றும் Detective. இந்த சேவைகள் ஒவ்வொன்றும் புதிய region இல் வெளிப்படையாக செயல்படுத்தப்பட வேண்டும். ஆனால் Organizations உடன் சுவாரஸ்யமான விஷயம் என்னவென்றால் - உங்கள் delegated administrator account settings உண்மையில் உலகளாவியவை. ஒரு பாதுகாப்பு சேவைக்கு delegated administrator ஆக ஒரு கணக்கை நீங்கள் நியமித்தவுடன், அந்த கணக்கு அனைத்து regions களிலும் அதன் சிறப்பு அதிகாரங்களை பராமரிக்கிறது.

எனினும், இன்னும் வேலை செய்ய வேண்டியுள்ளது. Delegated administrator கணக்கு இருந்தாலும், புதிய region இல் ஒவ்வொரு பாதுகாப்பு சேவையையும் செயல்படுத்த வேண்டும். எடுத்துக்காட்டாக, Security Hub உடன், உங்கள் delegated admin கணக்கு புதிய region இல் சேவையை செயல்படுத்தி பின்னர் member accounts இலிருந்து findings களின் aggregation ஐ கட்டமைக்க வேண்டும். GuardDuty க்கும் அதேதான் - உங்கள் delegated administrator நியமனம் தொடர்ந்தாலும், புதிய region இல் threat detection ஐ செயல்படுத்தி member accounts களை அதற்கேற்ப கட்டமைக்க வேண்டும்.

உதவிக்குறிப்பு: பல builders இந்த பிராந்திய செயல்படுத்தல் செயல்முறையை தானியக்கமாக்க AWS CloudFormation StackSets அல்லது பிற கருவிகளைப் பயன்படுத்துகின்றனர். Regions முழுவதும் நிலையான security controls களை பராமரிக்க automation முக்கியம் என்பதை நாங்கள் கண்டோம். உங்கள் தேவையான அனைத்து பாதுகாப்பு சேவைகளையும் செயல்படுத்தி கட்டமைக்கும் "new region security bootstrap" template ஐ உருவாக்குவதைக் கருத்தில் கொள்ளுங்கள் - உங்கள் எதிர்கால self நன்றி சொல்லும்!

Regional aggregation ஐ மறக்காதீர்கள்! Security Hub அல்லது GuardDuty ஐ மைய பாதுகாப்பு கண்காணிப்பு கருவிகளாகப் பயன்படுத்தினால், அந்த single-pane-of-glass view ஐ பராமரிக்க cross-region aggregation ஐ கட்டமைக்க விரும்புவீர்கள். நல்ல செய்தி என்னவென்றால், உங்கள் delegated administrator கணக்கை அமைத்து புதிய region இல் சேவையை செயல்படுத்தியவுடன், உங்கள் aggregation configuration இல் அதைச் சேர்ப்பது பொதுவாக சில clicks மட்டுமே.

தெரிவுநிலை பெறுதல்

புதிய regions க்கு விரிவாக்கும் போது கவனிக்க வேண்டிய சில அடிக்கடி கவனிக்கப்படாத ஆனால் மிக முக்கியமான சேவைகள் பற்றி பேசுவோம். உங்கள் பிராந்திய விரிவாக்கத்தைத் திட்டமிடும் போது, உங்கள் செயல்பாட்டு தெரிவுநிலை கருவிகளை மறக்காதீர்கள் - அவற்றுக்கும் கவனிப்பு தேவை. Resource Explorer, எங்கள் பயனுள்ள unified search சேவை, உங்கள் அனைத்து AWS ஆதாரங்களின் ஒருங்கிணைந்த view ஐ பராமரிக்க விரும்பினால் உங்கள் aggregator settings இல் புதிய regions களைச் சேர்க்க வேண்டும். இதேபோல், IAM Access Analyzer, உங்கள் permissions guardian, புதிய region இல் செயல்படுத்தப்பட்டு விரிவான permissions insights ஐ பராமரிக்க உங்கள் aggregation configuration இல் சேர்க்கப்பட வேண்டும். CloudWatch Logs ஐ மறக்காதீர்கள்! Cross-account, cross-region centralized logging ஐப் பயன்படுத்தினால், புதிய region ஐ உள்ளடக்க உங்கள் log routing மற்றும் replication settings களை புதுப்பிக்க வேண்டும். உதவிக்குறிப்பு: பல builders centralized logging account ஐ உருவாக்கி ஒற்றை source of truth ஐ பராமரிக்க CloudWatch Logs cross-region observability sink ஐப் பயன்படுத்துகின்றனர். இந்த aggregation configurations களை உங்கள் regional expansion runbook இல் ஆவணப்படுத்த பரிந்துரைக்கிறோம் - எதிர்கால நீங்கள் இந்த அனைத்து படிகளையும் ஒரே இடத்தில் வைத்திருப்பதை பாராட்டுவீர்கள்!

என்ன விடுபட்டுள்ளது?

அந்த புதிய region க்குள் குதிப்பதற்கு முன், உங்கள் AWS சேவை இருப்பு பற்றி பேசுவோம். வெற்றிகரமான பிராந்திய விரிவாக்கத்திலிருந்து backwards work செய்து, உங்கள் AWS சேவை footprint இன் விரிவான மதிப்பீட்டை உருவாக்க விரும்புவீர்கள். வெளிப்படையான சேவைகளுக்கு அப்பால் சிந்தியுங்கள் - நிச்சயமாக, நிறுவன சேவைகள், பாதுகாப்பு மற்றும் compliance கருவிகள், கண்காணிப்பு மற்றும் logging configurations பற்றி நாங்கள் விவரித்தோம், EC2 மற்றும் S3 பற்றி நீங்கள் அறிவீர்கள். ஆனால் அந்த Route 53 health checks, AWS Backup plans அல்லது மாதங்களுக்கு முன் நீங்கள் அமைத்த AWS Private Certificate Authorities பற்றி என்ன? உங்கள் முக்கிய உள்கட்டமைப்பு மற்றும் ஆதரவு சேவைகளை உள்ளடக்கிய சேவை checklist ஐ உருவாக்குங்கள். உதவிக்குறிப்பு: நீங்கள் தற்போது பயன்படுத்தும் அனைத்து சேவைகளையும் கண்டறிய AWS Resource Explorer அல்லது AWS Config ஐப் பயன்படுத்துங்கள் - சில மறந்த பொக்கிஷங்களை நீங்கள் கண்டுபிடிக்கலாம்! ஒவ்வொரு சேவைக்கும், அது global, regional அல்லது குறிப்பிட்ட regional configuration தேவையா என்பதை ஆவணப்படுத்துங்கள். இந்த மதிப்பீடு உங்கள் விரிவாக்க playbook ஆக மாறும், regions முழுவதும் நிலையான திறன்களை பராமரிப்பதை உறுதி செய்யும், அதே நேரத்தில் "அட, அந்த சேவையை மறந்துவிட்டோம்" தருணங்களை தவிர்க்கும். நினைவில் கொள்ளுங்கள், நன்கு திட்டமிடப்பட்ட பிராந்திய விரிவாக்கம் வெற்றிகரமான பிராந்திய விரிவாக்கம்!

Landing Zones தலைப்பில்

AWS landing zones கருத்து மற்றும் home region இன் முக்கிய பங்கு பற்றி ஆராய்வோம் - பல-region deployments ஐ நிர்வகிக்கும் எவருக்கும் இது முக்கியமான அறிவு!

உங்கள் AWS Landing Zone ஐ உங்கள் கிளவுட் தலைமையகமாகவும், home region ஐ உங்கள் முக்கிய அலுவலகமாகவும் நினைத்துக் கொள்ளுங்கள். AWS Control Tower ஐ முதலில் அமைக்கும் போது அல்லது தனிப்பயன் Landing Zone தீர்வை செயல்படுத்தும் போது, home region ஐ தேர்வு செய்கிறீர்கள் - இந்த முடிவு பலர் நினைப்பதை விட முக்கியமானது. "இங்கே தான் எங்கள் முக்கிய configurations வாழ்கின்றன!" என்று சொல்லும் கொடியை நடுவது போன்றது!

உங்கள் home region இல், Control Tower மற்றும் அதன் management கூறுகள் போன்ற முக்கியமான சேவைகள் அமைகின்றன. Account Factory configurations, audit log archives, deployment pipelines மற்றும் பிற அடித்தள சேவைகள் இதில் அடங்கும். உங்கள் Landing Zone ஐ புதிய regions க்கு விரிவுபடுத்தும் போது, அசல் home region இல் உங்கள் தலைமையகத்தை பராமரிக்கும் அதே நேரத்தில் கிளை அலுவலகங்களைத் திறப்பது போன்றது. புதிய region governance controls களை பெறுகிறது மற்றும் முழுமையாக பயன்படுத்தப்படலாம், ஆனால் முதன்மை configurations மற்றும் management கூறுகள் home region இல் தங்கும்.

உங்கள் Landing Zone இன் home region ஐ மாற்றுவது உங்கள் default AWS Console region ஐ மாற்றுவது போன்றது அல்ல. வணிகத்தை சீராக நடத்தும் அதே நேரத்தில் உங்கள் நிறுவனத்தின் தலைமையகத்தை புதிய நகரத்திற்கு மாற்ற முயற்சிப்பது போன்றது. முக்கிய சேவைகளை decommission செய்து மீண்டும் deploy செய்ய வேண்டும், logging aggregation ஐ மறுகட்டமைக்க வேண்டும், நிறுவன configurations களை மறுகட்டமைக்க வேண்டும், automation pipelines ஐ மீண்டும் உருவாக்க வேண்டும். Control Tower இன் configuration data, audit logs மற்றும் AWS Organizations management போன்ற இந்த சேவைகளில் பல home region உடன் இறுக்கமாக இணைக்கப்பட்டுள்ளன.

Home region ஐ மாற்றுவது பொதுவாக என்னவெல்லாம் உள்ளடங்கும் என்பதை சித்தரிப்போம்:

• தற்போதைய home region இல் Control Tower ஐ decommission செய்தல்
• முக்கிய account structures ஐ மறுகட்டமைத்தல்
• IAM Identity Center configuration ஐ decommission செய்து மீண்டும் deploy செய்தல்
• Logging மற்றும் audit architectures ஐ மீண்டும் கட்டமைத்தல்
• Automation மற்றும் pipeline configurations ஐ மீண்டும் deploy செய்தல்
• Cross-account மற்றும் cross-region service configurations ஐ மறுகட்டமைத்தல்
• Historical data மற்றும் archives ஐ migrate செய்தல்

இதனால்தான் உங்கள் home region ஐ தேர்ந்தெடுப்பது "இரண்டு முறை அளந்து, ஒரு முறை வெட்டு" முடிவுகளில் ஒன்றாகும். உங்கள் நீண்ட கால புவியியல் உத்தி மற்றும் compliance தேவைகளுடன் ஒத்துப்போகும் home region ஐ தேர்ந்தெடுக்க பரிந்துரைக்கிறோம். புதிய regions க்கு விரிவுபடுத்துவது நேரடியானதாக இருந்தாலும், உங்கள் Landing Zone இன் home ஐ நகர்த்துவது கவனமான திட்டமிடல் மற்றும் செயல்படுத்தல் தேவைப்படும் குறிப்பிடத்தக்க முயற்சியாகும்.

உதவிக்குறிப்பு: உங்கள் Landing Zone ஐ வடிவமைக்கும் போது, உங்கள் home region dependencies களை முழுமையாக ஆவணப்படுத்துங்கள். அதை நகர்த்த திட்டமிடாவிட்டாலும், இந்த உறவுகளைப் புரிந்துகொள்வது புதிய regions க்கு விரிவாக்கும் போது சிறந்த கட்டிடக்கலை முடிவுகளை எடுக்க உதவும். உங்கள் home region தேர்வு பிற regions களில் செயல்படும் உங்கள் திறனை கட்டுப்படுத்தாது என்பதை நினைவில் கொள்ளுங்கள் - இது உங்கள் AWS சூழலுக்கான control center மட்டுமே.

முடிவுரை

முடிவாக, உங்கள் AWS Landing Zone அல்லது Organization ஐ ஒரு region க்கு விரிவுபடுத்த சிந்தனைமிக்க திட்டமிடலும் AWS சேவைகளின் பிராந்திய நடத்தைகள் பற்றிய விரிவான புரிதலும் தேவை. அடித்தள governance controls மற்றும் security சேவைகளிலிருந்து செயல்பாட்டு தெரிவுநிலை கருவிகள் மற்றும் Landing Zone பரிசீலனைகள் வரை முக்கியமான அம்சங்களை நாங்கள் விவரித்தோம். IAM மற்றும் CloudTrail போன்ற சில சேவைகள் தானாகவே புதிய regions களை ஏற்றுக்கொள்ளும் அதே நேரத்தில், மற்றவை வெளிப்படையான செயல்படுத்தல் மற்றும் கட்டமைப்பு தேவை என்பதை நினைவில் கொள்ளுங்கள். உங்கள் விரிவாக்கப் பயணம் நன்கு ஆவணப்படுத்தப்பட்ட சேவை இருப்பு மற்றும் உங்கள் Landing Zone இன் home region implications பற்றிய தெளிவான புரிதலால் வழிநடத்தப்பட வேண்டும். இந்த சிறந்த நடைமுறைகள் மற்றும் பரிசீலனைகளைப் பின்பற்றுவதன் மூலம், உங்கள் விரிவாக்கப்படும் AWS footprint முழுவதும் நிலையான பாதுகாப்பு, compliance மற்றும் செயல்பாட்டு சிறப்பை பராமரிக்க நீங்கள் நன்கு தயாராக இருப்பீர்கள். வெற்றிக்கான திறவுகோல் முழுமையான தயாரிப்பு, சேவை-குறிப்பிட்ட தேவைகளைப் புரிந்துகொள்வது மற்றும் வலுவான governance அடித்தளத்தை பராமரிப்பதில் உள்ளது. AWS அதன் உலகளாவிய உள்கட்டமைப்பை தொடர்ந்து வளர்க்கும் போது, இந்த கொள்கைகள் எதிர்கால பிராந்திய விரிவாக்கங்களுக்கு உங்கள் திசைகாட்டியாக செயல்படும்.